DEV Community: Raman Tiwari

Sloth Ledger: the model has an opinion, the ledger has the numbers

Raman Tiwari — Sat, 24 Oct 2026 17:18:05 +0000

TL;DR — Describe a chore in plain English. An open-weight model decides whether to automate it, hand it to a human, or ignore it forever. When an automation actually runs, the reclaimed minutes go into a Tiger Cloud hypertable, and every figure on screen prints the arithmetic that produced it. Runs locally with python app.py; also deployed on Render's free plan, where the web process is disposable and the ledger is not.

Repo: https://github.com/ramantiw45/SlothLedger
Live demo: https://sloth-ledger.onrender.com

The problem with "this saved me hours"

Every automation post ends the same way. The tool saves you time, the author says so, and the number is whatever the author felt like typing.

I have written two of those posts this month. So this week I wanted to build the opposite: a ledger that refuses to print a saving it cannot show. Not a productivity dashboard with a big friendly number, but the receipt behind the number, including the part where the automation did not pay off.

The theme is Slow and Steady. The slow part is the accounting. The steady part is that the accounting keeps working after the demo is over.

One rule, enforced in code

The model never produces a figure that ends up in the ledger.

If the chore carries a countable quantity, the minutes come from count × a per-item rate kept in a plain table in sloth/model.py: a receipt is 20 seconds, a statement line 30, a file rename 8. You can read the table and argue with it.
If you measured the chore yourself, your number wins.
Only when there is nothing countable does the model's estimate stand, clamped to 1–480 minutes.
Weekly and all-time totals come from SQL. Never from text a model generated.

In a live call during the build, the model proposed 20 minutes for renamed 40 receipts from the shoebox. The ledger booked 13, because 40 × 20 seconds is arithmetic and arithmetic belongs to the database. That disagreement is the feature. A card prints 40 × 8s = 5 min under its description, so you can check it with a calculator and a bad attitude.

The trust boundary is not "we used a good model". It is that the opinion and the number travel on separate wires.

What it looks like

The interface is a card tray, not a dashboard: manila index cards on a dark desk, verdicts as rubber stamps, a punch hole in every card whose minutes came back, and a total that gets restamped when the ledger changes.

I went this way because every productivity tool looks like the same grid of rounded KPI tiles, and a ledger should look like something you could drop on a desk. The ruled lines are not decoration: typed text sits on them at a fixed 28px rhythm.

Slow and steady, measured

The demo ledger, after eight chore entries and four automation runs:


Reclaimed this week	15m
All time	43m
Still on you	16m
Chores judged	8
Automations run	4

The live demo is a shared ledger: its totals move as visitors use it. The table and the screenshots are the snapshot from the build; the arithmetic printed on each card is the part that does not move.

That still on you line is the one I care about. It is the manual time in chores the tool declined to automate, and it is allowed to grow. A ledger where every number only goes up is a sales pitch, not a record.

Fifteen minutes in a week is not a headline. It is what an honest first week looks like when you count setup time against savings and refuse to round up.

Why open weights are the core, not a badge

The judgement lane is Qwen 3.8 27B, an open-weight model served over an OpenAI-compatible API by Groq. Three environment variables point the app at any compatible host, including a local server on http://127.0.0.1:11434/v1 if you prefer to keep it on your own machine. The demo used the hosted lane; the model that judged those eight chores was qwen/qwen3.8-27b.

Under it sits a deterministic rules floor. With no key, no network, and no model, the app still answers: same output shape, same ledger, a little dumber about intent. That means the product never depends on a vendor staying online, staying affordable, or staying in business.

Why not a closed model? Two reasons, and the second is the one judges should care about.

Swap cost. The model is one file and one HTTP call. Replacing it with next year's open-weight model is a config change, not a migration. The per-item rates, the schema, and the arithmetic do not move.
Auditability. The whole argument of this project is that an opinion and a number should not come from the same black box. A closed API that both judged the chore and totalled the savings would reproduce exactly the problem the ledger exists to solve.

