DEV Community: Souptik

SlothSpend: a lazy, local-first subscription audit desktop app with Gemma and TabPFN

Souptik — Thu, 22 Oct 2026 06:41:17 +0000

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

What I Built

SlothSpend is a desktop app that checks your bank statement for subscriptions you forgot about. It runs entirely on your own computer.

You give it the CSV your bank already lets you download. A few seconds later it tells you:

which charges repeat (and which ones only look like they do),
which prices went up without you noticing,
which merchant charged you twice,
which services overlap (two streaming apps doing the same job),
how much the next 30 days will probably cost, as a range rather than one made-up number.

Then it does the part I always skip: it follows up. It reminds you a few days before a renewal. If you say "I cancelled it", it waits for your next statement and checks that the charge actually stopped. If the merchant charged you anyway, it tells you so and already has a refund email written, with the exact dates and amounts.

So who gets to be lazy? Anyone who has ever said "I should really go through my statement" and then didn't. That includes me. Reading 400 rows of ACH DEBIT IRONTRAP FITNESS MEMB 7731 is boring enough that most of us never do it, and that's how a $39.99 gym membership turns into $49.99 without anyone noticing.

The sloth rules

I gave the app a personality to fit the theme, and some hard limits that come with it:

It informs, it never acts. SlothSpend never cancels anything, never logs into anything and never emails a merchant. It writes the draft and you send it.
It never makes up a link or a phone number. Every answer and draft goes through a guard that removes them. A model inventing a "cancel here" URL is a phishing risk.
It never claims to have done something it didn't. If the model says "I've set a reminder" and no tool call confirmed it, the reply gets replaced with what actually happened.
Every number says where it came from. Each figure is labelled Gemma 4 · local, TabPFN v2, or a clearly marked Template / Heuristic fallback if a model isn't available.

Demo

🌐 Website: slothspend.netlify.app

The app has a Demo data → Sample statement button that loads 12 months of made-up charges, so you can try everything without using your own bank data. The screenshots below come from that sample. Here's the whole flow, step by step.

1. Getting ready (one time only)

On first launch, SlothSpend checks three things: its own local engine, a Gemma model in Ollama, and TabPFN. If you don't have Gemma yet, it offers to download it and shows a progress bar. TabPFN v2's weights (~70 MB) download on their own. After that, nothing leaves your computer.

2. Import a statement, even an awkward one

Every bank exports CSVs differently. This one is from an Indian bank: 13 junk lines before the header, dates written day-first, separate Debit and Credit columns, amounts in ₹. SlothSpend worked out most of that by itself and only asks about the one thing it wasn't sure of, which column holds the money. It remembers the layout for next time.

3. The report

The pink card at the top is Sloth's summary in plain English. Below it:

Monthly recurring: what you actually pay every month.
Next 30 days: TabPFN's forecast with a likely range (q10–q90), not one fake-precise number.
Potential savings: how much you'd save by cancelling the "zombie" subscriptions yourself, plus any double charge worth disputing.
Flags: duplicates, price rises, overlaps and zombie suspects.

The chart shows 12 months of subscription spend. The pink July bar is the month the gym raised its price and charged twice.

4. "Why was this flagged?"

Click any merchant to see its full history and the reasons in plain words: "Billed every ~30 days, ±1 day, near the 5th of the month. The same $39.99 eight times in a row, then $49.99 for the last four." If the model got it wrong, press Not a subscription. TabPFN takes your correction into account and re-scores everything in about 2 seconds, with no retraining.

5. Ask Sloth, a chat agent that shows its work

Ask Sloth is a local agent: Gemma 4 with 8 typed tools. You can ask things like "What will subscriptions cost next month if I cancel StreamFlix and WatchNest?" and watch it call get_merchant twice and then forecast_spend. That last one runs a live TabPFN forecast with those two merchants removed. Every tool call shows up in the chat, so you can see where each number came from.

6. "Cancel it for me" → "No, but here's everything you need"

This was my favourite thing to test. If you ask "Cancel IronTrap for me", Sloth explains that it can't, writes a cancellation email using your real renewal date and amount, and offers to remind you 3 days before the next charge. The email contains no links and no phone numbers, and it ends with "Check the dates and amounts, then send it yourself."

7. Reminders that actually follow through

Each reminder goes through four steps: Watching → Reminded → Kept / You cancelled → Verified. You can keep it, snooze it (up to 3 times), or say you cancelled it. You also get desktop notifications. If the app was closed when a reminder was due, it shows up the next time you open it.

8. Verified… or still charged

When you import the next statement, SlothSpend checks whether a charge appeared after your cancellation date. If none did, the reminder becomes Verified and shows what you're saving.

If the merchant charged you anyway, you get the screen at the very top of this post: Still charged, plus a refund request that lists both the charge after you cancelled and the old July double charge.

9. Settings and privacy

Here you can pick which Gemma model to chat with, set your default currency and reminder timing, and switch on a demo mode that shrinks every wait to a few seconds. There's also a privacy table listing every possible network call, and a Delete all local data button.

Code

souptik4572 / sloth-spend

