DEV Community: SRG-Cy

Halloween started in Ireland. I put a century of Irish ghost stories back on the map, and code wouldn't let the AI invent a single place

SRG-Cy — Sat, 31 Oct 2026 20:17:47 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

Halloween started here. Long before plastic pumpkins, Samhain was the night at the end of October when the Irish said the wall between this world and the other one wore thin, and the dead walked the roads.

I live in Ireland. In the 1890s an American folklorist, Jeremiah Curtin, sat by firesides in Kerry and wrote down what people told him: a man walking to Sneem at night who meets a ghost and fights it off with a steel sword, a midwife carried away to a fairy fort on a horse that turns out to be a plough beam, a dead mother walking a strand at night, perishing with the cold, asking for a pair of shoes to be given to the poor in her name. He printed thirty of them in 1895 as Tales of the Fairies and of the Ghost World.

Every one of those tales happens somewhere real. The road to Sneem. Blackwater bridge. Ventry strand. You can still walk most of them. But in the book they're just words on a page, and the old spellings (Lochlein, Rahonain) don't match any modern map.

Kerry is only one corner, though. So I added a second public-domain book: True Irish Ghost Stories (1914), compiled by a Tipperary rector, St John D. Seymour, and a police district inspector, Harry L. Neligan, from accounts people sent in from all over the country: haunted houses in Dublin squares, banshees, poltergeists, RIC barracks with something in them besides the police.

So I built Samhain Map: click a place anywhere in Ireland and read the ghost stories that happened there.

What I Built

A story on a phone: Curtin's own words, in type close to how they were first printed, with the scanned 1895 page one tap away.

A map of Ireland with a glowing mark at every place the stories happen: 156 stories, 82 places in 22 of the 32 counties, north and south. Click one and you get the stories set there.
Each story opens with the old text itself, then a one-line summary, the line that shows its ghost or fairy, every place it names with a ✓ or ✗ and the reason, and a link to the scanned page or the book on Project Gutenberg.
Famous haunted sites, as pale ghosts on the map: Leap Castle, Loftus Hall, Charles Fort, Kilkea Castle, Dunluce and Dunseverick castles, Clare Abbey, and Lough Leane, where O'Donoghue's ghost rides the lake on May mornings. Each one is there only because a public-domain book (1825 to 1914) tells its story, and code checked the quote word for word. Famous places none of these books tells, like the Hellfire Club, aren't on the map.
Stories you can listen to. The haunted sites' stories and a few of the best short ones are read aloud by an ElevenLabs storyteller voice: slow, low, a little unsteady, the way they were first told by a fire.
Filters by what haunts the story: ghosts, banshees, poltergeists, death warnings, fairies, the dead returning, a seal woman.
A count of what the checker refused, right on the front page. That number matters to me as much as the pins.

The rule behind all of it: Gemma reads. Code decides.

Demo

Live: samhain-map.onrender.com (no sign-up, works on a phone)

Try: filter by Ghost, click Sneem, open The Ghost of Sneem, then scroll to "Where it happened". Then zoom into Dublin Bay and click Dún Laoghaire: the 1914 story calls it Kingstown. Or click any white ghost, like Leap Castle, open its story and press play under "Listen to the story". Headphones, lights off.

Code

SRG-Cy / samhain-map

Kerry's 1890s ghost and fairy tales, put back on the map. Gemma reads, code decides.

Samhain Map

Irish ghost and fairy stories from two public-domain books, put back on the map.

Jeremiah Curtin's Tales of the Fairies and of the Ghost World (1895): 30 tales told to him by firesides in south-west Munster.
St John D. Seymour and Harry L. Neligan's True Irish Ghost Stories (1914): ghost accounts sent in from all over Ireland.

An open-weight model (Gemma 4) reads each story: what haunts it, a one-line summary, and which places it names. Plain code then checks every answer before anything is pinned on the map.

Gemma reads. Code decides.

Every place must come with an exact quote, and the quote must be in the story.
The name must be a real place on the island of Ireland: a Tailte Éireann or OSNI townland, or a GeoNames town, hill, lake or bridge.
Curtin spelled names as he heard them (Lochlein, Rahonain). Gemma may suggest a…

View on GitHub

How I Built It

1895 scan (archive.org) ─▶ code splits it into 30 tales
1914 book (Gutenberg)   ─▶ Gemma says which paragraph each account starts at ─▶ code cuts 124 accounts
each story ─▶ Gemma 4 26B (JSON mode): beings, summary, every place + the exact words it came from
           ─▶ code: is the quote really in the story? is the name in the quote?
           ─▶ code: is it a real place? (59,618 townlands from Tailte Éireann and OSNI + 31,329 GeoNames places, all 32 counties)
           ─▶ code: several places share the name? nearest the story's other places, or in the county the story names, or refuse
           ─▶ old spelling not found? Gemma suggests a modern one; code accepts it only if it exists near the story's other places
           ─▶ map

Gemma only points at the text

