DEV Community: Faraz S.

RecallSloth: Your Medical Revision Queue Can Do the Sorting

Faraz S. — Sat, 24 Oct 2026 10:22:06 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

I wanted opening a revision app to end with one small choice: start.

No rearranging a deck. No deciding which chapter deserves attention. No reviewing the same fact twice because it appeared under two different headings.

RecallSloth is the little system I built around that idea: a medical revision desk that turns definition notes into source-linked recall cards, uses an open model to find overlapping explanations, and picks a short daily queue. A very contented sloth keeps it company.

What I Built

The intended user is a medical student or another learner revising physiology from their own trusted notes. The effort I want to remove is the repeated organization around studying: formatting definitions into cards, spotting duplicates, balancing due topics, and carrying unfinished sessions forward.

The flow is small enough to explain without a tutorial:

Import TXT/Markdown notes with one Term: definition per line.
Check and approve the extracted source cards.
Let the local AI overlap scout find explanations worth comparing. Confirm any groups yourself.
Choose a two-, five-, or ten-minute session and start recalling.
Reveal the exact source answer, self-rate, and let the due date move.

Every source card survives grouping. Each answer points back to the original note, line, character range and text checksum. Nothing invents a new medical explanation.

The sample contains twelve newly written pulmonary-physiology definitions grounded in NIH/NHLBI factual references. They are educational examples, not patient records or an endorsed curriculum. Your own course notes remain the authority for what you study.

Demo

Open RecallSloth →

The app runs on Render's Free plan. It can take a little time to wake after inactivity. The first local-model download needs internet; later cached runs can work offline.

Choose Try the sample notes, then Review & approve cards. Open Overlap scout and consent to the model download. Compare the proposed pairs; only group cards if they test the same fact, including direction and context.

Return to Today, set your budget, and start a queue. Think about the term, press Space to reveal its source answer, then use 1–4 to self-rate. The queue stops when its selected cards are done. There is no timer to race or streak to protect.

Close the tab halfway through and return: the unfinished session resumes from browser storage. If a rating was a misclick, undo it during that in-memory session. You can pause cards, separate a group, export a checksum-verified deck backup, restore it after confirmation, or clear the browser's study data.

The Lazy Payoff

In the sample, four learner-confirmed pairs turn twelve source cards into eight recall steps for a complete pass. All twelve originals remain inspectable.

At the app's illustrative estimate of 45 seconds per step, that is three fewer estimated minutes per full pass. It is arithmetic on a demonstration deck—not measured time saved or a learning-outcome claim. A daily session may cover only part of that deck.

The repeatable payoff is the routine: notes come in once, approved groups stay together, ratings update due dates, and the next queue respects the chosen budget. Taking a rest day does not erase progress. The system does the sorting again whenever you return.

Code

Source, tests, measured diagnostic, licenses and self-hosting instructions

npm ci --ignore-scripts
npm run dev

The application code is MIT. Model/runtime licenses and reused infrastructure code are credited separately.

How I Built It

Keep the answers attached to the notes

The card parser does one narrow job: extract explicitly defined terms from the learner's notes. It preserves each definition's exact source span. Unstructured prose without definition lines is rejected rather than converted into speculative questions.

The app checks a citation against its source before approval or study. A modified answer in an imported backup fails validation. Restoring a backup never replays session or history commands.

Notes, cards, groups, due dates and review history persist in local, unencrypted IndexedDB. A backup contains the source text, so it belongs somewhere private. This is personal study software; patient records should stay out.

Use an open model for the fuzzy part

The overlap scout runs Xenova/all-MiniLM-L6-v2, pinned to revision 751bff37182d3f1213fa05d7196b954e230abad9. Transformers.js loads quantized weights into ONNX Runtime Web and produces normalized 384-dimensional embeddings on WASM CPU.

It encodes the source definitions, compares cosine similarity, and offers the highest-ranking comparisons above an illustrative threshold. It generates no answers, approves no cards, and merges nothing automatically.

The most useful debugging result was a failure. Two gas-transfer definitions could look very similar to the model while describing different facts. A high cosine score was enough to justify comparison, but it did not establish equivalence.

