DEV Community: Analyse with Vanshaj Poonia

Duplicate of #...: an open model that remembers 23,000 GitHub issues so maintainers don't have to

Analyse with Vanshaj Poonia — Sat, 24 Oct 2026 21:42:11 +0000

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

What I Built

The laziest comment in open source is four words long: “Duplicate of #1234.” Paste it, and GitHub links the two issues and closes the new one.

It is only lazy if you already know #1234 exists. In zed-industries/zed, maintainers have written it 1,653 times, and the issue they pointed to was filed a median of 1,343 issues (64 days) earlier. Nobody remembers that far back. So every duplicate is a search through a tracker with thousands of open issues, or a contributor fixing a bug that already has a thread, a workaround and a PR somewhere else.

Already Filed remembers for you. Point it at a GitHub repo and an open model, running in your browser tab, reads every open issue (and every one closed in the last 30 days), then lists the open issues that say the same thing as an earlier one. Each comes with the earlier issues it most resembles and a button that copies “Duplicate of #…”. It suggests; you decide.

It works the other way too: paste the issue you are about to file, and it shows you whether someone got there first.

Who gets to be lazier: maintainers on triage duty, and anyone about to file a bug who would rather not be told “dupe” by a bot an hour later.

Demo

🔗 vanshajpoonia.github.io/already-filed

No sign-up, no API key. Press ollama/ollama (instant snapshot) to open a snapshot of ollama's 2,711 open and recently closed issues, read in advance by the same model, so you see results straight away. On that snapshot it flags 51 of 2,585 open issues as probably filed before: two requests for the same Rockchip NPU, two for a Windows portable mode, three reports of the Mac app stuck on “Loading…”, and a run of Apple M5 Metal shader crashes.

Or type any public repo and press Find the duplicates to read it live. The model (197 MB) downloads once. After that, ollama's 2,714 open and recently closed issues take about five minutes on my laptop: 45 seconds to fetch them from GitHub, four minutes to read them on the GPU, and a few seconds to compare.

Code

VanshajPoonia / already-filed

Finds the open GitHub issues that were already filed. EmbeddingGemma reads every issue in your browser; tested against every duplicate maintainers linked in zed and neovim.

Already Filed 🦥

Finds the open GitHub issues that say the same thing as an earlier one, so maintainers can type “Duplicate of #…” without remembering thousands of issues. And lets a reporter check before filing.

Point it at a repo. EmbeddingGemma, Google's open-weight embedding model, reads every open issue (and every one closed this month) in your browser, and the page lists the open issues that look like one filed before, with the comment ready to copy. Nothing is sent anywhere except the request to GitHub's public API for the issues.

Live: https://vanshajpoonia.github.io/already-filed/

Why

Big repos get the same bug reported again and again. In zed-industries/zed, maintainers have linked 1,653 issues to the issue they duplicate; the original was filed a median 1,343 issues (64 days) earlier. Nobody remembers that far back, so every duplicate costs a maintainer a search, or a contributor's time on an issue…

View on GitHub

Static files, no build step, no backend. MIT.

How I Built It

Ground truth that maintainers already made

The best thing about this problem is that the answers already exist. When a maintainer writes “Duplicate of #123”, or uses GitHub's close-as-duplicate menu, GitHub records a MarkedAsDuplicateEvent linking the two issues. So I downloaded every issue of three busy repos through the GraphQL API, with those links, and froze them into the repo:

Repo	Issues	Linked duplicates
ollama/ollama (tuning)	11,478	681
zed-industries/zed (test)	23,450	1,653
neovim/neovim (test)	14,762	379

The test replays each repo in the order issues were filed. For every issue that was later linked as a duplicate, the question is simple: is the issue it duplicates among the top suggestions, using only what existed on the day it was filed? Every choice below was made on ollama, then frozen. I did not look at zed or neovim until the end.

First attempt: barely better than Ctrl+F

