DEV Community: Saurabh Chauhan

The Won't-Do List: a local model that tells you what you can safely ignore

Saurabh Chauhan — Mon, 26 Oct 2026 04:17:04 +0000

This is my submission for the Hacktoberfest Open-Source AI Challenge: Week 3, "Slow and Steady".

What I built

Every to-do list has the same flaw: it only grows. Adding a task is free. Removing one needs a decision, and deciding is the part nobody does on purpose.

The Won't-Do List is an anti-to-do list. You paste everything you meant to get to (bullets, numbers, checkboxes, whatever your notes app spits out) and a small open-weight model, running on your own computer, sorts every task into one of four piles:

Do now: ignoring it costs you soon, or it takes under ten minutes.
Do later: it matters, but nothing breaks this week.
Let it expire: nothing bad happens if it never gets done.
Not my problem: it belongs to someone else, or you are waiting on them.

Every card says why, and, the part I care about most, says in one honest sentence what actually happens if you ignore it. The tasks you put down come back a week later for a single question: did letting go cost you anything? Your answers become examples the model sees next time.

The effort it saves is the effort you never spend. At the top of every sorted list the app tells you how many minutes you were just handed back.

Demo

Try it yourself. There is nothing to pip install; it is plain Python and plain JavaScript:

ollama pull gemma3:4b      # or any instruct model of about 3B parameters or more
python3 -m wontdo          # then open http://127.0.0.1:8742

No model running? The app still opens and sorts with a few keyword rules. They are not AI, and every list they make says so.

The lazy payoff

I ran it on my own list of 9 tasks with gemma3:4b on Windows 11:


Tasks pasted	[9]
Put down (let it expire, not my problem)	[3]
Minutes handed back	[about 1 h 40 min]
Time for the model to sort the list	[300 seconds]
Verdicts I disagreed with	[1 of 9]

The minutes are the model's own rough estimates, rounded to five, ten, fifteen minutes and so on. They are a nudge, not a stopwatch.

Why open innovation matters here

A task list is the most candid document you own. It holds the rent you are late on, the appointment you keep postponing, the name of the person you are avoiding. Sent to a hosted model, that list becomes a request body on a server I do not control. Run through an open-weight model on my own machine, it stays inside one process on one computer. The app listens on 127.0.0.1 only, it loads its own fonts, and a browser test records every request the page makes while you sort a list and fails if any of them leaves the machine.

It works on a plane. No account, no key, no quota, no connection.

The model is a setting, not a dependency. The app talks to Ollama, llama.cpp's llama-server, LM Studio or any OpenAI-compatible server. Swap one model for another and nothing else changes; the Test connection button tells you in about ten seconds whether the new one behaves. Because those protocols are open and simple, I could also test the whole pipeline against scripted stand-in servers that misbehave on purpose: invalid JSON, slow replies, dropped connections, a reasoning model that thinks out loud.

Nothing is metered. Sorting a list twice with two different models, to see who you trust, costs a little electricity.

Teaching it stays private. The check-in answers and the tasks you move by hand become up to six short examples in the next prompt. That trick works with any model. What open weights change is that those examples are the most personal data you have, and they never leave your disk.

Where a closed model would have been better. A large hosted model would almost certainly judge ambiguous tasks better than a 4B model on a laptop. A small model will sometimes tell you to ignore your tax return. So I did not try to make the model perfect. I built around it.

How I built it

The model proposes, plain rules veto. Seven regex tripwires (money, official paperwork, health, safety, booked commitments, people who matter, someone you answer to) plus your own never-skip words watch every task. If the model says "let it expire" and a tripwire fires, the task moves to Do later and the card says why. A second rule says the model cannot rate something medium or high risk and also skip it. Only you can overrule the net, with the Move to… menu. The rules lean towards false alarms on purpose: a false alarm costs one extra item on your list, and a missed one costs a late fee.

Dates are worked out by code. "by Friday" becomes [due in 6 days] before the model sees it, because small models are poor at calendar arithmetic.

Consequence before verdict. The output schema asks for if_ignored and risk before bucket, so the model has to write what happens if you ignore the task before it chooses a pile. I picked that order so the verdict has to agree with the sentence the model has just written. I did not run a controlled comparison, so treat it as a design choice, not a result.

Small models are messy, so the client is forgiving. It pulls usable JSON out of code fences, <think> blocks, trailing commas and truncated replies, and understands loose spellings such as "skip" or "defer". It retries without JSON-schema mode when a server rejects it. If the model dies halfway through a long list, the remaining tasks are finished with the keyword rules and labelled as such, instead of throwing the whole list away.