Open innovation here is not a licensing preference. It is what lets a stranger re-run my arithmetic on their own machine and get the same ledger.

How it works

flowchart LR
  A[Browser: card tray] -->|POST /api/log| B[Python stdlib server]
  B --> C{Judgement lane}
  C -->|key set| D[Qwen 3.8 27B<br/>OpenAI-compatible API]
  C -->|no key| E[Deterministic rules floor]
  D --> F[Reconcile: count x rate beats estimate]
  E --> F
  F --> G[(Tiger Cloud<br/>hypertable + continuous aggregate)]
  G -->|SQL totals| A

The stack is deliberately small: http.server, vanilla HTML/CSS/JS, SQLite as the default store, and pg8000 (pure Python) for the Postgres lane. Python 3.14 has no wheels for most Postgres drivers, and a compiler on the judge's laptop is a bad install story.

What Tiger Data is doing that SQLite is not

The reclaimed minutes are a time series, so they live in a hypertable:

CREATE TABLE ledger.reclaimed (
    reclaimed_at timestamptz NOT NULL,
    chore_id     bigint REFERENCES ledger.chore (id) ON DELETE CASCADE,
    automation   text NOT NULL,
    minutes      numeric NOT NULL CHECK (minutes >= 0),
    source       text NOT NULL DEFAULT 'run'
);
SELECT create_hypertable('ledger.reclaimed', 'reclaimed_at');

The top-automations panel does not scan that table. It reads ledger.reclaimed_daily, a continuous aggregate bucketed by day with a refresh policy, so the query stays small as history grows. A compression policy moves chunks older than 30 days to columnar storage. In this deployment the app connects as a least-privilege role (sloth_app) with grants on the ledger schema only, not as the database owner.

None of that is visible in a screenshot, which is the point: it is the difference between a demo that survives a year of entries and one that gets slower every week.

Deployed on Render, including the parts that sleep

The public demo is a Render web service built from the repo's render.yaml: Python 3.12, free plan, Singapore region, health check on /healthz, and a build step that installs exactly one package. The two secrets are sync: false in the blueprint and pasted into the dashboard once, so neither the Tiger connection string nor the model key ever enters git.

Render's free plan sleeps after fifteen minutes without traffic, and the first request afterwards takes a few seconds. That constraint is why the split matters: the web process is disposable, the ledger is not. I can redeploy the service and every reclaimed minute is still there when it wakes, because the minutes live in the hypertable, not on the instance's disk.

Because every visitor shares one ledger, the deployed build sets DEMO_MODE=1: writes are rate-limited to eight per visitor per ten minutes, and the header says public demo · shared ledger. The page is honest about being a demo instead of pretending the seeded chores are yours.

Four things that broke, written down

Groq returned 403 with no useful body. Python's default User-Agent was being rejected by the WAF in front of the API. Identifying the client (sloth-ledger/0.1) fixed it. This is the kind of bug that looks like a bad key for an hour.
llama-3.3-70b-versatile was gone. The model name from every tutorial returned 404. Listing /models for the key showed the current catalogue and I moved to qwen/qwen3.8-27b. Pinning a model name in a tutorial is a gift with an expiry date.
Tiger returns numeric as Decimal and timestamps as datetime. json.dumps refused both. The fix belongs at the store boundary, not in every route: one normalising step in _rows.
The first deployed request used the rules floor and said nothing. Falling back quietly is the right behaviour for a person typing a chore and the wrong behaviour for me. I added one stderr line naming the lane and the HTTP status; the next build called the model. The cause of that first miss was never proven, which is the argument for logging a fallback rather than trusting it.

Related work

Week 3 has a healthy sloth population. Sloth Errands runs web chores overnight and asks before it pays; SlothDesk goes after digital busywork; InvoiceSnap turns receipt photos into expenses with local AI.

All three automate the chore. Sloth Ledger asks the next question: did it actually pay? That is why the tray keeps the chores it refused, and why the total is allowed to be small.

Run it yourself

git clone https://github.com/ramantiw45/SlothLedger
cd SlothLedger
python app.py                       # http://127.0.0.1:8787

