DEV Community: Rehan Mehta

My laptop has no GPU, so I gave it the night shift

Rehan Mehta — Thu, 22 Oct 2026 06:23:31 +0000

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

What I Built

I built Later, a small open-source tool that reads the screenshots you took "for later" while you sleep, and hands you a morning digest of what you meant to remember.

My screenshots folder did not need more screenshots. It needed someone to read it.

It had 575 files, the oldest from January 2024. Every one was taken with the same quiet promise: I'll deal with this later. Later never came, because the files are all called Screenshot_20261020-213412.jpg and nobody opens them.

So now an open-weight model on my own laptop opens them, one by one, overnight. In the morning:

Do these. Deadlines, exams, events and tickets sorted by date. "Friday 11:59 PM" in a Tuesday group chat becomes Fri 23 Oct, 23:59, in 2 days, with a calendar button and a reminder the day before.
Saved for someday. Articles, recipes, products, places, error messages, loose to-dos.
Shred pile. Expired OTPs, memes, duplicates. Nothing is deleted. You decide.
Search by meaning. "That Wi-Fi password." "Train to Pune."
Tidy, with undo. Screenshot_20261020-213412_Chat.jpg becomes Deadlines/2026-10-23 DBMS assignment 3 deadline.jpg. One command puts everything back.
Demo

Later runs on your own laptop and opens as a web page on 127.0.0.1. Nothing is hosted, because the whole point is that your screenshots never leave your machine.

The repo includes later demo-pack, which writes synthetic screenshots (fake OTPs, a fake chat about a deadline, a recipe, a train ticket) so you can try everything without exposing anything real. I did not put my own screenshots in the demo, because they contain OTPs and private chats.

git clone https://github.com/Rehan1604/hackw4.git
cd hackw4
pip install -r requirements.txt
ollama pull gemma3:4b
ollama pull embeddinggemma
python -m later doctor
python -m later demo-pack demo_screenshots --add
python -m later sleep --now --limit 5
python -m later

The last command opens the morning digest in your browser: the night strip, the Do these list, search, and the tidy preview.

Code

Rehan1604 / hackw4

Later

A sloth that reads the screenshots you took "for later" while you sleep.

Screenshots are the laziest note-taking system ever invented: two buttons and the problem feels handled. Then the file sinks into a folder of a thousand others called Screenshot_20261020-213412.jpg, and later never comes.

Later is the lazy second half. Point it at your screenshots folder and go to bed. Overnight, on your own laptop, an open-weight model (Gemma 3) reads every screenshot, one at a time, and works out what you meant to remember. In the morning you get:

Do these: deadlines, exams, events and tickets, sorted by date, each one click away from your calendar (.ics, with a reminder the day before a deadline).
Saved for someday: the articles you meant to read, the earbuds you meant to buy, the recipe, the café, the plumber's number, the error message.
Shred pile: expired OTPs…

View on GitHub

How I Built It

Everything runs on the laptop, with no cloud account and no API key:

Gemma 3 4B (vision) through Ollama reads each screenshot and returns structured JSON.
EmbeddingGemma turns each result into a vector for search by meaning.
Tesseract OCR reads small text exactly.
SQLite (FTS5 for keywords) stores everything. FastAPI serves the digest on 127.0.0.1, and the page is plain HTML, CSS and JavaScript with no build step.

My laptop is an Intel i5 with integrated graphics and 16 GB of RAM. On it, Gemma 3 4B averages about 33 seconds per screenshot. In a chat app that would be unusable. For a job that runs while I sleep it does not matter, so I designed around it. The sloth has rules.

Work while I'm not. later sleep --until 07:00 waits until the keyboard has been quiet for a few minutes, stays off a draining battery, and lowers Ollama's CPU priority. later schedule sets it up once as a nightly Windows task that wakes the laptop.

Never lose your place. Every screenshot is keyed by a hash of its contents, not its name. Kill it, reboot, rename the files: it resumes where it stopped.