Your energy sets the size of Do now. A slider fills Do now up to that many minutes and slides the overflow to Do later, instantly and without asking the model again. Anything important that is due within two days stays put.

The boring parts are the point. The server is Python's standard library and the front end is one HTML file, one stylesheet and one script, so there is nothing to install and nothing to break. Fonts ship with the app (Atkinson Hyperlegible, under the SIL Open Font Licence) and the colour pairs were run through a contrast checker. [N] tests cover the parser, the dates, the safety net, both model clients, the pipeline, HTTP security and the command line, and [N] more drive a real browser.

What I would do next

Teach the date finder and the safety net languages other than English. Today a model may cope with other languages, but the tripwires will not.
Measure how often each verdict is overruled, per model, so choosing a model stops being guesswork.
A weekly sweep: re-sort what is still sitting in Do later.

Code

github.com/SaurabhEffect/HacktoberFest-2026/tree/main/wont-do-list

Prize categories

Best Use of Gemma: the demo above runs Gemma (gemma3:4b) locally through Ollama.

Hinglish reel captions, made offline on your own laptop

Saurabh Chauhan — Mon, 19 Oct 2026 06:57:28 +0000

This is a submission for the Hacktoberfest Week 2 "Side Hustle" challenge.

What I Built

Scroll through Indian Instagram and you will keep running into captions like this one:

aaj hum baat karenge ki kaise aap apne reels mein captions laga sakte ho

Hindi and English in one sentence, typed in English letters. It is how a lot of people talk and post, and Roman script is what many viewers find easiest to read on a phone.

Someone has to caption those reels, and for plenty of creators that someone gets paid: a freelance editor, a two-person agency, a cousin who "does the editing". Their problem is not that speech recognition can't hear Hindi, because open models like Whisper hear it well. The problem is what comes out. Hindi arrives in Devanagari, English words arrive in whichever script the model fancied, and nothing turns that into the spelling people actually type (kya, nahi, bahut) with a timestamp on every word. Cloud caption tools tend to bill by the minute or by the month, and they want the client's unreleased footage on their servers.