No install step. Without a .env you get the rules floor and a SQLite file. To use the same lanes as the demo, copy .env.example to .env and set MODEL_BASE_URL, MODEL_API_KEY, MODEL_NAME, and optionally DATABASE_URL for Tiger Cloud.

The hosted demo is this same code with HOST=0.0.0.0 and DEMO_MODE=1; render.yaml and docs/deploy.md are in the repo. It sleeps on Render's free plan, so give the first request a few seconds.

The checks I ran before writing this:

python tests/test_ledger.py     -> 11 tests, OK
python tools/smoke_http.py      -> 15 checks passed (live server, real database)

The smoke test logs a chore, books an automation, refuses a second booking of the same chore, and rejects an empty description. The SQLite and Postgres lanes share one interface, so the same suite covers both.

Credits and disclosure

Built for the Hacktoberfest Open-Source AI Challenge, Week 3. MIT licensed. The demo corpus is a labelled synthetic freelancer week, not a real person's measurements; the eight chores live in tools/seed_demo.py and you can replace them with your own.

AI assistance: I used an AI coding agent for implementation and editing, and an open-weight model at runtime for judgement. Every number in the screenshots comes from the database, and the arithmetic that produced each one is printed on its card.

Udhaar Book: photograph the khata, get the udhaar back

Raman Tiwari — Sun, 18 Oct 2026 19:54:43 +0000

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

TL;DR — Photograph one page of a shop's handwritten credit notebook. An open-weight model reads it (a deterministic parser takes over when there is no key), the shopkeeper confirms every line, the balances follow, and each customer gets a polite WhatsApp reminder in their own language. The AI does the reading; the shopkeeper does the deciding. Repo: https://github.com/ramantiw45/UdhaarBook

What I built

Every kirana, medical and vegetable shop around me runs on a khata — a paper notebook where credit gets written in pen, in a hurry, at the counter. "Ramesh — cheeni 2kg + tel — 340." Nothing is typed anywhere. When money comes back, it's squeezed into the margin in a different pen, and the running balance lives in the shopkeeper's head until the day it doesn't.

The money isn't lost because customers are dishonest. It's lost because asking is awkward. Nobody wants to walk up to a neighbour and say "aapke ₹140 baaki hain" — so the shopkeeper waits, the page gets older, and by month end he genuinely isn't sure who owes what any more.

Udhaar Book does three things:

Reads one page of the notebook from a photo. Local OCR if it's installed, an open-weight model otherwise, a plain deterministic parser if there is no key at all.
Shows every line for confirmation. Nothing is written to the ledger until a human says it's right.
Turns balances into reminders, in English, हिंदी or मराठी — with the figure coming from the ledger, never from the model.

Who would pay for this

This is the part I took seriously, because "Side Hustle" invites you to hand-wave it.

A shop carrying ₹40,000 of udhaar with even 5% quiet leakage loses ₹2,000 every month to money it has already earned. Recovering a third of that is ~₹650 a month. The app costs ₹0 to run: free-tier model lanes, one SQLite file, one Android phone that is already on the counter. Charge ₹99/month and the tool has paid for itself the first time it recovers a single ₹140 line.

The competitor is not another app — it's the pocket of khata apps that want the shopkeeper to type every entry. That's the same reason the money gets lost in the first place: the entry never gets made. The only input that already exists in every one of those shops is the photo of a page.

Demo



Read — photo the page, or tick "use the sample page" and walk the whole flow with nothing installed.	Confirm — every line the reader found, editable, with the raw text one tap away.

The book — the ledger: what was given, what came back, what is left, per page.	Who to ask — the reminder screen. Names stay coded until you tap; the message is already written.

One page of the sample notebook: 12 transactions, 8 customers, ₹3,210 given, ₹1,000 received, ₹2,210 still out. Three of those eight have both taken credit and paid some back — that's the state a shop actually lives in, and the one a hand-written margin is worst at tracking.

Why open matters for what I built

The shop's record of who owes what, and to whom is about as private as a small business gets. Names, amounts, neighbourhood relationships. That record should not require an account, a subscription, or an API that reads it.