Don't read anything twice. A 256-bit perceptual hash spots near-duplicates. If the OCR text matches too, the copy reuses the earlier answer with no model call.

Trust, but verify. Ollama's structured outputs constrain Gemma to a JSON schema, so kind is always one of fifteen known values and every field is present:

python
body = {
"model": "gemma3:4b",
"messages": [
{"role": "system", "content": SYSTEM_FULL},
{"role": "user", "content": prompt, "images": tiles}, # tiles + OCR transcript
],
"format": SCHEMA, # kind is an enum, every field required
"stream": False,
"options": {"temperature": 0, "num_ctx": 4096},
}

A valid shape is not a correct answer, so plain Python checks the content afterwards. Relative dates resolve against when the screenshot was taken, so "Friday" in a Tuesday chat means that Friday. A date years away is dropped. A meme does not get a to-do.

Two locks on the secrets. A screenshot counts as private if the model says so or a deterministic check fires: OTP wording next to a code, a card number that passes the Luhn checksum, ID numbers, balances, password: lines, lab-report terms. Digits are then masked in the database, thumbnails are blurred on the server, and the full image is sent to the browser only after you click Reveal.

The night strip. The digest opens with proof of the night's work: a band that shades from night to dawn, one bar per screenshot, as tall as the seconds it took. While the sloth works you can watch the bars appear. It is a progress bar that is honest about being slow. The page loads no external fonts, scripts or images.

Here is the shape of what the model returns for a chat screenshot (an illustrative example):

json
{
"kind": "deadline",
"title": "DBMS assignment 3 deadline",
"summary": "Group chat says the DBMS assignment is extended to Friday 11:59 PM.",
"action": "Submit it on the portal",
"date": "2026-10-23",
"time": "23:59",
"sensitive": false,
"keep": true,
"tags": ["dbms", "assignment", "deadline"]
}
What broke along the way

Four things broke, and each one taught me something.

I optimised the wrong thing

My first runs took 60 to 110 seconds per screenshot. I assumed the image was the cheap part and the text was the cost, and I sliced every tall screenshot into two tiles to be sharper. Then I wrote a benchmark instead of guessing. On my CPU, one image takes Gemma about 30 seconds to read, while 450 tokens of text take 1.6 seconds. Extra tiles doubled the cost for almost nothing once OCR was in the loop.

So Tesseract now reads every screenshot first. If it finds plenty of text, Gemma gets the transcript and never sees the pixels: about 20 seconds. A map, a meme or a photo still gets the image: about 55. Thread count barely mattered either (12 threads took 28 s, 4 took 37 s).

The model invented dates

On my first 41 screenshots, Gemma attached a date to 27. That sounded great until I looked: most were ordinary notes and AI chats with no date anywhere on the screen.

I added one rule. A date has to be backed by the screenshot's own text: a month and day, a numeric date, or a word like "Friday" it can resolve. Re-checking the stored results removed 23 of the 27. The 4 that survived were real. A model that sounds confident about a deadline is more dangerous than one that says nothing.

My "reset" did not reset

I had mixed my synthetic demo screenshots into my real database, so I deleted the data folder to start clean. The folder did not exist. Python from the Microsoft Store virtualises %LOCALAPPDATA%, so my files were somewhere else entirely. The fix was boring: set LATER_HOME to a normal folder and keep a separate home for demos. My real data and my demo data can no longer touch.

The terminal closed in the middle of the night

I woke up to a closed terminal. Because the queue is keyed by file hash and resumes by design, I re-ran one command and it carried on. One screenshot had failed once and read fine on the retry. That is the whole reason the sloth saves its place after every single screenshot.

What I would do next

Honest limits, so you know what you are getting:

A 4B model makes mistakes. The validation catches invented dates and missed secrets, not every wrong summary. The privacy checks are a safety net, not a guarantee, so look before you share a folder.
It is tuned for English-heavy screenshots from my own phone and laptop. I have not tested other scripts.
The scheduling and keep-awake pieces are Windows-only. The rest should run anywhere Ollama does, but I have only tested Windows.
The tests use a fake Ollama server. They check the plumbing (resume, duplicates, privacy, digest order, calendar files, tidy and undo, the web API). They cannot judge the model. Only real screenshots can, which is what the numbers below are for.

The idea I most want next: let the digest learn which things I actually open and which I always dismiss. If you build it, contributions are very welcome.

Why Does Open Innovation Matter?

Because screenshots are the most private files you own. They hold OTPs, bank balances, lab reports and your friends' messages. The people in those group chats never agreed to be uploaded anywhere. With an open-weight model, "your data stays on your laptop" is enforced in code: Later refuses to talk to a model server that is not on the same machine unless you explicitly switch that check off.

Because slowness is free when the weights are yours. A hosted vision API bills per image and is built to answer in a second, which is speed I do not need. On my own laptop, a slower night costs nothing. Open weights let me spend time, which I have plenty of overnight, instead of money.

Because I can change the brain. One environment variable swaps in gemma3:12b on a machine with more memory. I can cap threads, change how often the image is used, and use EmbeddingGemma's task prefixes for search. None of that is a feature request to anyone.

Because it works when nothing else does. No internet, no key to leak, no deprecation email. The model only changes when I choose to pull a new one.

Where closed would have won: a frontier hosted model would read messy screenshots more accurately, and in a second rather than 33. I narrowed that gap with OCR and validation and accepted the rest. The privacy gap is the one I could not have closed any other way.

The Lazy Payoff

Setup took a few minutes, once. After that, I pointed Later at my real folder and went to bed. These numbers come straight from python -m later stats:

575 screenshots, oldest from January 2024. 574 were read by the model and 1 was recognised as a duplicate with no model call. 527 were read in a single run of 4 h 51 min while I slept.
5 h 13 min of CPU work, 32.8 seconds per screenshot, about 10.6 tokens per second. 473,770 tokens read, 75,701 written. Total cost: some electricity.
What was in there: 211 code and error screenshots, 118 "other", 108 chats, 58 loose to-dos, 46 things to read, 15 contacts. Only 17 had a real date and 1 was a true deadline. My folder is not full of deadlines. It is full of things I wanted to find again, which is why search matters more than the calendar button.
45 screenshots were flagged private, blurred and digit-masked.
By hand, at around 20 seconds each (my estimate), that is about 3 h 11 min of opening, reading and deciding. The honest number is higher, because I never did it. The oldest screenshot has been sitting there for almost two years.

If you have a screenshots folder you are afraid to open, give it to a sloth.

Prize Categories

Best Use of Gemma. Gemma 3 4B reads every screenshot (vision plus schema-constrained JSON), and EmbeddingGemma powers search by meaning. Both run locally through Ollama on a laptop CPU.

__ This project comes from a human. AI helped with its design and code.

QuoteShield: Turn a Client's WhatsApp Message into a Watertight Scope of Work published: true

Rehan Mehta — Wed, 14 Oct 2026 19:40:35 +0000

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

What I Built

Every freelancer has had this message:

"Need an app that tracks my clients — who owes me money, project status, invoice dates. Simple UI, maybe mobile friendly too. Nothing too fancy."

"Nothing too fancy" usually turns into three extra screens, a login system, "can you also host it?", and six rounds of "small changes". Most of the work you never get paid for comes from scope creep, and scope creep comes from a scope nobody wrote down.

QuoteShield fixes that. You paste whatever the client sent you (a WhatsApp message, a rambling email, a voice-note transcript) and in a few seconds you get a professional scope of work:

Deliverables specific enough that both sides know when each one is done. Not "Shop page" but "E-commerce shop page with product grid, category filters, cart and Razorpay checkout".
Milestones with testable outcomes instead of "Development".
A "Not Included" list, which does most of the protecting: hosting, SEO, copywriting, post-launch support, everything a client quietly assumes is free.
Binding assumptions that name what the client must deliver and by when.
An hours estimate and a revision policy that defines what actually counts as a revision.