For every place, Gemma has to return the place and the exact words it came from. Code then checks two things: the quote is really in the tale, and the name is really in the quote. If either fails, the place is refused, and the map says so.

Across Curtin's 30 tales, Gemma reported 95 place names. Two failed the quote check, and they surprised me: neither was invented. Both places are really in the tales. Gemma just changed one word while copying:

Tale says	Gemma quoted
"…the fort on the place where I am living now, in Lismore."	"in the place where I am living now, in Lismore."
"…the eldest son to marry and Gort na Leachtan (the field of the stone heaps)…"	"is Gort na Leachtan (the field of the stone heaps) as fortune."

I kept the rule strict anyway. A checker that lets "close enough" through is a checker that will one day let a made-up townland through. Losing two pins is the cheaper mistake. (The 1914 book added 223 more place names; three more failed the same check.)

A real place, or nothing

A name that passes the quote check still isn't pinned until it matches a real place: one of 59,618 townlands (Tailte Éireann for the 26 counties, OSNI Open Data for the six in the North), or a town, hill, lake or bridge from GeoNames. "Munster", "Co. Kerry" or "the North of Ireland" are listed but never pinned: too broad to be a place you could stand.

Many names exist more than once. Ireland has 41 places called Derry and 49 called Curragh. Code decides, in this order:

Nearest the story's other places. A place with only one match anywhere is a reference point.
In the county the story names. "A haunted house in Kingstown, Co. Dublin" only looks in Co. Dublin.
The only town of that name, if nothing else in the story helps.
Otherwise, refuse. "41 places in Ireland are called 'Derry', and the story gives nothing to choose by."

That Kingstown is my favourite fix. Co. Dublin has three townlands called Kingstown, so code refused, until Gemma's modern name for it, Dún Laoghaire, turned out to be exactly one town in the county the story names. Kingstown is the old name for Dún Laoghaire.

The 1914 book has no story headings

True Irish Ghost Stories runs 124 accounts together inside ten chapters. I didn't let Gemma rewrite or split the text. It sees each chapter with numbered paragraphs and answers only "account starts at paragraph 4, call it The Spectral Charwoman". Code checks the numbers exist and does the cutting, so every word on the map is the book's. The titles of those stories are Gemma's, and each one says so.

Famous haunted sites, but only with a source

Leap Castle is the one everyone in Ireland names. The 1914 book has it, but under a made-up name: "Kilman" Castle, "perhaps the worst haunted mansion in the British Isles". Seymour gives the clue himself: its owner wrote about it in the Occult Review in December 1908. That was Mildred Darby of Leap Castle, and the site page says so and links the source.

The sites are a short hand-picked list, but nothing on it is taken on trust. For each one, code checks that its quote is word for word in exactly one story, and takes the location from the same gazetteer as everything else. Only Charles Fort and Dunseverick Castle, which the gazetteer doesn't have, use Wikipedia's coordinates, and say so. Gill Hall, home of the famous Beresford ghost, is in the 1914 book, but I couldn't find a source for exactly where the house stood, so it isn't a ghost on the map.

Each site has an image from Wikimedia Commons, taken only if its licence is free (all turned out CC BY-SA) and credited on the page. Kilkea Castle has none: Commons tags its postcard CC BY-SA, but the postcard's own credit line says CC BY-NC, and when two licences disagree I leave the image out.

Told aloud again

These stories were told by a fire long before anyone wrote them down, so reading them silently felt like half of them. Twelve, about 69 minutes in all, are now read aloud by an ElevenLabs voice ("George", an older storyteller), set slow and slightly unsteady: lower stability so the voice can drop and linger, speed at 0.9.

The same rule holds: the voice reads only the book's own words and the story's title, nothing generated. The audio is made once by a script and served as small static files (32 kbps speech, about a quarter of a megabyte a minute), so the API key never reaches the page and the site still costs nothing to host. Long stories go up in 4,000-character pieces cut at paragraph ends, each sent with the end of the piece before it, so the voice keeps its tone across the joins.

Mentioned is not where it happened

My first 1914 map pinned Waterloo, in Co. Cavan. The story says the widow's husband "fought at Waterloo". It also pinned the town of Shannon for "the estuary of the Shannon", and Cashel for "the diocese of Cashel". A review of every 1914 pin found them.

Gemma had already marked each place as setting or mentioned, and every one of those bad pins was mentioned. The 1914 contributors constantly say where they live ("the Archdeacon of Limerick sends…"), which isn't where the ghost is. So for that book only settings are pinned, and the rest are listed with the reason. A story whose only place is a county (The Pig-Headed Ghost, somewhere in Co. Cavan) is pinned on the county, marked as county-level.

The 1890s spellings

Curtin wrote names as he heard them. Lochlein is Lough Leane. Rahonain is probably Rahinnane. Modern maps have never heard of the first spelling.