I added a small contrast check that flags different gas terms, negation and numeric details, and moves flagged comparisons behind unflagged ones. Its vocabulary is deliberately limited. It cannot verify medical meaning, and every group still needs the learner's explicit confirmation.

Publish the misses too

The app includes a downloadable diagnostic: eight directional alias lookups across the twelve sample definitions, compared with Jaccard word overlap.

Method	Expected alias ranked first
Word-overlap baseline	4 / 8
Raw MiniLM similarity	5 / 8
MiniLM with the limited contrast ordering	6 / 8

The raw report includes every prediction, its source checksum, the pinned model and actual inference duration.

These examples were revised during development. The contrast check was added after observing related errors. This is not an independent holdout, and those numbers establish no general or medical accuracy. Even the contrast-aware version misses two expected aliases. Alternatives, source inspection and reversible learner decisions remain part of the product.

Let Render handle a very small tool

Render hosts the study-agent frontend, the queue-planning API, and the compressed inference runtime assets. The model and note text stay on the learner's device.

The queue tool receives only opaque card/topic/group IDs, due timestamps, lapse counts, estimated step durations and the time budget. The browser offers only approved, unpaused cards with valid source citations. The tool then:

keeps future cards out;
choose one representative per learner-confirmed group;
balance due topics within the budget;
return a visible tool trace and the selected IDs.

Its schema rejects extra fields and unbounded inputs. There is no note-upload endpoint or server database. The browser checks the result against the same deterministic planner running locally. If the service is waking or unavailable, the queue can still be built on-device. You can turn the server option off yourself.

The model loader, tokenizer files and runtime are pinned. Generic runtime assets are self-hosted with correct compression/MIME headers, and a service worker caches the app shell. The real browser check disables the network, reloads the stored deck, runs actual model inference again, and starts an on-device queue.

Test the quiet details

A fresh Linux CI run passed the build and complete software checks. The repository includes 26 unit/API tests and 21 browser checks covering source fidelity, grouping, schedule boundaries, undo, persistence, keyboard controls, backup tampering, mobile layouts and offline use.

A unique synthetic private marker in a test note never appears in outgoing request URLs or bodies. The browser test uses real embeddings and synthetic actions; model responses are not mocked. It runs in its own isolated browser profile, never a signed-in user's existing browser.

The interval ladder is intentionally transparent: Again is one minute; Hard, Good and Easy increase the interval at different rates, capped at 365 days. A grouped card moves its confirmed siblings together. This is a simple prototype schedule, not a validated retention model or a claim of mastery.

Why Does Open Innovation Matter?

The open model can do the fuzzy comparison on a laptop CPU while the note text stays in the browser. There is no inference API key, per-definition API charge or GPU dependency. The learner can inspect a failure, keep an alternative separate, and continue with cached assets offline.

The surrounding rules are open too. Someone can change the queue budget, examine the contrast vocabulary, replace the scheduling ladder, or evaluate another embedding model without depending on a hosted model's hidden behavior.

There are still practical limits. First use downloads generic assets; providers can see ordinary connection metadata; browsers can evict caches; and Render's Free service sleeps and shares workspace allowances. Local storage is unencrypted, and backups contain notes. The current deployment is a free educational prototype, with no clinical use, student trial, retention validation or measured educational outcome.

Prize Categories

Best Use of Render — the single partner category I am entering. Render serves the study-agent frontend, strict queue tool, and self-hosted runtime assets, with a functioning on-device fallback.

Credits

Built by @faraz_s_0a6e70a4bbdc6622 with AI coding assistance. The cover was generated with OpenAI's built-in image tool; the exact prompt and saved asset paths are included. Screenshots show the actual app.

The generic pinned browser-model loader, WASM compression and service-worker patterns are adapted from my earlier ReferralGlass project and credited in THIRD_PARTY.md. RecallSloth's study workflow, source-card parser, overlap/contrast controls, grouping, scheduler, IndexedDB store, UI and tests were written for Week 3.

Factual background for the newly written sample: National Heart, Lung, and Blood Institute; National Institutes of Health; U.S. Department of Health and Human Services. No agency endorsement is implied. No agency images, logos or formatted publications are reproduced.