You can choose a tone (Professional, Friendly or Strict), add your hourly rate to see a live cost range, add your own constraints ("I only do React, no SEO"), and copy the result as plain text or Markdown to paste straight into a proposal.

It also gives each scope a health score out of 100 based on how complete it is, so you can see a thin one before you send it.

Who pays for this? Freelancers and small agencies who quote work every week. One avoided scope argument pays for a year of a small subscription.

Demo

🔗 Live: https://quoteshield-ten.vercel.app

Try one of the built-in examples, or paste a real client message you've received.

Code

Rehan1604 / quoteshield

⚔️ QuoteShield

Paste a chaotic client brief — a WhatsApp message, a rambling email, a voice-note transcript — and get a professional scope of work in seconds: specific deliverables, testable milestones, a thorough "not included" list, binding assumptions, an hours estimate and a revision policy.

Live: https://quoteshield-ten.vercel.app

Stack

Frontend: React + Vite (Vercel)
Backend: FastAPI (Render)
AI: open-weight gpt-oss-20b on Groq, with automatic fallback to gpt-oss-120b

Run locally

Backend

cd backend
pip install -r requirements.txt
# get a free key at https://console.groq.com
export GROQ_API_KEY=your_key        # PowerShell: $env:GROQ_API_KEY="your_key"
uvicorn main:app --reload --port 8000

Frontend

cd frontend
npm install
# point at your local backend (defaults to the hosted one)
echo VITE_API_URL=http://localhost:8000 > .env.local
npm run dev

Deploy

Render (root backend): build pip install -r requirements.txt, start uvicorn main:app --host 0.0.0.0 --port $PORT, env var GROQ_API_KEY. Optional GROQ_MODELS to override the model list.
Vercel (root frontend): framework…

View on GitHub

How I Built It

Frontend: React + Vite with CSS Modules, deployed on Vercel. A dark UI with the tone selector, rate calculator, example briefs and the scope document view with its health score.

Backend: FastAPI deployed on Render. It does more than pass the request along:

A strict prompt. The model gets seven rules: no vague words like "premium" or "clean" without defining them, every milestone needs a testable outcome, assumptions must name who delivers what and by when, and so on. This is the biggest factor in output quality.
A model fallback chain. The backend tries gpt-oss-20b first and falls back to gpt-oss-120b. The list is an environment variable, so swapping models takes no code change.
JSON mode with a retry. It asks for structured JSON. If the model rejects JSON mode or returns something that won't parse, it retries in plain mode, then moves to the next model.
Output normalization. LLMs sometimes return "60-80" for hours, an object where a string should be, or "exclusions" instead of "not_included". The backend reshapes everything into one fixed schema, so the frontend never gets a broken scope.

Render hosts the API. A pinned .python-version keeps builds reproducible, the Groq key lives in Render's environment settings, and the frontend sends a wake-up ping to the Render service when the page loads, so the free tier's cold start is usually over before the user clicks Generate.

The road here (the part I learned the most from)

QuoteShield started fully local: Mistral 7B on Ollama, on my laptop's CPU. The output was decent, but each scope took 60–90 seconds and nobody else could use it.

So I moved inference to an open-weight model on Groq, and a lot broke along the way:

Render picked Python 3.14, which had no prebuilt pydantic-core wheel, so the build tried to compile Rust and failed. Pinning Python 3.11 fixed it.
CORS preflight requests got 400 until the middleware was set up correctly.
The Groq SDK clashed with the installed httpx version (unexpected keyword argument 'proxies'), so I dropped the SDK and call the API directly.
The first model I switched to had already been decommissioned, and so had the second one.

That last one is why the fallback chain exists. A product that depends on one hosted model ID can break without notice, so the code now expects models to come and go.

Why Does Open Innovation Matter?