SlothSpend audits a 12-month bank-statement CSV entirely on the user's machine, finds recurring charges, price creep and duplicate charges, forecasts the next 30 days of subscription spend, lets the user interrogate the audit through a local chatbot.

SlothSpend

Slow and steady subscription audits — on your own computer.

Find the subscriptions you forgot, the prices that crept up and the charges that came twice with open models (Gemma + TabPFN) running locally. SlothSpend informs, never acts.

Website · Download · How it works · Privacy · Develop

Why SlothSpend

A year of bank transactions says where you live, what you eat and who you love. Cloud "subscription trackers" want that data — and often a login to your bank. SlothSpend takes a CSV export, keeps it in a local database, and runs every model on your own machine. After a one-time model download it makes no network calls at all.

The theme is slow…

View on GitHub

To run it from source you need Node 24, Python 3.11, uv and Ollama 0.20+ with any Gemma model:

git clone https://github.com/souptik4572/sloth-spend.git
cd sloth-spend
npm install
npm run engine:venv   # builds engine/.venv from the pinned lockfile
npm run dev

Then click Demo data → Sample statement.

How I Built It

SlothSpend has two halves: an Electron + React desktop app and a Python FastAPI engine that runs next to it as a local sidecar process.

Electron (React 19, Tailwind v4, zustand)
      │  HTTP + server-sent events, 127.0.0.1 only, per-launch token
      ▼
Python engine (FastAPI, pandas, SQLite)
  ingest → normalise (Gemma) → detectors → TabPFN score + forecast → summary (Gemma)
  Ask Sloth agent + 8 tools · reminder scheduler
      │  127.0.0.1:11434
      ▼
Ollama → Gemma 4

Electron picks a free port and a random token on every launch, then starts the engine. If Electron crashes, the engine notices its stdin closing and shuts itself down, so you never end up with a stray Python process.

The interesting part is that two very different open models each do the job they're good at.

Gemma 4 (via Ollama): the language part

Gemma handles everything that involves words:

Cleaning up merchant names. ACH DEBIT IRONTRAP FITNESS MEMB 7731 becomes IronTrap Fitness with the category Fitness. Ollama handles one request at a time, so this runs in priority order under a time budget. Whatever doesn't fit in the budget falls back to rules and gets cleaned up in the background later. If you rename a merchant yourself, your name always wins.
The summary. The code writes the facts and Gemma only rephrases them into friendly English. The output is then checked: if Gemma drops or changes any number, the code-written version is used instead.
Ask Sloth. Gemma does tool calling over 8 typed tools (get_merchant, find_duplicate_charges, spend_by_category, forecast_spend, score_merchant, run_readonly_sql, set_renewal_reminder, get_report_overview), with up to 4 tool rounds per answer.
Emails. Refund, cancellation and negotiation drafts start from a code-written template with the exact facts in it. Gemma makes them read naturally, and then a guard checks the result.

TabPFN v2: the numbers part

This was the bit that surprised me most. TabPFN is a tabular foundation model. You show it example rows when you call it (in-context learning) and it predicts straight away, with no training step.

Model A (classifier): "Is this a subscription?" Every merchant becomes a row of features: median gap between charges, how regular that gap is, how stable the amount is, day-of-month spread, and so on. The context is a set of simulated billing histories that ship with the app, plus your own corrections, each repeated 3 times. That's why "Not a subscription" changes the score in ~2 seconds: there's no retraining, the new label is just part of the next call.
Model B (regressor): "What will the next charge be?" It predicts the next/last price ratio as 19 quantiles. That's where the q10–q90 range on the forecast card comes from, and it's what Ask Sloth's live what-if forecast runs on.

TabPFN refuses more than 1,000 training rows on CPU by default (I found that out the hard way), so the context is capped at 950 rows.

Making it trustworthy

Deterministic detectors handle duplicates, price creep, overlaps and possible annual plans. I don't want a language model deciding whether $49.99 on Jul 5 and Jul 6 counts as a double charge.
Reminders are rows in SQLite plus a single loop that ticks at startup and every 30 seconds. There's no workflow engine. Every state change is compare-and-set, so a click and a tick can't overwrite each other.
An egress test. engine/tests/test_egress.py runs the whole app (audit, every chat tool, drafts, a full reminder cycle, Delete all local data) with every non-loopback network connection refused, and fails if anything tries to reach the internet.

Numbers

Measured on the packaged macOS build (Apple Silicon, TabPFN v2, gemma4:latest):

Check	Measured
Launch → window shown	0.18 s
Launch → engine healthy	7.1 s
Full audit of the sample (412 rows, 12 months)	27.7 s
Re-score after a correction	2.4 s
Engine health check p95 during an audit	19 ms

One real bug from the week: launch first took 22.5 s. It turned out that reading the saved Prior Labs key synchronously from the macOS keychain made the OS verify the whole app bundle (921 MB including the Python engine) before handing the key over, and it froze the window while doing so. Switching to safeStorage.decryptStringAsync brought the window to 0.18 s and the engine to 7.1 s.

Why Does Open Innovation Matter?

For this app, open models aren't a nice extra. Without them the app doesn't really work.

