DEV Community: Yash Kumar

Dabba: a 4B model reads a tiffin kitchen's WhatsApp group and TabPFN says how many thalis to cook tomorrow

Yash Kumar — Thu, 15 Oct 2026 13:07:59 +0000

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

What I Built

Every evening, in a few thousand Indian neighbourhoods, a WhatsApp group fills up with messages like these:

[14/10/26, 9:12 PM] Priya Sharma: kal 2 veg thali lunch, no onion
[14/10/26, 9:40 PM] Rahul Verma: parso ka dabba cancel kar do
[14/10/26, 10:05 PM] Megha Jain: kal se 6 din band, bahar ja rahe
[14/10/26, 10:31 PM] Harsh Khan: 1 dabba kl afternoon 12 bje

They are orders for a home tiffin service, a side hustle that feeds office-goers and students one dabba at a time. The owner reads the group at night, tallies on paper, and decides how much to cook at six the next morning. Harsh's "1 dabba" means a paneer thali because Harsh always takes paneer. Megha's "6 din band" means six fewer every day until she's back. Then the walk-in orders arrive at nine, after the shopping is done.

Cook too much and the margin goes into the bin. Cook too little and a regular eats elsewhere, and regulars are the whole business.

Dabba turns that WhatsApp group into tomorrow's prep list. Paste tonight's messages, and a fine-tuned 4B model turns each one into a structured order: who, what, how many, which meal, which day, with the kitchen's memory filling in what "dabba" means for that customer. Then TabPFN, a tabular foundation model, looks at the kitchen's history and the orders already booked and says how many of each dish to cook, with a band around it. The cook gets a shopping list in rotis and kilos.

Who pays: the owner. One over-cooked tray of chicken is more than a month of this.

Demo

Hosted demo: https://dabba-jgho.onrender.com (free tier, about a minute to wake). Press Use tonight's sample to load twelve messages from the simulated kitchen's last evening, parse them (about 12 seconds for all twelve), and get the prep list (about 30 seconds, one TabPFN call per plan). Then change Harsh Khan's "1 dabba" to a paneer thali and watch the kitchen memory learn it.

Code

its-kumar-yash / dabba

Dabba: tiffin-kitchen ops with a Tinker-tuned order parser and a TabPFN demand forecast

Dabba · kal kitna banana hai

An ops tool for a home tiffin (dabba) kitchen. Paste tonight's WhatsApp messages, get tomorrow's orders as a table and a prep list that says how many of each dish to cook, with a confidence band.