Reading: gemma-4-26b-a4b-it (open weights) via Google AI Studio's free tier, qwen/qwen3.8-27b on Groq as failover, gemma3:4b via Ollama when the shop's own machine can carry it, and a deterministic parser with no key and no network as the floor.
Swapping is one env var. Ollama and Groq speak plain chat-completions; Gemma 4 on AI Studio has a small native-route adapter (it is no longer served on the OpenAI-compatible endpoint). Pointing OLLAMA_BASE_URL at a local model still moves the whole pipeline on-device with zero code changes. Nobody can re-price a shop's own bookkeeping.
Cost structure: at ₹0 per page, the ₹99/month price is a business. Per-token billing turns every read into a cost of goods, and at a ₹99 price point that math gets thin fast.
Data shape: one SQLite file. It can be copied, backed up, deleted, or never uploaded at all. There is no vendor in the middle of a shop's ledger.

The honest asterisk: the model only writes the sentence, never the number. The amount in a reminder is read from the ledger; the model gets to soften the wording and nothing else. That rule is in the code, not the prompt.

One more thing, because "runs locally" is the easiest claim in a hackathon post to fake: the repo ships docs/offline-proof.md, a five-step test (install the reader, switch the Wi-Fi off physically, submit a page) and a table of what each possible outcome lets you claim — including the claims you are never allowed to write, like "100% offline" after a hosted lane answered the request. On this machine the honest row is the third one, and that is the row I used.

How it works

  one photo of a khata page
        │
        ▼
  local OCR (optional, CPU only) ──► raw text
        │  no OCR installed: the photo goes straight to the lane
        ▼
  open-weight lane chain
    gemma3:4b       Ollama, on-device, offline
    gemma 4 26B A4B AI Studio, free tier (native generateContent)
    qwen 3.8        Groq, failover
    deterministic   no key, no network — text only
        │
        ▼
  transaction rows ──► shopkeeper confirms ──► one SQLite file
                                                   │
                                     ┌─────────────┴─────────────┐
                                     ▼                           ▼
                            balances per customer      WhatsApp reminder
                                                        en / हिंदी / मराठी

Stack: FastAPI + Jinja2 + SQLite + httpx. No model SDKs, so a new lane is a dozen lines and a Python upgrade can't break the app on a Tuesday. Fonts are self-hosted; nothing on any screen makes a third-party request.
The reminder is a link, not a send. wa.me/?text=... opens WhatsApp with the message written. Nothing leaves the server, no customer phone numbers are stored, and the shopkeeper still chooses who gets it.

The decision that took the longest

I am not going to pretend this was an OCR problem. Reading a messy page is the easy half.

The hard half is that this screen lives on a counter where other people can see it. The reminder screen is a list of the shop's debtors, and a shopkeeper will not use a tool that flashes a neighbour's name at whoever is standing there.

The screen I designed for is 9pm: shutter half down, one tube light, the shopkeeper alone with the notebook and a phone. That is the one moment the names are safe to show — and the moment the screen has to be worth opening.

So the names are coded: each customer shows as an entry number (their place in the order to ask), a hue strip and an amount, and one tap decodes the row into the name, the plain-language history ("Page 1 · 1 line · last 15/10 · ₹560 given") and the message. The first row is decoded on load, so the screen teaches itself in one look. Decoding is a one-tap act on a 68px row, and Reveal opens all eight when the counter is finally empty.

The screen is built as a catalogue sleeve, not a dashboard: one white hairline per customer, the amount as the only headline, identity as a hue strip and a number until you touch it. That is written down as a design system rather than left as taste.

Two more things I made the design carry its weight on:

Nothing is signalled by colour alone. A filled strip means credit was given; a hollow strip with a line through it means money came back. Strip the colour off and the meaning is still there — which also matters because a shopkeeper will screenshot this and print it.
The reminder screen must survive a greyscale print, so I checked it in greyscale, not just in the browser. It does.

What I got wrong

An honest build log, because the flaws are more useful to read than the features.