A year of bank transactions shows where you live, what you eat, who you see and what you're struggling with. Most "subscription tracker" apps want that data on their servers, and many want your bank login too. I didn't want to build another one of those, and honestly I wouldn't use one.

Open weights changed what I could build:

Nothing leaves the machine. Gemma runs through Ollama on 127.0.0.1 and TabPFN runs on local PyTorch. After the one-time model download, SlothSpend makes no network calls, and there's a test that proves it. A closed API would mean sending every transaction to someone else's server.
It costs nothing to run. No API key, no per-token bill, no usage limit. An app whose job is saving you money shouldn't charge you every time it reads your statement.
Swapping models is easy. Any Gemma you already have in Ollama works, and Settings lets you pick one. TabPFN goes v2 (open weights, the default) → 3.5 (if you add a free Prior Labs key) → a labelled heuristic (if no model is available). Being able to fall back like this only works because I control the model layer.
TabPFN made the "learns from you" part possible. Because it learns in context, a user correction becomes part of the prompt rather than a training job, so the app adapts to you, on your own device, in two seconds. I couldn't have built that loop with a hosted black box.
It's auditable. The engine is open source, the models are open, and the privacy table in Settings lists every byte that could ever leave your computer. You don't have to take my word for any of it.

The Lazy Payoff

On the 12-month sample statement, a single 28-second audit found:

$87.46/month of potential savings across 4 "zombie" subscriptions, about $1,050 a year,
a $49.99 double charge worth disputing,
two price rises: a gym at +25% and a music app at +9.1%,
two streaming services doing the same job.

Finding that by hand means reading 412 rows, matching messy merchant names across 12 months, and noticing a $10 price change in the middle of the year. For me that's an evening I'd keep putting off. Then there's the follow-up, which is where most of the money actually gets lost: remembering a renewal date, checking next month's statement, and writing the refund email. SlothSpend turns all of that into one import, one click on "I cancelled it", and a second import a month later.

The sloth does the slow and steady part. You just stay lazy.

Prize Categories

Best Use of Gemma: Gemma 4 runs locally through Ollama and does every language task in the app: merchant normalisation, the summary (with a number-preservation check), the tool-calling Ask Sloth agent, and refund/cancellation/negotiation drafts.
Best Use of TabPFN: TabPFN v2 is the scoring and forecasting core. The classifier decides what recurs, using simulated priors plus user corrections as in-context examples, and the quantile regressor powers the q10–q90 forecast and the live "what if I cancel X" tool. Built with PriorLabs-TabPFN.

AI disclosure: I built SlothSpend with help from Claude Code (Claude Opus) as a coding assistant, and this post was drafted and edited by me. The product decisions, the "inform, never act" rules and the testing are mine.

SlothSpend is MIT-licensed. TabPFN v2 weights are under the Prior Labs License 1.1; Gemma is used under Google's Gemma terms.

TuitionSetu: a tutor's Sunday of WhatsApp updates, written by Gemma on her own laptop

Souptik — Sat, 17 Oct 2026 06:25:12 +0000

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

What I Built

Mita teaches Maths to 30 children from home. After every batch she jots something like:

Riya ch5 test 14/20 careless in algebra, missed HW twice; Arjun absent

Parents expect a WhatsApp update every week, in Bengali, Hindi or English. So on Sunday evening she turns a week of those scribbles into 30 polite, specific messages. It takes about two hours.

TuitionSetu does the Sunday part. She types her notes the way she always has, on her phone or laptop. A local model works out who each line is about and every score. On report day it writes each parent's update in the parent's language. Code checks every number against her notes, and then she reads, approves and taps Send on WhatsApp.

Who pays, and why. Home tuition is a common side income for teachers in India, and regular updates to parents are part of keeping students. A tutor with 30 students would pay a small monthly fee (I'm thinking ₹99, about a dollar) to get Sunday evening back and to send updates that sound like her and quote the right numbers. That price only works because there is no per-message AI bill: the model runs on the laptop she already owns.

A week with TuitionSetu

After each class. She types the note on her phone, exactly as she'd scribble it. It's saved the moment she taps Save, and the laptop reads it in the background. The note then shows who it was about and what was found: scores, homework, attendance and topics.

When something isn't clear. TuitionSetu never guesses. Anything it isn't sure of becomes one short question in Needs you:

Who is 'Riya'? Maybe Riya Sen (there are two Riyas)
Riya 14 — out of how many? The total is missing
Arjun 18/15 — is that right? The score is more than the total
Mark fees pending for Kabir? Your note mentions fees

When she picks the right student for a name, that spelling is saved as a nickname, so she's asked once. Names it matched on its own are listed under Matched for you, with Undo.

On report day. She opens the week's review and taps Write updates. Each parent's update streams onto the screen in that parent's language and is checked the moment it's finished. It's either ready, or flagged with the exact words highlighted. She can edit any update (the check runs again on her words), dismiss a warning she knows is fine, or Skip this week for a student. Then Send on WhatsApp opens WhatsApp with the message filled in, and she presses Send herself.

Demo

In the GIF: Mita types one note about five students. Gemma reads it in about 17 seconds and writes Riya's update in Bengali. A score changed by mistake (80% → 90%) is flagged before anyone sees it. She approves, WhatsApp opens with the message ready, and she presses Send herself. Everything runs on one laptop, with no internet needed.

There's no hosted demo, on purpose: the point is that children's names, marks and parents' phone numbers never leave the tutor's laptop. Trying it takes two commands:

Code

souptik4572 / tuition-setu

Turn 5 minutes of rough tutor shorthand into 35 personalized parent WhatsApp updates. 100% local AI, zero cloud costs, total student privacy.

TuitionSetu

Turn a private tutor's class notes into WhatsApp updates for parents — written by an open-weight model on the tutor's own laptop, and checked by code before anything is sent.

Mita teaches Maths to 30 children from home. After each batch she jots shorthand like Riya ch5 test 14/20 careless in algebra, missed HW twice; Arjun absent. On Sunday evening she spends two hours turning a week of those notes into a message for every parent, in English, Bengali or Hindi.

TuitionSetu does the Sunday part:

She types the note as she always does, on her phone or laptop, right after class.
The laptop reads it with a local model: who each line is about, scores, homework, attendance. Anything it isn't sure of (a name it doesn't know, a score without a total) waits in Needs you; it never guesses.
On report day it writes each…