What part of setting up a revision session would you most like to hand over to a sloth?

ReferralGlass: An AI Referral Desk That Shows Its Work

Faraz S. — Sun, 18 Oct 2026 06:32:56 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

“The imaging report is still pending.”

Put that sentence inside a referral packet and a semantic search for investigation reports will find a convincing match. The office still needs the actual report.

That small distinction became the center of ReferralGlass, a medical-office paperwork agent I built for this week's challenge. It finds relevant passages, opens their source pages, and asks a person to decide whether the requested paperwork is actually there. Every checklist begins with zero automatic approvals.

What I Built

ReferralGlass is a referral-packet desk for a small independent practice. Its intended user is the coordinator preparing documents for a receiving specialist office: several files, an office-specific checklist, and a handoff that another person needs to understand.

The workflow is deliberately concrete:

Import PDFs, text files, or scans. PDF extraction and English OCR run locally.
Describe the receiving office's paperwork requirements, including optional age limits.
Run a small open model in the browser to locate candidate passages.
Inspect the exact extracted quote, file, page, and original page image.
Confirm each source manually, then export a review or draft a request for missing paperwork.

AHRQ's referral guidance provided useful background on organizing a referral and its relevant information. The six bundled checklist items are illustrative office rules, not an official clinical checklist.

The buyer hypothesis: an independent practice could pay for reusable checklists, private packet preparation, consistent handoffs, and support. I would test $29/month per office as a starting price. That is an unvalidated hypothesis: there is no active subscription, paying customer, clinic pilot, or measured time-saving claim.

The first validation step would be a consented pilot with de-identified packets, measuring staff time, missed paperwork, corrections, and willingness to pay. The prototype provides a working workflow to evaluate before making those promises.

Demo

Open ReferralGlass →

The live version runs on Render's free web-service plan. It may take a little time to wake after inactivity. A recent desktop browser works best for the first model download; the interface also fits a phone.

Try the missing-report scenario:

Choose Try a sample packet. The four fictional files contain six pages.
Choose Find evidence and allow the one-time generic model download. No account or inference key is required.
Open Investigation reports. The closest passage explicitly says the report is pending. Attempting to confirm it opens an explanation and leaves the item outstanding.
Inspect the other source pages and confirm them. Each confirmation requires an acknowledgement that the passage belongs to this packet and meets this office's requirement.
Open Prepare handoff. The missing-paperwork request follows the staff decisions. Save the source-linked JSON or print/save a PDF locally.

The original-page viewer makes extraction checkable. The bundled two-page sample PDF also gives you a safe way to try real PDF import and scan reading. Every example is explicitly fictional.

There is a complete-packet example too, along with manual source selection, checklist import/export, and an activity record. Changing files, dates, or the checklist clears earlier findings and confirmations so stale decisions do not silently survive an edit.

Code

Source, setup instructions, tests, licenses and measured reports on GitHub

npm ci --ignore-scripts
npm run dev

The application is MIT-licensed. The open model and supporting engines retain their own licenses, which are documented and distributed with the runtime.

How I Built It

A compact model, close to the documents

The model is Xenova/all-MiniLM-L6-v2, pinned to revision 751bff37182d3f1213fa05d7196b954e230abad9. Transformers.js runs its quantized weights through ONNX Runtime Web on WASM CPU. It produces normalized 384-dimensional embeddings for the office's requirements and the source passages.

The index preserves a document reference, page number, exact character range, and SHA-256 of the source file. Clicking a citation resolves the passage against the current extracted text. A changed passage cannot become a valid citation. For PDFs and OCR, “exact” means the extracted text: the original page remains available because extraction can be wrong.

The agent then runs a bounded plan: inspect ranked candidates, flag uncertainty or quality problems, present the sources, and wait for staff. It does not generate a clinical summary. The missing-paperwork message is assembled from the unconfirmed required checklist items, so it stays tied to the review state.

The Render boundary

Render hosts the agent frontend, the stateless review planner, and the compressed PDF/OCR/inference runtime assets. Keeping the language model on the user's device lets the server operate within a small free instance while avoiding a document-upload workflow.

The planner request contains only a short internal requirement ID and candidates like this:

{
  "ref": "d0:p1:c0",
  "score": 0.5134,
  "absence": false,
  "dateIssue": false,
  "ocr": false,
  "weakOcr": false
}

No names, filenames, document text, checklist descriptions, images, or source quotes are needed. Imported checklist IDs are replaced with internal IDs before use. The API rejects unknown fields and unbounded inputs; there is no upload endpoint, session database, or application request-body logging.

A raw cosine score describes similarity, not confidence that an office requirement has been met. Closely competing sources, explicit missing-document language, low OCR quality, and office date limits remain visible. Those heuristics are illustrative and can fail; source inspection is essential.

Every response records autoApproved: 0 and nextAction: "staff_review". A visible activity record shows the steps. If Render is waking or unavailable, the same planner runs locally. You can also turn off the server planner yourself.

What the real tests caught

The first browser run revealed that the inference runtime tried loading an external JavaScript module that the site's content policy blocked. I self-hosted the exact matching runtime and compressed its large WASM binary; its gzip transfer is about 6.8 MB.

Later, visiting the retrieval lab exposed a service-worker bug: the lab's page could overwrite the main app's offline cache entry. Navigation responses now retain their own request keys. The browser check visits both pages, disables the network, reloads, and runs actual inference again.

The SDK also probed an unpinned metadata URL while discovering tokenizer files, which broke offline startup. The loader now constructs the public feature-extraction pipeline with the exact pinned tokenizer assets. The browser test checks every model request against the immutable revision.

These are the reasons I wanted executable checks and real source images alongside the polished interface.

What I measured

The retrieval lab compares MiniLM with a TF-IDF cosine baseline on 24 fixed synthetic cases, each with one target passage and five other document types. Both methods receive the same requirements and text. The corpus was fixed before the first run, and all predictions are published.

Method	Top-1 matches on this fixture
Local MiniLM semantic retrieval	21 / 24
TF-IDF cosine baseline	21 / 24

The aggregate is a tie. MiniLM finds one paraphrased referral example that the lexical method misses; it also confuses an administrative example that TF-IDF gets right. Both miss two other cases. The raw report includes those failures.

This is a small software fixture, not clinical accuracy or evidence of better real-world performance. It supports keeping alternatives and manual source selection available, and keeping human confirmation mandatory.

A fresh Linux GitHub Actions run passed the build and the complete software checks. The repository includes 24 passing unit/API tests and 26 passing browser checks in the full browser report. The browser checks use actual local embeddings, real PDF parsing, actual English OCR, source confirmations, JSON and A4 PDF exports, mobile layouts, and offline reload. A unique synthetic private marker never appears in outgoing request URLs or bodies. Staff actions are automated with fictional records; clipboard behavior is stubbed during the test.

Why Does Open Innovation Matter?

An open local model makes the data boundary possible. The browser can encode a document without sending its text to an inference provider, inspect the ranking, and continue with cached assets offline. The same small planner is readable, testable, and runnable on the device or on Render.

It also makes the business hypothesis easier to test. There is no per-document inference API charge or GPU requirement in this prototype. A practice could self-host the code, change its checklist, inspect a failure, or replace the model. Model swaps would need fresh evaluation rather than an assumption that larger means better.

There are still ordinary hosting and download costs and limits. First use downloads roughly 50 MB of generic model/runtime assets; OCR adds its assets when needed. Hugging Face and Render can see normal connection metadata. Browser caches can be evicted, and free Render services sleep and share workspace allowances. This is a prototype deployment, not a production healthcare hosting or compliance claim.

Documents and review state stay in browser memory; exports contain excerpts and need an approved secure workflow. There is no clinical validation, automatic patient identity reconciliation, diagnosis, urgency assessment, treatment recommendation, or automatic sending. A real deployment would need a separate assessment with the practice and appropriate specialists.

Prize Categories

Best Use of Render — the single partner category I am entering. Render serves the agent's frontend, bounded score-planning API, and self-hosted runtime assets, with an on-device fallback when the service is unavailable.

Credits

Built by @faraz_s_0a6e70a4bbdc6622 with AI coding assistance. The cover was generated using OpenAI's image tool; the exact prompt and provenance are in the repository. Screenshots show the real application with fictional data.