So there's a second, small Gemma pass: for every name the map couldn't find, Gemma suggests up to three modern spellings. Code still decides. A suggestion is accepted only if that place exists and lies within 30 km of the tale's other places. Those pins are labelled "via modern spelling, suggested by Gemma", so you can see which ones the model helped with.

Curtin wrote	Gemma suggested	Code said
Lochlein	Lough Leane	✓ pinned: the big lake at Killarney (two tales)
Skneem	Sneem	✓ pinned
Awnascawil	Annascaul	✓ pinned: a real village in the right corner of Kerry
Castlemain	Castlemaine	✓ pinned (two tales)
Kilshanig	Kilshannig	✓ pinned
Rahin	Rahan	✗ refused: Rahan exists, but 124 km from the tale's other places (and once the map covered all Ireland, a real Rahin turned up in Co. Laois, refused at 244 km)
Dun Lean	Dunlea	not pinned: no such place
Drumfada	Drumfada	not pinned: no such place on modern maps

The Rahan one is my favourite row in the project. Gemma's suggestion was a real place. It just wasn't this place, and only the distance check could tell.

This pass was also the flakiest part of the build. Asked about 29 names at once, Gemma reasoned past every time limit I gave it. Even 5 at a time timed out. One name per call, with a hard 150-second limit, got answers for 15 of 26 names after two runs; the rest (Rahonain among them) simply stay unpinned. In the end 8 place names are on the map because of this pass, and every one of them is labelled as a suggestion.

Measuring it

For 7 of the shorter tales, every real place in Ireland they name was labelled by hand: 22 places. Then I compared two versions of the map: one that pins everything Gemma reported, and the real one.

Tale	Places in the tale	Gemma found	Gemma alone would also pin	Pinned (correct / wrong)
The Midwife of Listowel	1	1		1 / 0
Tom Connors and the Dead Girl	5	5		3 / 0
James Murray and Saint Martin	3	3	"Kerry"	3 / 0
The Ghost of Sneem	7	7		6 / 0
The Dead Mother	3	3	"America"	2 / 0
Tim Sheehy Sent Back…	1	1		1 / 0
The Four-leafed Shamrock	2	2		2 / 0
Total	22	22	2	18 / 0

Gemma's reading was excellent. It found all 22 places and invented none.
Every pin on the map in these tales is right. The 4 it couldn't pin are 1890s spellings that no modern map has: Rahin, Rahonain, Drumfada and "Ventry Strand".
The honest limits: it's 7 tales and 22 places, not a benchmark. The labels were drafted with my coding agent rather than by an independent annotator, so read them as a sanity check, not ground truth. The 1914 book has no hand labels yet; its pins were checked by reading through the checker's decision list, which is how Waterloo was caught.

Things that went wrong

Gemma 4 31B returned server errors all afternoon on AI Studio, so everything ran on Gemma 4 26B (the mixture-of-experts one). Because the weights are open, switching was one line.
At temperature 0, Gemma 26B got stuck in its own reasoning: "Wait, 'Sneem' is a setting. Wait, 'Blackwater bridge' is a setting." for 26,000 characters. JSON mode fixed it: about 11 seconds a tale.
Cork city wasn't on the map. City centres have no townlands, so the city sits in a hole in the county outline. Points just outside the outline now count.
The free tier rate-limited me halfway through. Every reply is cached per tale, so the run picked up where it stopped.
A Drummond in Tipperary dragged Waterville to Limerick. In Murderous Ghosts, the only "Drummond" in Munster is 178 km away in Tipperary. My first checker trusted a single match as a reference point, and then picked the Waterville in Limerick because it was "nearest". Now only places in Kerry and Cork count as reference points, and a lone match that far from the rest of the tale is refused with the distance.
Then my fix was too strict. Tales where someone travels to Cork city lost Dingle and Brandon Mountain, because Cork pulled the centre of the tale east. A trip to the city isn't where a tale is set, so cities no longer count as reference points.
Every line of the 1914 book became its own paragraph. Saving the download on Windows doubled the line endings, and Gemma happily split 491 "paragraphs". The chapter titles came out blank, which gave it away.
"Waterford North Station" and "Larne River". When a town, its station and its river sit within 4 km, they count as one place, and code first picked the wrong one to show. Now the town wins.
Still wrong: the Curragh. A story where "they gallop round the Curragh", near Athy and Kilkea in Kildare, is pinned on a townland called Curragh in Co. Laois, because the River Greese, matched in Laois, pulls the story's centre that way. It's the nearest-place rule doing exactly what it says. I left it in rather than add a special case.
Rate limits and 500s from the free tier for most of an evening. Every reply is cached, so two workers ran the 124 stories from both ends.
On a phone, the stories didn't show at all. The page was locked to one screen height, and the header, map and footer left the story panel 33 pixels tall, hidden behind the footer. Now a phone scrolls like a page: map first, then the stories.

Why Does Open Innovation Matter?

Archives don't want their collections fed to AI companies, and I understand why. Ireland's largest folklore archive, duchas.ie, blocks AI crawlers by name in its robots.txt. Those are people's grandparents' stories.

