DEV Community: Ankith M

A failed UPI payment owes you ₹100 a day. I built the sloth that waits to collect it.

Ankith M — Thu, 22 Oct 2026 18:34:41 +0000

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

Every Indian phone has this SMS somewhere: "Rs.1250.00 debited from A/c XX4521 ... Txn status: PENDING. If not credited to beneficiary, amount will be reversed." The money left. It didn't arrive. And then you wait, check the balance twice a day, maybe call the bank, and eventually forget about it. If it comes back in a week, you're relieved.

Here's what almost nobody knows: since 15 October 2019, the bank has to pay you ₹100 for every day that reversal is late. Not if you complain. Automatically. It's in RBI's circular on failed transactions, paragraph 5: compensation "shall be effected to the customer's account suo moto, without waiting for a complaint or claim from the customer."

So the money is owed. Getting it just needs someone patient: someone who remembers the date, counts the days, writes the letter, waits 30 days, writes the next letter. That's the most sloth-shaped job I could think of, so I built the sloth.

What I Built

Paisa Wapas ("money back"). You forward the failed-payment SMS once. Then you do nothing.

Gemma reads the SMS: is this a UPI payment to a person or to a shop, an ATM that didn't give cash, a card, IMPS, Aadhaar Pay, a wallet, a reversal, or just a normal payment? It pulls out the amount, date, reference, bank and payee.
Code checks every value Gemma gives against the SMS text. An amount, date or reference that isn't in the message is dropped and listed. The model never decides a deadline or a rupee.
Code applies the RBI rule: UPI to a person must be reversed by T+1, UPI to a shop by T+5, an ATM by T+5, and so on (ten rows from the circular's annex). It works out the deadline, how late it is, and what's owed.
A Temporal workflow does the waiting. A durable timer runs to the deadline. If the money isn't back, Gemma drafts a letter to the bank, from facts code worked out. When you send it, a 30-day timer starts, and if nothing happens, Gemma drafts the complaint to the RBI Ombudsman (free, at cms.rbi.org.in). When the money finally comes back, it tells you the compensation the bank owes.
Nothing is sent for you. Every letter is a draft you copy.

Who gets to be lazier: anyone who's ever had a payment fail. Especially the people at home who would never write to a bank's nodal officer, or know that there's a nodal officer at all.

Demo

Live (no sign-up): https://paisa-wapas-1037019152152.asia-south1.run.app

Tap a sample SMS, then pick "It takes 45 days" and Fast-forward. You're watching the real workflow run on Temporal's time-skipping test server: 45 days of patient waiting in about 15 seconds, with two real Gemma-written letters along the way.

Code

Ankith-m1006 / paisa-wapas

Forward a failed UPI/bank SMS once: Gemma reads it, code applies the RBI deadline and Rs 100/day, a Temporal workflow does the waiting.

Paisa Wapas

Money cut, payment failed? Forward the SMS once. Paisa Wapas knows the RBI deadline, counts the ₹100 a day the bank owes you, and does the waiting for you.

Live: https://paisa-wapas-1037019152152.asia-south1.run.app (no sign-up)

Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 3: Slow and Steady.

Read the SMS	The deadline and what's owed	Fast-forward 45 days

The rule almost nobody uses

Since 15 Oct 2019, RBI's circular on failed transactions (DPSS.CO.PD No.629/02.01.014/2019-20) sets a deadline for every kind of failed payment: a UPI transfer that left your account but never reached the other person must be reversed by T + 1, an ATM that didn't give cash by T + 5, and so on. After that the bank owes you ₹100 for every day of delay, and paragraph 5 says it must credit that without waiting for a complaint. If the…

View on GitHub

How I Built It

1. The rule first, from the source

Before any model, I read the circular itself (RBI/2019-20/67, DPSS.CO.PD No.629/02.01.014/2019-20, 20 September 2019) and turned its annex into a table in rules.py:

Failed payment	Back by	Then
UPI to a person, IMPS, card to card, NACH, wallet	T + 1	₹100/day
UPI to a shop, card at a shop or online, ATM, Aadhaar Pay	T + 5	₹100/day

T is the day of the transaction. Ten rows, one verdict() function, no model involved. Then the RBI Integrated Ombudsman Scheme, 2021 for the escalation: complain to the bank in writing first, and if there's no reply in 30 days, you can go to RBI, within a year and 30 days.

2. The model reads, code decides

Gemma 4 (gemma-4-26b-a4b-it) gets one SMS and returns a small JSON object: kind, amount, date, ref, bank, payee, each copied exactly as written. Then check() treats every field as a claim:

the amount must match a number in the SMS,
the reference must appear in the SMS,
the date must appear in the SMS and parse (18-10-26, 09-Oct-26, 16Oct26, 21 Oct 2026 ...),
anything that fails is dropped and shown as a problem, never guessed.

Why not just let Gemma do everything? Because the one place a model must not be creative is a number you'll put in a letter to your bank.

3. The waiting is a workflow, not a reminder

This is the part I'm proudest of, and the reason I picked Temporal. A failed payment is a slow process by law: one day, five days, then thirty more. A cron job and a database row can do it, but every edge case (the laptop sleeps, the server restarts, the money comes back while you're writing the letter) becomes my bug.

In Temporal it's just code that waits:

deadline_end = date.fromisoformat(self.status.deadline) + timedelta(days=1)
if await self._wait_until(deadline_end, lambda: self.reversed_on is not None):
    return self._close(case, "Money came back on time")

self.status.letters["bank"] = await workflow.execute_activity(draft_letter, Draft(...), **LETTER_OPTS)
...
rbi_day = self.complaint_sent_on + timedelta(days=30)
if await self._wait_until(rbi_day, lambda: self.reversed_on is not None):
    break

_wait_until is a durable timer that also wakes up early on a signal ("the money's back", "I sent the letter"). The workflow sleeps for weeks, survives restarts, and the code reads like the story.

4. Watching 45 days in 15 seconds

A demo of something that waits a month is a problem. Temporal's time-skipping test server is the answer: it fast-forwards the clock whenever the workflow is only waiting. The live preview runs the real PaisaWapas workflow on it, so what you see is the real logic, not an animation.

It took three tries to get right, and that's where most of my evening went:

The clock can't go back. The test server starts at "now", so an SMS from 18 October can't be replayed from its own date. The preview now runs as if the SMS arrived today, and says so on the page.
Blocking the event loop. The letter activity called Gemma with a blocking HTTP request inside async code, which froze the whole server. Fix: await asyncio.to_thread(gemma, ...).
Time kept skipping during the model call. While Gemma was writing (15-20 s), the test server skipped hours ahead, so the activity's 3-minute timeout fired in skipped time and it retried forever ("Activity not found on completion" in the logs). Fix: in the preview, the workflow records each letter request instantly, and Gemma writes those exact letters once the run is done. In real mode the real activity runs inside Temporal, with a timeout in days, because a letter is a draft a person sends later anyway.

5. The worst failure, and its guard

The worst thing this app could do is put a wrong number in a letter to a bank. So after Gemma writes a letter, code checks that the amount, the compensation and the deadline it was given all appear in the text. If any is missing or changed, the Gemma letter is thrown away and a plain letter built straight from the facts is used instead. Boring, correct, sendable.