The obvious version is: embed every issue with EmbeddingGemma, compare each new issue with every earlier one, and show the closest. On ollama it put the right issue in the top three 42% of the time. Keyword search (BM25, roughly what GitHub's own search box does) managed 38%. Four points is not a reason to download a 197 MB model.

Three things fixed it, and none of them was a bigger model.

1. Search where duplicates actually point. I looked at the issues maintainers pointed to: 91% were still open when the duplicate was filed, and another 7% had been closed in the 30 days before. Old closed issues are almost never the answer, but there are thousands of them, all waiting to be a near miss. Comparing each new issue only with issues open at the time (or closed in the last month) took the top three from 42% to 49%.

2. Tell the model what the vectors are for. EmbeddingGemma takes a task prompt. I had started with "sentence similarity", which sounds exactly right for "are these two issues the same?". On the tuning repo's titles I tried five prompts: "sentence similarity" found the right issue in the top three 41% of the time, "clustering" 40%, no prompt 47%, the document prompt 48%, and the retrieval prompt, task: search result | query:, 51%. Same weights, one line changed: on the full issues it took the top three from 49% to 61%.

3. Three signals instead of one. Issue templates make unrelated issues look alike: every ollama issue starts with "What is the issue?", "OS", "GPU", "Ollama version". Instead of hard-coding anyone's template, the app treats any line that appears in more than 2% of a repo's issues as template, and drops it, along with links, images and all but the first four lines of each log. Then each issue gets two vectors (title and body, and the title alone, because the title is where people name the bug), and keyword search comes back as a small third signal for exact error strings and model names that an embedding blurs. 0.7 × body + 0.3 × title + 0.1 × keywords took the top three to 65% and the top one from 29% to 46%.

Measured on two repos it never saw

Then I froze everything and ran the two test repos, which I had not looked at since downloading them.

	zed: top 1	top 3	top 5	neovim: top 1	top 3	top 5
Keyword search (BM25)	25%	38%	43%	26%	39%	45%
EmbeddingGemma alone	44%	62%	69%	42%	59%	64%
bge-small (a sixth of the size), same recipe	45%	64%	72%	40%	56%	60%
EmbeddingGemma recipe (shipped)	45%	65%	72%	43%	58%	64%

On zed's 1,653 duplicates, the issue a maintainer pointed to is in the top three suggestions 65% of the time, against 38% for keyword search. Of the duplicates only one of the two methods gets, 518 are EmbeddingGemma's and 64 are keyword search's. On neovim's 379 it is 58% against 39%. One result I did not expect: on neovim, EmbeddingGemma alone was as good as the full mix (59% against 58% at top three). The weights were fixed on ollama, and I left them alone rather than tune on the test set.

One honest surprise: a model a sixth of the size is almost as good once the recipe is right. bge-small, with the same search window and the same mix, is within two points of EmbeddingGemma on ollama and zed, and two to four behind on neovim. EmbeddingGemma is ahead at top three on all three repos, so it ships; but if you take one thing from this post, take the recipe: where to look, the right prompt, and a pinch of keywords.

Not every false alarm is false

The thresholds were chosen on ollama: “likely” is where 5% of issues that were never linked to anything would still get a suggestion. On zed, “likely” shows the right earlier issue for 12% of duplicates and fires on 4% of the other issues. On paper those 4% are all false alarms. But maintainers do not link every duplicate: plenty get closed as “completed” with a comment, or just sit there.

So I read them. node scripts/audit.mjs zed-industries/zed 30 prints a fixed random sample of 30 of zed's “false alarms”. By my reading, 21 are the same problem (two even have the same title, word for word: “Allow light/dark icon theme preference”, filed twice on the same day), 9 are related (same feature, a different bug: two Copilot problems in the agent panel, two MCP transport hangs with different triggers), and none are unrelated. That is my judgement, not the maintainers', and every number above still counts all 30 as wrong.

Running it in a browser tab

EmbeddingGemma runs through transformers.js, 4-bit, on WebGPU, or on WASM where there is no GPU (with a build that keeps the token table unquantised, because the WASM runtime lacks the quantised lookup). The issues come from GitHub's REST API, following GitHub's own pagination links: page numbers stop working after page 10 on big repos, which I found out from a 422 in the middle of a test run. The demo snapshot stores 8-bit vectors (4 MB for 2,711 issues), made by the same script and model as the tests.

Why Does Open Innovation Matter?

It needs no permission from anyone. The usual way to get duplicate detection is to install a bot: a GitHub App or Action that gets access to the repo and, often, sends each new issue to a hosted model API. Already Filed is a web page. Public issues come from GitHub's public API straight to your browser, and the model is a file your browser downloads. Add a token and it works on a private repo too, and the private issues still never leave the tab.

The ground truth is open too. Every number in this post comes from thousands of “Duplicate of #” comments that maintainers wrote in public. That is a labelled dataset nobody had to pay for, and it is the reason I can tell you how often this is wrong.

The thresholds only mean something because the model cannot change under me. “Likely” is a number chosen on one repo's similarity scores. With a hosted embedding API, a quiet model update would shift every score and nobody would know the thresholds had stopped meaning anything. These weights are a file; the tests and the page use the same one.

Reading 38,000 issues cost nothing. The test embeds every issue in both test repos with two models, on a laptop. No quota, no bill, no key to rotate, so it is cheap to measure properly instead of guessing.

My Agent Session

I built this with Claude Code as a pair programmer, and did not save the session to DevRelay, so here is the next best thing: every number in this post can be re-run.

git clone https://github.com/VanshajPoonia/already-filed
cd already-filed && npm install && npm test

That replays both test repos (it embeds about 38,000 issues the first time, about two hours on an M4, cached after) and prints the table above. npm run tune shows every choice made on ollama, and node scripts/audit.mjs zed-industries/zed 30 prints the false alarms I read.

The Lazy Payoff

Every duplicate in that test set was a maintainer doing the remembering by hand. In zed alone that happened 1,653 times, each time for an issue filed a median of 1,343 issues (two months) earlier.

For 65% of them, the right issue is in Already Filed's top three. That is one click on "Copy “Duplicate of #…”" instead of a search through 2,300 open issues.
It finds the ones nobody linked. Of 30 confident suggestions for zed issues that were never marked as duplicates, 21 were the same problem anyway. Each of those is a conversation happening twice.
It is lazy for reporters too. Pasting a draft into "About to file an issue?" takes seconds, and for about two thirds of zed's past duplicates, the issue they repeated would have been among the three it shows.
On ollama today, the snapshot flags 51 of 2,585 open issues as probably filed before. Finding them by hand would mean comparing every open issue with every other one; the snapshot does it in about six seconds.

Prize Categories

Best Use of Gemma: EmbeddingGemma (300M, 4-bit) runs in the browser and reads every issue. Every suggestion comes from its vectors, and the test runs the same model on 49,690 issues across three repos.

Kokoro read 'Chapter IV' as 'Chapter Roman Four'. So I gave it a proofreader with ears.

Analyse with Vanshaj Poonia — Tue, 13 Oct 2026 19:27:03 +0000

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

What I Built

An indie author with fifteen novels has fifteen audiobooks they will probably never make. A human narrator costs roughly $200 to $400 per finished hour, so a ten-hour novel is a few thousand dollars, before anyone knows whether the audiobook will sell. Multiply by a backlist and the answer is "not this year", every year.

Text-to-speech solves the cost. It does not solve the other half of making an audiobook: proof-listening. Somebody has to hear every minute against the manuscript and catch the skipped words, the misread words and the lines that came out garbled. With a human narrator, that is a paid job of its own. With a voice model, it is ten hours of your life spent waiting for the six lines it got wrong.

Backlist does both halves on your own laptop:

Kokoro, an open-weight voice model, narrates your chapter in the browser.
Whisper, an open-weight speech recogniser, listens to every line it produced and checks it against your manuscript.
You only listen to the lines it flags. If one sounds right, say so. If not, fix the text the narrator reads (or add a name to your pronunciation guide) and re-narrate just that line. Then download a chapter file mastered to audiobook spec.

That flag is real. Doyle's newspaper paragraph runs through "the Vehmgericht, aqua tofana, Carbonari, the Marchioness de Brinvilliers", and the listener heard "the Vame direct, Aquatophana, Carbonari, the Martianest of Brinvaliers". Fourteen other lines of the passage passed. Instead of 2 minutes 16 seconds of listening, the author has 19 seconds to check.

Who pays for this? Self-published authors with a backlist, which is a lot of people: the indie side hustle that already pays for covers, editing and ads. What they would pay for is not the voice (open voices are free) but the workflow that makes a voice usable: the proof-listening, the pronunciation guide, the mastering. Because everything runs on the author's machine, each extra book costs me nothing to serve, so it can be a one-off price per book, or a few dollars a month for a whole backlist, and still be a business.

An honest note on where the files can go: at the time of writing, Audible's ACX requires human narration, while Google Play Books has a "Synthesized voice" narrator type in its Partner Center, Kobo Writing Life accepts digitally narrated audiobooks if you say so, and selling direct (your own site, Bookfunnel, a Kickstarter reward tier) has no such rule. Backlist is for those.

Demo

🔗 vanshajpoonia.github.io/backlist

No sign-up. Pick a sample and press Narrate this chapter:

A Princess of Mars, chapter XI, which is full of names nobody has heard of: Dejah Thoris, Tars Tarkas, Sarkoja, Lorquas Ptomel. The pronunciation guide comes filled in, the way an author would hand one to a human narrator.
A Study in Scarlet, chapter I: "Dr.", 1878, Netley, the Fifth Northumberland Fusiliers.

The first run downloads both models once (about 400 MB if your browser can use the graphics card, 170 MB if not). On my laptop, the Mars chapter (3 minutes 21 seconds of audio) is narrated, proof-listened and mastered in 44 seconds. Your manuscript never leaves the tab.

Code

VanshajPoonia / backlist

Audiobooks of your backlist, made on your own laptop: Kokoro narrates, Whisper proof-listens every line, both in the browser.

Backlist 🎙️

Audiobooks of the books you have already written, made on your own laptop.

Paste a chapter. Kokoro, an open-weight voice model, narrates it in your browser. Then Whisper, an open-weight speech recogniser, listens to every line and checks it against the manuscript. You re-check the handful of lines it flags instead of the whole chapter (accept them by ear, or fix the text and re-narrate just that line), and download a file mastered to audiobook spec.

Live: https://vanshajpoonia.github.io/backlist/

Why a second model

A human-narrated audiobook costs an indie author $200 to $400 per finished hour, so a ten-hour novel is $2,000 to $4,000. An author with fifteen books in their backlist does not have that, which is why most backlists are never narrated. Text-to-speech fixes the cost. It does not fix the other half of audiobook production: proof-listening, where someone hears every minute against the…

View on GitHub

Static files, no build step, no backend, no API keys. MIT.

How I Built It

Two open models, two workers, one runtime

Both models run on transformers.js, each in its own Web Worker. The narrator works ahead and the listener follows one line behind, so proof-listening costs almost no extra time and the page never freezes.

Narrator: Kokoro-82M (Apache-2.0). On the GPU through WebGPU when there is one, 8-bit on the CPU otherwise. Kokoro's official JavaScript package is built on an older transformers.js, and loading both versions would mean two copies of the ONNX runtime in one tab. So I ported its text handling (about a hundred lines: normalisation, eSpeak NG phonemes, voice styles) onto the same runtime as the listener. That also means the browser and the test suite run identical code.
Listener: Whisper base.en (MIT), 8-bit, on the CPU.

What the listener caught in the narrator

I built the listener to catch narration errors, and the first thing it did was catch Kokoro's:

Roman numerals are read as "Roman". Chapter IV came back from the listener as "Chapter Roman 4". Henry VIII was "Henry Roman 8". A great many chapter headings look exactly like that. Backlist now reads book structure as cardinals ("Chapter Four") and monarchs as ordinals ("Henry the Eighth").
Long sentences are cut off without a word. Kokoro reads at most 510 phoneme tokens at a time and silently drops the rest. I counted: across A Princess of Mars, A Study in Scarlet and A Christmas Carol, 21 sentences are over that limit. The longest, in A Princess of Mars, is 168 words, which is 1,317 tokens: more than half of it would simply never be said, and nothing would tell you. Backlist splits sentences over 50 words at their own semicolons and commas, and re-splits any line that still comes close.

I measured the narration rules too: of 31 test lines they change, the listener flagged 6 as written and 1 with the rules. Five of the six were chapter headings ("Chapter Romans 3, my Advent on Mark" is my favourite), all fixed. The one left is "bade adieu to their landlady upon Tuesday, the 4th inst.", which comes back as "bated due" either way: archaic and French words are exactly what the pronunciation guide is for. My other rules (Saint or Street, military titles) never changed a verdict in these books, so I am not claiming they fixed anything.

Teaching the listener what not to worry about

The obvious checker compares what Whisper heard with the book, word by word. On clean, correct narration of A Christmas Carol, that flagged 40% of the lines. Whisper is a model with habits of its own, and almost none of the differences were narration errors. A few I collected along the way:

Dickens writes "door-nail"; Whisper writes "doornail". "Ironmongery" came back as "iron mongering".
"In 1878" comes back as digits, "Mister" comes back as "Mr.", "colour" as "color".
"There I was struck" came back as "Their eye was struck". Correct narration, creative spelling.
And names. Whisper has never heard of Dejah Thoris, and writes "Digiothorus". "Tars Tarkas" was "Tar's Tar Cuss".

So the checker (src/compare.js) aligns the two word sequences, compares words by how they sound rather than how they are spelled, turns numbers into words on both sides, and forgives compounds, homophones and abbreviations. For names, it only checks that something name-shaped was said in the right place. Whether Tars Tarkas sounds right is a question for the author's pronunciation guide and the author's ears, and the app says so.

What it never forgives: words skipped, words added or said twice, a word swapped for a different one, a line cut short.

Measuring it with planted faults

A proof-listener has two jobs: catch real mistakes, and stay quiet on good audio. One that cries wolf sends you back to listening to everything. To measure both, npm test takes real lines from the books and renders each one five times through the real narrator: once as written, and four times with a fault planted in the text the narrator reads (three words skipped, three words said twice, one word swapped for an unrelated one, the last 40% never said). Every rendering is heard back by the real listener and checked against the book. Lines rotate through four voices, two American and two British.

I tuned the checker's rules on 30 lines of A Christmas Carol, then froze them and tested on lines from A Study in Scarlet and A Princess of Mars that it had never seen:

Checker	False alarms on clean audio	Skipped	Repeated	Swapped	Cut off	All faults
Exact match after normalising	25/80 (31%)	74/74	68/74	74/74	74/74	98%
Word error rate ≤ 15%	1/80 (1%)	27/74	24/74	5/74	74/74	44%
Backlist, rules frozen before the test	1/80 (1%)	74/74	67/74	72/74	74/74	97%
Backlist after fixing what the test exposed	0/80	74/74	67/74	74/74	74/74	98%

The exact-match checker catches nearly everything and cries wolf on almost a third of perfectly good lines. The usual word-error-rate threshold is quiet but misses more than half the faults, including 69 of 74 swapped words, because one wrong word in a long sentence is under 15%. Backlist's checker is as quiet as the threshold and nearly as thorough as exact match.

The test also found three gaps in my rules. A title-case table of contents had made "Through" count as a name (so a swap there was forgiven), "Decameron" came back as "de Cameron", and "corps" came back as its homophone "core". I fixed all three; the last row is after those fixes, so the frozen row above it is the honest held-out number.

Every fault it still misses is a repetition. Kokoro said "after he had after he had listened", and Whisper wrote it down once. Whisper was trained on tidied-up transcripts, and it tidies. That is a limit of the listener, not something a rule can fix, so the README says so plainly: a stutter can get through.

Mastering, and making it fast

The chapter file is built in the browser (src/audio.js): Kokoro's own silences trimmed, consistent pauses added (sentence, paragraph, scene break), resampled to 44.1 kHz with a windowed-sinc filter, the loudness set to -20 dB RMS and the peaks held under -3 dB with a limiter. That is the spec most audiobook distributors publish, and the app checks the file against it.

The listener was the bottleneck. It runs on the CPU, and single-threaded WebAssembly is slow. Cross-origin isolation lets ONNX Runtime use several threads, but it needs two HTTP headers, and GitHub Pages cannot send headers. So the service worker adds them to every file it serves, and the page reloads itself once on the first visit. On my laptop that took the Mars chapter (3 minutes 21 seconds of audio) from 1 minute 34 seconds to 44 seconds, 4.5x real time. A browser without WebGPU still gets there, with both models on the CPU, at 0.7x real time: a chapter is something to start before making a cup of tea.

Why Does Open Innovation Matter?

Because the business is the backlist. One audiobook is a few hundred thousand characters, rendered more than once while you fix things. A backlist is fifteen of those. With a voice model you rent by the character, every re-render is a line item, and the economics push you towards narrating only the books you are already sure will sell. With open weights on the author's own machine, the fifteenth book costs the same as the first: nothing. That is what makes a cheap tool for indie authors possible at all.

Because a manuscript is the most private thing an author has. Unpublished and backlist books are the author's income. Plenty of authors are, reasonably, unwilling to upload them to a service whose terms they cannot control. Here the chapter goes into a model in the tab, and audio comes out. Nothing is uploaded.

Because I could take the narrator apart. Every finding in this post (the 510-token cliff, the "Roman four", the stutters Whisper tidies away) came from running the same open weights in Node hundreds of times, reading the code that feeds them, and porting it. The test suite alone renders and listens to about 600 clips, and costs nothing to re-run. With a closed voice API I could not have found the truncation, only suffered it.

Because the safety net is open too. The proof-listener is itself an open model I can run locally and measure. That is why I can tell you how often it is wrong, on books it was not tuned on, instead of asking you to trust it.

My Agent Session

I built this with Claude Code as a pair programmer. I didn't save the session to DevRelay, so here is the next best thing: every number in this post can be re-run.

git clone https://github.com/VanshajPoonia/backlist
cd backlist && npm install && npm test

That downloads the three public-domain books from Project Gutenberg, renders every test line and its planted faults through Kokoro, listens to all of them with Whisper, and prints the table above along with every false alarm and every missed fault. SET=tuning npm test reproduces the tuning set; LISTENER=whisper-tiny.en npm test swaps in the smaller listener.

My First User

Not yet, and I would rather leave this empty than invent one. If you write, paste in a chapter of your own (it never leaves your browser) and tell me in the comments what it flagged, how your character names came out, and whether you would pay for it. I will add the first answers here.

There is no Red Tomb: making a 1B model write walking quests without making things up

Analyse with Vanshaj Poonia — Sat, 10 Oct 2026 22:16:45 +0000

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

What I Built

"Go touch grass" is good advice that rarely works, because a walk with no destination loses to the couch every time. What gets people out of the house is a reason: a dog that needs walking, a kid who needs tiring out, a thing to go and see.

Sidequest gives a walk a reason. You tell it three things:

where (your location, or one of four famous parks if you are trying it from a desk),
how long (20 minutes, 40, or an hour),
who is coming (just you, you and a kid, or you and a dog).

It reads OpenStreetMap around you, picks the most interesting real things within reach (a 500-year-old tomb, a statue, a bench with an inscription, a tree someone bothered to name), and routes the shortest loop through them that fits your time. Then Gemma, running on your device, writes you one small thing to do at each stop.

It is for anyone who wants to walk more and keeps not doing it, and for the parent at 4 pm on a Saturday who needs the next 40 minutes to have a plot. The quest is written at home on wifi and saved on the phone, so it still works in the middle of a park with one bar of signal.

Demo

🔗 vanshajpoonia.github.io/sidequest

No sign-up. Pick Lodhi Garden, Golden Gate Park, Hampstead Heath or Central Park, choose a length, and press Make my quest. Or press Start where I am and get a walk around your own block.

The first quest downloads Gemma once (about 860 MB, so use wifi). After that, on my laptop in Chrome with WebGPU, the three-stop quest above took 21 seconds to write, retries included. Every stop has a Walk there ↗ link for directions and a "Why this mission?" panel, which turns out to be the most important part of the app:

That is a real one from the quest above. Gemma's first idea for a radio mast was to climb it. The checker said no, told Gemma why, and the second draft kept you on the ground. The panel shows you all of it.

Code

VanshajPoonia / sidequest

Turns the real map around you into a short walking quest. OpenStreetMap stops, missions written by Gemma 3 running in your browser.

Sidequest 🧭

Turns the real map around you into a short walking quest.

Pick a start and a length (20 minutes, 40, an hour). Sidequest reads OpenStreetMap around you, picks the most interesting real things within reach (a 500-year-old tomb, a blue plaque, the 1894 Liberty Tree, a whispering bench), routes the shortest loop through them that fits your time, and then Gemma, running in your browser, writes you one small thing to do at each stop.

Live: https://vanshajpoonia.github.io/sidequest/

Stop 2 · 🏛️ Viaduct Bridge. Cross the Viaduct Bridge and examine the bridge’s construction – is it solid stone or a cleverly constructed timber?

The model writes. The code navigates.

Given only a place's name, a 1B model fills the gaps with confident inventions (the table below counts them). So Gemma is never asked where to go: choosing stops and adding up distances is arithmetic, and arithmetic belongs in…

View on GitHub

Static files, no build step, no backend, no API keys. MIT.

How I Built It

The model writes. The code navigates.

The first decision was what not to ask Gemma. Picking stops and adding up distances is a job ordinary code does perfectly, so Gemma never chooses where you go. src/plan.js scores OpenStreetMap features by what their tags prove (has a name? an inscription? a Wikipedia link? a date?), keeps one of each kind where it can, and brute-forces the shortest start → stops → start loop, walked at 75 m a minute with a 1.3× allowance for paths not being straight, plus three minutes at each stop. If a loop does not fit your time, you are not offered it.

That leaves Gemma one job, the one a language model is actually good at: turning a list of facts about a place into a sentence a person wants to act on. "Race your kid to the English oak and see if the two of you can reach all the way around its trunk."

The hard part was getting it to do only that.

Measuring it

I took the six best stops around each of the four parks (24 in all, a mix of tombs, statues, plaques, trees, viewpoints and benches), cycled through solo, kid and dog walkers, and wrote a checker that flags a mission if it:

mentions a year or a proper noun that is not in the stop's OpenStreetMap tags,
asks the walker to find out a date the map does not have ("determine the original construction date" turned out to be Gemma's favourite filler),
asks for anything unsafe (climbing, wading, picking, feeding, going inside),
describes the place instead of giving an instruction, or talks to a kid on a dog walk,
runs past 35 words.

Then I ran Gemma 3 1B (4-bit, the exact weights the browser loads) over all 24 stops in four configurations, with greedy decoding so the numbers come out the same on every run.

Prompt	Invented a name or date	Asked for a date the map lacks	Not a mission, or wrong walker	Clean
The place's name only (rules + examples)	15	0	2	8 / 24
OSM tags + rules, no examples	0	0	12	12 / 24
OSM tags + rules + 4 examples as chat turns	4	1	3	16 / 24
+ checker, retry with feedback, template (shipped)	0	0	0	24 / 24

Nothing unsafe and nothing over-long turned up in any configuration, so those columns are left out.

Attempt 1: give it the name and let it use what it knows. This is the obvious prompt, and 15 of 24 missions invented something. Gemma knows of Lodhi Garden and Golden Gate Park, but not well enough to send someone anywhere real, so it fills the gaps with confident detail:

Lion (a statue in Golden Gate Park): "Search the Lion statue in Golden Gate Park for a discarded leash."

Richard Tucker (a bust near Central Park), for a parent and kid: "Search the Red Tomb for your kid's favorite toy, a red rubber ball, and see if it's visible from the entrance."

There is no leash, there is no ball, and there is no Red Tomb in New York. More on the Red Tomb shortly.

Attempt 2: give it the tags and a set of clear rules. The rules worked: no invented names at all. But only half the answers were missions. For a 1B model, rules written in prose are not instructions so much as text to continue, and it often just echoed the input back. Asked for a mission at the Athpula Bridge, it replied "Athpula Bridge". Twice it replied, in full, "Place:".

Attempt 3: show it, do not tell it. I kept the rules and added four worked examples, each as a real turn in the conversation (user: the facts, assistant: the mission) rather than as a paragraph of examples in the prompt. Small models copy the shape of what they have already "said" far more reliably than they follow instructions. Clean missions went from 12 to 16 out of 24.

They also copied things they were never supposed to copy. One of my examples was a made-up place called the Red Tomb, and it started turning up everywhere:

Karl Marx's original grave, Highgate, London: "Count the stones surrounding the Red Tomb and note the faint scent of lavender."

Attempt 4: do not trust it, check it, and tell it what was wrong. What ships runs every draft through the checker. If it fails, the draft goes back to Gemma with the specific reason (It mentions "Red", which is not in the facts. Write the mission again, using only the facts.). After three failures, a plain template takes over: "Find the view, then name the farthest thing you can see." A boring mission beats an invented one.

Result: 24 of 24 clean. Sixteen passed on the first try, five after being told what was wrong, and three fell back to a template.

Check the checker

That Karl Marx line was in my shipped results on the first full run, marked clean. The checker had compared words with a substring search, and the stop's inscription says the remains were buRIED, REmoved and re-inteRRED. As far as the checker could tell, "Red" was right there in the facts.

It now matches whole words, that case is a regression test, and the numbers in the table are from the fixed version.

It was not the only one. Taking the screenshots for this post, I watched the checker reject "Listen carefully to the faint hum emanating from the St. Columba Radio Mast" for "describing the place instead of giving you something to do". The full stop in "St." looked like the end of a sentence. Worse, the draft before it, "Ascend the tower of the St. Columba Radio Mast", had been rejected only by that same accident, because "ascend" was not on the unsafe list. Both are fixed and both are tests now.

I found every one of these bugs the same way: by reading the raw output to choose quotes for this post. I now think that is the most underrated debugging technique in AI work.

What the checker cannot catch

It catches names, dates, unsafe verbs and the wrong audience. It cannot catch an invented ordinary object: at a temple whose tags say nothing about lions, Gemma asked for "the most detailed carving of the lion's head", and that shipped. Some sentences that pass are just odd ("Listen carefully to the plaque"). And Gemma has no sense of occasion. At the spot in Delhi where Indira Gandhi was assassinated, its first draft asked a parent and child to "estimate the exact time of the assassination". The date rule rejected it, but by luck, not judgement.

So the app does not hide any of this. Every stop's "Why this mission?" shows exactly what Gemma was given, links to the OpenStreetMap object, and lists every draft that was rejected and why. If a mission is odd, you can see where it came from.

Choosing the model

Gemma 3 1B instruction-tuned, 4-bit ONNX, through transformers.js on WebGPU, falling back to WASM. About 860 MB, cached after the first visit.
Gemma 3 270M is about a quarter of the size, and in my tests it mostly repeated the prompt back. Too small for this job.
Gemma 4 E2B is the obvious next step up, but its ONNX build is around 3.2 GB, which is too much to ask of a phone browser for a walking app. I did not ship what I could not run on a phone.

Privacy, by construction

"Start where I am" snaps your position to a roughly 500 m grid before asking Overpass for map data, pads the search radius to cover the snap, and does the real distance filtering on the device. The map server learns which neighbourhood you are in, not which house. The AI learns nothing, because the AI is a file on your phone.

Why Does Open Innovation Matter?

Sidequest is two open things working together, and both halves matter.

Open data is what makes the stops real. Every stop is an OpenStreetMap object that a volunteer mapped, often down to the text on a bench plaque. When a mission is wrong because the map is wrong, the "Why this mission?" link takes you to the exact object, and anyone can fix it. That fix then improves every app that uses OSM, not just mine. A closed maps API gives you a rating and a photo carousel, and if it is wrong, you file feedback and wait.

An open model is what makes the walk private and offline. Where you walk, when, and with whom is about as personal as data gets. With Gemma running in the tab, the place facts go into a model on your own device and a sentence comes out. There is no request to an AI service to log, and nothing breaks when the signal does, which in a park is often.

And I could take it apart. Every number in the table above came from running the same weights in Node that the browser downloads, against frozen map snapshots, with greedy decoding. Anyone can run npm test and get the same table. I could compare prompt strategies, swap in a smaller Gemma with one environment variable, and find out exactly where the model needed help. With a hosted model the thing I measured could change next week behind an endpoint, and every stop would cost money forever. Here it costs nothing.

My Agent Session

I built this with Claude Code as a pair programmer. I didn't save the session to DevRelay, so here is the next best thing: the whole evaluation is reproducible.

git clone https://github.com/VanshajPoonia/sidequest
cd sidequest && npm install && npm test

That runs 31 planner and checker checks, then Gemma 3 1B over the 24 stops in all four configurations, and prints the table above along with every failed draft. MODEL=onnx-community/gemma-3-270m-it-ONNX npm test runs the smaller model for comparison.

Prize Categories

Best Use of Gemma: Gemma 3 1B runs entirely in the browser and writes every mission, constrained to OpenStreetMap facts by a measured prompt, a checker and a retry loop.

I turned my grandmother's voice notes into a recipe book, and none of it left my laptop

Analyse with Vanshaj Poonia — Mon, 05 Oct 2026 05:53:49 +0000

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

What I Built

Nani's Kitchen turns a grandparent's rambling voice memos into a printable family recipe book. It runs entirely in a browser tab. No server, no API key, no account, no upload.

I built it for my friend, my grandmother. She has never written a recipe down in her life. What she does is send four-minute WhatsApp voice notes that open with "okay so today I am going to make" and close with an unrelated story about the coal fire.

Those memos are the recipes. They are also the only copy, sitting in a chat backup, one phone replacement away from gone.

Drop a memo in, get back a recipe card with ingredients, method, and the part I actually care about: a section called In her words that keeps the stories instead of deleting them.

Demo

🔗 nanis-kitchen.vercel.app
Mirror: vanshajpoonia.github.io/nanis-kitchen

No sign-up. Load a model, then press Use the sample memo if you have no microphone handy - it drops in a real spoken aloo paratha transcript so you can see the structuring without recording anything.

Watch for the little ▶ buttons on each line. Whisper returns timestamps, so every ingredient and every step replays the exact second she said it. The transcript is a convenience; her voice is the source of truth, and I did not want the app to quietly swap one for the other.

Code

VanshajPoonia / nanis-kitchen

Turn a grandparent's voice memos into a printable family recipe book. Whisper runs in your browser tab; the audio never leaves your laptop.

Nani's Kitchen 🍲

Turn a grandparent's voice memos into a printable family recipe book. Entirely on your own laptop.

My grandmother does not write recipes down. She has never written one down. What she does is send four-minute WhatsApp voice notes that start with "okay so today I am going to make" and end with an unrelated story about the coal fire. Those memos are the recipes. They are also the only copy.

Nani's Kitchen takes those memos, transcribes them with Whisper running inside the browser tab pulls out ingredients, method and the stories, and builds a recipe book you can print and hand over.

No server. No API key. No account. The audio never leaves the machine.

Why it had to be open

This is the part that is not a technicality.

Uploading a recording of your grandmother to somebody's inference API is a thing you only do…

View on GitHub

MIT. Static files, no build step, no runtime dependencies.

How I Built It

Whisper — open weights from OpenAI, Apache-2.0 — running in the tab through transformers.js. WebGPU where the browser has it, CPU/WASM everywhere else, picked at runtime.

flowchart LR
  A[Voice memo<br/>.m4a / mic] --> B[AudioContext<br/>decode + resample 16 kHz]
  B --> C[Whisper<br/>transformers.js<br/>WebGPU / WASM]
  C --> D[Transcript<br/>+ timestamps]
  D --> E{Structurer}
  E -->|offline, instant| F[Rule parser]
  E -->|optional| G[Ollama<br/>any open-weight LLM]
  F --> H[Recipe card]
  G --> H
  H --> I[(localStorage)]
  I --> J[Markdown / printable book]

The interesting file is not the ASR, it is src/recipe.js. Spoken recipes and written recipes are different languages, and every recipe parser I could find assumes the written one. Nobody says "250 g all-purpose flour". They say "about two cups of maida, maybe a bit more if the dough feels dry". So the parser had to learn a few things:

Vague stays vague. "A pinch", "plenty of ghee, do not be shy with it". Converting those to numbers would be inventing data and would make the book worse.
Bare counts are ingredients. "Also four potatoes, medium size, boiled" has no unit anywhere in it, but it is obviously a shopping line, not an instruction.
Descriptors belong to the line above. That same sentence must not become three ingredients called four potatoes, medium size and boiled.
"And then" is a sentence boundary. "Knead it and then cover it" is two steps. My first attempt produced a cooking step that was just the word "And", which is how I learned to stop re-scanning a string I had already matched.
Memories are not instructions, and must not be deleted. "When I was a girl we had no gas, only the coal fire" is the reason you want the book at all.

There are 16 checks in tests/run.mjs covering exactly those cases. They run offline in milliseconds, because the parser is pure functions with no model in it.

There is also an optional path: if Ollama is running, the app finds it, lists whatever open-weight models you have pulled, and uses one instead of the rule parser. Swap llama3.2 for gpt-oss for qwen2.5 and nothing else changes.

Why Does Open Innovation Matter?

Three answers, in increasing order of how much I actually believe them.

The easy one: cost. Transcribing a few hundred old memos through a hosted ASR API is a real bill for something that should be a weekend favour for your family. Here it is zero, permanently.

The better one: it works on the machine it needs to work on. This is going to live on an old laptop in my parents' house, offline half the time. whisper-tiny.en is 40 MB and runs instantly on hardware like that; whisper-small.en is six times bigger and much better at accented English. The right trade-off differs per machine, so it is a dropdown rather than a decision I made for everyone. A closed API gives you whichever model the vendor is serving this quarter.

The one that actually drove the build: uploading a recording of your grandmother is a thing you do exactly once without thinking about it. That audio is her voice, her house, her health, whatever else was audible in the room, and often a language a cloud vendor charges a premium for. With a closed API, "it's private" is a sentence in a terms-of-service document that can be revised. With open weights running in AudioContext and WASM, it is a property of where the code runs — and you can confirm it by opening the Network tab and finding no request to inspect, because there is no request.

Open innovation did not make this cheaper than the closed version. It made a promise checkable that would otherwise have stayed a promise.

My Agent Session

No DevRelay session on this one, so here is the trail instead: the commit history and the test suite.

The parser was not designed up front, it was argued with. Every rule above exists because a test failed first, and tests/run.mjs reads as a changelog of everything I got wrong about how people talk about food:

git clone https://github.com/VanshajPoonia/nanis-kitchen
cd nanis-kitchen && npm test

16 checks, no model, no network. The one I am fondest of is no step is a lone conjunction.

Empowering Artisans in the Digital Marketplace

Analyse with Vanshaj Poonia — Thu, 07 Dec 2023 10:38:57 +0000

Etsy, founded in 2005 by Robert Kalin, Chris Maguire, and Haim Schoppik, has emerged as a global e-commerce platform specializing in handmade, vintage, and unique goods. It has redefined the landscape of online marketplaces by providing a space for independent artisans and crafters to showcase and sell their creations. With a commitment to sustainability and community, Etsy has grown into a unique online marketplace that fosters creativity and empowers small businesses.

Background and History:
Etsy's inception stemmed from the founders' desire to create a platform that connected craftspeople directly with consumers. The initial focus was on handmade goods, but the marketplace evolved to include vintage items and craft supplies. Over the years, Etsy has expanded its reach globally, connecting millions of sellers with a diverse customer base.

Business Model:
Etsy operates on a commission-based business model, charging sellers a nominal fee for listing items and a percentage of each sale. This model incentivizes the platform to support its sellers, as Etsy's success is directly tied to the success of its community. The platform also generates revenue through optional seller services such as advertising and payment processing.

Unique Selling Proposition (USP):
Etsy's USP lies in its commitment to fostering a sense of community and supporting small businesses. Unlike conventional e-commerce giants, Etsy focuses on niche markets, providing a platform where buyers can find distinctive, handmade, and personalized items. This emphasis on uniqueness and craftsmanship has helped Etsy carve out a distinct identity in the competitive e-commerce space.

Technology and Innovation:
Etsy has continually invested in technology to enhance the user experience for both buyers and sellers. The platform leverages machine learning algorithms to improve search and recommendation features, helping users discover relevant products. Additionally, Etsy has embraced mobile commerce, ensuring that users can access the platform seamlessly through mobile apps.

Community Building and Support:
One of Etsy's standout features is its emphasis on community building. The platform facilitates communication between buyers and sellers, enabling direct interaction and personalized customer service. Etsy also organizes events and forums, both online and offline, to connect sellers and share knowledge. This sense of community fosters trust and loyalty among users.

Challenges and Controversies:
While Etsy has experienced tremendous success, it hasn't been immune to challenges and controversies. Issues such as counterfeit goods, copyright infringement, and concerns about the platform losing its handmade focus have arisen. Etsy has responded by implementing stricter guidelines, deploying advanced algorithms to detect policy violations, and refining its policies to maintain the integrity of the marketplace.

Sustainability and Ethical Practices:
Etsy places a strong emphasis on sustainability and ethical practices. The company has committed to offsetting carbon emissions from its shipping activities and has implemented initiatives to reduce its overall environmental impact. This commitment to sustainability aligns with the values of many artisans and resonates with environmentally conscious consumers.

Global Impact and Expansion:
Etsy's impact extends beyond its platform, influencing the broader creative economy. By providing a global stage for artisans, Etsy has contributed to the economic empowerment of individuals worldwide. The platform's expansion into international markets has facilitated cross-cultural exchange and enabled small businesses from various regions to connect with a diverse customer base.

Financial Performance:
Etsy's financial performance has reflected its success in the e-commerce sector. The company's revenue has seen consistent growth, driven by an increase in active buyers and sellers. Strategic acquisitions, such as the purchase of Reverb, a musical instrument marketplace, have further diversified Etsy's portfolio and contributed to its financial resilience.

Future Outlook:
As Etsy continues to evolve, it faces challenges and opportunities in an ever-changing e-commerce landscape. The platform's future success depends on its ability to balance growth with maintaining its commitment to handmade and unique goods. Innovations in technology, sustainability practices, and community engagement will likely play pivotal roles in shaping Etsy's trajectory.

Conclusion:
Etsy's journey from a small online marketplace to a global e-commerce giant exemplifies the power of connecting artisans with consumers. The platform's unique focus on handmade, vintage, and personalized items has created a niche that resonates with a growing segment of conscientious consumers. Etsy's commitment to community, sustainability, and innovation positions it as a key player in the digital marketplace, with the potential to continue empowering independent creatives around the world.

Oracle Corporation - A Case Study on Success Factors

Analyse with Vanshaj Poonia — Mon, 20 Nov 2023 09:49:44 +0000

Oracle Corporation, founded in 1977 by Larry Ellison, Bob Miner, and Ed Oates, has emerged as one of the world's leading technology companies, specializing in database management systems, cloud solutions, and enterprise software. This case study delves into the key factors that have contributed to Oracle's remarkable success.

Innovation and Technology Leadership:

Oracle has consistently been at the forefront of technological innovation. The company's early success can be attributed to the development of the Oracle Database, which revolutionized the field of relational databases.
Continuous investment in research and development (R&D) has allowed Oracle to stay ahead of the curve. The company's commitment to cutting-edge technologies, such as artificial intelligence, blockchain, and cloud computing, has helped it maintain a competitive edge.

Comprehensive Product Portfolio:

Oracle offers a diverse range of products and services, catering to various business needs. The company's comprehensive product portfolio includes database management systems, cloud infrastructure, enterprise applications, and business analytics solutions.
The breadth and depth of Oracle's offerings make it a one-stop solution for businesses, allowing them to integrate various software and hardware components seamlessly.

Strategic Acquisitions:

Oracle has strategically pursued acquisitions to expand its product and service offerings. Notable acquisitions include Sun Microsystems, PeopleSoft, BEA Systems, and NetSuite.
These acquisitions have not only broadened Oracle's product portfolio but also allowed the company to integrate new technologies and talent, strengthening its overall position in the market.

Global Presence and Customer Base:

Oracle operates on a global scale, serving customers in virtually every industry. The company's expansive international presence has allowed it to tap into diverse markets and cater to the needs of a wide range of businesses.
Building and maintaining strong relationships with a large and loyal customer base has been a key factor in Oracle's success. The company's commitment to customer satisfaction and support has fostered long-term partnerships.

Adaptability and Cloud Transition:

Recognizing the industry shift towards cloud computing, Oracle has successfully transitioned its business model to focus on cloud services. The Oracle Cloud Infrastructure (OCI) offers a scalable and secure cloud platform for businesses.
The adaptability to market trends and the successful execution of cloud initiatives have positioned Oracle as a major player in the cloud computing space.

Strong Leadership and Corporate Culture:

Larry Ellison, Oracle's co-founder and long-time leader, has played a pivotal role in the company's success. His visionary leadership and strategic decision-making have shaped Oracle's trajectory.
Oracle's corporate culture emphasizes innovation, collaboration, and a commitment to excellence. The company fosters an environment that encourages employees to think creatively and stay at the forefront of technology.

Focus on Security and Compliance:

Given the critical nature of the data managed by Oracle's products, the company places a strong emphasis on security and compliance. Oracle databases are known for their robust security features, addressing the growing concerns around data protection.
Adhering to industry regulations and proactively addressing security challenges has enhanced Oracle's reputation as a trusted provider of enterprise solutions.

Summary:

Oracle Corporation's success can be attributed to a combination of innovation, strategic acquisitions, a comprehensive product portfolio, global reach, adaptability to market trends, strong leadership, and a customer-centric approach. By staying at the forefront of technology and continuously evolving its offerings, Oracle has maintained its position as a leader in the highly competitive tech industry.