That's exactly why the model being open matters. Gemma's weights are public, so an archive can run this same pipeline on its own server, on its own collection, and nothing ever leaves the building. I ran it on a hosted Gemma for the demo, using public-domain books. The National Folklore Collection could run it in-house without asking anyone's permission.

It's checkable. Same open model, same prompts, same public-domain books, same public maps: anyone can re-run it and argue with any pin. Every Gemma reply is committed in data/extract/.

It isn't locked inside a service that might disappear. When the bigger Gemma was down, I changed one line. If the hosted API went away tomorrow, the same weights run on a laptop.

The one closed piece is the voice. ElevenLabs reads the stories aloud because I didn't want to run a voice model on my own laptop, and its Hacktoberfest credits gave me a storyteller voice in an evening. An open voice model could take its place. It sits at the very end of the pipeline, though: it reads text the open model and the checker have already handled, it decides nothing, and if it disappeared the map would lose its voice but not one pin.

Where a closed model might do better: probably the old spellings. A bigger model might know more 1890s Kerry place names. It would still need the same checker, because a confident model inventing a townland is the one thing a map of real places can't have.

The Spirit of It

The Samhain stories in these books are less about monsters than about the dead being close, and close to particular places: a bend in the road, an old fort in a field, a lake at sunrise. Most of those places are still there, under the same names or close to them.

So that's what I'd ask you to do with it: find your own place on the map. If a story happened there, it has been waiting about a hundred years for someone from home to read it.

Prize Categories

Best Use of Gemma: Gemma 4 26B finds where each of 124 untitled accounts starts, reads all 156 stories for the beings, the summary and every place with its exact quote and role, and suggests modern spellings for old names. Every answer is checked in code before it reaches the map.
Best Use of ElevenLabs: twelve stories narrated with eleven_multilingual_v2 and voice settings tuned for a fireside ghost story (stability 0.35, style 0.45, speed 0.9), chunked at paragraph ends with previous_text/next_text for continuity, cached once as static audio.
Best Use of Render: the whole map is a static site deployed from a render.yaml Blueprint in the repo. Every push to main redeploys it, so each re-run of the checker goes live on its own.

Tales: Jeremiah Curtin (1895), public domain, scan by Cornell University Library via archive.org. Stories: St John D. Seymour and Harry L. Neligan (1914), public domain, Project Gutenberg #14099. Haunted sites also from T. Crofton Croker (1825) and D. R. McAnally (1888), public domain, Project Gutenberg. Townland boundaries © Tailte Éireann, CC BY 4.0; Northern Ireland townlands and counties from OSNI Open Data, OGL v3. Places: GeoNames, CC BY 4.0. Site images: Wikimedia Commons, CC BY-SA, credited on each page. Narration: ElevenLabs. Built with Claude Code; I directed it and checked the results.

Google's free Gemma failed 35% of my calls. My sloth-paced reminder app didn't lose one.

SRG-Cy — Sun, 25 Oct 2026 11:27:23 +0000

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

Return windows, warranty end dates, "come back in six months", the morning tickets go on sale, the bill that's due on the 5th. None of these are hard. They're just things I'm supposed to remember, and I don't.

So I built Later: you throw something at it, it works out the last sensible day to act, and then it does the most sloth thing possible. It waits. Quietly. For weeks or months. Then it nudges you once.

What I Built

Later is a phone-friendly web app with one big button, Throw something in. It opens a sheet with three ways in: Snap (a photo of a receipt, letter or poster), Say (a voice note, transcribed by ElevenLabs) and Type.

You capture something and it answers instantly: "Got it. I'm reading it now, so you can close this page."
In the background, an open-weight model (Gemma 4 31B) reads it and reports the facts: what kind of thing it is, the dates it saw, any window like "refunds within 28 days".
Plain code turns those facts into a deadline and a nudge time in Irish time: 3 days before a return window closes, 30 days before a warranty ends, 2 weeks before you should book that check-up.
A Temporal workflow sleeps until then. It survives restarts and deploys.
You get one push on your phone, with Done and Snooze 3 days buttons. That's the only time Later ever talks to you.

Everything Later is holding sits on one timeline, grouped by when you'll hear about it: Today, This week, This month, Later on. Anything that needs you (no date found) floats to the top. Tap an item to see the due date and Done / Snooze / Forget.

The lazy part is the whole point: you don't type a calendar entry, you don't work out what "28 days from the 20th" is, and you don't check an app to see what's coming. You throw it in and forget it.

Demo

Try it: https://later-h5nw.onrender.com (no sign-up). Tap Throw something in, then Type, paste something like "Penneys receipt 20/10/2026. Refunds within 28 days", and watch it move from Reading to This month. Tap the 🔔 to subscribe to your private push topic in the free ntfy app.

Code

SRG-Cy / later

Snap it, say it, paste it. Later reminds you at the last sensible moment. Hacktoberfest 2026 Week 3.