Generic deployment and browser-cache experience from my earlier Stillroot and ASCEND projects informed the setup. ReferralGlass is a new project built during this challenge window, with a new ingestion, evidence, planning and review workflow. Third-party licenses and source credits are included.

If you work with referral packets, which paperwork requirement would you want your office's first checklist to include?

ASCEND: A Solo Levelling Anime Based App To Turn a Small Walk into a Real-World Quest with Local Gemma

Faraz S. — Thu, 08 Oct 2026 11:37:28 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge: Week 1 — Touch Grass.

A nearby park can feel ordinary. Give it a mysterious gate, a small story, and a leaf-eared companion waiting at the end, and the same walk becomes an adventure.

That is the idea behind ASCEND. The next level is somewhere outside your front door.

What I Built

ASCEND is a browser-based outdoor quest game. It combines the anticipation of anime progression with the joy of finding things in the real world. You start at E-rank, finish small adventures, collect original companions, unlock trophies, and gradually work toward S-rank.

The game begins with your location and the time you have. It finds nearby parks, gardens, outdoor artwork, viewpoints, and other eligible places in OpenStreetMap, with a separate Wikidata fallback for urban parks, monuments, and fountains. Gemma runs on your device and writes a short fantasy atmosphere for the mapped destination. The story also helps choose a bounded observation prompt for a discovery quest.

There are three ways to explore:

Quest	What you do	Reward
Reach a gate	Walk to one mapped place and check in	100 XP
Make a discovery	Arrive, photograph something you notice, and write a few words	150 XP
Follow a trail	Check in at three places in order	250 XP

Your first completed quest unlocks Fernfox. Later adventures introduce a moss-covered tortoise, a luminous moth, a moonlit owl, an ember salamander, and an astral fawn. They are original characters with original generated artwork.

Companions are earned through completed quests. Rehearsal rewards stay separate from real-world rankings.

There is no streak punishment. A quiet walk tomorrow is still welcome if you missed today.

Demo

Play ASCEND

Start with Try the rehearsal to explore all three quest types without GPS, camera permissions, or an account. Its places and arrivals are explicitly fictional, and its scores never enter the global leaderboard.

For a real quest, choose Find my next quest, allow location, and select an adventure. Try the local Gemma writer, read or listen to the briefing, then open the pocket guide. At the checkpoint, reopen the app and check in.

The pocket guide has large controls for repeating the briefing, pausing, and checking in. Installed device voices can read the briefing. Optional browser recognition supports commands such as “repeat,” “status,” “pause,” and “check in.” No ElevenLabs is used. When a browser lacks voice support, the same actions are available on screen.

Browser GPS pauses when the page is hidden or the phone is locked, so ASCEND asks you to reopen at checkpoints. The phone helps launch the adventure and record its ending; the walk happens between those moments.

Code

Source, setup, tests, and deployment configuration

Explore the quest engine, Gemma worker, or deployment configuration. The README includes the commands to run it yourself.

The code is MIT-licensed. The generated art has its own attribution instructions, and downloaded model weights retain Gemma’s terms.

How I Built It

A story layer grounded in an actual map

The map service uses OpenStreetMap Overpass, with bounded provider fallbacks. A real deployment test exposed unavailable Overpass gateways, so I added an independent Wikidata lookup for urban parks, monuments, and fountains. Its bounded query searches the local area before following category relationships, then checks known indoor, dissolved, and future locations. Broad residential-garden and amusement-park categories are excluded.

Searches are cached and shared across concurrent explorers. Known private and indoor OpenStreetMap tags are filtered out. Access information and the original OpenStreetMap or Wikidata item remain visible because a mapped place is not proof that it is open or reachable by a pedestrian route.

Gemma writes the story; a separate quest engine pins the destinations, objectives, and XP. The model cannot invent a destination or grant rewards. Long, code-like, or unsuitable narratives fall back to a clearly labelled curated briefing.

The small model taught a useful lesson: a complicated formatting prompt could produce code or an overly dramatic story. A short request for two peaceful fairy-tale sentences worked better. I kept the output guard even after improving the prompt.