No lock-in. I've had a model retired out from under me twice while building this project. Because QuoteShield runs on open-weight models, a retirement is a config change. If a provider drops a model or changes its pricing, I can point at another host or run the same weights myself. With a closed model, the provider's decision would end the product.

I can go back to running it myself. The first version ran on Mistral 7B entirely on my laptop. A freelancer who doesn't want client briefs leaving their machine can do the same thing, because open weights make that possible.

The costs work for a small product. gpt-oss-20b costs fractions of a cent per scope. That means I could offer a free tier and still charge a cheap subscription without losing money on every request, which is what a side project needs.

The weights are inspectable. With open weights you can fine-tune on your own past proposals so scopes match how you quote. That's the next step for QuoteShield.

Doorstep: The AI That Gives You 45 Seconds, Then Tells You to Go Outside

Rehan Mehta — Thu, 08 Oct 2026 10:34:14 +0000

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

Every app wants more of your time. Doorstep wants 45 seconds.

What I Built 🌿

Doorstep is a mission app that is designed to be closed. You tell it how much time and energy you have. An open-weight model running on your own laptop writes you one small outdoor mission. You get 45 seconds of screen to read it. Then the app goes black, says PHONE DOWN, and you go outside.

When you come back, you type what surprised you, say how you felt, and get two honest sentences back. There is no feed, no chat, no streak and no leaderboard. The app succeeds when you stop using it.

And it learns. The longer you use it, the better it gets at choosing the kind of mission that actually leaves you feeling good, and it tells you why.

Demo

The demo was recorded on localhost, with Wi-Fi switched off mid-take. Missions kept coming because the model runs on the laptop.

🌐 Try it fast: doorstep-alpha.vercel.app. This is a hosted demo: it calls a hosted model, so the privacy and offline claims below do not apply to it. The free server sleeps, so the first request can take about a minute.

Code

Rehan1604 / doorstep

🌿 Doorstep

The AI app that is over the moment you cross your own doorstep.

Doorstep writes you one small outdoor mission with an open-weight model, gives you 45 seconds of screen to read it, then goes black and sends you outside.
It learns what works for you. In local mode, nothing leaves your machine.

🌐 Live demo · 📝 DEV post · 🧠 The ML · 🔒 Privacy · 🏗 Architecture

The problem

Apps are built to keep you looking at them. Even the ones that say they want you outside keep you scrolling inside.

The idea

A hard screen budget. Every mission gives you 45 seconds to read it. When the bar hits zero, Doorstep goes black: one instruction, one timer, PHONE DOWN. You go outside. When you come back you type what surprised you, say how you felt, and get two honest sentences back.

No feed…

View on GitHub

How I Built It

Step 1: Local first, because of what the app knows

Doorstep handles where you walk, what you notice, and how you feel. That is exactly the kind of data I don't want to send to a stranger's server. So the default path is:

React UI → FastAPI → Ollama → Qwen2.5-1.5B-Instruct → SQLite, all on one laptop. My machine is an Intel i5-13420H with 16 GB of RAM and no GPU.

Step 2: Pick the model with a benchmark, not a vibe

I wrote a benchmark that asks each model for 10 missions and checks the JSON, the safety screen and the clock. On my CPU-only laptop:

Model	Valid JSON	Safe output	Median	p90
qwen2.5:1.5b-instruct ✅	100%	100%	11.4 s	13.7 s
phi3.5	100%	100%	29.4 s	41.4 s

Both were reliable, so speed decided it. Eleven seconds is still a long wait, so I turned it into a breathing screen instead of a spinner. The delay now reads as part of the design.

Step 3: Never let the model break the app

Model output is constrained to a JSON schema, validated, retried twice, and screened for unsafe suggestions (climbing, private property, wildlife contact). If the model is down, slow, or wrong, the app serves a hand-written fallback mission and labels it OFFLINE-SAFE MISSION.

Step 4: Make the AI do something a dictionary can't