My machine cannot install the OCR layer. Python 3.14 has no wheels for the usual on-device runtimes yet, so on this box the photo path is: no local reader → model lane. With an AI Studio key set, an uploaded test khata page went through the Gemma lane and came back as rows in the confirm table; with no key, the screen says exactly that and hands you the sample page. The local OCR path is written, documented in requirements-ocr.txt and untested here. That is a gap, not a feature, and I've labelled it one in the README.
No shopkeeper has used this yet. No field test, no first user, no one has paid me ₹99. The sample notebook is a fixture I wrote; the shop name in the screenshots is a fixture shop. I would rather say that plainly than dress up a demo as a deployment.
Handwriting is genuinely hard, and the honest move is to say so. A benchmark of four open-source OCR engines on 5,578 handwritten prescriptions found the best of them get one word in three exactly right. I read that before building and it changed the design: the app does not try to be right, it tries to be checkable. Every figure is one tap from the raw text the reader saw, and the ledger never accepts a row nobody confirmed.
Devanagari handwriting is the weakest case for every reader I looked at. The reminder templates are in Marathi and Hindi because the message is the part that must feel native, but I am not going to claim the reading is equally strong in all three scripts.

Also worth reading, if you are building in this space

Three posts that shaped this build:

I Built a Receipt Bookkeeper That Runs AI Fully Offline — the closest project to this one this week, and the cleanest statement of why the economics only close with open weights. Different user: their freelancer has a wallet of printed receipts; mine has a paper notebook and no laptop.
How Well Can OCR Read Doctor Handwriting in 2026? — the 1-in-3-words number above, measured rather than assumed.
Building for the Next Billion Users: Engineering for Emerging Markets — why every screen here is phone-first and why a dead end with no key would have been the real failure.

Prize categories