Local Gemma, measured rather than assumed

The app uses Gemma 3 270M, Transformers.js, and ONNX Runtime in a worker. WebGPU is used when available; a separately pinned compatible model revision supports WASM on CPU. The first use downloads hundreds of megabytes, so the app explains that before loading.

A genuine browser inference produced this line:

The Lantern Garden whispered secrets as the sun warmed the mossy leaves, a gentle breeze rustled the silver petals of the flowers.

On the tested browser, generation took 5.1 seconds. The first model download plus generation took 98.5 seconds. Those are measurements from one machine, not a promise for every phone. The full prompt, output, revision, and timings are recorded in the inference report.

The CPU fallback was tested with WebGPU disabled: 33.1 seconds for generation and 170.4 seconds including the first download, on the same computer. Its separate report records actual WASM inference.

Large model downloads also exposed interrupted CDN transfers during testing. The loader now fetches pinned artifacts in verified 8 MiB ranges, retries interrupted chunks, and rejects mismatched revisions. This made both real GPU and CPU runs complete.

The model’s narration is fictional. The report confirms that generating it left the checkpoint coordinates unchanged.

Render for the shared game, the device for private memories

The frontend and Express API run on Render. The release configuration uses a free web service and free Postgres in Singapore. Reward updates use database transactions, including protection against duplicate simultaneous check-ins. Explorer state and world rankings are stored in Render Postgres.

GPS check-ins require a recent fix, acceptable accuracy, and proximity to the checkpoint. Previously completed destinations disappear from suggestions for 24 hours. Trail checkpoints must be completed in order.

World rankings are opt-in and publish an alias with aggregate game statistics. They do not expose destinations or photos. Camera images and the latest 30 journal memories remain in the device’s IndexedDB; the server receives photo metadata rather than pixels. A private session export lets you restore access to your explorer.

Render’s free service can take about a minute to wake, and its free Postgres expires after 30 days. The README documents those limits and the need to export or migrate before expiry. This entry uses free services and no paid AI API.

What I actually verified

33 automated tests cover auth, GPS validation, camera metadata, progression, cooldowns, duplicate rewards, map caching and backoff, and Postgres rollback and cleanup.
19 browser scenarios cover the quest flows, camera capture, companions, trophies, rankings, session export/restore, journal deletion, and every screen at 390 px width.
The deployed API returned 18 real mapped landmarks near a public central London test coordinate and created a grounded quest without claiming an outdoor visit or reward.
A private explorer and its active quest survived a service restart with Postgres. The live deployment report records the checks; no test XP was added to public rankings.
Gemma’s inference ran for real in the browser; its measured output is linked above.

The browser suite uses simulated GPS and a synthetic camera feed. Voice-command actions were tested with a synthesized transcript. Audible local speech and live microphone transcription still need testing on a physical phone. I have not claimed an outdoor field trial, and browser-reported GPS remains spoofable: these rankings support friendly play.

Why Does Open Innovation Matter?

A location-aware game can easily become another stream of private information sent to a remote model. Open weights let ASCEND generate its story on the explorer’s device. The prompt does not need a hosted AI endpoint, a per-story charge, or an AI API key.

OpenStreetMap and Wikidata supply inspectable destinations. Transformers.js and ONNX Runtime make browser inference practical. The quest engine is readable, so someone can change reward rules, add companions, swap a model, or host their own version.

Local inference does not make the whole app offline: new map lookups and shared rankings still need a connection. It does let the creative part run locally after the model is downloaded, on a capable device. That is a useful boundary for a game built around stepping outside.

Build Notes and Credits

ASCEND’s new repository, gameplay, API, databases, interface, artwork, and tests were built during this Week 1 window. Local-model compatibility work draws on my earlier Stillroot experiments. The anime progression and location-collecting inspirations are acknowledged; no Solo Leveling or Pokémon game assets are used.

Codex assisted with implementation, testing, and this write-up. The cover and companion illustrations were generated for this project; their prompts and provenance are documented.

Prize Categories

Best Use of Gemma: genuine device-local Gemma inference writes the grounded adventure’s fantasy story and contributes to the discovery focus.
Best Use of Render: Render hosts the playable frontend and shared quest API, with Postgres for explorer progression and rankings.