View on GitHub

git clone https://github.com/souptik4572/tuition-setu.git && cd tuition-setu && ./setup.sh
./start.sh            # or ./start.sh --lan to use it from a phone on the same Wi-Fi

You need Node 22+ and Ollama. The first run downloads the model (about 6.6 GB). On my laptop, with the model already downloaded, setup took 17 seconds.

How I Built It

The model writes; code checks. Only two steps use the model: reading messy shorthand, and writing a warm paragraph in Bengali. Everything a parent could act on is plain code.

Type a note. It's saved instantly, even if the AI engine is off.
Extract (Gemma). The model returns JSON: who, topics, scores, homework, attendance.
Validate (code). Every number the model returns must appear in the line it came from, or it's removed. A score with no total, or a name it doesn't know, goes to Needs you instead of being guessed.
Resolve names (code). Exact name, saved nickname ("Riyu"), or close spelling ("Payal" → Payel). Anything unsure is asked.
Facts (code). This week's scores, percentages and the trend, worked out from the confirmed notes.
Draft (Gemma). Only the body, in the parent's language, from those facts. It streams on screen.
Guard (code). Every number in the draft must be in the facts, including Bengali and Devanagari digits. No other child may be named, and the language must be right.
Assemble (code). The title, greeting, fee line and sign-off come from templates, never from the model.
The tutor approves, and a wa.me link opens WhatsApp with the text. TuitionSetu never sends anything on its own.

Reading the note, and what code won't take on trust

Gemma reads the note through Ollama's structured outputs, so its reply has to fit a JSON schema, and Zod checks it again on arrival. If the reply isn't valid JSON or doesn't fit, the app asks once more and says what was wrong. Thinking is turned off: these jobs don't need it, and it makes a small model slow.

Then the validator checks the reading against the note itself:

The part of the note each entry came from must really be in the note. If it isn't, the entry waits for the tutor.
Every number must appear in the line it came from. One that doesn't is removed, not trusted.
A score with no total ("Riya 14"), or one bigger than its total, becomes a question, not a fact.
Two entries about the same child in one note are merged.
A line about no one becomes a question. If it isn't in the note at all, it's dropped.

Names. Each name is checked in order: the exact name, then a saved nickname, then a close spelling. "Close" means one letter off for names of five letters or fewer, two for longer ones. Only one clear answer is ever taken. Two students called Riya, or two names that are equally close, go to the tutor with up to three suggestions.

Facts. Code works out everything an update may say: this week's scores and percentages, homework missed, attendance, topics, strengths and concerns. The trend compares the latest score with the average of up to three earlier ones, and needs at least two. Eight points or more either way is "improving" or "declining"; less is "steady". Code rounds the average before Gemma sees it, so the percentage Gemma quotes is exactly the one the guard allows.

The guard

Every update goes through seven checks before the tutor sees it:

Check	What it catches	Result
Numbers	Any number not in the facts. Scores are checked as pairs (14/20), percentages against the ones code worked out. Bengali (১৪) and Devanagari (१४) digits count, and so do "২০ এর মধ্যে ১৪" and "20 में से 14", which put the total first.	Flagged, number highlighted
This child	The update never names the student	Flagged in English. A warning in Bengali and Hindi, where the name is written in another script
Other children	Any other student's name, including Bengali forms like তন্ময়ের ("Tanmoy's")	Flagged
Language	Under 60% of the letters in Bengali or Devanagari script (90% for English)	Flagged
Length	Under 30 or over 160 words	Warning
Fees	Any mention of fees or money	Flagged: the fee line only ever comes from a template
Leftovers	Braces, "JSON", "as an AI" and the like	Flagged

A flagged update can't be approved. The tutor can edit it, and the guard runs again on her words. An out-of-date update is checked against this week's current facts, so an old number can't slip back in. Or, if the flagged part is right, she can dismiss the warning. The dismissal is written to the audit log, lasts only until the text changes, and can be undone.