Hinglish Reel Captioner is a small local web app for that job. You drop in a video or a voice note. It listens with open-weight Whisper, converts each Hindi word to Roman Hinglish while leaving English words English, and plays big word-by-word captions over a live preview. You fix any word in an editor that keeps the timing intact, pick a look (or save the creator's brand colours), and either burn the captions into the MP4 or export SRT, VTT, ASS or a plain transcript.

The person who would pay is the person who captions other people's reels. Their price per reel is set by their clients, and their cost per reel is their time. The point of the tool is to turn the slowest part of that job, typing Hinglish against a waveform, into skimming and fixing, without adding a per-minute line to their costs.

Roman Hinglish, word by word. क्या becomes kya, वीडियो stays video, एपीआई becomes API.
An editor that keeps the timing. Respell a word and nothing moves. Add or delete words and the neighbours keep their timing.
Four looks, your brand colours. Pumpkin, Pop, Classic and Box, with one-click "my brand look".
Burned in, or as files. An MP4 with the captions drawn in, or .srt, .vtt, .ass and a plain transcript.
Voice notes too. Audio-only files get a branded background and become a captioned video.
My words. One line fixes a spelling for every future video: doston=dosto, or insta gram=Instagram.

Demo

There is nothing to sign up for and nothing to deploy, because the point is that it runs on your own machine. Demo mode plays a scripted Hinglish transcript over any video you drop in, so you can try the whole studio without downloading a model. You need Python 3.10 or newer and FFmpeg:

{% https://github.com/SaurabhEffect/HacktoberFest-2026/tree/main/hinglish-reel-captioner %}
./run.sh --demo

On Windows PowerShell, from the cloned project folder, run:

.\run.bat --demo

It opens http://127.0.0.1:8000. Drop a video and you land in the studio. The preview plays with the same fonts, line breaks and colours as the final render. The panel on the right has Captions (edit, split, join, click a time to jump), Style (four looks and every control behind them) and Export.

The Options panel holds the language, the speech model and the My words rules:

It is a small FastAPI app (reelcaptioner/) and a front end of plain HTML, CSS and JavaScript modules: no build step, no CDN, fonts bundled. There are 395 tests. The README covers the settings, the HTTP API (so a batch of reels can be captioned from a shell script) and troubleshooting.

How I Built It

I directed an AI coding agent (Claude) to build this. I chose the idea and the shape of the product, and the agent wrote and tested the code, so everything below is about the product and about what the tests in the repo actually check.

The open pieces

Whisper (OpenAI, MIT licence), run through faster-whisper and CTranslate2, does the listening: word timestamps, voice-activity detection, your own names as hotwords, and a Hinglish prompt. Any CTranslate2 Whisper model works, so you can pick a size from tiny to large-v3, or point the Custom model box at a Hindi fine-tune.
FFmpeg and libass probe the file, pull out 16 kHz audio, make a small preview copy and burn the captions in.
FastAPI and plain HTML, CSS and JavaScript make the app.
Ollama is optional. It runs a local model, Gemma by preference, to tidy spellings card by card.

Three problems that took more thought than the model

1. Whisper writes Hindi in Devanagari, so the app converts. Rather than coax Roman text out of the model, it lets Whisper write what it writes and converts each word afterwards, in a fixed order: your own rules first, then English loanwords (kept as English), then a lexicon of common Hindi words with their usual spellings, then rule-based transliteration for everything else. The rules are where the craft is. Devanagari writes an inherent a after every consonant and then does not pronounce some of them: समझ is samajh, not samajha, and बनता is banta, not banata. Deleting those schwas correctly does a lot of work for words that are in no lexicon. The whole thing is deterministic, so a wrong spelling is fixed once and stays fixed.

2. The preview has to match the render. The studio draws captions in the browser, but the export burns them in with libass. If the two disagree, the editor approves one thing and ships another, and by default they do disagree. Browsers place text using a font's ascent and descent (for Poppins, 1.05 and 0.35 em), while libass uses the Windows metrics (1.135 and 0.627 em) and scales font size by their sum. So the exporter converts every size (×1.762) and places each baseline explicitly, the server measures the line breaks once with the real font and hands the same ones to both renderers, and the outline is drawn in the browser as rings of hard text-shadows, because -webkit-text-stroke draws mitred spikes that libass does not.

To check it, a script captions the same flat-colour clip for nine looks and positions, once in the live preview in headless Chromium and once burned in by FFmpeg, and compares where the caption lands. The worst difference was 0.19% of the frame, about one pixel on a 640 px tall video. The tests derive each constant from the font file, so changing the font cannot quietly pull the two apart.

3. An editor that never loses the timing. Fixing a spelling moves nothing: when the word count is unchanged, every timing is kept. When you add or delete words, the words before and after the edit keep their timing and the new ones share the gap. The optional LLM pass follows the same discipline. It may only respell: each card has to come back with the same number of words and mostly the same letters, or the original card is kept, and it is only ever shown the text, so it cannot move a timestamp.

How it was tested without a model

The build environment could not download a Whisper model, so the tests exercise the real transcription code against a stand-in model that returns faster-whisper's real output shapes. Every FFmpeg render is run for real and measured pixel by pixel, the command-line tests boot an actual server, and the Ollama pass is tested against a fake one. There are 395 tests, passing on Python 3.10, 3.11, 3.12 and 3.13, each in a freshly built environment.

What that cannot prove is accuracy on real Hinglish audio, which depends on your recording and your model. That is why the editor is a first-class feature, and measuring word error rates on real reels is the first thing I would do next.

Why Does Open Innovation Matter?

Four things in this project only work because the model is open.

It costs nothing per reel. A captioning side hustle runs on thin margins and many small jobs. When the model runs on the captioner's own laptop, the hundredth reel costs the same as the first: a few minutes of CPU. There is no meter to watch and no plan to outgrow, so what they charge a client stays their own decision.

The footage stays put. Reels for a brand deal or a launch are often unreleased, and sometimes under NDA, by the time they reach the editor. With local inference the audio is extracted and transcribed on the machine that already holds the file. The server listens on 127.0.0.1 by default, there are no analytics and no CDN, and a test fails if the front end ever references an outside address. The only network traffic is the one-time model download.

The spelling is mine to change. Hinglish has no standard spelling (hai, hain, h), so the spelling layer is where the value is. Hosted captioning APIs typically hand back finished text in their own conventions. With open weights I get word timestamps and hotwords instead, and everything after the model is code I control: the romanizer, the My words rules and the editor. When someone says "my audience writes dosto, not doston", that is one line in a text box and it holds for every video after. When a better Hindi model appears, it is a drop-down choice or a folder path, not a migration.

Nobody can change the terms. The weights are a file on disk. They cannot be repriced, deprecated or rate-limited out from under a business that depends on them.

Where would a closed API have been better? Probably out-of-the-box accuracy on noisy audio, since a large hosted model will beat small on a laptop CPU, and setup is friction because you need Python and FFmpeg. I would rather say that plainly than pretend open wins every column. It wins the ones this customer cares about: cost per reel, where the footage lives, and who controls the spelling.

This Week Outside: a field guide you print, built from open data and a local LLM 🌿

Saurabh Chauhan — Mon, 12 Oct 2026 06:54:44 +0000

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

Most "get outside" apps ask you to stare at your phone while you're outside.
This one does its thinking at your desk, then hands you a sheet of paper and gets out of the way.

What I Built

This Week Outside is a hyperlocal field guide you print and take with you.

You type your town. It asks iNaturalist what people within a few kilometres have actually spotted in the last two weeks, checks the 7-day forecast, and works out which species have just showed up: logged recently, but not in the two months before. A small open-weight model running on your own machine then writes the friendly parts (an intro, a weekly mission, and a short what to look or listen for tip per species). You hit print, leave the phone at home, and tick things off with a pen.

It's for anyone who would walk more if the walk came with a tiny quest, and who would rather not have an app open on the trail to get it.

The screen is the shortest part


01 · Pick your patch	Type a town or share your location. Coordinates are rounded to about 1 km before they leave your computer.
02 · Read the neighbourhood	Recent sightings plus the forecast, with a ★ on the best day and the golden-hour time. A local model writes the tips.
03 · Print it. Go.	A clean, ink-friendly sheet with a tick box beside every species and a ruled space for field notes.

A minute at the screen. The rest is the point.

Demo

The home page

![The This Week Outside home page: a forest-green hero reading "Something wild is near you", a big search bar, and die-cut leaf, bird, mushroom, sun and acorn stickers]

The UI borrows its look from hacktoberfest.com: forest green, cream paper, sticker art, an italic accent inside a bold headline.

Code

SaurabhEffect / HacktoberFest-2026

Hacktoberfest 2026

This repository collects projects for Hacktoberfest 2026. Each project lives in its own top-level folder.

Projects

NoFumble - local-first cash-flow forecasting and expense checks.
This Week Outside - a hyperlocal field guide for things to look for outdoors this week.

View on GitHub

The project lives in this-week-outside/. It has a Dockerfile and compose file, and a CI workflow that runs the test suite on Python 3.10, 3.11 and 3.12.

How I Built It

 browser ──► Flask (app.py) ──► fieldguide/guide.py
                                   ├─ inat.py     iNaturalist species_counts  (recent window + 60-day baseline)
                                   ├─ weather.py  Open-Meteo 7-day forecast   (+ best-day score, golden hour)
                                   ├─ geocode.py  Open-Meteo geocoding        (place name → lat/lng)
                                   └─ llm.py      local model via Ollama or any OpenAI-compatible server

Stack: Python + Flask + requests, vanilla JavaScript with no build step, and no API keys anywhere.

Why Does Open Innovation Matter?

Because of four things I couldn't have promised with a hosted model:

What I wanted	What open made possible
Private	The AI text is written on your machine. What leaves it is the place name you search for and a coordinate rounded to ~1 km, sent to the public iNaturalist and Open-Meteo APIs.
Free to run, forever	Open data and an open-weight model mean no API key, no bill, and no tier to outgrow. Anyone can run a card for their own town.
Swappable	Try another model, or another server (Ollama, llama.cpp, LM Studio, vLLM), by changing one variable.
Useful where signal isn't	Once the card is printed, the trail needs no connection at all.

And where open is harder. A 3B-parameter model is not as reliable as a frontier model, and it will sometimes get a species tip wrong. That's exactly why the architecture is "data decides, the model decorates", with a validator and a safe fallback around it. Working with a small open model pushed me toward a more careful design than I'd have bothered with otherwise.

Honest limits

Sightings reflect where people use iNaturalist: dense in cities and popular parks, sparse elsewhere. Widen the radius if a card looks thin.
"Just showed up" means newly logged, which can also mean newly noticed.
Everything the model says is a hint, not an identification.

Credits & attribution

Sightings and species photos: iNaturalist observers (each photo keeps its own licence).
Forecast and place search: Open-Meteo.
Look inspired by hacktoberfest.com.

If you try it, tell me what you found near you. 🌿

hello guys I just joined dev

Saurabh Chauhan — Fri, 02 Oct 2026 12:32:30 +0000