Your next gate might be a garden you have walked past a hundred times. Bring a little curiosity. Fernfox will meet you there.

Stillroot: a quiet plan companion for my friend

Faraz S. — Sat, 03 Oct 2026 11:08:20 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

I built Stillroot, a quiet plant-care companion for my friend Rohan.

The project is built around an everyday dilemma: a few plants on a windowsill, an upcoming weekend away, and the question, "Will someone need to check the soil while I'm gone?"

It's set up as a working gift prototype. The demo comes preloaded with sample data for a pothos, monstera, and basil so anyone can take it for a spin before Rohan connects his real sensors.

Stillroot focuses on three things:

A 7-day moisture forecast with an estimated range.
A care plan that adapts to how long he'll be away, plus a ready-to-share note for a friend who's house-sitting.
A compact, on-device Gemma companion that explains the forecast in plain English.

The interface is intentionally simple: one plant, one forecast, and one clear action. If a sensor reading looks stale, the app flags it before making any predictions. And if dry soil is forecasted while he's traveling, it suggests asking a friend to check on the plant instead of guessing a generic watering schedule.

Demo

Open Stillroot on Render

Try this quick walkthrough:

Choose Basil and slide Days away to 7. The status updates to ASK FRIEND.
Turn on Simulate a stale sensor reading to see it switch to VERIFY SENSOR.
Turn that off and click Before I water to watch Gemma generate advice locally in your browser.
Head to Try your own CSV history and upload the included sample file to see custom predictions in action.

Note: Since this runs on Render's free tier, the demo may take around a minute to spin up if it hasn't been visited recently. Gemma downloads on the first run (~350 MB on WebGPU, ~850 MB on CPU fallback) and is cached in your browser for subsequent visits.

Code

GitHub: faraz-shamim/stillroot

The repository includes the frontend app, local prediction runtime, dataset generator, forecast experiments, raw benchmark files, and deployment config. Application code is MIT licensed; TabPFN and Gemma retain their respective licenses.

To run it locally:

npm ci
npm run build
python -m pip install -r requirements.txt
python -m uvicorn backend.app:app --host 127.0.0.1 --port 8000

Open http://127.0.0.1:8000. The README includes instructions for reproducing the TabPFN experiments and running predictions on custom CSVs.

How I Built It

TabPFN provides the forecast

I used Prior Labs' TabPFN v2 running on CPU, feeding it historical soil moisture, temperature, humidity, light hours, pot size, and days since watering to predict the next reading.

To evaluate accuracy, I benchmarked it across 294 rows of data spanning 42 watering cycles, split cleanly by full cycle (196 train / 49 calibration / 49 test) so readings from the same drying cycle never leaked across splits.

Model / Baseline	Error (MAE in relative moisture points)
TabPFN v2	0.4890 MAE
Mean training-drop baseline	0.9766 MAE
Last-reading baseline	6.2986 MAE

TabPFN cut prediction error by roughly 50% compared to the mean-drop baseline, achieving 91.8% empirical coverage on a 90% prediction interval.

The hosted demo serves precomputed TabPFN outputs for fast load times and a light Render footprint, while the local Python runtime allows running TabPFN directly on custom CSV uploads.

You can view the measurement report, dataset card, and experiment code in the repo.

Gemma makes the numbers understandable

Google's Gemma 3 270M instruction model runs right inside the user's browser via a Web Worker using Transformers.js and ONNX Runtime. The app packages the plant's recent telemetry and current care signal into a concise prompt, and the model explains the situation conversationally. Because inference runs client-side, sensor data never leaves the device.

On WebGPU, Gemma answers questions like "What should I check before I water?" in about 7.9 seconds.

One practical detail from the build: the latest embedding operator worked smoothly on WebGPU but broke under WASM. Pinning an earlier compatible conversion resolved the issue for the CPU fallback. Deterministic logic always guides the signal, so the AI focuses on explaining the plan clearly rather than making unpredictable watering decisions.

Render makes it easy to give away