The guard caught Gemma for real while I was recording the demo. Its advice said "practicing 2-3 short word problems together each evening", and "2" and "3" aren't in Mita's notes, so the update was flagged. Here it's harmless advice, so the tutor can dismiss the warning (the dismissal is recorded) or edit the text. What she can't do is approve a number she hasn't seen.

The guard has a limit, the same one @nodefiend spells out in Trust the Server, Not the LLM: A Deterministic Approach to LLM Accuracy: it checks that every number exists in the facts, not that it sits next to the right label. If Riya scored 14/20 in algebra and 18/20 in geometry, an update that swapped them would pass. That's one reason a person reads and approves every message.

Choosing the model by measurement

I wrote an eval harness (npm run eval): 10 real-style notes covering Hinglish, Bengali in English letters, one-liners, nicknames, a date that looks like a score, typos in names and an unknown student. It runs the actual extract, validate and resolve code and scores the result:

Model	Version	Students	Scores	Extra questions	Names as written	Median time	p95
gemma4 (E4B)	v1	100%	100%	0	56.5%	7.4 s	11.9 s
gemma4 (E4B)	v2	100%	100%	0	91.3%	7.8 s	13.7 s
qwen3.5:9b	v1	95.7%	100%	1	77.3%	23.6 s	40.0 s
qwen3.5:9b	v2	100%	100%	0	82.6%	23.7 s	39.3 s

Every run returned valid JSON on the first try, and every run left the unknown student for the tutor instead of guessing.

Two things came out of it. First, Gemma kept "helpfully" correcting names ("Payal" → "Payal Dutta"), which broke the check that the model's quote really appears in the note. One change to the reading step, keeping every name exactly as the tutor spelled it, took names-as-written from 56% to 91%. Second, after that change Gemma sometimes returned the class date as a line about no one. That would have become a pointless question for the tutor, so the validator now drops any such line that isn't in the note. Gemma matched Qwen on accuracy and was three times faster, so it does both jobs.

When things go wrong

The AI engine is off. The note still saves (in 106 ms in my QA run) and is read automatically once the engine is back (19 seconds later, in the same run).
The engine stops halfway through an update. The screen says "The AI engine stopped partway through. Your note is safe and nothing was sent.", and the previous version stays.
A note can't be read. It waits in Needs you, with Try the other model when another model is installed.

Keeping it on the laptop

The server listens only on 127.0.0.1 unless it's started with --lan.
Every page needs the PIN. It's stored as a scrypt hash, and five wrong tries in ten minutes pause sign-in for ten minutes.
The AI log records timings and token counts only. The logging function has no parameter for note or message text, so there's nowhere for it to go.
If the AI engine is ever pointed at another machine, the home screen shows a red warning.
Fonts are bundled at build time, so the app makes no internet requests at runtime.

Testing it like a tutor would

I did a QA pass from a fresh git clone on a MacBook with an M4 and 16 GB, driving the app in headless Chrome against the real model:

41 seconds from the fresh clone to the first draft, with the model already downloaded and the setup wizard scripted.
One note about five students was read in 16 seconds, with every score right and nothing left in Needs you.
Five updates in 21 seconds: three in Bengali, one in Hindi, one in English, all checked.
A sampler listed every connection the server opened during the run. All of them were on 127.0.0.1.

It found four bugs, now fixed: a vague error when the engine died mid-update, a score shown as "unknown 18/25" because Gemma named an unnamed test "unknown", a sent update still labelled "Preview · not sent", and 12 lines of npm warnings in ./setup.sh that look like errors to someone who isn't a developer.

The rest of the stack: Next.js 16 and React 19, SQLite through Drizzle, Zod for every model reply, and Ollama for the models. There's a PIN-protected local sign-in, a --lan mode so the tutor's phone can use the laptop, and 243 tests across 33 files. Models are swapped with one line in .env.local.

Why Open Innovation Matters Here

Children's data stays home. The notes, marks and parents' numbers live in a SQLite file on the tutor's laptop. In my QA run, the app's only network connections were to itself and to Ollama on 127.0.0.1. A closed API would mean sending every child's marks to a third party.
Bengali quality is something I can measure and swap. If a better open model for Bengali appears tomorrow, it's one line in .env.local, and the eval tells me whether it really is better before any parent sees it. Gemma was a good place to start: in I Tested Gemma 4 and GPT-4o-mini on Indian Language Tasks, @devsaquib found that Gemma 4 (31B) wrote proper Bengali and Devanagari, where GPT-4o-mini answered a formal Hindi request in Roman script and sent the Bengali prompt back instead of answering it. I run the much smaller E4B, so my own eval is what decides.
No lock-in. It's Apache-2.0, the data is a file she owns, and once it's set up it needs no internet.

The honest limits: a tutor needs a laptop with at least 8 GB of memory, and 16 GB is comfortable. The Bengali and Hindi templates for greetings and sign-offs still need a native speaker's review.

What's Next

Photos of the paper register. Gemma 4 reads images, and the step is designed, but it was cut from this MVP.
A settings page, and setup scripts for Windows.
A hosted version for tutors without a capable laptop. It's designed in the spec, with Postgres and row-level security keeping each tutor's data apart, and the code already carries a workspace on every table so the switch is small.
Later, an Android app with a small on-device model, so the phone works without the laptop.