A reviewer's fair point: a Python dictionary of tasks could do what the LLM was doing. So I added three pieces of ML that actually depend on you.

🎯 A style bandit. Missions have styles (stillness, sensory hunt, close-up, detour, and so on). A small contextual Thompson-sampling bandit learns which style leaves you feeling best. It is pure Python, runs offline, and the card explains each pick: "Close-up has left you feeling better in 3 of 4 missions."

I tested it against random choice with a simulation (500 synthetic people, 20 missions each):

Simulated people	Random picks their favourite	Bandit picks it
Stable taste	20%	43%
Different taste per context	20%	25%

It helps clearly when taste is stable, and barely when taste changes by context. That is a real limit, and it is in the docs.

🧭 An embedding novelty guard. Each mission is embedded and compared by meaning to your recent ones. A near-repeat gets regenerated once, and the card shows how new it is.

🧠 Private semantic memory. Your notes are embedded locally. When you finish a mission, related earlier notes are retrieved so the reflection can connect today to before: a grey heron by the river, then weeks later another heron near the water.

Step 5: A hosted demo, with honest labels

Judges shouldn't need to install Ollama to try the idea, so I deployed a demo: Vercel (React), Render (FastAPI) and Groq's API with gpt-oss-20b. The top status strip tells the truth in both modes: AI: LOCAL · DATA: LOCAL on my laptop, AI: READY · DATA: CLOUD on the hosted site.

🔎 Tip: A Silent Fallback Can Hide a Real Bug

Hosted missions kept coming back as "OFFLINE-SAFE", and nothing crashed, which is exactly why I nearly missed it. I found two problems. In hosted mode I was never telling the model the JSON field names, because JSON mode doesn't enforce a schema. And the provider could reject JSON mode with a 400 whose reason httpx hides. Now the schema goes into the prompt, the call retries once without JSON mode, and the provider's error text is logged. If you build a fallback, make it loud in your logs.

🔎 Tip: Stored Text Is Untrusted Text

The model's own earlier output and the user's notes get put back into later prompts. I strip anything that could break out of a one-line prompt before it goes in. It is cheap and it closes a real prompt-injection path.

Why Open Innovation Matters

A closed API would have made this a different app. Because the model, the embedder and the server are open:

The data stays home. Notes about your walks never leave the laptop in local mode.
It works where there is no signal. A park, a trail, a train. The Wi-Fi-off moment in the demo is real.
I could choose. I benchmarked two models and swapped them with one environment variable.
I could read everything. Every prompt is in one file, and the safety screen is code I can inspect.

One honest nuance: the hosted demo also uses an open-weight model, but through someone else's server, which gives up the privacy advantage. Open weights give you the choice. Local mode is what makes that choice private.

Summary

🟢 One small mission, 45 seconds of screen, then the app gets out of the way.
🟢 Runs on a CPU-only laptop with no GPU: ~11 s per mission on qwen2.5:1.5b-instruct.
🟢 A bandit that learns what works for you, an embedding novelty guard, and private semantic memory.
🟢 29 backend tests and 7 frontend tests.
⚠️ A 1.5B model writes valid but often generic missions.
⚠️ The bandit needs several missions to adapt and barely helps when taste varies by context.
⚠️ The safety screen is keyword-based and can't guarantee safety.
⚠️ The hosted demo sends your input to third parties and can reset its data.

Scope: one laptop (i5-13420H, 16 GB RAM, CPU only), 10 benchmark runs per model, a synthetic bandit simulation, and self-testing only. No user study has been run, and the optional voice-note feature was not part of the demo.

The best AI interaction is the one that ends with you leaving the room.

References

"My local model called a flagged result 'within range', so I stopped letting it do arithmetic"

Rehan Mehta — Sat, 03 Oct 2026 07:18:04 +0000

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

The first time I asked a local model to explain a lab report, it told me a result the report had flagged as high was "within the reference range". I ran the same prompt again and got a different answer.