A lightweight FastAPI service on Render's free plan serves the frontend, static prediction assets, and care-policy endpoints. Because Gemma runs directly in the client and TabPFN runs locally during development, the backend stays lean and doesn't need PyTorch or heavy model dependencies in production.

The full stack runs reliably on $0 in infrastructure costs and API fees.

Why Does Open Innovation Matter?

For this gift, openness means Rohan actually understands how his plant monitor works.

Nothing is hidden behind a black box: the care logic is a short, transparent function, the forecast model and benchmarks are easy to inspect, and Gemma runs directly on his hardware without relying on an external API or sending personal home data over the wire. If he wants to tweak the thresholds, test a new plant, or build a version for someone else, the whole system is his to modify.

Open weights and open tooling made it possible to build an intelligent, responsive assistant that costs nothing to run and respects user privacy by design.

Prize Categories

Best Use of TabPFN — Fast, tabular time-series forecasts evaluated on cycle-aware splits with solid baseline gains.
Best Use of Gemma — A 270M open-weight model running entirely in the browser via WebGPU/WASM for private, on-device guidance.
Best Use of Render — A clean full-stack deployment combining FastAPI and static frontend assets on a free-tier web service.

Stillroot: a quiet plant companion for my friend Rohan

Faraz S. — Sat, 03 Oct 2026 10:52:52 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

I built Stillroot, a quiet plant-care companion for my friend Rohan.

The project is built around an everyday dilemma: a few plants on a windowsill, an upcoming weekend away, and the question, "Will someone need to check the soil while I'm gone?"

It's set up as a working gift prototype. The demo comes preloaded with sample data for a pothos, monstera, and basil so anyone can take it for a spin before Rohan connects his real sensors.

Stillroot focuses on three things:

A 7-day moisture forecast with an estimated range.
A care plan that adapts to how long he'll be away, plus a ready-to-share note for a friend who's house-sitting.
A compact, on-device Gemma companion that explains the forecast in plain English.

Demo

Open Stillroot on Render

Try this quick walkthrough:

Choose Basil and slide Days away to 7. The status updates to ASK FRIEND.
Turn on Simulate a stale sensor reading to see it switch to VERIFY SENSOR.
Turn that off and click Before I water to watch Gemma generate advice locally in your browser.
Head to Try your own CSV history and upload the included sample file to see custom predictions in action.

Code

GitHub: faraz-shamim/stillroot

To run it locally:

npm ci
npm run build
python -m pip install -r requirements.txt
python -m uvicorn backend.app:app --host 127.0.0.1 --port 8000

Open http://127.0.0.1:8000. The README includes instructions for reproducing the TabPFN experiments and running predictions on custom CSVs.

How I Built It

TabPFN provides the forecast

I used Prior Labs' TabPFN v2 running on CPU, feeding it historical soil moisture, temperature, humidity, light hours, pot size, and days since watering to predict the next reading.

Model / Baseline	Error (MAE in relative moisture points)
TabPFN v2	0.4890 MAE
Mean training-drop baseline	0.9766 MAE
Last-reading baseline	6.2986 MAE

TabPFN cut prediction error by roughly 50% compared to the mean-drop baseline, achieving 91.8% empirical coverage on a 90% prediction interval.

The hosted demo serves precomputed TabPFN outputs for fast load times and a light Render footprint, while the local Python runtime allows running TabPFN directly on custom CSV uploads.

You can view the measurement report, dataset card, and experiment code in the repo.

Gemma makes the numbers understandable

On WebGPU, Gemma answers questions like "What should I check before I water?" in about 7.9 seconds.

Render makes it easy to give away

The full stack runs reliably on $0 in infrastructure costs and API fees.

Why Does Open Innovation Matter?

For this gift, openness means Rohan actually understands how his plant monitor works.

Open weights and open tooling made it possible to build an intelligent, responsive assistant that costs nothing to run and respects user privacy by design.

Prize Categories

Best Use of TabPFN — Fast, tabular time-series forecasts evaluated on cycle-aware splits with solid baseline gains.
Best Use of Gemma — A 270M open-weight model running entirely in the browser via WebGPU/WASM for private, on-device guidance.
Best Use of Render — A clean full-stack deployment combining FastAPI and static frontend assets on a free-tier web service.