DEV Community: Prakhar Agrawal

My Laptop Is Too Slow to Chat With an AI, So I Gave It the Night Shift

Prakhar Agrawal — Wed, 21 Oct 2026 17:21:38 +0000

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

What I Built

My Downloads folder is where files go to be forgotten. invoice (3).pdf. Screenshot 2026-10-12 141502.png. Document1.docx, which could be anything. Every few months I promise myself I'll clean it up, and every few months I don't.

So I built sloth, about 200 lines of Python that do it while I sleep. Every night it goes through my Downloads folder with Gemma 4 running on my laptop. It reads each document, looks at each image, gives the file a name a human would pick, and moves it into a folder. In the morning, a report is waiting:

invoice (3).pdf                  -> Finance/2026-10-01_acme_cloud_services_invoice.pdf
Document1.docx                   -> Work/2026-10-01_sprint_meeting_notes_prakhar_meera_jonas.docx
Screenshot 2026-10-12 141502.png -> Screenshots/2026-10-01_error_message_screenshot_python_app.png
export (1).csv                   -> Finance/2026-10-01_salary_and_transaction_report.csv
VSCodeUserSetup-x64-1.105.1.exe  -> Installers/VSCodeUserSetup-x64-1.105.1.exe
scan0001.pdf                     -> left alone (Gemma wasn't sure)

If I don't like what it did, python sloth.py undo ~/Downloads puts everything back.

Anyone with a Downloads folder gets to be a little lazier, which is everyone. It's especially for people whose laptop, like mine, has no business running AI.

Here's a real run on my test folder. Read the timings, because they're the point:

$ python sloth.py tidy ~/sloth-test
[1/13] 2409.11873v2.pdf -> Reading/2026-10-01_quantization_aware_training_paper.pdf (14s)
[2/13] data.bin -> left alone, unknown type
[3/13] Document1.docx -> Work/2026-10-01_sprint_meeting_notes_prakhar_meera_jonas.docx (13s)
[4/13] e-ticket.pdf -> Personal/2026-10-01_train_ticket_booking_confirmation.pdf (11s)
[5/13] export (1).csv -> Finance/2026-10-01_salary_and_transaction_report.csv (15s)
[6/13] image (2).png -> Images/2026-10-01_quarterly_revenue_by_region_report.png (21s)
[7/13] invoice (3).pdf -> Finance/2026-10-01_acme_cloud_services_invoice.pdf (11s)
[8/13] notes.txt -> Personal/2026-10-01_banana_bread_recipe_personal.txt (11s)
[9/13] photos_backup.zip -> Archives/photos_backup.zip (0s)
[10/13] resume_final2.docx -> Personal/2026-10-01_resume_final_dok_prakhar_a.docx (11s)
[11/13] scan0001.pdf -> left alone, not sure (9s)
[12/13] Screenshot 2026-10-12 141502.png -> Screenshots/2026-10-01_error_message_screenshot_python_app.png (19s)
[13/13] VSCodeUserSetup-x64-1.105.1.exe -> Installers/VSCodeUserSetup-x64-1.105.1.exe (0s)

The folder actually held 15 files. The other two are skipped on purpose: a boarding pass I'd downloaded that day (I might still need it) and a half-finished Ubuntu download.

Code

Prakhar0013 / sloth

sloth

Tidies your Downloads folder overnight with a local Gemma model, so you don't have to.

While you sleep, sloth reads each file (or looks at it, for images), gives it a real name, and files it into a folder. In the morning there's a SLOTH_REPORT.md waiting for you, and one command puts everything back if you don't like it.

invoice (3).pdf                   -> Finance/2026-10-01_acme_cloud_services_invoice.pdf
Screenshot 2026-10-12 141502.png  -> Screenshots/2026-10-01_error_message_screenshot_python_app.png
notes.txt                         -> Personal/2026-10-01_banana_bread_recipe_personal.txt
VSCodeUserSetup-x64-1.105.1.exe   -> Installers/VSCodeUserSetup-x64-1.105.1.exe
scan0001.pdf                      -> left alone (Gemma wasn't sure)

Everything runs on your machine through Ollama. No file, filename, or snippet ever leaves it.

Setup

You need Ollama and Python 3.9+.

ollama pull gemma4:e2b-it-qat
pip install -r requirements.txt

Use

python sloth.py tidy ~/Downloads --dry-run   # show the plan, move nothing
python sloth.py tidy ~/Downloads             # do it
python sloth.py undo ~/Downloads             # put the last run back

Run it every night

Windows (PowerShell)…

View on GitHub

How I Built It

The constraint. My laptop has an Intel Core i3-1215U, 8 GB of RAM and no graphics card. While I was testing, Windows had about 1 GB of memory free. Chatting with a model on this machine would be miserable: you type a question and go make tea.

But tidying files isn't a chat. Nobody is waiting for an answer at 2 a.m. That's the whole project: slow inference is fine when nobody's waiting for it.

The model. Gemma 4 E2B (gemma4:e2b-it-qat), served by Ollama. It's the smallest Gemma 4, a 4.3 GB download. The QAT build was trained to keep its quality after being squeezed down to 4 bits, which is what lets it fit in 8 GB. It can also see, so a screenshot gets named after what's in it, not after when I took it.

The pipeline, in the order the script runs it:

Skip what I might still need. Anything modified in the last 24 hours stays put, and so does any .crdownload or .part file.
Don't think unless you have to. Installers, archives, audio and video are sorted by extension and keep their names. The model is never called for them. A sloth saves its energy.
Read a little. The first two pages of a PDF (via pypdf), the text inside a .docx (which is just a zip of XML), the first 1,500 characters of a text file, or the whole image.
Hand Gemma a form, not a blank page. Ollama can force the reply to match a JSON schema, and the category field is an enum of eight folders. A 4.6B-parameter model can't invent a "Misc Stuff 2" folder, because the schema won't let it.
Never trust a model with a date. The 2026-10-01_ prefix comes from the file's timestamp. Gemma only supplies the words.
Write down every move as it happens. If the laptop dies at 3 a.m., undo still knows what went where.

The heart of it is a single HTTP request to Ollama:

body = {
    "model": "gemma4:e2b-it-qat",
    "messages": [message],  # prompt, plus the image as base64 if it's a picture
    "format": SCHEMA,       # category must be one of 8 folders
    "think": False,
    "stream": False,
    "options": {"temperature": 0, "num_ctx": 4096},
}

It uses no framework and no SDK, just the Python standard library plus pypdf.

The one line that made it 7 to 30 times faster. When I ran ollama show on the model, it told me something I didn't expect: Gemma 4 has a thinking mode, and it's on by default. I timed the same three files both ways:

File	Thinking off	Thinking on	Tokens generated (off / on)
`invoice (3).pdf`	8.7 s	59.8 s	31 / 533
`export (1).csv`	4.3 s	60.4 s	32 / 535
Screenshot of a Python error	2.7 s	91.7 s	23 / 667

It picked the same folder every time, and the same name for two of the three. On a CPU, 500 tokens of deliberating over whether an invoice is an invoice costs a full minute per file. So "think": False it is. Even a sloth has limits. (These timings come from a separate test. In full runs, with Windows fighting for memory, it takes 8 to 26 seconds per document and more than a minute for a large photo.)

The bug was in my test, not my code. My first prompt gave Gemma two example names: acme_cloud_invoice and python_import_error. The first run looked perfect. Then I noticed that my test folder contained an Acme Cloud invoice and a screenshot of a Python import error. I'd been grading the model on how well it could copy my examples. I swapped them for examples that match nothing in the folder (dentist_appointment_reminder, github_actions_failed_build). It still put every file in a sensible folder, so it really was reading them. Lesson learned: if your examples look like your test data, your test isn't testing anything.

What it still gets wrong. Some names are clumsy. banana_bread_recipe_personal repeats its own folder, and my résumé came out as resume_final_dok_prakhar_a (I have no idea what "dok" means). A scanned PDF with no text layer gets left alone, because all Gemma can see is the filename. That's the right call, but a smarter version would turn the page into an image and let Gemma look at it.

Why Does Open Innovation Matter?

Look at what's in a Downloads folder. My little test folder alone had a bank export showing a salary, a résumé, a train ticket with a booking number, and an invoice. My real one is worse.

A version of this tool built on a closed API would only work by uploading all of that, every night, to a server I don't control. I wasn't going to make that trade to save ten minutes of dragging files around. With Gemma running in Ollama, no file, filename or snippet ever leaves the laptop. I can turn the Wi-Fi off and it still works.

Then there's cost. It runs every night, on as many files as I've downloaded, for nothing. There's no API key, no rate limit, and no surprise bill if a bug makes it loop.

And there's control, three kinds of it:

I picked a model that fits my machine. I chose the size (E2B) and the quantization (4-bit QAT) specifically so it would fit in 8 GB of RAM.
I can swap it. The model is one constant at the top of the file. When a better small model comes out, upgrading is a one-line change.
I can share it. ollama show lists Gemma 4's license as Apache 2.0, so anyone can run sloth without signing up for anything.

Where open beat closed. A hosted frontier model would be faster per file, and it would probably come up with better names. But speed is the one thing this job doesn't need. At 2 a.m., one second per file and fifteen seconds per file both mean "done before I wake up." Once speed stopped mattering, everything that was left (privacy, cost, working offline, no account) pointed to the model on my own laptop.

My Agent Session

TODO: save the session with DevRelay and embed it here, or delete this section.

The Lazy Payoff

Test folders are polite. So I pointed sloth at my real Downloads folder, with --dry-run so it planned everything and moved nothing.

72 files were old enough to touch, going back to February.
36 would have been filed. Gemma read 31 of them and gave each a name, and 5 were sorted by extension alone.
3 were left alone because Gemma wasn't sure what they were. That's exactly what I want it to do when it can't tell.
33 were left alone because sloth can't read them yet: 25 Excel files, 6 PowerPoints, an old .doc and an .mpeg. Spreadsheets turned out to be the biggest kind of clutter in my real folder, and my test folder had none. That's the most useful thing the run taught me, and reading .xlsx and .pptx is next on the list. (Two of those "Excel files" were really Office lock files, ~$…. Sloth skips those now, and .mpeg now goes to Media.)

The whole folder took 11.5 minutes on the i3, with no GPU. Documents took 8 to 26 seconds each. The two images took 70 and 106 seconds, because big pictures are slow on a CPU. It's a lot of minutes, and I was asleep for all of them.

The best result was an ebook whose filename was a website prefix followed by six ISBNs. It came out as the_art_of_thinking_clearly_ebook. It also found two receipts and sent both to Finance, and it spotted two editions of the same book, filed under filenames that looked nothing alike, and gave them both the same clean title.

It made mistakes too. Two versions of the same report got identical names, so the only way to tell _v2 apart is the date prefix. El Niño became el_ni_o, because my filename cleaner threw away accented letters (my bug, not Gemma's, and it's fixed now). A WhatsApp photo got a name that just repeated its old filename. And it would have filed my coding agent's instruction file, CLAUDE.md, under Reading. To be fair, that's technically correct.

Opening 34 documents one at a time to work out what they are is exactly the chore I'd been putting off since February. Sloth did it in 11 minutes while I did nothing at all.

Prize Categories

Best Use of Gemma: Gemma 4 E2B runs locally through Ollama and does all of the reading. It reads documents, looks at screenshots, and decides each file's name and folder. Vision is what turns Screenshot 2026-10-12 141502.png into error_message_screenshot_python_app.png.

Paydar: my laptop reads my invoices and tells me which clients will pay late

Prakhar Agrawal — Thu, 15 Oct 2026 04:35:28 +0000

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

What I Built

Freelancers rarely go under for lack of work. They go under in the gap between doing the work and getting paid for it.

Meet Maya, the made-up illustrator in Paydar's demo. She has $25,440 in open invoices and $1,400 in the bank. On paper she's having a great month. In practice, Acme Retail always pays about two weeks late, her café client goes quiet at the end of every month when rent is due, and Orbit Media pays small invoices on time but sits on anything over $2,500 until a second manager signs it. None of that is written down anywhere except in her payment history, and none of it is visible from her invoicing tool, which only knows "due" and "overdue".

By the end of every month, maya gets to feel emptiness because of the lack of funds. These funds often lead her to taking debt for the time period till she gets her operational expenditure. To help her it was decided to build a project.

Paydar is a cash-flow radar for people like Maya. You drop invoices into a folder (PDFs, forwarded emails, phone photos) and it:

Reads them on your laptop with Gemma 4 (the 2B "E2B" model, about 4.3 GB), pulling out the client, dates, terms, total, and two details that turn out to matter: whether there's a PO number and whether the invoice mentions a late fee.
Predicts how each invoice will actually be paid with TabPFN, trained on your own payment history: the chance it lands more than a week late, and a likely pay-date range.
Projects your bank balance week by week, under an expected case and a "everyone drags their feet" case, so you see a tight week coming a month out instead of the morning rent bounces.
Drafts reminder emails timed to the risk. The trick I like most: clients who are likely to pay late get a friendly heads-up three days before the due date, not an awkward chase after it.

You can also just ask it things. "Can I afford a $1,500 laptop on November 3rd?" gets checked against the pessimistic forecast, not a gut feeling.

Who pays for this? Solo freelancers and two-to-five person studios who invoice a handful of repeat clients and live close to the line between invoices. Because every model runs on the user's own machine (or on a pseudonymized table, more on that below), my cost per customer is close to zero, so it can be priced like a small utility: "$6/month or a one-time $39" rather than another $30/month SaaS seat.

Demo

![Paydar dashboard]
The dashboard Paydar writes after every run. It's a single HTML file that works offline.

Code

Prakhar0013 / Paydar

Paydar

A private cash-flow radar for freelancers. Drop your invoices in a folder. A small Gemma model on your laptop reads them, TabPFN learns how each of your clients actually pays, and you get a week-by-week view of your bank balance, which invoices will land late, and reminder emails timed to go out before the slow payers slip.

Your invoice PDFs, client names and emails never leave your computer.

$ npm run radar
9 open invoices worth $25,440. About $25,440 should land in the next 30 days.
Likely late: Bluebird Café $640 (100%, expect ~2026-10-21); Acme Retail Group $7,400 (87%, expect ~2026-11-11).
Tight week ahead: if slow payers drag their feet, you'd be down to $14 in the week of 2026-10-26.
3 reminder emails drafted; first one goes out 2026-10-14.

(Output from the demo workspace with the offline baseline. Numbers change with Gemma + TabPFN.)

How it works

flowchart LR

…

View on GitHub

TypeScript, MIT licensed. npm run demo creates a synthetic freelancer with 184 paid invoices and nine open ones, so you can try it without your own data. The test suite (26 tests) runs with a fake Gemma and a fake TabPFN server, so CI needs no models or keys.

How I Built It

flowchart LR
  subgraph laptop["Your laptop"]
    inbox["inbox/ PDFs, emails, photos"] --> gemma["Gemma 4 E2B (Ollama)"]
    history["history.csv (paid invoices)"] --> feats["features + pseudonymizer"]
    gemma --> feats
    forecast["weekly cash forecast"] --> nudges["reminder drafts (Gemma)"]
    nudges --> report["offline dashboard"]
  end
  feats -->|"C01, C02… + numbers"| tabpfn["TabPFN-3.5 API"]
  tabpfn -->|"P(late), pay-date range"| forecast

Gemma 4 E2B, run locally with Ollama, does all the reading and writing. The interesting part was making a 2-billion-parameter model reliable at a form-filling job. Three things did it:

Constrained decoding. Ollama's format field takes a JSON Schema and constrains generation to it, so the model cannot return a malformed date or a missing field. I generate the schema from the same Zod object I use to validate the result, then re-validate anyway and retry once with the error message if something's off.
Thinking off. Gemma 4 reasons before answering by default. That's great for hard questions and pure waste for "what's the invoice date" on a laptop CPU, so Paydar sends think: false, after checking that the model reports thinking as a capability.
Code does the arithmetic, the model doesn't. Gemma extracts what's printed. Due dates from "Net 30", client-name matching ("Helix Labs Inc." is "Helix Labs" in your history), and sanity checks happen in plain TypeScript, and anything shaky becomes a visible warning rather than a silent guess.

TabPFN does the predicting. It's a tabular foundation model: you hand it your training table and it predicts in a single forward pass, no training loop, no hyperparameter tuning. That matters here because a freelancer's whole payment history is a couple of hundred rows, which is too little for most models to learn from and exactly where TabPFN shines. Paydar builds 17 features per invoice: the client's track record, their most recent payment, how big this invoice is compared with what they usually get, month-end timing, terms, and the PO and late-fee flags Gemma extracted. Then it makes two calls to the /tabpfn/* API with model_path: "v3.5_default": a classifier for "more than 7 days late?" and a regressor asked for the 10th, 50th and 90th percentile of days late. Those quantiles become the shaded range on the chart.

One rule I was strict about: every feature only uses what was knowable on the invoice's issue date. A payment that arrived after an invoice was sent can't be used to describe that invoice. Without that rule the backtest would quietly grade itself on the answers.

Mastra ties it together. The pipeline is a Mastra workflow with five typed steps (scan inbox, predict, forecast, draft reminders, write report), which made each step testable on its own and gave me Mastra Studio for free to watch runs step by step. On top sits a Mastra agent, also on local Gemma, with six tools: radar status, refresh, "can I afford", client history, draft a reminder, mark as paid. Its instructions say to quote numbers only from tools, so the small model's job is choosing the right tool and explaining the answer, not doing maths.

Does TabPFN beat common sense? The bar isn't zero, it's what a careful freelancer does in a spreadsheet: "this client usually pays N days late." npm run eval replays the history, trains on invoices paid before a cutoff, predicts the ones issued after, and scores both:

Predictor	Late? AUC ↑	Brier ↓	Pay-date error ↓	80% range hit rate
Per-client average (baseline)	0.58	0.264	6.3 days	0.63
TabPFN-3.5	TODO	TODO	TODO	TODO

Demo data: 132 training invoices, 46 test invoices. The baseline row is real output from npm run eval on the demo workspace.

The demo clients have habits a per-client average can't see by design: Orbit's $2,500 sign-off threshold, the café's month-end crunch, Helix Labs slowly getting worse over nine months, Kite & Co freezing payments over the holidays. TODO: one or two sentences on which of these TabPFN picked up in your run (look at the Orbit $3,900 invoice and Helix Labs: the baseline rates them "On track" and "Watch"). It's synthetic data, so the honest test is your own history, which is why eval exists.

Why Does Open Innovation Matter?

Because invoices are the most sensitive documents a freelancer has. An invoice carries a client's legal name, address, sometimes bank details, my rates, and what I built for them, often under an NDA. "Upload your invoices to our AI" is a non-starter for a lot of people, and for many it would breach a contract. With Gemma running in Ollama, the documents are read on the same laptop they were written on. Paydar's dashboard ends with a "What left this computer" box that lists exactly which columns went anywhere, and the answer for documents, names and emails is "nothing".

Because I could choose exactly what to share, and how little. TabPFN is used through Prior Labs' hosted API, but what it receives is a table of numbers and pseudonyms: clients become C01, C02, no invoice numbers, no descriptions. The model gets the pattern and none of the identities. With no API key, Paydar falls back to an offline baseline, so you can run the whole thing with Wi-Fi off. TabPFN itself is open too: the package is on GitHub with weights on Hugging Face for non-commercial use.

Because the business only works if each customer costs me almost nothing. A tool aimed at people who are short on cash can't carry a per-document API bill. Here the heavy lifting runs on hardware the customer already owns, so the price can be small and flat.

Because I could fit the model to the machine, not the other way around. The default is Gemma 4 E2B, quantization-aware trained, about 4.3 GB, chosen because my target user has an ordinary 8 GB laptop, not a GPU. Someone with 16 GB can switch to E4B with one environment variable, and any other Ollama model works the same way. Constrained JSON output, turning thinking off, a retry with the validation error: those are knobs I control because the stack is open.

Where open was harder: speed. Reading a document on a laptop CPU takes TODO-seconds (measure it on your machine) versus near-instant from a hosted API, so Paydar caches every extraction by file hash and never reads the same document twice. Scanned PDFs without a text layer need to come in as photos so Gemma's vision can read them. For a nightly "how's my cash" check, I'll take that trade.

Prize Categories

Best Use of Gemma: Gemma 4 E2B runs locally through Ollama to read invoices (text and photos) into a constrained JSON schema, draft reminder emails, and power the chat agent.
Best Use of TabPFN: TabPFN-3.5 (classifier plus quantile regressor via the /tabpfn/* API) inside a wider prediction agent, with a walk-forward backtest against a per-client baseline.
Best Use of Mastra: a five-step Mastra workflow orchestrating open models, plus a Mastra agent with six tools on a local Gemma model.

Spotter an app for gym data

Prakhar Agrawal — Mon, 05 Oct 2026 07:00:16 +0000

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

What I Built

Himank Singhvi is 21, trains 3-4 days a week, and is cutting. His current weight is 91 kg. His tracking lives in four places: a calorie app on his phone, a Samsung band syncing sleep and heart rate to Samsung Health, a notes app for his lifts and supplements, and a folder of blood test PDFs he's never looked at twice. He asked me to check the protein diet records and even told that the apps handling data are charging after the trial period.

None of those places talk to each other. His calorie app doesn't know he slept five hours. His workout notes don't know his resting heart rate jumped. And nobody was looking at the Vitamin D number in his last report.

So I built him Spotter, an app that runs on his own laptop and pulls all of it together:

Food in plain words. He types "3 eggs, 2 rotis with dal, scoop of whey in milk" and gets back an editable table with calories and macros, measured against targets worked out from his body and his chosen deficit.
Supplements as a daily checklist, so he can see whether he's actually taking the creatine he pays for.
A workout plan built around his training days and equipment, with set logging and an estimated one-rep-max chart. That chart answers the question every cutting lifter has: am I losing fat or losing strength?
Recovery from his Samsung band. Spotter imports the Samsung Health data export and turns last night's sleep, resting heart rate and stress into a plain call for today: push, train as planned, or go lighter.
Blood tests. He drops in a lab PDF. Spotter extracts every result, flags anything outside the lab's own reference range, tracks markers across reports, and explains flagged results in plain language with questions to take to his doctor.
A weekly check-in written like a message from a gym buddy, built from the week's real numbers.

Demo

All demo data is fictional and included in the repo under sample_data/. His real numbers stay on his laptop, which is rather the point.

Code

Prakhar0013 / Spotter

Built for friend to help with his gym routine

🏋️ Spotter

A local-first training, nutrition and recovery log, built for one friend who lifts.

Spotter keeps his food, supplements, workouts, Samsung band data and blood test results in one place, on his own laptop. A local open-weight model (via Ollama) reads the messy stuff: meal descriptions, lab PDFs, plan requests. Plain Python does every number.

What it does

Log food in plain words. "3 eggs, 2 rotis with dal, scoop of whey in milk" becomes a checked, editable table with calories and macros.
Targets. Maintenance and cut calories from the Mifflin-St Jeor formula, a chosen deficit that never drops below BMR, protein per kg.
Supplements. A daily checklist, 14-day adherence, and a timing review that defers to a pharmacist.
Workouts. A weekly plan the model builds only from a fixed exercise library, set logging, and estimated 1RM trends to check strength holds during the cut.
Band & recovery. Imports…

View on GitHub

How I Built It

Spotter is a Streamlit app backed by SQLite, with Qwen2.5 7B running locally through Ollama on my RTX 3050. The 3B model works too on smaller GPUs or CPU only.

The most important design decision was deciding what the model is not allowed to do.

A language model is great at reading "had two rotis and a bowl of dal" and terrible at arithmetic. So Spotter splits the work:

The model reads. It turns free text into structured JSON: food items with quantities and units, lab markers with values and reference ranges, a workout plan.
Code does every number. Food items are fuzzy-matched against a built-in nutrition table with Indian staples (roti, dal, poha, paneer, soya chunks) alongside the usual gym foods. Units like "bowl" or "scoop" convert to grams, and the macros are calculated in Python. Calorie targets come from the Mifflin-St Jeor formula, with a floor at his BMR so the app never suggests eating less than his body burns at rest.
Guardrails catch the model when it's wrong. When the model estimates a food that isn't in the table, Spotter checks its calorie number against the macros (4/4/9 kcal per gram). If they disagree by more than 25%, it trusts the macros. Workout plans can only use exercises from a fixed library; anything else gets dropped. Lab values always land in an editable table that he checks against the PDF before anything is saved.

The weekly check-in follows the same rule. Python computes the averages, the days he hit his protein target and the strength trends, and the model's only job is to turn those numbers into a note a friend would actually read.

The Samsung part was the most difficult, challenging. Samsung Health exports a folder of CSVs with a metadata line on top, column names like com.samsung.health.sleep.start_time, and timestamps in UTC stored next to a separate offset like UTC+0530. The parser is deliberately forgiving about all of that, because the format changes between app versions.

Why Does Open Innovation Matter?

Look at what Spotter holds: everything he eats, every supplement he takes, how he slept every night, his resting heart rate, and his blood test results. That's one of the most personal datasets a 21-year-old has.

With a closed API, every meal description and every lab report would travel to someone else's server. With an open-weight model running in Ollama, none of it leaves his laptop. There's no account, no sync, and no privacy policy to read. The database is one SQLite file he can delete whenever he wants.

Open made three more things possible:

It costs nothing to run. He'll log food three or four times a day, every day. A per-token bill on a habit app is a slow leak; a local model is free after the download.
I could pick the model to fit his hardware. Qwen2.5 7B fits on his GPU; on a weaker machine it's one environment variable to switch to the 3B model. Nothing else changes.
It works offline. Gym Wi-Fi is famously bad. Spotter doesn't care.

Where a closed frontier model would have done better: estimating unusual dishes from scratch, and parsing very messy lab PDFs. The answer wasn't a bigger model. It was making the small one's job smaller and checking its work in code. That split ended up being the best design choice in the project.

Handing It Over

Once I gave him, he told that he will try using it. Though after testing he told that this one is good. First few times he tried doing it with heavy food items like Chicken and some other stuff. He even recommended an improvement for android compatibility.

Team Submissions
Prashant Kumar: @blackpearl_iiith

Thank you for giving us opportunity to participate.