My First User

Prize Categories

Best Use of Gemma. Gemma 4 (E4B, gemma4:latest in Ollama) does both model jobs: reading the tutor's shorthand into structured JSON, and writing each parent's update in Bengali, Hindi or English. I chose it over Qwen 3.5 9B by measurement (table above): just as accurate on my fixtures, three times faster, and small enough for a tutor's 16 GB laptop. It reads notes through Ollama's JSON-schema structured outputs with thinking off, streams each update as it writes, and stays loaded for 15 minutes between notes so the next one starts quickly. A tutor with more memory can switch to a bigger Gemma, such as gemma4:12b, with one line in .env.local.

I built TuitionSetu with Claude Code as my pair programmer. Every number above comes from the project's tests, evals and my QA run.

Plink: a patient xylophone practice partner for my friend's daughter

Souptik — Sat, 03 Oct 2026 05:19:29 +0000

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

What I Built

My friend's daughter has just started her first instrument: a toy xylophone with eight coloured bars. She reads a little, and practice works best when a grown-up sits beside her, points at the next bar, and waits. Plink is that patient partner.

Plink is a web app that runs on the family laptop. It listens through the microphone, learns the sound of her bars, lights up the bar to hit next and waits, with no buzzer, until she finds it. Between parts, two open models help: TabPFN learns from every note she plays and picks the part she'll get right about 80% of the time, and Gemma 4 turns any tune into a short lesson and writes a two-line note for her parent. Nothing she plays leaves the laptop, and it works with the Wi-Fi off.

A session goes like this:

Plink's turn: Plink plays the part while the bars light up, a little slower than normal.
Her turn: the next bar glows and Plink waits. A miss just makes the right bar wiggle.
Help that fades: lots of help (only the right bar sounds, and Plink says its colour), some, or little (she plays from memory).
Every note right first time is a star, and every 15 stars unlock a sticker.
After every three parts of her song, Plink slips in a short part on a jump she finds hard. The last part is always one she's likely to get right, so she ends on a win.

The app is loud and colourful everywhere except during a part. Then the page calms down, the other bars dim, and only the target glows, in its real colour, because Plink's hints name the colours.

There's also an on-screen xylophone (mouse, touch, or the A S D F J K L ; keys) for when the real one isn't to hand. A grown-ups area behind a simple sum lets her parent add songs by playing them in, typing letters, singing them, or taking a photo of a song card.

Handing it over

Hosted Demo

plink-tt30.onrender.com

Code

souptik4572 / plink-xylophone-practice-app

Plink is a local-first web app built for children playing their first xylophone, and for the parent who sits beside her. It has a built-in on-screen xylophone, playable by mouse, touch or the home-row keys, so she can play and practise even without the real instrument.

Plink

A patient xylophone practice partner, built for one child and the parent beside her. Hacktoberfest 2026 Weekend Challenge, "Build for a Friend". Full design in spec.md.

Run

make setup   # uv sync, pnpm install, ollama pull
make dev     # backend on 127.0.0.1:8000, app on http://localhost:5173
make test
make eval    # TabPFN drill-picker benchmark

The first time, make an account in the app (see Accounts).

Accounts

A grown-up signs up with an email and a password (8 characters or more), on the laptop and on the demo alike. Everything Plink keeps (her songs and their lessons, practice, settings and calibration) belongs to that account, and no account can see another's.

Passwords are stored only as Argon2id hashes.
The avatar at the top right opens the grown-up's Account page and Log out, both behind the grown-up sum, so she can't log herself out. The page holds your name…

View on GitHub

make setup && make dev runs it locally: FastAPI and SQLite on the back end, React, TypeScript and Vite on the front, and Gemma through Ollama. There are 215 backend and 114 frontend tests, plus headless-Chrome runs that play whole sessions.

How I Built It

her xylophone ── mic ──▶ browser: AudioWorklet → strike gate → which bar?
on-screen xylophone ──┘   (plain signal processing; audio never leaves the tab)
                                  │ only bar numbers and timings
                                  ▼
         FastAPI ── SQLite on the laptop (Postgres on the Render demo)
            │  every note she plays = one row in her practice log
            ├── TabPFN: what to practise next, when to help, her trickiest jumps
            └── Gemma 4: lessons, praise, the parent note, song cards, Ask Plink
singing ──▶ Basic Pitch (in the browser) → notes → fitted to her eight bars

Hearing her bars is not a model's job

Detection is plain signal processing, on purpose. It has to answer the moment she strikes, the audio must stay in the browser, and it has to fail predictably.

Calibration has her strike each bar three times. Plink stores what each bar sounds like on a musical scale (quarter-semitone bands), so a calibration made on one laptop still works on another with a different sample rate. A sound only counts as a strike if it peaks at the mallet and then only decays, as a few clear partials. Claps, knocks, key clicks and voices don't behave like that, so Plink ignores them, and it re-measures the room's noise as she plays.