I was building Plain-Words for Bhavya, a classmate. When a confusing document lands in their family, they ask the family doctor if it's medical, and upload it to Google and try to work it out themselves if it isn't, which they described as very stressful. A tool meant to make that less stressful can't be wrong about the one thing that matters. So most of this project is about what the model isn't allowed to decide.

What I Built

Plain-Words takes a photo, PDF or pasted text of a document and gives back a plain-language explanation. For a lab report, that's:

a short summary of which results fall outside the range printed on the report
one key point per result, tagged "Above listed range" or "Within listed range"
a glossary of the terms and units
specific questions to ask a doctor
all of it again in Hindi, because that's what an older relative might read

There's a history with a delete button and a thumbs up/down on every explanation.

The version I built and tested runs entirely on my laptop with a local model, and nothing leaves the machine. I also put a hosted demo online, which works differently (see below).

Demo

Live demo: https://plain-words-ox04ps1vb-rehan-6df9.vercel.app?_vercel_share=9PNLhyXGNTZ4cv3g2bGr6V9km6pcsXW2

The hosted demo sends text to a server and to an AI provider, so use it with the fictional sample report only. There's a "Try the fictional sample report" button on the first screen. Photo reading may not work there.

The first version, which Bhavya tested (fictional sample report):

No real patient data is in the repo, the screenshots or this post.

Code

https://github.com/Rehan1604/plain-words

MIT-licensed. The Gemma model keeps its own terms.

How I Built It

The front end is React and Vite. Behind it is FastAPI, with Tesseract for photos, SQLite for history and a model behind a small LLMProvider interface.

phone browser → FastAPI → PDF text / Tesseract OCR
                           ├→ range parser (plain code): above / below / within
                           └→ LLMProvider → Gemma 3 4B (local, Ollama): glossary + Hindi glossary
                          → SQLite

The decision that matters most is what the model doesn't get to do. My first attempts simply asked Gemma to explain a sample HbA1c report. On a report that flagged the result high, it told me it was within the reference range, and in a bare prompt it drifted into diet advice. A small model on a CPU isn't a reliable number comparer.

So the app doesn't ask it to. A parser reads each result and the reference range printed next to it, and plain code decides above, below or within. That output becomes the summary, the key points and the doctor questions, with no model involved. The model only writes the glossary, and the Hindi version of it. For documents with no numbers, like a notice or a form, the model writes the summary instead. That path is less reliable, and I haven't tested it much.

Each glossary entry quotes a line from the document, and the code checks the line really appears there. That proves the quote exists, not that the explanation is right. The meanings are the model's general knowledge and can be wrong.

The local model. Gemma 3 4B through Ollama, on the CPU. I'd planned around having a GPU, but the laptop I built this on has only Intel UHD graphics (i5-13420H, 16 GB RAM). The 4B model at 4-bit quantization ran at about 12.7 tokens per second, which is slow but usable. I compared it with Qwen 2.5 3B, which was faster at about 15.9 tokens per second. Its Hindi was gibberish: it talked about an injection and "five to ten months" for a blood sugar value that had neither in it. For a tool that's supposed to calm someone down, that settled it.

Gemma comes under Google's own Gemma Terms of Use, not a standard open-source license, so I call it open-weight, not open-source.

The hosted demo. Because everything sits behind LLMProvider, the hosted option was a new provider class plus a few config values, selected with one environment variable (LLM_PROVIDER=groq). The backend runs on Render and calls openai/gpt-oss-20b, an open-weight model, through Groq. I haven't measured speed or Hindi quality on that model, so every timing and Hindi claim in this post is about local Gemma.

Speed (local). After I added the guardrails, a full run took 262 seconds. I'd made the model write a summary, key points and doctor questions, then replaced all of it with code anyway. Leaving only the glossary to the model brought it to about 35 seconds. The Hindi step fell from 52 to about 19 seconds for the same reason.