Later 🦥

Snap it, say it or type it. Later works out what you'll need to do and the last sensible day to do it, then stays quiet until then and nudges you once.

Live: https://later-h5nw.onrender.com · Built for the Hacktoberfest 2026 Open-Source AI Challenge, Week 3: Slow and Steady.

How it works

phone ──capture──▶ FastAPI ──store──▶ MongoDB Atlas
                      │
                      └─start──▶ Temporal workflow (one per item)
                                   1. read_item   ── Gemma 4 31B (open weights) reads the text or photo
                                   │                  retried patiently: the free endpoint fails ~1 call in 3
                                   2. resolve     ── plain code turns facts into a deadline (the model never does date maths)
                                   3. sleep until the last sensible moment (days or months; survives restarts)
                                   4. send_reminder ── one ntfy push with signed Done / Snooze buttons

The model reports facts, code does the maths. Gemma copies dates and windows ("30 day returns") exactly as written; later/resolve.py…

View on GitHub

MIT licensed, with 113 tests. Temporal workflows are tested with Temporal's time-skipping test server, so "wait 30 days" runs in a second.

How I Built It

phone ──capture──▶ FastAPI ──store──▶ MongoDB Atlas
                      │
                      └─start──▶ Temporal workflow (one per item)
                                   1. read_item       Gemma 4 31B reads the text or photo
                                   2. resolve         plain code computes the deadline
                                   3. sleep until the last sensible moment
                                   4. send_reminder   one ntfy push, signed Done / Snooze links

The model reports facts. Code does the maths.