On synthetic wooden and metal bars it accepted all 96 test strikes and rejected every clap, knock, click and voice. In the browser, fed a recording through Chrome's fake microphone, the Mic check scored 40 of 40. [TODO: her real xylophone's Mic check score from Sunday.]

TabPFN: seven small decisions, from her first session

TabPFN is a tabular foundation model: you hand it a small table and ask for predictions, with no training loop. That fits a child's practice log well. Every note she plays is one row (the bar, the jump from the last one, the help level, how many times she's seen the part…) plus whether she got it right first time.

From about 20 rows, which is her first session, TabPFN:

chooses the next part at the level she'll get right about 80% of the time. It predicts every candidate part "as if she played it next" and picks the one closest to 0.8;
times the help for each note: where it expects a miss, the glow comes sooner and Plink says the colour;
advises more, less or the same help, but only for levels it has seen her play. It can't know what it hasn't seen, so otherwise it suggests trying that level once;
rates each song for her and suggests one on the home screen;
finds her trickiest jumps between bars;
turns those jumps into practice: three short parts per jump, easiest first ("Stepping stones", "One big hop", "Hop and back"), slotted in after every three song parts at her sweet spot;
ends the session on a win: when the next part probably won't fit in the time left, Plink says "Last one!" and plays the part TabPFN is surest she'll get right.

A fit and prediction takes 0.8 s warm on a laptop, so the next pick is computed in the background while she's celebrating the last one. On the 36 notes I played while testing, TabPFN edged logistic regression (ROC AUC 0.858 against 0.819). That's far too little data to call a win, and it isn't the point. The point is that TabPFN works on the tiny table you actually have in week one.

Gemma 4: six jobs, and code that owns the notes

Gemma 4 (gemma4:e4b, through Ollama) does the language and vision work:

Lessons: it splits any tune into short named parts, with a tip for each.
Praise and the parent note: the note is two plain lines on what to practise next, with TabPFN's trickiest jumps fed in.
Song cards from a photo: beginner songbooks often print songs as coloured circles or letters. Gemma counts the notes first (with thinking on), then lists them (thinking off), and code maps each one to her bars. That two-pass approach read 14 of 14 notes on test cards printed with letters, numbers and colours.
Ask Plink: a grown-up can ask "Is she ready for Jingle Bells?" Gemma calls read-only tools over her practice data and TabPFN, and answers with the numbers ("87% first try"). TabPFN decides; Gemma explains.
The line Plink says before each jump practice part, naming the colours: "Go orange and turquoise back and forth, yay!"

The rule everywhere is that code owns the notes. Gemma names and explains, but every reply goes through a validator, and when one fails, Plink falls back to plain parts and plain text. A child never sees a broken lesson.

Two surprises along the way. Gemma 4 thinks by default: a lesson took 44 s with thinking and 10 s without, so thinking is only on for counting the notes on a song card. And with no name set, Gemma called her "Lily", in the praise and in the note. The prompts now forbid inventing names.

What didn't work: asking Gemma twice

The usual advice for structured output is a bounded retry-repair loop: when the JSON fails validation, send the error back and let the model fix it. Structured Output From LLMs: A Retry-Repair Loop Your Parser Never Sees Through by @devshakib lays the pattern out well. I added one (simplified from backend/app/coach.py):

REPAIR = ("That answer can't be used: {problem}. Reply again with only the corrected JSON, "
          "nothing before or after it, keeping every rule in the first message.")

for attempt in range(config.GEMMA_REPAIRS + 1):
    reply = _post(body, timeout)
    try:
        return validate(json.loads(reply["message"]["content"]))
    except (ValueError, KeyError, TypeError) as e:
        messages += [{**reply["message"], "role": "assistant"},
                     {"role": "user", "content": REPAIR.format(problem=e)}]

It barely helped. The repair fixed 2 of 10 broken lessons; the rest repeated the mistake or made a new one. The mistakes were arithmetic. I'd asked for each part's first and last note, and Gemma wrote things like "phrase 4 starts at note 2" when it had to start at note 21.

So I changed the question. Gemma now says how many notes each part holds ({"notes": 4, "nickname": "…", "tip": "…"}), and code places the parts:

Lessons on the Gemini API (gemma-4-26b-a4b-it)	Valid first try	Repairs that worked	Valid
First and last note, with repair (10 runs)	6	1 of 4	7
+ complaints that say how to fix it (20 runs)	13	1 of 6	14
Part sizes, placed by code (20 runs)	11	1 of 1	12

Every lesson that came back was valid. The other 8 hit the API's 60 s timeout, and those songs keep plain parts until a grown-up asks again. On the laptop's e4b, 5 of 5 were valid.

The jump practice taught me the same thing. Asked to name six nearly identical practice parts, Gemma came back with junk half the time ("nickname-2", "=", "pattern-pattern"), and the repair fixed none of it. Now each kind of part has a fixed name, which is also easier for a child to learn, and Gemma only writes the spoken line, which it got right in 11 runs of 12. A line that names a colour the part doesn't use goes back for repair, because she finds her bars by colour.

The lesson: a retry loop can't fix a question the model finds hard. Change the question, and let code do the counting.

Render: the public demo