There are 10 automated tests: the range parser, the Hindi templates and the API round trip with a fake model. I checked the photo path, the real model output and the Hindi quality by hand.

Why Does Open Innovation Matter?

Privacy, when you run it locally. A lab report is the kind of document I'd hesitate to paste into a cloud service. In the local version the photo, the extracted text and the history stay on one machine. The hosted demo gives that up, which is why it carries a warning and I only use the fictional report there.
Cost. The local version has no API bill and no account. A student laptop is enough.
Picking and swapping the model. I put Gemma and Qwen side by side on the same task and chose the one that handled Hindi. Later I added a hosted open-weight model behind the same interface without touching the rest of the app.
Designing around the weaknesses. The model is swappable and runs where I choose, so I could build around what it gets wrong instead of waiting for a better release.

Testing It With Bhavya

Bhavya tried the local version on an Android phone over Wi-Fi, using the sample report (fictional data) and the in-app camera. What follows is paraphrased from their written feedback, which they cleaned up afterwards, so none of it is a direct quote:

It worked. The OCR read most of the text, though a couple of numbers and formatting spots were harder.
They waited and wondered whether it was still processing.
They found the result much easier to understand than the original report.
The Hindi sounded natural rather than word-for-word, and leaving some medical words in English was fine. They thought it would help parents and grandparents.
They had to ask what the "ask your doctor" lines meant, and I explained they weren't a diagnosis. They also weren't sure at first whether the numbers were normal until they read below.
They'd use it again for blood-test reports, prescriptions and relatives' documents, to get the meaning without looking up every word.
They suggested a clearer progress state, and said to keep the warning to check the original document.

One tester and one sample document, so I wouldn't call this validation.

What Changed After That

Bhavya's feedback (paraphrased)	What changed
Wondered whether it was frozen during the wait	Spinner and a "still working, not frozen" message, plus a note that photos take longer
Wasn't sure if numbers were normal until reading below	An "Above / Within listed range" badge on every result, instead of color alone
Had to ask what the doctor lines meant	A one-line "not a diagnosis" note under that heading, in English and Hindi
Photos can misread numbers; keep the check-the-original warning	A panel showing the exact text read from the photo, with a note to compare it against the paper

Afterwards I also redesigned the interface (range bars, summary counts, a one-tap sample button, dark mode). That wasn't based on Bhavya's feedback, and Bhavya hasn't seen these changes yet.

What I Got Wrong

I let the model write the whole explanation, then replaced most of it with code anyway. That was the 262-second version.
I asked the model to write Hindi for sentences the code had already computed. It returned English. I switched to fixed Hindi templates for those parts.
Gemma sometimes fell into a repetition loop while writing JSON, and Ollama killed the request with a "token repeat limit reached" error. I capped the output length and retry when that happens.
One glossary entry in Hindi contradicted itself, saying "after eating" and "after not eating for 8 hours". The 8 hours wasn't in the report at all. I tightened the prompt against adding numbers, but it can still happen.
My test script looked dead because it printed nothing for over a minute, so I added a heartbeat line. Bhavya hit the same wall in the app.

What I Didn't Do

I haven't tested it on real reports, only a fictional sample, and only with one tester.
The parser handles two line formats. Other layouts fall back to the model alone, which is less reliable.
Bhavya was the only Hindi reader.
The glossary meanings are the model's general knowledge. Nobody has checked them against a medical source.
The hosted backend has no login or rate limiting, and its CORS setting is wide open. Anyone with the URL could call it, so the Groq key's usage is capped on their side.
I haven't measured the hosted model's speed or Hindi, and photo reading there is untested.
No staged progress bar yet (reading the photo, then explaining it).

Prize Categories

Best Use of Gemma. Gemma 3 4B, an open-weight model, runs locally through Ollama and writes the glossary, the Hindi glossary and the summary for documents without numbers. Code, not the model, compares the numbers, because Gemma got that wrong. (The hosted demo uses a different model, so to see Gemma in action, run the local version.)