Best Use of Gemma. Gemma 4 is the default hosted reader (gemma-4-26b-a4b-it, the fast MoE variant, via AI Studio's free tier on the native generateContent route — the OpenAI-compatible one stopped serving Gemma after 3 was retired in 2026), and Gemma 3 4B (gemma3:4b via Ollama) is the on-device lane. The two Gemma lanes sit at the two ends of the price/privacy trade-off — one free and remote, one free and offline — and both are selected by environment variable, not by code.

Run it yourself

git clone https://github.com/ramantiw45/UdhaarBook.git && cd UdhaarBook
python -m venv .venv && .venv\Scripts\activate     # or source .venv/bin/activate
pip install -r requirements.txt
uvicorn app:app --reload                            # http://127.0.0.1:8000

No key needed to judge it. Tick use the sample page, press Read this page, and the whole flow runs on the built-in parser: 12 transactions, 8 customers, ₹2,210 outstanding, and a Marathi reminder at the end. Add one free AI Studio key in .env and the same flow goes through Gemma; add OLLAMA_BASE_URL and it never leaves the machine. pip install -r requirements-ocr.txt adds the on-device photo reader where wheels exist.

Tests: python tests/test_pipeline.py (5 checks — parsing, money maths, reminders, the no-key path, and the native Gemma request) and python tools/smoke_http.py (20 checks against the running app, including "an uploaded photo fails honestly, with 200, not a blank page"). Neither needs a test framework installed.

Credits

Built with an AI coding agent in an opencode session over one weekend. The product truth was the human's — the shopkeeper, the counter scene, the rule that names stay coded — and the visual direction was chosen from options the agent dealt and built; the agent wrote the app, the test suite, the design system and this draft, and the human approved each ship decision. FastAPI, Jinja2, SQLite, httpx, the self-hosted Rajdhani, Mukta and Spline Sans Mono (all SIL OFL), and the open weights of Gemma 4, Gemma 3 and Qwen 3.8. The sample notebook is synthetic and labelled as such in the repo.

AI disclosure: some_ai.

I planned a walk in 60 seconds, then walked for two hours (open-weight AI, no GPU)

Raman Tiwari — Thu, 08 Oct 2026 16:11:41 +0000

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

TL;DR — One input gives you one walk: the best time window, a loop idea, a nature cue and a packing line, plus a live map pin. Under a minute on screen, then you go outside. Open-weight openai/gpt-oss-20b via Groq's free tier, no GPU, $0 to run.

Live: https://foliage-walk-planner.onrender.com
Repo: https://github.com/ramantiw45/Hacktoberfest/tree/main/week-01-touch-grass

What I Built

A walk planner for people who keep meaning to get outside and don't. You enter a place and a time budget; you get back the best two-hour window, a 2–3 km loop idea, one nature cue worth looking for, a packing line, and a map pin. Then you close the tab and walk.

I built it because planning the walk is exactly where plans die. Weather apps want a full day of your attention, trail sites want a login and ten minutes of map-fiddling, and foliage trackers are US-only. I wanted the whole decision to fit inside one minute, because at one minute it competes with nothing.

On my own test walk I spent about one minute on the screen and one to two hours outside — roughly sixty to one. The screen being the shortest part of the experience is a design target here, not a slogan.

Demo

Live: https://foliage-walk-planner.onrender.com — try Virar (19.45510, 72.82513) or Prospect Park (40.660, -73.969). Cold start takes ~30–60s on Render's free tier.

Verbatim output for Virar (this screenshot predates a prompt fix described below, which is why line 3 is wrong for India):

10:00-12:00
2-3 km loop around Virar Lake promenade (no car needed)
First golden leaves on the banyan trees
Water, a light jacket, and a phone charger
It's a real nature escape that recharges your brain more than scrolling.

Field test — I took it to Virar

One tap, then I went outside for one to two hours. From the walk:

What worked. The plan named a destination I would not have picked myself — the lake promenade — and the "no car needed" line meant I walked instead of driving somewhere and sitting in a car park. The packing line (water, light jacket) was correct.

What failed, honestly.

Weather never rendered on the deployed app. Render's free tier shares one outbound IP across many instances, and Open-Meteo rate-limits that IP. So the forecast silently fell back to generic advice. My fix (a 10-minute cache plus one polite retry, with stale-if-error) landed after this test, which is why the failure is still visible in the screenshot above. I'm leaving it visible rather than retaking a flattering one.
"First golden leaves on the banyan trees" is a New England line, not a Maharashtra one. The prompt was written for autumn foliage. In mid-October Virar the banyans are still deep green, so I ignored the cue completely. Testing a fall-foliage tool in a city with no fall foliage is my mistake, and it's the clearest lesson of the build. The prompt now asks for a cue that is true for the given location in October.
The suggested window was wrong by hours. It said 10:00–12:00; I went early morning, because the midday haze in my own photos is the honest reason to go earlier. The app couldn't tell me that — the weather call was the part that failed.

Would I use it again next weekend? Yes — for the destination, not for the foliage talk. "Here is a walk you can start in 60 seconds" is the value. If the weather call worked, it would have told me early morning beats midday, which is exactly what I did.

Code

https://github.com/ramantiw45/Hacktoberfest/tree/main/week-01-touch-grass — public, MIT LICENSE, no API keys required for the map or weather.

pip install -r requirements.txt
copy .env.example .env   # add GROQ_API_KEY from console.groq.com (free, no card)
uvicorn app:app --reload --app-dir week-01-touch-grass
# open http://127.0.0.1:8000

With no key at all the app still serves a mock plan plus readable lane errors, so you can always click through.

How I Built It

Model: openai/gpt-oss-20b — OpenAI's open-weight model, Apache-2.0, on Hugging Face — served through Groq's free tier on an OpenAI-compatible endpoint. Swapping models is one env var: GROQ_MODEL, or GEMINI_MODEL for Gemma 3, or MODEL_ID for any Hugging Face model.
Stack: FastAPI + Leaflet/OpenStreetMap (no Google Maps key) + Open-Meteo (no key), deployed on Render's free tier.
No GPU required. The same weights run on a laptop later via ollama run gpt-oss:20b.

flowchart LR
  User-->Web[Leaflet + FastAPI]
  Web-->Weather[Open-Meteo, cached]
  Web-->Lane[Free lane chain: Groq - AI Studio - HF - mock]
  Lane-->Plan[2-hour walk plan]
  Plan-->Outside[Go outside]

The honest build log: two providers died mid-week

This is the part I did not expect.

I started on Qwen 2.5 via Hugging Face. It worked, then stopped:

HTTP 402, "Payment Required." Hugging Face had moved Inference Providers behind paid credits. I checked their free hf-inference lane programmatically and found essentially no chat models left on it. Dead end.
So I moved to Groq — and got a 404. I probed the endpoint with a deliberately fake API key and got a 401 back, which proved the path was correct and the model ID was the problem, not my code.
Reading Groq's live model docs showed both Llama 3.x models had been moved to Enterprise. Their free tier now offers openai/gpt-oss-20b, which is open-weight under Apache-2.0 and free — so the swap made the open-source story stronger, not weaker.

Two providers changed their terms in the same week, and my app did not break, because it talks OpenAI-compatible chat with model IDs in environment variables. Every swap was one line. That portability is the whole argument for open weights, and I only appreciate it because it happened to me on a deadline.

There was one more bug worth naming, because it is the kind that ships silently. With weather unavailable, my prompt contained literal question marks:

Weather tomorrow: high ?C low ?C rain ?%

The model read that as a request and replied: "Could you share tomorrow's forecast?" The app looked broken — it was asking the user to do its job. Three fixes: tell the model in the prompt to give a complete plan and never ask a question, treat a question-shaped reply as a failure so it falls through to the next provider, and make the weather cache stale-if-error so one good reading survives later rate limits.

Why Does Open Innovation Matter?

$0 to run. No per-token billing, no card, free tier.
No vendor lock, demonstrated. I changed models three times in one week without touching application logic.
Swappable and hackable. The model ID is an env var and the prompt is mine to edit. With a closed API I cannot fine-tune, cannot self-host, and cannot reason about why the output changed.
Data stays in the open ecosystem. Coordinates go to a free inference lane, not to a vendor I can't audit or leave.

If this had been built on a single closed API, I would have been stranded the moment that provider changed its pricing. Open weights meant there was always another lane.

Theme mapping

Touch Grass, literally: about one minute on a screen, one to two hours of hill, lake and estuary. Getting people into the world — the app's only job is to end its own usefulness; every output is an instruction to close the tab. Screen is the shortest part: sixty to one, measured on my own walk, not asserted.

My Agent Session

The full build, including both dead provider integrations and the empty-completion bug, is saved as a session — so you can read the process, not just the finished app.

Building Foliage Walk Planner with open-weight AI (no local GPU)

You

New to open source, want to submit to this week's Hacktoberfest DEV challenge. Help me get started.

Agent

Read the project skills and the live challenge page. Key finding: 2026 Hacktoberfest does NOT count PRs. You must build a brand-new project with open-source AI at its core and publish a DEV post in-window. Week 1 theme is 'Touch Grass' - get people off the screen and outside. Window Oct 05-11, 11:59pm PDT. Judging weights Writing Quality most heavily, then relevance, creativity, technical execution, plus 16 partner categories ($200 each) as smaller pools.

You

Suggest something related to finance or market or money management.

Agent

Proposed three finance-adjacent ideas that still satisfy Touch Grass: Farmers Market Saver, Walk-to-Save Challenge, Yard-Sale Flipper. Recommended Farmers Market Saver because it hits the theme, money management, and two partner categories.

You

Start with Foliage Walk Planner. I cannot run a local LLM, use Python.

Agent

Scaffolded FastAPI + Leaflet/OSM + Open-Meteo with a hosted open-weight model so no GPU is needed. Added requirements.txt, render.yaml, .env.example, LICENSE, draft.md, field-test.md.

You

Can you push to GitHub?

Agent

Initialized git, added .gitignore protecting .env, verified no secrets staged via grep for hf_/gho_/sk- patterns, committed, created public repo ramantiw45/Hacktoberfest. SSH push failed with publickey denied, so switched the remote to HTTPS and pushed successfully.

You

How can I deploy? Also create a simple frontend.

Agent

Rebuilt the frontend: autumn paper palette, Bitter display typeface, authored SVG leaf mark instead of emoji, side-by-side form and map collapsing on mobile, and real loading, error, and empty states plus keyboard focus rings and reduced-motion support. Ran the mechanical design detector, which flagged Fraunces as an overused AI-convergent font, so swapped to Bitter and re-ran clean. Gave step-by-step Render instructions including the Root Directory setting people miss.

You

I reached this point - model call failed with 402 Payment Required.

Agent

Hugging Face had moved Inference Providers behind paid credits. Probed their free hf-inference lane programmatically and found no usable chat models left. Built a free-lane chain instead: Groq, then Google AI Studio, then Hugging Face, then a mock fallback.

You

Groq returns 404 Not Found.

Agent

Probed with a deliberately fake key: got 401, which proved the path was correct and the model ID was wrong. Improved error reporting to surface the provider's actual response body instead of a bare status code.

You

Now model_not_found for llama-3.3-70b-versatile.

Agent

Fetched Groq's live model docs and found both Llama 3.x models had moved to Enterprise. Switched the default to openai/gpt-oss-20b, which is open-weight under Apache-2.0 and free, making the open-source story stronger.

You

Now the plan is empty and weather unavailable.

Agent

Two causes. GPT-OSS is a reasoning model, so it spent the entire 300-token budget thinking and returned nothing; raised to 1024 and made an empty completion an explicit failure. Weather 429 came from Render's free tier sharing one egress IP across many instances while Open-Meteo rate-limits that IP, so added a 10-minute cache and one polite retry.

You

It works now but the live API asks me to share tomorrow's forecast.

Agent

Caught a genuine production bug before publishing: with no weather the prompt contained literal question marks, so the model replied by asking the user for a forecast instead of planning. Rewrote the prompt to instruct a complete plan with no questions, made the nature cue location and October specific, added a guard treating a question-shaped reply as a failure so it falls through to the next lane, and made the weather cache stale-if-error.

You

How do I field test? I took screenshots.

Agent

Walked through the field test, then wrote the results: about one minute on screen against one to two hours outside at Virar, roughly sixty to one. Captured three honest failures for the write-up including the Render shared-IP 429 that killed the weather call, and a 'golden leaves on the banyans' cue that is wrong for monsoon-green Maharashtra.

You

Help me connect the DevRelay MCP server.

Agent

Found DevRelay already installed at ~/.devrelay but never registered with OpenCode. Added it as a local stdio MCP server under mcp.servers in the global config, preserving existing provider and model settings, and confirmed authentication as ramantiw45.

Prize Categories

Best Use of Render — the FastAPI app is hosted on Render's free tier (Root Directory week-01-touch-grass), with the live URL above. Every part of it — API, static frontend, and the map — is served from that one free service.

Credits

Open-Meteo, OpenStreetMap contributors, Leaflet, Groq, and the GPT-OSS open weights. Frontend and backend built with an AI coding agent.

DEV Community: Raman Tiwari

Sloth Ledger: the model has an opinion, the ledger has the numbers

The problem with "this saved me hours"

One rule, enforced in code

What it looks like

Slow and steady, measured

Why open weights are the core, not a badge

How it works

What Tiger Data is doing that SQLite is not

Deployed on Render, including the parts that sleep

Four things that broke, written down

Related work

Run it yourself

Credits and disclosure

Udhaar Book: photograph the khata, get the udhaar back

What I built

Who would pay for this

Demo

Why open matters for what I built

How it works

The decision that took the longest

What I got wrong

Also worth reading, if you are building in this space

Prize categories

Run it yourself

Credits

I planned a walk in 60 seconds, then walked for two hours (open-weight AI, no GPU)

What I Built

Demo

Field test — I took it to Virar

Code

How I Built It

The honest build log: two providers died mid-week

Why Does Open Innovation Matter?

Theme mapping

My Agent Session

Prize Categories

Related reading

Credits