Her copy stays on the laptop. For everyone else there's a public demo on Render, defined in one render.yaml Blueprint: a web service that serves the app and the API from one Docker image, plus a free Render Postgres database for logins and each account's practice. Render generates the login-signing secret, and each new demo account is seeded with simulated practice (6 sessions, 373 notes), so TabPFN is live on the first visit. Render has no GPUs, so the demo runs Gemma 4 through Google's Gemini API (gemma-4-26b-a4b-it), which built a lesson in about 6 s.

Two things I learned getting there. PyTorch in a 1-CPU container saw all 10 of the host's CPUs, started 10 threads, and was throttled for 486 s until I set OMP_NUM_THREADS. And leaving uv's download cache in the image made it 3.47 GB instead of 2.06 GB.

Why Does Open Innovation Matter?

Because of who it's for. Building Local-First AI Apps: What Changes When the Data Stays on the Device by @sanskarin covers the general case. For a child's practice, it isn't a nice-to-have:

Her audio never leaves the room. Detection runs in the browser, and only bar numbers and timings are saved. There is no recording of her to leak.
It works with no internet. Gemma runs through Ollama on the laptop and TabPFN runs locally, so practice doesn't depend on a connection or a subscription.
It fits her. It's calibrated to her bars, Plink's words can be in her family's language, and a smaller or bigger Gemma is one environment variable (GEMMA_MODEL) away.
It costs nothing per session, so she can play every day.

A closed API could write lessons too. But every song, every practice note and every question about a child would go to someone else's server, and practice would stop when the Wi-Fi does.

The honest limits: Gemma 4 and Basic Pitch are Apache 2.0, but TabPFN's weights are open under a non-commercial licence. That's fine for a gift, not for selling it. And the public demo trades some of this away for convenience: there, song-card photos, the numbers behind a parent note and Ask Plink questions go to Google's Gemini API. Her laptop copy sends nothing.

My Agent Session

I built Plink with help from Claude Code. This session is day two: logins (JWT access and refresh tokens), the calibration rework, moving the demo's Gemma to the Gemini API, and the Gemma and TabPFN upgrades above, measurements included.

Prize Categories

Best Use of Gemma: six jobs across text, vision and tool calling (lessons, praise, the parent note, song cards from a photo, Ask Plink, and the lines for jump practice), with validators, a repair step and fallbacks, so a child never sees a bad answer.
Best Use of TabPFN: seven live decisions from her own practice log, starting in her first session: what to practise next, when to help, which help level to try, how hard each song is for her, her trickiest jumps, practice on those jumps, and a last part she'll get right.

Plink's on-screen xylophone was inspired by my earlier project souptik4572/xylophone and rebuilt from scratch here. Thanks to Prior Labs (TabPFN), Google DeepMind (Gemma), Spotify (Basic Pitch) and Ollama. I built Plink with help from Claude Code.

DEV Community: Souptik

SlothSpend: a lazy, local-first subscription audit desktop app with Gemma and TabPFN

What I Built

The sloth rules

Demo

1. Getting ready (one time only)

2. Import a statement, even an awkward one

3. The report

4. "Why was this flagged?"

5. Ask Sloth, a chat agent that shows its work

6. "Cancel it for me" → "No, but here's everything you need"

7. Reminders that actually follow through

8. Verified… or still charged

9. Settings and privacy

Code

souptik4572 / sloth-spend

SlothSpend audits a 12-month bank-statement CSV entirely on the user's machine, finds recurring charges, price creep and duplicate charges, forecasts the next 30 days of subscription spend, lets the user interrogate the audit through a local chatbot.

SlothSpend

Contents

Why SlothSpend

How I Built It

Gemma 4 (via Ollama): the language part

TabPFN v2: the numbers part

Making it trustworthy

Numbers

Why Does Open Innovation Matter?

The Lazy Payoff

Prize Categories

TuitionSetu: a tutor's Sunday of WhatsApp updates, written by Gemma on her own laptop

What I Built

A week with TuitionSetu

Demo

Code

souptik4572 / tuition-setu

Turn 5 minutes of rough tutor shorthand into 35 personalized parent WhatsApp updates. 100% local AI, zero cloud costs, total student privacy.

TuitionSetu

How I Built It

Reading the note, and what code won't take on trust

The guard

Choosing the model by measurement

When things go wrong

Keeping it on the laptop

Testing it like a tutor would

Why Open Innovation Matters Here

What's Next

My First User

Prize Categories

Plink: a patient xylophone practice partner for my friend's daughter

What I Built

Handing it over

Hosted Demo

Code

souptik4572 / plink-xylophone-practice-app

Plink is a local-first web app built for children playing their first xylophone, and for the parent who sits beside her. It has a built-in on-screen xylophone, playable by mouse, touch or the home-row keys, so she can play and practise even without the real instrument.

Plink

Run

Accounts

How I Built It

Hearing her bars is not a model's job

TabPFN: seven small decisions, from her first session

Gemma 4: six jobs, and code that owns the notes

What didn't work: asking Gemma twice

Render: the public demo

Why Does Open Innovation Matter?

My Agent Session

Prize Categories