A second, real one from tonight: a Gemma reply came back with extra text after the JSON and crashed my eval. Now the reader parses the first JSON object only, and if a reply can't be read at all, it records "the model's answer couldn't be read; nothing was assumed" instead of guessing.

Gemma vs the regex app I'd otherwise write

The test set is 40 SMS written by hand in the real formats of SBI, HDFC, ICICI, Axis, Kotak, PNB, Canara, Bank of Baroda, Paytm and PhonePe (no real customer data): failed UPI to people and shops, ATMs, cards, IMPS, AePS, wallets, reversals, and normal payments, salary credits, OTPs and offers that must not be chased. 25 of them are failed payments.

The baseline is the honest alternative: keywords for the status ("failed", "pending", "not credited", "timed out"...), the first Rs/INR amount, the first 12-digit reference, the first date. It was written while looking at SMS 1-30; SMS 31-40 were written afterwards (Hinglish, a balance printed before the amount, a reversal mentioned inside a success message, a forwarded PhonePe notification), so those ten are held out for it. Gemma was never tuned on any of them.

"Letter-ready" means everything a letter needs is right: the deadline (the right T+1 / T+5 row), the amount and the date.

	Letter-ready (deadline, amount and date right)	Wrong chase / don't-chase call	Amount right	Held-out 31-40: letter-ready	Time per SMS
Regex baseline (written while looking at SMS 1-30)	20/25	3/40	23/25	4/8	instant
Gemma 4 26B A4B, thinking on	24/25	1/40	25/25	7/8	23.9 s
Gemma 4 26B A4B, thinking minimal (default)	23/25	1/40	25/25	7/8	3.3 s

What the numbers say:

On the SMS the regex was written for, it looks great. On the ten it hadn't seen, it fell apart: it took the balance (₹3,412.50) as the amount, missed a Hinglish ATM failure ("ATM se paise nahi nikle par Rs 10,000 debit ho gaye") as "nothing to chase", and filed a failed wallet payment as a reversal. That's what every regex app does in real life: it works on the formats its author saw.
Gemma's misses are the interesting kind. An SMS that says a new payment succeeded but an earlier one failed. A masked reference (6284XXXX) it copied faithfully. An ATM ID it offered as a reference. None of them would have produced a wrong deadline in a letter; the guard catches values that aren't in the text.
Thinking costs time, not much accuracy. With Gemma's thinking set to minimal a read takes about 3 s instead of about 20 s, so that's the default.

Two places, timed

	Read one SMS	Fast-forward 45 days (2 letters)
My laptop (Windows, 8 GB)	5.2 s	16.2 s
Cloud Run, asia-south1	3.6 s	14.9 s

Gemma runs on Google AI Studio in both; the workflow, the rules and the checks run where the app runs.

Why Does Open Innovation Matter?

Both halves of Paisa Wapas are open, and each one is open for a reason.

Gemma is an open-weight model. Bank SMS are about as personal as data gets: account numbers, amounts, who you pay. The job here is small and fixed (read one SMS, fill six fields), which is exactly the kind of job an open model can do on hardware you control, with nobody else's terms deciding whether your messages are kept. For this week's build I called Gemma 4 through Google AI Studio, and I haven't run it on my own laptop yet; the reader only needs one HTTP call, so pointing it at a local Gemma is the next step, not a rewrite. I'd rather say that plainly than pretend.

Where would a closed model do better? Probably on the hardest SMS, the "your new payment worked, your old one failed" kind. But it would also be the one part of the app I couldn't move, audit or run offline.

Temporal is open source (MIT). The whole point of Paisa Wapas is to wait for weeks without losing track. With Temporal, the waiting is plain code I can read, test (the 36-day case runs in seconds in pytest), and self-host with temporal server start-dev on the same laptop. And the time-skipping server, the thing that makes a 45-day story demo-able in 15 seconds, exists because the project is open and built to be tested.

The rules are open too. RBI publishes the circular; I just turned it into ten rows of code with the annex row number next to each one, so anyone can check the app against the source.

The Lazy Payoff

What it saves, for one late UPI transfer:

Remembering: the T+1 date, the 30-day date. 0 minutes of your attention.
Counting: days late × ₹100, on the day it's checked.
Writing: two letters, each with the circular's number, the annex row, the amounts and the dates, already right. Writing one from scratch starts with finding the circular and the right annex row.
Not giving up: the one that matters. The ₹100 a day only adds up for the people who keep going after day 5. The sloth always keeps going.

Prize Categories

Best Use of Temporal: the whole product is a Temporal workflow that waits days by law (durable timers, signals for "money back" and "letter sent", queries for the status), plus Temporal's time-skipping test server to run the real workflow in the live demo and in the tests.
Best Use of Gemma: Gemma 4 reads every SMS (with every value checked against the text by code) and writes every letter (with every number checked again), evaluated against a regex baseline on 40 SMS, with held-out messages and both thinking levels measured.

How I worked: I built this with an AI coding assistant, dictating my side through Wispr Flow. The idea and the decisions are mine, and every claim here was checked against the code, the eval output and the RBI texts.

Three doctors, eight pills, one graph: what my agent found that nobody was looking for

Ankith M — Sun, 18 Oct 2026 05:19:07 +0000

Meet Lakshmi. She is 72, and she doesn't exist. I built her for this project as a synthetic patient, but if you grew up in an Indian family you have probably met someone exactly like her.

Lakshmi sees a general physician for her blood pressure, sugar and thyroid. A cardiologist added a blood thinner and a statin last month. Her knee started hurting, so an orthopaedic surgeon prescribed a painkiller and an antacid. Then she had a fever on a Tuesday night, and her son Ravi picked up a strip from the chemist downstairs.

That is four prescribers, eight medicines, and every single one written by brand name:

Doctor	What they wrote
Dr. Rao, general physician	Telma 40, Glycomet 500, Thyronorm 50
Dr. Menon, cardiologist	Ecosprin 75, Atorva 10
Dr. Shetty, orthopaedic	Aceclo Plus, Pan 40
Chemist, for the fever	Dolo 650

Each doctor saw their own page. Nobody saw the whole box. So here is the question Ravi can't answer on a Sunday morning, holding the pill organiser:

Is anything in this box the same medicine twice? And does anything here fight with anything else?

I built DawaiGraph (dawai is Hindi for medicine) for Graph Hacks to answer that question. This post is the story of how a graph answers it, one hop at a time.

Why this is a graph problem, not a search problem

Look at "Aceclo Plus" and "Dolo 650". The two names share nothing: no word, no letters that matter. Text search won't connect them, and neither will embeddings of the names.

But Aceclo Plus is a combination pill: aceclofenac plus paracetamol. And Dolo 650 is paracetamol. The connection doesn't live in the names. It lives one level down, in the salts.

That is a pattern, and patterns are what a graph database is for:

MATCH (b1:Brand)-[c1:CONTAINS]->(s:Salt)<-[c2:CONTAINS]-(b2:Brand)
WHERE b1.id IN $brand_ids AND b2.id IN $brand_ids AND b1.id < b2.id
RETURN s.name AS salt, b1.name AS brand_a, c1.strength AS strength_a,
       b2.name AS brand_b, c2.strength AS strength_b

Two brands, one shared salt, two hops. For Lakshmi, DawaiGraph returns:

Aceclo Plus and Dolo 650 both contain paracetamol (325 mg + 650 mg).
Path: Aceclo Plus → CONTAINS → Acetaminophen → CONTAINS → Dolo 650
Doctors to ask: Dr. Shetty, the chemist

That path is the explanation. Nobody has to trust a model's word for it; they can see the hops.

The graph model

Everything lives in one FalkorDB graph: what medicines are, and what this family takes.

Medicine knowledge: (:Brand)-[:CONTAINS {strength}]->(:Salt), (:Salt)-[:INTERACTS {level}]->(:Salt), and (:Salt)-[:IN_CLASS]->(:DrugClass).
Family memory: (:Person)-[:TAKES]->(:Brand), prescriptions with the doctor who wrote them, and (:Finding) nodes for every problem raised, with (:Carer) nodes for the family members who follow up.

The data is all open: the A–Z Medicine Dataset of India from Kaggle (about 250,000 brand rows), DDInter for drug–drug interactions (160,235 pairs), and Wikidata for drug classes. I loaded the 70,000 best-known brands, which takes about 65 MB of FalkorDB Cloud's 100 MB free tier.

One small thing made a big difference: a full-text index with phonetic matching on brand names. When someone types, or a photo gets read as, "Telmaa 40", it still finds "Telma 40 Tablet".

Hop by hop

Here is everything DawaiGraph found in Lakshmi's box, ordered by how far the graph had to walk.

Three hops: interactions live between salts, but people hold brands.
Telma 40 is telmisartan, and Ecosprin 75 is aspirin. DDInter lists a moderate interaction between those two salts. So the path is Brand → Salt → Salt → Brand:

Ecosprin 75 → CONTAINS → Acetylsalicylic acid → INTERACTS (Moderate) → Telmisartan → CONTAINS → Telma 40

The same walk found three more moderate interactions in her box: Atorva with Pan 40, Glycomet with Thyronorm, and Pan 40 with Thyronorm. Three of the four cross a doctor boundary: Dr. Menon's Atorva meets Dr. Shetty's Pan 40, Dr. Shetty's Pan 40 meets Dr. Rao's Thyronorm, and Dr. Menon's Ecosprin meets Dr. Rao's Telma. The doctor who wrote one half never saw the other half.

Four hops: some links only exist through a third medicine.
I added a tool to the agent that answers "why are these two connected?" with a shortest-path search over just this person's medicines. Ask it about Thyronorm and Ecosprin, two medicines with no direct link, and it comes back with:

Thyronorm and Ecosprin are connected through PAN 40, another medicine Lakshmi takes:
Thyronorm → contains → Levothyroxine → Moderate interaction → Pantoprazole (in PAN 40) → Minor interaction → Acetylsalicylic acid → contained in → Ecosprin 75

It also adds a note that each link is a separate pairwise fact, not a combined effect. That honesty mattered to me more than the path itself.

The hop that doesn't exist: India's data gap

This is the part that surprised me.

Open interaction datasets are built mostly around drugs sold in the US and Europe. Many salts Indians take every day simply aren't in them. When I matched the Indian brand list against DDInter, the most common salt with no interaction data at all was aceclofenac: about 9,000 brands of it. Domperidone was right behind it.

Lakshmi's knee painkiller, Aceclo Plus, contains aceclofenac. A plain lookup returns nothing. And in a medicine app, "nothing found" quietly reads as "safe".

So I asked: what would a careful pharmacist do? They'd reason from the drug's family. Aceclofenac is an NSAID, in the same class as ibuprofen, naproxen and diclofenac, which do have data. In the graph, that is a walk to the drug's cousins:

MATCH (x)-[:IN_CLASS]->(c:DrugClass)<-[:IN_CLASS]-(sib:Salt)
WHERE sib.ddinter = true
OPTIONAL MATCH (sib)-[i:INTERACTS]-(y)
WHERE i.level IN ['Major', 'Moderate']

If at least 80% of at least 3 siblings interact with something in the regimen, DawaiGraph raises a class signal. For Lakshmi:

No interaction data exists for aceclofenac (Aceclo Plus). 10 of 10 drugs in its class have a Major or Moderate interaction with aspirin (Ecosprin 75). Unverified: a signal to ask about, not a known interaction.