Order parsing: Qwen3.5-4B LoRA fine-tuned on Tinker reads Hinglish messages like kal 2 veg thali lunch, no onion or parso ka dabba cancel and resolves relative dates against the WhatsApp timestamp.
Demand forecast: TabPFN (Prior Labs' tabular foundation model) predicts tomorrow's final count per dish from the kitchen's history and the orders already booked by 9 pm.
Kitchen memory: Backboard remembers each customer's usual dish and prefs so a bare "1 dabba" from a paneer regular becomes a paneer thali.
Hosted on Render.

uv venv --python 3.12 && uv pip install -r requirements-train.txt
cp .env.example .env                      # TINKER_API_KEY, BACKBOARD_API_KEY, TABPFN_TOKEN
.venv/bin/python data/simulate.py         # kitchen

…

View on GitHub

How I Built It

Three open pieces, each doing one job.

1. The parser: Qwen3.5-4B + a LoRA trained on Tinker

The hard part of a tiffin message is not the vocabulary, it is the timestamp. "kal" is a different date on every line, "parso" is two days from whenever the message was sent, and "Monday" from a Thursday night is in four days. A general model has to count; a model that has seen 1,400 of these does not.

I generated the training set from a simulated kitchen rather than labelling by hand. Eighty customers with usual dishes, preferences, office days, travel pauses and churn produce five months of orders; each order is rendered into a message in one of three registers (Hinglish, English, roman Hindi) with the WhatsApp export prefix. The program that writes the message also writes the label, so the labels are exact. A quarter of the training messages get the typos and lowercase that real thumbs produce.

Training is the plain Tinker loop, three epochs, rank 16, 129 steps, under two dollars:

tc = service.create_lora_training_client(base_model="Qwen/Qwen3.5-4B", rank=16)
renderer = get_renderer("qwen3_5_disable_thinking", tc.get_tokenizer())
for step in range(129):
    tc.forward_backward(batch(step), "cross_entropy")
    tc.optim_step(adam_params=tinker.AdamParams(learning_rate=lr(step)))
sampler_path = tc.save_weights_for_sampler(name="dabba-v2").result().path

Did it beat the baseline? Same 200 held-out messages, same system prompt, exact match on every field. Baselines are zero-shot: the untouched 4B and gpt-oss-120b.

System	valid JSON	action	date	items	prefs	time	all fields	p50 latency	$ / 1k msgs
Qwen3.5-4B zero-shot	72%	56%	56%	53%	67%	66%	30%	2.1 s	$0.52
gpt-oss-120b zero-shot	98%	96%	50%	86%	96%	96%	38%	2.8 s	$0.56
Qwen3.5-4B + Dabba LoRA	100%	100%	100%	100%	100%	99%	98%	2.3 s	$0.49

The 120B model writes valid JSON almost every time and still gets fewer than four messages in ten fully right, because it resolves "kal" against the wrong day. The fine-tuned 4B resolves every date in the test set and gets 98% of messages fully right. Of the four it misses, two are a template of mine whose delivery time never made it into the text (label noise, my fault), one is a dropped "jain", and one is a real slip: "kal" from the night of 30 May came out as 1 June.

2. The memory: Backboard

"1 dabba" from Harsh means a paneer thali. No model can know that; the kitchen can. When the owner corrects a parsed order once, Dabba writes one Backboard memory:

POST /assistants/{id}/memories   {"content": "Harsh Khan: usual dish paneer_thali, prefs no_onion."}

Before parsing a message, Dabba searches those memories with the message, keeps only the ones whose subject is the sender, and prepends them to the system prompt as a Known rules from the kitchen block. The model was trained with that block present on 18% of examples, so it obeys it. On the 35 test messages where a bare "dabba" came from a non-veg-thali regular, the zero-shot 120B picked the right dish 69% of the time with the same rule in its prompt; the fine-tune picked it 100%.

Memory writes and reads are plain API calls, no LLM in the loop, which is what you want for a fact as boring as "Harsh takes paneer".

3. The forecast: TabPFN inside a small prediction agent

At 9 pm the kitchen knows three things: what it sold on each day of the last five months, what today's weekday and date are, and how many dabbas are already booked for tomorrow. That last one is the strong signal, and it is a known-future covariate, which is why I used TabPFN as a tabular regressor with hand-built features rather than a pure time-series model. For each dish and meal:

dow, day of month, holiday, Navratri, advance_orders (booked by 9 pm),
lag1, lag7, lag14, 7-day mean, 28-day mean, 7-day mean of advance orders, advance share

Rain is in the history and deliberately not a feature: nobody knows tomorrow's rain at 9 pm.

The model is TabPFNRegressor from Prior Labs, fitted on everything before the test day and asked for the 10/50/90 quantiles. I walked it forward over the last 28 days against the rules of thumb an owner actually uses, plus gradient boosting for honesty:

Predictor (per dish, per meal)	MAE in dabbas	over-cooked / day	under-cooked / day	exactly right
Same as yesterday	2.56	18.1	17.7	24%
7-day average	2.30	15.7	16.5	26%
Last week, same weekday	1.79	12.6	12.5	32%
Advance orders ÷ usual advance share (what an owner does)	1.55	12.4	9.3	36%
Gradient boosting on the same features	1.07	7.3	7.7	39%
TabPFN	0.90	3.9	8.7	51%

28 test days, 14 dish-meal series, 392 predictions, walk-forward with the model refitted weekly. "Over/under-cooked" are summed across all dishes for a day; "exactly right" is the share of dish-day predictions that hit the integer.

The number that matters is the over- and under-cooked columns, because they are the money. The owner's own rule mis-cooks about 22 dabbas a day across the menu; TabPFN mis-cooks about 13, and most of its misses are on the under side, which is why the app's "cook" number leans towards the top of the band when the extra is cheap. Gradient boosting on identical features gets close on MAE, but TabPFN over-cooks half as much and needed no tuning at all.

One honest note on the band: it was asked for 10–90% and covered 97% of outcomes, so it is wider than it claims. For a kitchen that is the right failure mode, but it is a failure mode.

4. Render

One render.yaml, one Python web service, free tier. The parser is served from Tinker's sampling API because 512 MB cannot hold a 4B model; TabPFN runs through Prior Labs' API for the same reason. The same app can point at Ollama and the local TabPFN weights instead, one environment variable each; the parser backend and the local TabPFN mode are in the repo, though this week I only had time to measure the hosted path.

Why Does Open Innovation Matter?

You can fine-tune. No prompt teaches a frontier model that "parso" from a Tuesday night is Thursday and that a kitchen's "dabba" is whatever that customer always takes. Three epochs of LoRA on a 4B model did, for under two dollars, and the adapter is a file I own. When the kitchen adds a dish, I regenerate and retrain over lunch.

Small is the right size. A 4B model beat a 120B model by 60 points on this task. A tiffin kitchen's compute budget is a phone and, at best, an old laptop. A 4B adapter fits; a 120B API bill does not.

The group chat stays in the house. Those messages carry names, addresses, who is travelling and when. Run on a laptop with Ollama and the local TabPFN weights, which the repo supports, and nothing leaves. A closed model is a copy of the whole neighbourhood's routine on someone else's server.

A tabular foundation model changes who gets a forecast. Demand forecasting used to mean a data scientist and a month. TabPFN fits in one call on 2,000 rows and gives calibrated bands. The owner never sees it; the owner sees "cook 34, maybe 38".

Where a closed model would do better: nowhere I could find for this job. Where my setup is worse: the history is simulated, which I say plainly below.

Honest limits

The kitchen is simulated. The customers, their habits and the festival dips are mine, so the forecast numbers measure the method on a realistic kitchen, not on a real one. The parser's messages are also generated, from 26 templates in three registers; the test set is held out but it is the same distribution. The real test is the next section.

My First User

I took it to a two-person tiffin kitchen near my flat that runs on one WhatsApp group and a notebook. I asked for one evening of messages with the names changed. Eleven messages, all of them parsed. One regular's "1 dabba" came out as a veg thali when he always takes rajma; the owner changed it in the table, the app said yaad rakh liya, and the next "1 dabba" from him was rajma. She tested that twice to be sure.

What she asked for next was not the forecast. It was the delivery list: who gets which dabba, with the "no onion" next to the name, printed. That is a five-line change and it went in the same evening.

Would she pay? "Agar yeh bill bhi bana de" — if it also makes the monthly bill. That is the next feature, and that is a yes with a condition, which is the best kind of first answer.

My Agent Session

Built with Claude Code over three evenings. The session did the simulator, the Tinker and TabPFN scripts, the app, the deploy, and caught two of its own labelling bugs by reading the error files.

Prize Categories

Thinking Machines (Tinker), Prior Labs (TabPFN), Render, Backboard.

Kharcha: a 4B model that reads Indian bank SMS so the money stays on your laptop

Yash Kumar — Fri, 02 Oct 2026 13:37:59 +0000

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

What I Built

I built this for my mother, who keeps the household accounts in a paper diary and forwards me bank SMS with the same question: "ye kya tha?" Was this the gas cylinder or the electricity bill? Half the diary entries say "online" and nothing more.

The obvious fix, a finance app, is the one thing she won't install, and she is right. Those apps read every SMS on the phone and ship them to a server you have never heard of, and a bank SMS is the most private text a person receives.

Kharcha (Hindi for "expense") is a small ledger built to run entirely on a laptop. You paste a bank or UPI SMS, or you type what you would have said out loud ("aaj sabzi wale ko 80 diye"), and a 4-billion-parameter open-weight model turns it into one clean row: who, how much, which account, which date, which category. It learns from corrections. Change "Sharma Kirana" from shopping to groceries once and it stays groceries. Tell it Rahul is family and transfers to Rahul stop landing in "other".

It understands the formats of HDFC, SBI, ICICI, Axis, Kotak and PNB, the PhonePe, Google Pay and Paytm notifications, and Hinglish with spoken numbers like "dhai hazaar" and "baarah sau".

Demo

Hosted demo: https://kharcha-4aax.onrender.com (free tier, first load takes about a minute to wake up, and the ledger resets on every deploy). The demo serves the same fine-tuned adapter from Tinker's sampling API because the free tier cannot hold a 4B model.

In the recording: a bank SMS and two spoken notes become ledger rows, "Sharma Kirana" gets corrected from food delivery to groceries once and the app says yaad rakh liya (remembered), and a Hinglish question gets a Hinglish answer.

Code

its-kumar-yash / kharcha

Kharcha · ghar ka hisaab, phone se bahar nahi jaata

A tiny, private expense ledger for my parent. Paste any Indian bank/UPI SMS, or say "aaj sabzi wale ko 80 diye", and a 4B open-weight model fine-tuned on Tinker turns it into a categorised ledger row The model runs offline on a laptop with Ollama; bank SMS never leave the machine Backboard remembers the corrections ("Sharma Kirana is groceries", "Rahul is my son") and answers Hinglish questions about the month. The demo is hosted on Render: https://kharcha-4aax.onrender.com (free tier, ~1 min cold start).

Built for the DEV Hacktoberfest Weekend Challenge "Build for a Friend" (Oct 2026).

How it works

SMS / voice note ─▶ Qwen3.5-4B + Kharcha LoRA ─▶ {"direction","amount","counterparty","channel","account_last4","date","category"}
                          ▲ hints                         │
                 Backboard memory  ◀── corrections ───────┘

data/ – program-labelled dataset generator (real HDFC/SBI/ICICI/Axis/Kotak/PNB/PhonePe/GPay/Paytm formats + Hinglish voice notes). Labels are exact because the program that writes…

View on GitHub

How I Built It

The core is a LoRA fine-tune of Qwen3.5-4B trained on Tinker and exported as a 146 MB adapter that I own. Around it: a FastAPI app with a single HTML page, Backboard as the memory layer, and Render hosting the demo.

1. A dataset with no labelling errors

Hand-labelling 1,500 SMS in a weekend was not going to happen, and asking a big model to label them would have baked its mistakes into mine. So I wrote the SMS the way the banks write them. Twenty-six templates copied from real formats, filled with real merchant names, Indian number grouping (1,72,300.00), six date styles, VPAs, reference numbers, and Hinglish voice notes with word numbers. The program that writes the message also writes the label, so the ground truth is exact by construction. A quarter of the training messages are then corrupted the way phones corrupt them: truncated, lower-cased, punctuation stripped.

About one in eight examples carries a "Known rules from the user" block in the system prompt, such as Treat Agarwal Sabzi Bhandar as groceries. or Rahul Kumar is family (beta). That is how the model learns to obey the memory layer rather than its own prior.

1200 train / 150 val / 150 test · 12 categories · 26 message templates

2. Fine-tuning on Tinker

Tinker gives you a training loop, not a black box. The whole run is forward_backward plus optim_step on batches of rendered conversations:

training_client = service.create_lora_training_client(base_model="Qwen/Qwen3.5-4B", rank=16)
renderer = get_renderer("qwen3_5_disable_thinking", training_client.get_tokenizer())
data = [conversation_to_datum(conv, renderer, max_length=640,
                              train_on_what=TrainOnWhat.LAST_ASSISTANT_MESSAGE) for conv in rows]
for step in range(111):
    fb = training_client.forward_backward(batch(step), "cross_entropy")
    training_client.optim_step(adam_params=tinker.AdamParams(learning_rate=lr(step)))
sampler_path = training_client.save_weights_for_sampler(name="kharcha-v1").result().path

Three epochs, 111 steps, rank 16, about 1.1 million training tokens. The run cost under a dollar. The model only sees loss on the JSON tokens; the 266-token system prompt and the SMS are context, not targets.

3. Did it actually beat the baseline?

Same 150 held-out messages, same prompt, exact-match on every field. The two baselines are zero-shot: the untouched Qwen3.5-4B and gpt-oss-120b, a model thirty times larger.

System	valid JSON	amount	counterparty	date	category	all fields	p50 latency	$ / 1k msgs
Qwen3.5-4B zero-shot	93%	89%	76%	72%	71%	28%	2.2 s	$0.33
gpt-oss-120b zero-shot	97%	97%	85%	76%	81%	49%	2.8 s	$0.38
Qwen3.5-4B + Kharcha LoRA	100%	100%	100%	100%	100%	97%	2.7 s	$0.31

The four misses are all the same thing: whether "jooti ke 1200 lage" was paid in cash or by an unknown channel. My own labels decide that arbitrarily, so I count those as label noise rather than model error.

Two honest caveats. First, part of the gap is convention: the big model writes "ATM" where my label says "SBI Bank ATM LAJPAT NAGAR", and both are defensible. Category accuracy, which has no convention problem, still moves from 81% to 100%. Second, the latency on Tinker is similar across models because it is dominated by queueing, so it says little about the size difference; the number that would matter is the offline one on a laptop, which I did not get to measure.

Where the gap is real: the big model calls a petrol pump "other", a Jio recharge "other", a Croma autopay "subscriptions", and misses the date inside a PhonePe transaction ID. The fine-tuned 4B gets every one, because it has seen a thousand of them.

On the 7 test messages that carried a user rule, the baselines followed the rule 86% of the time. The fine-tune followed it 100%. That is the number that makes the memory layer trustworthy.

4. Bringing the weights home

adapter_dir = weights.download(tinker_path=sampler_path, output_dir="out/adapter_raw")
weights.build_lora_adapter(base_model="Qwen/Qwen3.5-4B", adapter_path=adapter_dir, output_path="out/peft_adapter")

That is a 146 MB adapter_model.safetensors sitting in my out/ folder: the whole of what the model learned, in a file I own. train/export_adapter.py carries it the rest of the way, merging into the base, converting to GGUF and registering it with Ollama, and app/parser.py already has the OllamaBackend that the UI switches to with PARSER_BACKEND=ollama. I ran out of weekend (and of home bandwidth: the base weights are 8 GB) before I could time that last step on the laptop, so the table above shows Tinker-served numbers only. The hosted demo and the laptop run the same code and the same adapter; only that one environment variable differs.

5. Memory with Backboard

Backboard stores facts at the assistant level, so one "household" assistant remembers across threads, devices and sessions. When a category gets fixed in the UI, the app writes one memory:

POST /assistants/{id}/memories   {"content": "Treat SHARMA KIRANA STORE as groceries."}

Before parsing the next SMS it runs a semantic search over those memories with the raw message as the query, keeps only hits whose subject actually appears in the text, and prepends them to the system prompt as the Known rules block the model was trained on. Memory writes and reads are plain API calls with no LLM in the loop, which is what you want for something as deterministic as "this merchant is groceries".

The Ask box ("is mahine kirane pe kitna gaya?") pulls the relevant memories plus the month's ledger summary and hands them to an open-weight model: a stock Qwen3.5 in Ollama at home, Qwen3.5-9B through Tinker's sampling API on the hosted demo (it shares the parser's tokenizer, which is what keeps the service inside Render's 512 MB). Backboard's own chat endpoint is wired in too and takes over automatically when the account has LLM credits (mine only has memory credits), but I liked that the fallback keeps the entire stack open-weight. One detail I got wrong first: that chat call ran with memory on, and Backboard dutifully extracted "user received a salary of..." from the ledger summary into long-term memory. It now runs read-only. The ledger is context, never a memory.

6. Render

render.yaml describes one Python web service. Tinker key, sampler path and Backboard key are secrets; PARSER_BACKEND=tinker tells the app to serve the adapter from Tinker's sampling API instead of a local Ollama. The same code, one environment variable apart, runs privately on a laptop or publicly on Render.

Why Does Open Innovation Matter?

The data never has to leave. A bank SMS contains your account suffix, your balance, who you paid, when, and how much. With a closed API every one of those messages is a request to someone else's server. With an open-weight model and a 146 MB adapter the whole thing fits on a laptop with the Wi-Fi off. That is not a feature you can add to a closed model, and it is the reason the adapter, not the hosted demo, is the real deliverable.

Fine-tuning is the product. No prompt turns a general model into something that knows PNB writes XX4521 while Axis writes XX4521 02-10-26 UPI/P2M/.... Three epochs of LoRA did. The run cost less than a dollar, the adapter is mine, and if Qwen3.6-4B comes out next month I change one string and retrain over lunch.

Small beats big when the task is narrow. A 4B model with 111 steps of training beat a 120B model by 48 points on this task. In practice that means a model that fits in 3 GB of RAM on an old laptop instead of a GPU cluster.

Memory you can read. Every rule the app learns is a sentence in Backboard that you can list and delete. There is no fine-tuned personalisation hidden in weights she cannot inspect.

Where a closed model would have been better: the Ask box. A frontier model answers Hinglish questions about a ledger more fluently than a 4B. But that part has no access to raw SMS, only to the monthly summary, so the privacy line holds.

My Agent Session

Built over one weekend with Claude Code: the dataset generator, the Tinker training and eval scripts, the app, and most of this post's numbers came out of that session.

The hand-over

We went through one diary page together. The gas cylinder came out as utilities and was immediately disputed: that is rasoi, kitchen. One click, "Yaad rakh liya", and the next gas SMS landed in groceries on its own.

The verdict: "Theek hai. Par diary bhi rakhungi." Fine. But the diary stays.

I will take that.

Prize Categories

Thinking Machines (Tinker), Render, Backboard.