LLMs are not reliable at date arithmetic (there's data on this), and a reminder app that's a day out is worse than none. So Gemma is told to copy dates exactly as written and report lengths of time separately:

{"kind": "return_window", "org": "Penneys", "anchor_date": "2026-10-20",
 "window_days": 28, "evidence": "Refunds within 28 days with receipt"}

Then resolve() does the rest in plain Python: month ends (31 Aug + 6 months = 28 Feb), Irish dates (day/month), and the clock change. Ireland's clocks went back on Sunday 25 October, the last day of this challenge, and 09:00 nudges stay at 09:00 local.

Reading slowly on purpose

I first ran Gemma 4 on Google AI Studio's free tier as a normal request: you capture, you wait for the answer. It was right every time it answered, but it failed a lot and was slow. In a 24-call comparison, Gemma 4 31B succeeded 4 times out of 6, with each answer taking ~30 seconds. OpenRouter's free Gemma was rate-limited on all 12 calls.

Nobody should stare at a spinner for a minute, so reading moved into the background:

/capture stores the raw item as reading and starts its workflow. It returns in milliseconds.
The workflow's first step is a read_item activity with a patient retry policy: 5 s, then doubling up to every 2 minutes, for up to 2 hours.
A model error raises, so Temporal retries it. A reply that's understood but has no date becomes no date found, with no endless retries.
If the model is down for 2 hours, the item is marked failed instead of quietly vanishing.

That's this week's theme taken literally: the sloth takes its time so you don't have to.

No accounts, still private

The public demo has no sign-up, so each visitor gets an anonymous cookie and only sees their own items. Each visitor gets a private ntfy topic derived with an HMAC. The push buttons carry a signed per-item token, because the ntfy app has no cookie, and a forged token gets a 404. Daily capture limits protect the free model quota.

Deploying

One Docker container on Render runs the Temporal dev server (state on a 1 GB persistent disk), a self-restarting worker and the web app. MongoDB Atlas holds the items and photos.

Results

I ran 35 captures through the real pipeline (Gemma extraction, then the resolver), with Temporal-style retries:

	30 hand-written captures	5 real Galway event listings
	27 typed, 3 drawn images	3 typed, 2 screenshots of the live listing pages
Due date exactly right	30/30	5/5
Kind of item right	28/30	5/5
Model calls that failed	16 of 46 (35%)	1 of 6
Captures lost	0	0
Time to read, median	60 s	55 s

The hand-written set includes an Irish mix: Penneys and Zalando returns, an ESB bill, motor tax, the NCT, a Revenue Form 11 deadline, a Panda bin top-up, a passport expiry. One gig poster has a decoy date: the gig is in March 2027, but tickets go on sale 13 Nov 2026, and that's the date that matters. The Galway set uses real listings: Paul Brady at Leisureland, The Frank And Walters and Pa Sheehy at Róisín Dubh, and the Eyre Square Christmas Market.

The number I care about is the third row. Google's free Gemma endpoint failed 35% of calls. The worst capture, an ESB bill, failed 4 times and was read on the 5th try, 8½ minutes later. Without the retries, a third of everything you threw at Later would simply be gone. With them, nothing was lost. (The standard advice on retrying LLM calls with backoff applies; Temporal just makes it durable.)

What went wrong

Gigs were nudged after the gig. The real Galway listings caught this one. Gemma labels gigs as "ticket" events, which nudge 30 minutes before a known time. With only a date, that came out as 23:29 on the night. Now a date-only event nudges at 09:00 that morning.
Gemma 4 thinks out loud. On Google AI Studio it always writes a <thought> block before its answer, sometimes wraps the JSON in code fences, and JSON mode returned 500 errors. The parser now skips the thinking and takes the last complete JSON object.
Date-only dates became midnight. Pydantic happily parses "2026-11-05" into a datetime at 00:00, which would have fired reminders a day early. Dates without a time now stay dates.
Two kind mix-ups in the test, both with the right date: a Hozier ticket sale labelled a deadline (nudges 2 days early instead of 30 minutes before), and a flight labelled a ticket event.

Why Does Open Innovation Matter?

The weights are open, so the exact same model can run anywhere. I used Google AI Studio's hosted Gemma for the demo, but Gemma is open-weight: anyone who doesn't want their receipts and letters leaving their machine can point LLM_BASE_URL at their own server and run the identical model. The code only needs an OpenAI-compatible endpoint.
No lock-in. Switching provider or model is one environment variable. I did exactly that mid-build: I benchmarked two providers and two Gemma sizes, then moved, without touching the code.
The free tier made it possible, and open tools made it reliable. A free, flaky endpoint was fine because open-source Temporal absorbs the flakiness. The whole stack is open source or has a free tier: Gemma, Temporal, ntfy, FastAPI.

The Lazy Payoff

Here's what one capture saves you:

By hand	With Later
Work out "28 days from the 20th"	Snap the receipt
Open the calendar, make an event, pick a reminder time
Remember to check it
Notice when you've missed it	One push, the morning it matters

Capturing takes one tap and a photo, a few seconds. After that the effort is zero. Across the 35 test captures, Later worked out every deadline correctly, and the person capturing never had to look at a date.

Prize Categories

Best Use of Gemma: Gemma 4 31B reads every capture, text and photos, and returns structured facts. It's evaluated on 35 captures, with 35/35 due dates correct.
Best Use of Temporal: one durable workflow per item. It reads in the background with patient retries (recovering from a 35% failure rate with 0 lost captures), sleeps for days or months until the nudge, and handles Done/Snooze signals. Tested with the time-skipping test server.
Best Use of ElevenLabs: the Say button. ElevenLabs speech-to-text (scribe_v2) turns a voice note into text in about 2 seconds, and Gemma reads the transcript like anything typed. Live test: "Dentist said come back for a checkup in six months" was transcribed word for word and scheduled for 25 April 2027. If transcription fails, the person gets a clear message instead of a lost capture.
Best Use of MongoDB Atlas: stores every item and photo, with per-visitor queries and daily limit counts.
Best Use of Render: one Docker web service from a render.yaml Blueprint runs Temporal, the worker and the app, with a persistent disk for Temporal's state. Push links fall back to Render's own RENDER_EXTERNAL_URL, so they work without extra setup.

This project and post were built with the help of AI (Claude Code). I reviewed and tested everything here, and every number comes from runs in the repo's eval/results.

StyleCast: an AI outfit planner that runs on your phone

SRG-Cy — Sat, 17 Oct 2026 13:59:36 +0000

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

What I Built

Every morning I check the weather app, open the wardrobe, and guess. Then it's 22 degrees and I'm in a hoodie, or it's pouring and my jacket isn't waterproof.

StyleCast does the guessing for me:

📸 Snap your wardrobe once. An open vision model running in the browser tags each item: type, colour, warmth, waterproof, formality. Every tag is one tap to edit.
🌦️ Get today's outfit. It reads the forecast for where you are (rain, wind, temperature) and your plan for the day (casual, work or gym), then picks from your clothes.
🧺 It remembers. No wearing the same shirt three days running, and anything marked "in the wash" stays out.
🕳️ It spots gaps. "Nothing waterproof for days like today."
🛍️ Budget chat. Ask "I have €50, what should I buy?" and Gemma, running on your device, plans searches from your gaps and shows real products that fit the budget.

Demo

Try it: https://srg-cy.github.io/StyleCast/ (works best in Chrome on a laptop or Android; it installs to your home screen like an app).

Code

SRG-Cy / StyleCast

StyleCast

Photograph your wardrobe once. Every morning, get an outfit from your own clothes that fits the real forecast.

Built for the DEV Hacktoberfest 2026 Open-Source AI Challenge, Week 2 ("Side Hustle").

Today's outfit stands in a fitting-room mirror under the forecast; the wardrobe hangs on rails, one per category.

What it does

Wardrobe scan: snap each item. An open model running in your browser tags type, colour, warmth, waterproofing and formality. Every tag is editable.
Daily outfit: checks today's forecast (rain, wind, temperature) and your occasion (casual, work or gym), then picks an outfit from your wardrobe.
Wear history: remembers what you wore recently so it doesn't repeat, and lets you mark items "in the wash".
Gap spotting: tells you what your wardrobe is missing for the weather you actually get ("nothing waterproof for days like today").
Budget chat (Shop tab): say "I have €50 today, what should I…

View on GitHub

It's a static site with no build step, MIT licensed. npm test covers the outfit rules, the budget chat and the shopping server, and CI runs it on every pull request.

How I Built It

Version 1 was a dead end
On day one, StyleCast was a Python server calling Qwen2.5-VL through Ollama on my PC. The outfits were good. The setup was terrible: every user would need to install Ollama and pull a 6 GB model before seeing a single outfit. Nobody pays for that.

So on day two I threw it away and moved the AI into the browser:

Tagging clothes from photos: CLIP ViT-B/32 via Transformers.js, on your device (WebGPU on laptops, WebAssembly on phones). Budget chat: Gemma 3 1B, or Gemma 3 270M without WebGPU, on your device in a web worker.
Weather: Open-Meteo, free with no key, called from the browser. Shopping results: SerpApi Google Shopping, through a tiny Node server on Render.
Wardrobe and photos: IndexedDB, in your browser.

CLIP doesn't describe photos the way a chat model does. It compares a photo with a list of descriptions and picks the closest. For "what kind of clothing is this?" that's enough, and it's small enough to run on a phone. The outfit itself is chosen by plain JavaScript rules: weather first, then occasion, then what you haven't worn lately. I don't need a model to tell me it's raining.

Then my jeans became a jacket
The first thing I photographed on my own phone was a pair of jeans. StyleCast filed them under jackets.

I could have tweaked a prompt and hoped. Instead I wrote a scoring script that runs the tagger over 272 labelled product photos, and it now runs in CI on every pull request that touches the tagger. It found three problems:

Lazy labels. CLIP was matching my photo against "a photo of a jeans". With nothing else to go on, it went by colour and fabric, and blue denim looks like a denim jacket. Each type now gets a few plain descriptions: "a pair of jeans", "blue denim jeans", "denim trousers with two legs".
The centre crop. CLIP crops to a square, which cut tall photos like jeans in half. Photos are now padded to a square instead.
A shortcut that cost accuracy. I'd put phones on an 8-bit model to save memory. Now they use the 16-bit model, loaded in two halves (text first, then image) so it fits in phone memory.

With all three fixed, on the same 272 photos:

📱 Phones: right clothing type went from 55% to 77%, and right category (top, bottom, shoes...) from 90% to 93%.
💻 Laptops: right clothing type went from 72% to 77%, and right category from 92% to 93%.
The cost: phones now download about 300 MB the first time instead of about 150 MB. The browser keeps it after that.

The cost: phones now download about 300 MB the first time instead of about 150 MB. The browser keeps it after that.

The budget chat: Gemma, Render and SerpApi
Ask "I have €50, what should I buy?" and this happens:

Gemma(on your device) reads your wardrobe and the gaps the rules found, and plans up to three searches.
Only the short query ("rain jacket") and a price cap go to a Render server. It holds the SerpApi key, caches each search for six hours, and caps searches per IP and per day.
Rules pick one product per search so the total stays within budget, and Gemma writes a sentence on why each pick fits.

If you name the item ("shoes under 20"), it skips planning and searches for that. If Gemma can't load on your device, the rules plan the searches and write a plain explanation, so the chat still works.

One lesson for anyone running models in the browser: a failed first load can leave ONNX Runtime broken for the rest of the page. Now each model attempt gets a fresh web worker, so a failed WebGPU attempt doesn't break the WebAssembly fallback.

Why Does Open Innovation Matter?

StyleCast is only a viable side hustle because the models are open.

🔒 Privacy. Nobody wants photos of their bedroom wardrobe on a stranger's server. An open model running in the browser means the photos never leave the phone. A hosted vision API can't promise that.
💸 €0 per user. Closed APIs bill per photo and per message. Open weights on the user's device cost me nothing, which is what makes a €2 subscription work.
✈️ Offline. Once the model is downloaded, tagging and outfit picks work without a connection. The last forecast is saved for mornings with bad signal.
🔧 Fixable. When CLIP got my jeans wrong, I could look inside: change the labels, change the preprocessing, compare precisions, and measure every change. A closed API would have left me rewording prompts.
🔁 Swappable. Gemma 1B drops to 270M on weaker devices, and the repo has a test page comparing CLIP with SmolVLM. No vendor decides that for me.

Transformers.js, ONNX Runtime Web, CLIP, Gemma and Open-Meteo did the heavy lifting. My part was gluing them together for one specific morning problem.

My First User

My first users were two friends. They photographed their own clothes on their Android phones, and StyleCast got them right. Their verdict was "good, but it can be improved", which is fair. StyleCast is only a few days old, and their feedback is what goes into the next version.

Before that, my first real test was my own wardrobe, and that's how the jeans bug turned up. That one wrong tag sent me from "it works on the demo photos" to measuring accuracy properly, and it was the most useful thing that happened all week. I've also run the full shopping flow live, with the app on GitHub Pages, the server on Render and real Google Shopping results from SerpApi.

Prize Categories

Best use of Gemma: Gemma 3 runs entirely in the browser and powers the budget chat. It plans searches from the user's wardrobe gaps and explains each pick.

Best use of Render: the shopping server runs on Render from a one-click blueprint (render.yaml) and keeps the SerpApi key off users' devices.

Best use of SerpApi: Google Shopping results with a price cap turn wardrobe gaps into real products within budget.

LevelOut: an anime-style System that levels you up at a real skill, outside

SRG-Cy — Sun, 11 Oct 2026 12:13:23 +0000

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

LevelOut turns learning a real skill into a leveling anime.

You know the trope: a weak hero gets chosen by a mysterious System that hands out daily quests, and every completed quest makes them stronger. I wanted that feeling for real life, with the quests happening outside.

Pick a skill. Football, cricket bowling, badminton footwork, skipping, a 5K, or type anything.
Tell the System what you have: a wall, stairs, water bottles, a ball, or nothing at all.
Take the trial. The open-weight model writes 6 questions for your skill, including an injury check.
Awaken. You get a rank (E to S), a title like E-Rank Striker, five stats (STR / AGI / VIT / SKL / FOC), a 30-day goal, a rank-up test and a weekly plan.
Daily Quest. Warm-up, drills, cool-down, bonus. Every drill works alone, outdoors, with only the things you said you have.
Pocket your phone. Accepting the quest starts a timer and tells you to go.
Report back. Rate each drill Easy / Just right / Hard / Hurt / Skipped. You earn XP, stats and levels, and the next quest adapts. Drills that hurt are replaced with gentler ones for a different body part.

To rank up you have to pass a real-world test the System set for you, such as "juggle 25 times in a row". The game only moves when you do.

Demo

🔗 Try it live: https://levelout.onrender.com

Code

SRG-Cy / LevelOut

⚔️ LevelOut

Train outside. Level up for real.

LevelOut turns learning a real skill into a leveling anime. An open-weight AI model plays the System: it tests you, assigns you a rank, and gives you a Daily Quest of outdoor drills you can do alone, with little or no equipment. Complete it, report back, and you gain XP, stats and levels, while the System adapts tomorrow's quest to how you actually did.

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

How it plays

Accept the System. "You have met the conditions to become a Player."
Choose your path. Pick any skill (football, cricket bowling, badminton footwork, skipping, a 5K, parkour, anything) and tick what you have: a wall, stairs, water bottles, a ball, a bench, or nothing at all.
The trial. The model writes 6 assessment questions for your skill, including…

View on GitHub

How I Built It

LevelOut runs an open-weight model, and it can run that model locally too.

Open-weight model: the System runs on gpt-oss-120b, an open-weight model (Apache 2.0), served by Groq through its OpenAI-compatible API and called with the open-source huggingface_hub client. Any open model works: Qwen through Hugging Face Inference Providers is built in, and Llama, Gemma or Mistral are one environment variable away.
Local inference (optional): set LLM_BASE_URL to an Ollama, llama.cpp or vLLM server and the same app runs entirely on weights you host yourself, with no code changes.

The open model isn't decoration. It is the game master. Without it there is no trial, no rank, no quest and no adaptation. It does three jobs, each with a strict JSON contract:

Step	What the open model does
Trial	Writes level-check questions specific to the chosen skill
Awakening	Rates the Player honestly (most people start at E or D), sets stats, a 30-day goal, a rank-up test and a 7-day plan
Daily Quest	Designs drills from the Player's own equipment, then adapts them using the last report. Drills that hurt are replaced.

The game maths (XP curve, levels, rank gates, streaks, penalty quests) is deterministic JavaScript in the browser, so the model can't "inflate" your progress. You only level up by doing the drills.

Why Does Open Innovation Matter?

Your training data stays yours. Fitness and injury answers are personal. Because the System is an open-weight model, you can run the exact same app on your own machine or server with LLM_BASE_URL, and nothing leaves it.
No lock-in. The model is a setting, not a dependency: gpt-oss today, Qwen, Llama or Gemma tomorrow, on any host or none.
Anyone can audit the coach. The prompts (prompts.py) and the model weights are both public, so you can see exactly why the System gave you a drill, and change it if it's wrong for you.
Free to run. Open models on free hosts, or on your own hardware, mean a student can use a personal coach without a subscription.

Prize Categories

Render. LevelOut is deployed on Render's free tier from a render.yaml Blueprint in the repo, so anyone can fork it and get their own System running in a few clicks: Render reads the build and start commands, pins Python, sets the open-model settings, and only asks you to paste your own API key, which never touches the repo. Two choices were shaped by running it as a public Render service: a 120-second gunicorn timeout, because reasoning models like gpt-oss can think for a while before answering, and a per-visitor limit on AI calls so a public link can't drain the key's free quota.

Built with Flask, vanilla JS, and the open-weight gpt-oss-120b model served by Groq. MIT licensed.