It raised a second one with metformin (Glycomet), and for Suresh, 68, another person in the demo whom Ravi also looks after, the same aceclofenac (in a dentist's Zerodol-SP) against his warfarin.

I didn't pick 80% and 3 from thin air. I hid 272 drugs that do have data, pretended they didn't, and checked how often the class signal predicted their real interactions. At 80% of at least 3 siblings, 87.4% of the signals were real interactions (recall 43%). Lower thresholds caught more but were wrong more often. For something a family reads about a parent's medicines, I chose fewer, more reliable signals, and the label says "unverified" every time.

No hop: "no path" is not "safe"

Suresh also takes Augmentin (from the dentist) and Amlong (from his cardiologist). Ask why they're connected, and the agent says there is no link in the data, not even through his other medicines, and then adds the sentence I care about most:

Having no data in the database is not the same as proving it is safe.

Making the agent unable to make things up

A medicine agent that sounds confident and is wrong is worse than no agent. So I took a few decisions early:

Fixed tools, no text-to-Cypher. The agent (Gemini, with function calling) can only call a small set of parameterised queries: resolve a brand, list the family, read a person's medicines, check them, explain a connection. It never writes its own Cypher.
Resolve every brand first, and ask when unsure. When I gave it a photo of a synthetic prescription, it read the brands it could find in the graph and refused to guess one it couldn't read clearly.
A name check after every answer. Code collects every medicine name in the reply and checks that it came from a tool result or the user's own words. In testing, the agent wrote "paracetamol" where the data says "Acetaminophen". It got caught and rewrote the answer.
"How I got this" under every answer. Every tool it called, the Cypher file behind it and what came back. Each decision can be traced.

Memory that belongs to one family

Findings are nodes, not chat history. A finding's key is a hash of what it's about, so if the same problem shows up next week, it updates the existing node instead of raising the alarm again. When Divya, Lakshmi's daughter, marks it "asked the doctor", Ravi sees that too.

Each family is its own tenant in the graph, so one family never sees another's data. And before the next appointment, the app prints a doctor visit sheet: one checklist per doctor, with what to raise first.

The number

I wanted to know what the graph actually adds, so I measured it. I built 30 regimens of 5 to 9 real Indian brands each (half with a deliberately repeated salt), computed the ground truth straight from the source tables, and asked two systems for the duplicates and interactions:

30 regimens, 119 known interactions	DawaiGraph	Gemini 3.5 Flash alone
Interactions found	119 / 119	48 / 119 (40%)
Stated interactions that DDInter lists	100%	46%
Stated interactions DDInter doesn't list	0	52
Duplicate salts found	24 / 24	21 / 24, plus 7 that aren't duplicates

To be fair: DawaiGraph scores 100% because the graph is built from the same data, so this mainly proves the queries are faithful. The interesting column is the right one. The same model that writes DawaiGraph's explanations, asked without the graph, missed 60% of the listed interactions and added 52 that the data doesn't list. That is the whole argument for giving an agent a graph instead of asking it to remember.

Limits, honestly

The brand data's prices are from 2022, and it lists at most two salts per brand.
About 77% of brands matched a salt with interaction data. The rest are exactly the gap the class signal tries to cover, and it covers part of it, not all.
All the people here are synthetic.
It is not medical advice. DawaiGraph never says "safe" and never tells anyone to stop a medicine. It tells you which doctor to ask.

What I learned

Put the reasoning in the data, not the prompt. Every finding above is a path in the graph, which is why it can be shown, checked and remembered.
The empty result is a feature. The most useful thing DawaiGraph does may be refusing to treat "no data" as "safe".
Small free tiers teach you to be careful. One unbounded path query on the whole graph froze my free FalkorDB instance. Restricting path search to one person's medicines made it fast and safe.

Try it

Live: https://dawaigraph-1037019152152.asia-south1.run.app (each browser gets its own copy of the synthetic families)
Code, graph model and every Cypher query: https://github.com/Ankith-m1006/dawaigraph
Demo video: https://youtu.be/cQ_jSRnSp58
There's also a read-only MCP server, so any AI assistant can check a medicine list against the same graph.

Built for Graph Hacks by WeMakeDevs × FalkorDB. I used Claude (Anthropic) as a coding assistant to build DawaiGraph and to help draft this post; the decisions, testing and final wording are mine.

GraphHacks @WeMakeDevs @falkordb

BillSahi: I built a GST checker, and a shopkeeper told me GST wasn't his problem

Ankith M — Sat, 17 Oct 2026 05:14:51 +0000

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

What I Built

Four bills on a counter near Pavagada

The supermarket is in a village outside Pavagada, in Tumkur district. Like most shops of its size it doesn't buy everything from one wholesaler. Soaps and Horlicks come from the Hindustan Unilever distributor, coconut oil and gram-flour soap from another, detergent from a third, and creams and lotions from whoever brings them that week. When I asked the owner for supplier bills, he handed me what he had kept: four of them.

Two looked like any GST tax invoice. One was printed from a phone app with a running balance in big letters at the top: ₹2,13,672 due. One just said CASH BILL 2025: 31 lines of creams and soaps, ₹15,252 in total, no supplier name, no GSTIN and no tax shown anywhere.

I had come with a GST rate checker. I had spent the week building it: you photograph a supplier's bill, and it checks every line against the official rate. So I asked him what worries him about supplier bills.

It wasn't the GST rate. He has hundreds of suppliers, he said, and most of them charge the same prices for the same goods. A few charge more, a few charge less, and that's what bothers him. The other problem, a big one in his words, is keeping track of credit: who he owes, and how much.

Then he told me the part that made GST matter again. The shop is registered under the composition scheme, so today it can't claim back any GST it pays on purchases. From January 2027 he's moving to regular GST, and from then on every purchase bill has to be good enough to claim the GST back.

So BillSahi changed. This post is about what it does now, and what it found on his four bills.

What BillSahi does now

BillSahi checks a small Indian shop's supplier bills. Take a photo of the bill and it tells you four things:

Is the GST rate right on every line? Every line is checked against the official rate, and any difference is shown in rupees.
Can you claim this GST back? It checks the supplier's GSTIN (format and check digit), your GSTIN on the bill, GST shown on every line, and the HSN and rate on every line, then gives the rupees of credit at risk if something is missing.
Did you pay less for this before? Every line is saved with what one unit cost the shop. When a later bill charges more for the same item, from any supplier, you see it, with the rupees extra on that bill.
How much do you owe each supplier? Every bill is added to that supplier's account; record a payment in one tap and see who you owe, next to what the supplier's own bill says you owe.

It also still does what I first built it for: type items the way a shop writes them ("Parle G 800g", "hawai chappal 199", "ಬಟ್ಟೆ ಸೋಪು 4pc") and get the HSN heading and GST rate.

Who pays, and how much. I asked the owner. He said he would pay, but not much. He buys stock only two or three times a month, so he would use it two or three times a month, and around ₹49 a month is what he said he'd pay. That number shaped the build: at ₹49 a month, every bill check has to cost almost nothing to run, which is why open models matter here (more on that below).

The one rule everything is built around: the model never states a rate. It picks an HSN heading, then one of the official notification entries for that heading, and code reads the rate from the entry. Everything that's arithmetic (rupees overcharged, credit at risk, the ₹2,500 line for clothing and footwear, what one unit cost, what you owe) is done by code.

Demo

Live: https://billsahi-pb7k.onrender.com
The shop's four real bills, as a read-only demo book: https://billsahi-pb7k.onrender.com/?shop=kvr-demo#book

What it found on the four real bills

62 lines across four bills from September and October 2026. The photos were forwarded on WhatsApp, so they are compressed. I didn't retake them; this is what a real shop would send.

Bill	Lines	Read right	What BillSahi found
Hair-oil and soap distributor	10	10 of 10	Aloe vera skin gel billed as hair oil (HSN 3305 at 5%). Skin-care gel is 3304 at 18%: GST short by ₹174.57.
Detergent distributor	3	3 of 3	All rates right. Supplier's printed balance ₹2,13,672 against this bill's ₹3,648.
Cash bill	31	31 of 31	No GST shown at all on ₹15,252 of purchases. 30 of 31 items placed correctly; hair colour wasn't.
HUL distributor (dense, blurry photo)	18	partly	Rows from line 15 shifted by one. BillSahi caught it and marked nothing (see the failure below).

The credit check is where his January problem shows up. Neither GST invoice has the shop's GSTIN on it. Today that doesn't matter, because a composition shop claims nothing. From January, a bill without his GSTIN means the supplier's GST doesn't show up against his GSTIN, and he can't claim it. On these two bills alone that's ₹834.76 + ₹556.48 = ₹1,391.24 of GST, and the cash bill would add ₹15,252 of purchases with no claimable GST at all. That's why BillSahi now ends every bill with "Can you claim this GST back?" and a list of ✓ and ✗.

The aloe vera catch is the kind of thing nobody checks by hand. The bill prints HSN 33059011 (hair oil, 5% since GST 2.0). The product is a skin gel, which is 3304 at 18%. Here the supplier charged less GST than due, so it's not money the shop lost today. But a wrong HSN on a purchase bill is exactly what an officer questions once the shop starts claiming credit.

The detergent supplier's balance is the credit problem in one number: the bill is for ₹3,648, and the top of it says ₹2,13,672 due. Two weeks after this bill, would the owner know which of those numbers is right? In BillSahi's supplier book, the supplier's printed balance sits next to what the shop's own bills add up to, so a gap is visible instead of buried.

Speed. Each bill took between 3.6 and 7.7 minutes on the free hosted Gemma 4 31B, from photo to every line checked: 3 lines in 217 s, 10 lines in 259 s, 31 lines in 353 s, 18 dense lines in 461 s. Most of that is the vision read and one model call per line. It's slow for a demo and fine for a shop that buys stock three times a month; the page prints each line as soon as it's checked, so nobody stares at a spinner.

Code

Ankith-m1006 / billsahi

Right HSN code and official GST rate for small Indian shops, and a check of every supplier bill for the wrong rate. Open models: Qwen3.5-4B fine-tuned on Tinker, Gemma 4.

BillSahi

Is your supplier's bill sahi? BillSahi checks a small Indian shop's supplier bills: the GST rate on every line, whether the bill is good enough to claim the GST back, whether a supplier is charging more than the shop paid before, and how much the shop owes each supplier.

Live: https://billsahi-pb7k.onrender.com · Demo book with four real bills from a supermarket near Pavagada, Tumkur: https://billsahi-pb7k.onrender.com/?shop=kvr-demo#book

Type items the way a shop writes them (brands, Hinglish, Hindi or Kannada, abbreviations, pack sizes) or upload a photo of a supplier's GST bill. BillSahi finds the 4-digit HSN heading, matches the official GST notification entry, and reads the rate from that entry.

The model never states a rate. It picks a heading and an entry; code reads the rate from the official CBIC notifications. When the rate depends on something the item name doesn't say (pre-packaged or loose, sale value above…

View on GitHub

How I Built It

1. The official rates, as data. I parsed every goods entry of CBIC Notification 9/2025-CT(Rate) and the exemption Notification 10/2025-CT(Rate) (GST 2.0, effective 22 September 2025), and applied the later amendments 19/2025 and 01/2026: 1,570 rows covering 1,372 entries, each with its source notification, plus spot checks against the PDF text (data/RATES_PROVENANCE.md).

The thing that surprised me is that an HSN heading often doesn't decide the rate on its own. Heading 3401 holds toilet soap in bars (5%) and other soap and washing preparations (18%). Heading 3304 holds talcum and face powder (5%) and skin-care creams (18%); that split is the aloe vera catch above. So the model's job isn't "guess the code", it's "pick the official entry that describes this item".

2. Search (Tiger Data). The 12,604-code HSN directory and the 1,570 entries live in Postgres on Tiger Data with BM25 indexes (pg_textsearch). Every item first gets a shortlist of headings from plain search. The shop's own book lives in the same database: bills, lines and payments, created on first use.

3. Reading the bill (Gemma 4). Gemma 4 31B reads the photo and only transcribes: supplier and buyer GSTIN, invoice number and date, the bill total, any running balance, and for each line the item, printed HSN, MRP, quantity, taxable value, GST rate and line total. The request is streamed. Before I switched to streaming, the dense HUL bill failed three times in a row with "remote end closed connection": a long, silent request gets dropped as idle, while a streamed one keeps the connection busy.

4. Heading, then entry. For each line, the model picks a heading from the shortlist, then one entry from the official entries for that heading, shown without their rates. Code rejects a heading that isn't in the directory and an entry that isn't in the list, and applies the ₹2,500 threshold for clothes and footwear itself.

Shop bills write things like "PCNO 500ML FT" (Parachute coconut oil) and "MORELIGHT LIQUID 99/-". From the name alone, neither can be placed. When the name fails, BillSahi uses the HSN printed on the bill as a hint and marks the line "read from the bill's HSN". On the real bills that rescued 7 lines: 5 coconut-oil lines and 2 detergent lines. It's used only when the name fails, so a wrong HSN on a named item (like the aloe vera gel) can't hide a wrong rate.

5. Price memory and the supplier book. Plain code (app/ledger.py):

What one unit cost: the line total divided by the quantity. For a composition shop, the GST is part of the cost because it can't be claimed back.
Same item? The same pack size and MRP when both are printed, and most of the name's words shared. Suppliers spell brands differently: the cash bill says "LIFEBOY RED SOAP 125G", and another bill could say "LIFEBUOY". Near-identical words count as shared. A test against the saved real bills flagged a Lifebuoy line at ₹40 a piece against the ₹38 the shop paid before (₹48 extra on 24 pieces), and left alone a Garnier line whose MRP differed (a different pack) and a Santoor line at the same price.
Dues: the bills of a supplier minus the payments recorded, with the supplier's own printed balance shown next to it.
Credit check: the GSTIN check digit is a mod-36 checksum over the first 14 characters, so a GSTIN misread from a blurry photo shows up as "check digit doesn't match" instead of passing as valid.

6. A fine-tuned open model (Tinker). Before the shop visit, I fine-tuned Qwen3.5-4B with LoRA on Tinker to answer the same two questions (heading, then entry) as short JSON. The training data was written by open models and checked by another one. Gemma 4 and Qwen3.5-397B (on Tinker) wrote shop-style item names for every notification entry, and every item was classified blind by the other model and dropped if the two disagreed on the chapter (about 76% kept). That caught real label errors, such as a Hep-B test kit filed under the vaccines' chapter. The result was 20,689 training conversations. Data generation and training together used about $10.69 of Tinker credit.

7. Traces (Sentry). Every item is an agent span with tool spans (search, official entries, sale value) and a chat span for each model call, so one slow or wrong line can be traced to the step that caused it. [TODO: screenshot of one bill's trace]

The failure that matters, and the guard

The fourth bill is the Hindustan Unilever distributor's tax invoice: 18 lines, 14 columns, tiny print, photographed at an angle and compressed twice. The first version of BillSahi read it and reported that one Horlicks line was overcharged by ₹110.20, charged 18% instead of 5%.

That was wrong. Horlicks was billed at 5%. From line 15 down, the model had shifted every row by one: each item's name was paired with the next line's numbers, and the 18% belonged to the Vim bar below it. The last "line" it read was the bill's total row.

For a shop, a false overcharge is the worst mistake this app can make. The owner calls the supplier, the supplier shows him the paper bill, and he never trusts the app again.

So now BillSahi checks its own reading before it says anything about money. The lines must add up to the total printed on the bill. On this bill they added up to ₹27,060 against a printed ₹13,745. When they don't match:

no line is marked overcharged or undercharged; they go back to "check this line on the paper bill";
none of the bill's prices are saved, so a misread price can't later produce a false "you paid less before";
the receipt is stamped RETAKE PHOTO instead of RATES OK, with a note to send the original photo instead of a forwarded one.

On the other three bills the lines matched the printed totals to the rupee: ₹17,530, ₹3,648 and ₹15,252. The check runs in code after every read (ledger.reconcile in app/ledger.py).

Results on the item test set

Before the shop visit I wrote a test set of 57 shop items across kirana, personal care, hardware, stationery, medical, textile and footwear, labelled against the notification text and frozen before training.

Approach	Heading right	Rate right	Wrong rate stated confidently	Median time
Plain search (BM25, no model)	42%	68%	16%	2.8 s
Qwen3.5-4B, base	65%	28% (asks 68% of the time)	0%	5.6 s
Qwen3.5-4B fine-tuned on Tinker (v1, step 200)	67%	84%	16%	5.8 s
Gemma 4 31B (hosted)	91%	100%	0%	23.3 s

Fine-tuning moved the 4B model from 28% to 84% of rates right, at about a quarter of Gemma's time per item. But it still stated a wrong rate confidently on 16% of items, the same as plain search. Its failures were brand names (it filed several under 1511, palm oil) and the price thresholds. So the live app runs Gemma 4 31B, which got every rate right on this set, and the fine-tuned model stays switchable with one setting (HSN_MODEL_PATH). I'd rather ship the slower, correct model than the fast one that is confidently wrong one time in six.

The training run died at step 209 of 647 when my laptop ran out of memory, and my Tinker credit ran out with it. The v1 numbers above are from the step-200 checkpoint. That's honest, and it's where the next ₹49 subscriptions would go.

Why Does Open Innovation Matter?

Price. At ₹49 a month and a few bills a month, a check can't cost more than a few rupees, even with 30 lines on a bill. Open models are what make that possible: Gemma 4 runs on free and cheap hosted endpoints today, and a fine-tuned 4B model runs on hardware a small company can own. A per-token closed API with a 30-line bill and two calls per line would eat that ₹49 quickly.

The data stays the shop's. Supplier bills are a shop's purchase prices, margins and suppliers. With open weights the whole thing can run where the shopkeeper's data already lives, instead of every bill going to whoever owns the model.

The niche is the point. GST 2.0 moved toothpaste, hair oil and toilet soap to 5% and left skin creams at 18%. A general model has no reason to know that the aloe vera gel on this bill is in the 18% heading, or that "PCNO 500ML FT" is coconut oil. With open weights I can train exactly that niche, check it against the official text, and hand the arithmetic to code.

Where a closed model would do better, honestly: reading the blurry HUL bill. A larger closed vision model might have read it in one go. BillSahi's answer for now is to notice when it has misread a bill and say so.

My First User

The owner of a supermarket near Pavagada, Tumkur, gave me his last four supplier bills and answered my questions. What changed because of him:

I stopped treating the GST rate as the main problem. His suppliers charge the right rate: of the 31 lines on his three GST bills, I checked every one by hand, and the only wrong ones were the 2 aloe vera lines.
I added the credit check because he's moving from composition to regular GST in January. Every one of his bills would fail it today.
I added price memory because "a few suppliers charge more" was the first thing he said.
I added the supplier book because tracking credit is, in his words, a big problem.
₹49 a month is what he said he would pay, for two or three uses a month.

He hasn't paid yet; BillSahi isn't a business yet. But it is now the tool he described, not the one I walked in with.

Prize Categories

Gemma: Gemma 4 31B reads every bill photo (streamed vision), places every line in the live app, and got 100% of rates right on the 57-item test set. Gemma 4 also wrote half of the training data and blind-checked the other model's items.
Tinker: Qwen3.5-4B LoRA fine-tuned on Tinker, from 28% to 84% of rates right (table above), plus Qwen3.5-397B on Tinker for training data. Switchable in the live app with HSN_MODEL_PATH.
Render: the web app and API run on Render: https://billsahi-pb7k.onrender.com, with background jobs so the page prints each line as it's checked.
Tiger Data: BM25 search with pg_textsearch over the 12,604-code HSN directory and the 1,570 official entries, and the shop's book (bills, lines, payments) in the same Postgres.
Sentry Agent Tracing: an agent span per item with tool and chat spans for every step. [TODO: screenshot]

What's next

The owner sends the next bill from the same HUL distributor, as an original photo, so price memory gets its first real repeat.
WhatsApp: forward a bill to a number and get the check back, since that's how the bills arrive anyway.
Finish the fine-tune (v2, with the brand-heavy retail data) so the cheap model can take over from Gemma.

BillSahi is a helper, not tax advice. Anything marked "check" or "ask" should be confirmed with an accountant.

AI Assistance Disclosure: I have used Anthropic's Claude Code for planning and helping me to draft this post.

My village has patchy signal and people who know every plant. I built a field guide that sends you to ask them.

Ankith M — Fri, 09 Oct 2026 07:06:14 +0000

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

What I Built

Wayside is a pocket field guide for walks. You snap a plant, bird or insect, put the phone back in your pocket, and keep walking. A few seconds later the phone buzzes and reads the answer aloud: what it is, two things to check with your own eyes, whether it is safe to touch, and what to look for next.

I live in rural Karnataka. Two things about my walks shaped the whole app:

The signal comes and goes. So Wayside opens offline, saves photos taken with no signal, and identifies them on its own when the phone is back in range.
The people around me know these plants by names no app has. The names my mother uses for the plants in our garden are not always the ones in a book, and they change from village to village. So Wayside only shows a local (Kannada) name when Gemma is very sure. Otherwise it says "ask someone nearby what they call it", and saves their answer to your journal.

That second one is my favourite feature, because the best thing an AI can do on a walk is send you to talk to a person.

My walk

On the morning of 9 October, at 7:53, I took Wayside around our garden after the monsoon. It was a short walk, about six minutes, and I spotted 9 things. Two of them came back with Kannada names: curry leaf, ಕರಿಬೇವು and hibiscus, ದಾಸವಾಳ. I asked my mom what she calls them, and she said the same names.

What I liked most: it made me stop in the middle of the walk and look properly at things I walk past every day, and then go and learn what they are. It made me happy.

At the end of a walk you get a walk card: time, distance, what you found, and how much of the walk you spent with the screen off.

Honest number: only 21% of my walk was with the screen off, because I kept looking at the results. That is exactly why the app vibrates and speaks the answer, so next time the phone can stay in my pocket.

Demo

Try it on your phone: https://wayside-1037019152152.asia-south1.run.app (no sign-up; add it to your home screen).

Tap Start walk and put the phone away.
Snap anything green or alive.
Wait for the buzz. If it says "ask someone nearby", ask, and type in what they call it.
Tap End walk for your walk card.

Code

Ankith-m1006 / wayside

A pocket field guide for walks: snap a plant, bird or insect and Gemma names it in English and your local language. Works with patchy signal.

Wayside

A pocket field guide for walks. Snap a plant, bird or insect you spot outside; Gemma names it in English and your local language, gives you two things to check with your own eyes, says whether it is safe to touch, and suggests what to look for next. Then you put the phone back in your pocket.

Try it: https://wayside-1037019152152.asia-south1.run.app (works on any phone; add it to your home screen)

Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.

Why

Most nature apps keep you looking at the screen. Wayside is built the other way round:

Snap and keep walking. Identification takes a few seconds; your phone buzzes and reads the result aloud when it is ready, so the phone stays in your pocket. Speech uses the device's own voices (Android Google TTS, Apple voices on iPhone and Mac, Windows voices); if the device has…

View on GitHub

MIT licensed. No build step and no dependencies on the server: one Node file, one HTML file, a service worker.

How I Built It

Gemma 4 is the whole brain. One multimodal call takes the photo (resized on the phone to 1024 px), the region name and the month, and returns strict JSON: common and scientific name, a confidence score, alternatives, two look-closer checks, a local fact, a safety level, the next thing to find, and the local name with its own confidence.

phone (PWA: IndexedDB queue, service worker)
   |  photo + "Karnataka, India" + "October"   (GPS never leaves the phone)
   v
Node server (/api/identify, /api/quest, /api/speak)
   v
Gemma 4 26B (gemma-4-26b-a4b-it) via Google AI Studio, falling back to Gemma 4 31B
or Gemma on your own machine through Ollama (gemma3:4b), fully offline

Testing it honestly. I did not want a demo that only works on the photos I chose, so I wrote a field test (scripts/fieldtest.mjs) that runs the exact production prompt on photos of 14 things you actually see on a Karnataka roadside, and scores the species and the Kannada name against an answer key.

Results with Gemma 4 26B on the exact production prompt (14 photos, Wikimedia images of things on a Karnataka roadside):

	Result
Species identified correctly	14 / 14 (banana, bulbul, coconut, drongo, frangipani, hibiscus, ixora, kingfisher, lantana, mimosa, myna, neem, plain tiger butterfly, tulsi)
Kannada names shown to the user	5, all 5 correct (ಬಾಳೆಹಣ್ಣು, ತೆಂಗಿನ ಮರ, ದಾಸವಾಳ, ಬೇವು ಮರ, ತುಳಸಿ)
Wrong Kannada names shown	0
"Not sure, ask someone nearby"	8 of 14
Time per photo	21 to 60 s, about 36 s on average

On my real walk the two Kannada names it showed were also right (my mom checked).

What the test taught me:

The confidence gate is doing real work. For the kingfisher, Gemma produced ಬಿಳಿ ಗಂಟಲಿನ ಮೀನುಗಾರ, a word-for-word translation of "white-throated fisher", not a name anyone in a village uses (people say ಮಿಂಚುಳ್ಳಿ). It rated its own confidence at 0.7, so the app hid it and asked the walker to ask a neighbour. Eight out of fourteen times the honest answer was "ask someone", and that is the point of the app.
The first version of the prompt invented local names. For an Ixora it gave "Rangan", which is the Marathi name, for a Kannada request. For the bulbul it wrote the English word in Kannada script. So the prompt now forbids other languages and transliterations, asks Gemma how sure it is about the local name, and the app hides anything below 0.85 and sends you to a neighbour instead. A wrong name stated confidently is worse than "ask someone".
I tried two more features and dropped them. Bird calls: the Gemma 4 API does not take audio input yet. A written nature journal: Gemma thought for over 8,000 tokens and three minutes to write a bland paragraph. Neither got people outside, so they went.

Small things that keep the phone in the pocket:

The phone vibrates and speaks the result (device voices, with a Google Cloud Text-to-Speech fallback for languages like Kannada that phones often lack).
Best time to walk today from Open-Meteo's open weather data: the driest, coolest hour before sunset.
A daily quest: three things common where you are in this season.
Any region: on first open it asks where you walk (Karnataka, California, Kenya...) so names and quests fit.

Privacy: only the photo, the region name and the month are sent. Location stays on the phone and is only used to draw your route.

Safety: wild plants and mushrooms are never called safe to eat, whatever the model says.

Why Does Open Innovation Matter?

Because Gemma is an open model, this does not have to depend on a big company's server or an internet connection. A village school, a farmers' group or a forest guide can run the same app on their own laptop with Ollama, with no bill and no signal. The names of plants belong to the people who use them, like my mom, and with open code anyone can add their own village's names. And because the model and the code are open, I could test exactly what it does, like the field test above, instead of trusting a black box.

Prize Categories

Best Use of Gemma: Gemma 4 (26B, with 31B fallback) does all the identification and quest writing in production; the same code runs on Gemma 3 4B locally with Ollama, fully offline.

I used an AI coding assistant while building this. The idea, the walk, the photos, my mom's names and the testing are mine.

Thanks for reading. Now put the phone down and go outside. 🌿

I tested 11 AI models on Indian GST, UPI and lakh-crore. Three famous ones got Puducherry wrong.

Ankith M — Tue, 06 Oct 2026 10:34:02 +0000

This is a submission for the Kaggle Benchmarking Challenge

What I Benchmarked

I build software for Indian small businesses (POS, billing, payments), and this month I've been contributing Kestra workflow blueprints for Indian finance: GSTIN validation, UPI end-of-day close, GSTR-2B reconciliation. Every one of them exists because one small mistake costs real money:

one mistyped character in a supplier's GSTIN and the input tax credit is at risk,
IGST booked as CGST + SGST and the buyer can't claim it,
"5 crore" written as 50 crore,
a UPI payment that "went through" on the customer's phone but never reached the shop.

So I asked: can AI models handle everyday Indian business data? I built a Kaggle benchmark with 6 tasks, 16 cases each:

Task	What the model has to do
`india_gstin_check_digit`	Validate a GSTIN and compute its Luhn mod 36 check character (algorithm given)
`india_gstin_from_memory`	Same, without being told the algorithm
`india_gst_tax_split`	Split GST into CGST + SGST, CGST + UTGST or IGST, with real traps: supplies to an SEZ unit in your own state, and Union Territories with and without a legislature
`india_invoice_number_rules`	Apply GST invoice-number rules (16 characters, only letters/digits/`-`/`/`, unique per financial year) with look-alike traps: en dash, division slash, trailing space, 17 characters, extra leading zero
`india_lakh_crore_formats`	Indian digit grouping (12,34,56,789), lakh/crore conversions, cheque amounts in words
`india_upi_reconciliation`	Match 18–30 UPI bills against a settlement report and list the bills whose money never arrived, arrived short, or share a UPI reference

How it's graded:

Every case is generated from a fixed seed with an exact answer key. No LLM judge.
Answers come back as structured output, so grading is exact.
The GSTIN answer key is cross-checked against python-stdnum (0 disagreements). The other answer keys use the same logic as my Kestra blueprints.
Every model gets the same answer budget. A case that errors (provider down, credit limit) is not counted as wrong. It's left blank.

Models Tested

I picked a mix to see what matters most: size, "thinking", or being open-weight.

Frontier: GPT-5.5, Claude Sonnet 5, Gemini 3.7 Flash, Gemini 3.5 Flash
Fast / small: GPT-5.4 nano, Claude Haiku 4.5, Gemini 3.1 Flash-Lite
Open-weight: gpt-oss-20b, Gemma 4 31B, Qwen3 235B Instruct, DeepSeek R1

(Grok 4.6 and gpt-oss-120b were unavailable through Kaggle's model proxy while I ran this, so they're not on the board.)

Findings

Overall (average of task scores): GPT-5.5 1.00 · Gemini 3.7 Flash 1.00 · Gemini 3.5 Flash 0.99 · Claude Sonnet 5 0.98 · Gemma 4 0.97 · DeepSeek R1 0.96 · gpt-oss-20b 0.92 · Gemini 3.1 Flash-Lite 0.75 · Qwen3 235B 0.51 · Claude Haiku 4.5 0.45 · GPT-5.4 nano 0.34

1. Puducherry is a State (for GST), and three famous models disagree

This was my favourite result. Under the CGST Act, section 2(103), a Union Territory with its own legislature (Puducherry, Delhi) counts as a State. So a sale inside Puducherry is CGST + SGST. UTGST is only for UTs without a legislature, like Chandigarh or Ladakh.

Claude Sonnet 5, DeepSeek R1 and Gemma 4 all charged UTGST on a Puducherry sale.
Claude Haiku charged UTGST and IGST on the same sale, so it taxed it twice.
GPT-5.5, every Gemini model, Qwen and even tiny GPT-5.4 nano got it right.

Bigger isn't uniformly better. Models fail on different local rules.

2. Checksums are a cliff, not a slope

On the GSTIN check character, every model that reasons step by step scored 100%, and every fast model scored 6–12%. That's no better than guessing. Small open models that reason (gpt-oss-20b, Gemma 4) beat bigger fast ones. In an early test, one model needed about 15,000 thinking tokens and 84 seconds for a single GSTIN. Correct isn't always cheap.

3. The SEZ trap

A supply to a Special Economic Zone unit in your own state is still an inter-state supply, so it's IGST (IGST Act, section 7(5)(b)). Claude Haiku, gpt-oss-20b and GPT-5.4 nano split it into CGST + SGST anyway.

4. 10× errors with lakh and crore

The small models made the most dangerous kind of mistake, being off by exactly one digit group:

"5 crore" → 500000000 (it's 50000000)
"Rs 98,64,000 in lakh" → 986.4 (it's 98.64)
Indian grouping written the Western way: 8,263,425,718 instead of 8,26,34,25,718

5. Invisible characters

On GST invoice numbers, the look-alikes caught the small models: a trailing space, a 17-character number, and a number with an extra leading zero (a different number, so it's allowed) that they called a duplicate. All the big models were perfect here.

6. UPI: the misses are the dangerous part

On days with 18–30 UPI bills, weaker models missed bills whose money never arrived (Claude Haiku 44%, Qwen 25%). A false alarm costs a minute. A missed bill is silent lost money.

7. The best value is open

On Kaggle's score-vs-cost chart, the efficient frontier runs through the open-weight gpt-oss-20b and Gemma 4 31B. They get most of the way to the top score at a small fraction of the cost.

What I'd measure next

GST rate schedules and HSN codes (which rate applies, not just how to split it)
E-invoice JSON validation
Invoices in Hindi and regional languages

My Benchmark

👉 Indian Business Data: GST, UPI and Lakh-Crore on Kaggle

All 6 tasks and their notebooks are public, so you can run them on any model.

I used an AI assistant to draft this post. The idea, benchmarking, the Indian accounting rules and the final review are mine.

GitHub said 31 issues were open. 0 were actually free. So I built Unclaimed for my best friend

Ankith M — Sun, 04 Oct 2026 18:35:33 +0000

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

What I Built

My best friend @SanjanaG-01 and I are both taking part in Kestra Hacktober this October. Writing the code is not the hard part. Finding an issue nobody has taken yet is.

On a busy repo, a fresh good first issue gets its first "can I work on this?" comment within about 20 minutes. By the time you open it, it might already have a pull request, five people asking for it, or a maintainer saying it isn't ready yet. GitHub still shows it as open.

So I measured it. GitHub's own search for open, unassigned good first issues in kestra-io/kestra returned 31 issues. When I checked every one of them:

21 already had a pull request (one had three)
8 had people asking for them in the comments (up to 11 on a single issue)
2 were marked "not ready for contributions"
0 were actually free

That's why I built Unclaimed. Paste a repository, and it tells you which issues are really Free, which are Claimed, which Have a PR, which are Assigned and which are Not ready, with proof for each one. Instead of opening 30 tabs and reading every comment, my friend sees the free ones first.

Demo

Try it live: https://unclaimed-production.up.railway.app

Paste any public repo, or a link to a single issue. It works beyond Kestra too: on zed-industries/zed it found that the repo calls its label .contrib/good first issue, and showed 4 of the 15 newest issues as free.

Code

Ankith-m1006 / unclaimed

Find open-source issues nobody has taken yet. Gemma reads every issue thread for you.

Unclaimed

Find open-source issues nobody has taken yet.

During Hacktoberfest, a fresh good first issue can get its first "can I work on this?" within 20 minutes. By the time you open it, it may be assigned, already have a pull request, carry a "not ready for contributions" banner, or have five people asking for it in the comments. Unclaimed checks all of that for you.

How it works

Hard facts from the GitHub API. For each open issue with the label you choose, it checks the assignees, linked pull requests (open or merged, from the issue timeline), and the "not ready for contributions" banner some projects add. Any of these settles the verdict without asking the model.
Gemma reads the thread. When nothing hard blocks the issue, the comment thread decides. Gemma 3 (4B), an open-weight model, runs on our own Ollama server and reads the issue and its…

View on GitHub

How I Built It

Unclaimed works in two steps.

1. Facts from GitHub first. For each issue it checks the assignees, the linked pull requests, and the "not ready" banner some projects add. If any of these settles it, the model is not needed at all.

2. Gemma reads the rest. When nothing hard blocks an issue, the comments decide. Gemma 3 4B, running in Ollama on our own small server, reads the issue and its latest comments and returns structured JSON: who asked to be assigned, who says they're working on it, what a maintainer decided, a one-line summary of the work, and a difficulty estimate.

Every claim comes with its proof: the person's real comment, their avatar, the date, and a link. You don't have to trust the model blindly.

The stack is deliberately small: plain Node.js, one HTML page, Gemma 3 through Ollama, and two containers on Railway.

What went wrong (and how I fixed it):

The 1B model wasn't good enough. gemma3:1b was fast, but it said "nobody asked" on an issue where five people had. Switching to gemma3:4b fixed accuracy at about 6 to 16 seconds per issue on CPU.
Requests timing out. The small model kept generating inside the JSON until it hit the timeout. Capping the answer length fixed it.
One rule made it worse. Someone wrote "I think you missed assigning this to Omer", and it counted as a claim. When I told Gemma to only count people asking for themselves, it became too cautious and missed all five real claimants. A small code rule worked better: let the model be generous, then correct it with cheap checks you can verify.
Hidden maintainers. On freeCodeCamp, a maintainer's standard note was counted as six claims, because many maintainers keep their organisation membership private. Now anyone who labelled or assigned the issue counts as a maintainer.
The token that hid pull requests. After I added a read-only GitHub token, issues with open PRs suddenly looked free. GitHub leaves pull request links out of the issue history for fine-grained tokens. The fix was to also search for PRs that mention the issue.

I checked it against 8 real issues I had read by hand, and it got all 8 right.

Why Does Open Innovation Matter?

Unclaimed reads other people's comments and usernames. With an open model on our own server, none of that goes to a closed AI company. There's no per-request bill either, so my friend can re-check as often as she likes during a race that is measured in minutes. And because it's open, she can run the whole thing on her own laptop with ollama pull gemma3:4b and node server.js. An open model helping people make their first open-source contribution felt like the right fit.

Prize Categories

Best Use of Gemma

Built with my best friend @SanjanaG-01. Good luck to everyone in Hacktober, and read the thread before you ask for an issue!

Thank you