DEV Community: Biprayan Choudhuri

Poltergit: I held a séance with a line of code, and it told me why it exists

Biprayan Choudhuri — Sun, 01 Nov 2026 01:19:19 +0000

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

Every codebase is haunted.

There's a time.sleep(3) nobody dares delete. A retry loop set to seven for a reason nobody remembers. A constant changed by a commit titled "update". The people who knew why have moved on, and git blame only tells you who and when. Never why.

So I built Poltergit, a séance for your git history. You point at a line of code, and the line answers in its own voice, citing the commits and discussions behind it. Every ghost brings receipts. And when the record has nothing to say, it says so.

What I Built

Poltergit is an open-source tool that runs entirely on your laptop, as a command line and a small local web "séance room".

Summon a line. poltergit why src/client.py:13 walks that line's history with git log -L: every commit that touched it, with its diff and message. If you opt in, it also pulls the GitHub pull requests, reviews and issues around those commits.
The line speaks. Gemma 4, running locally, answers in the first person, as the code and never as the person who wrote it. Every claim carries a citation and an exact quote.
The receipts are checked. Before you see an answer, every quote is matched word for word against its source. If one doesn't match, the whole answer is thrown away and you get the labelled source excerpts instead.
Silence is an answer. If the history doesn't explain the line, Poltergit says the record is silent instead of guessing.
Hear the spirit. Kokoro, an open text-to-speech model, reads the answer aloud with a quiet séance-room echo.
An ofrenda for deleted code. poltergit ofrenda builds a Día de los Muertos memorial page. Every deleted file and Python function gets an obituary: when it arrived, how long it served, and the commit that retired it.

How I read the theme: the ghosts in the machine are the reasons behind code, still there long after the people who wrote them have left. The séance is the spooky half: a voice from the other side, answering questions. The ofrenda is the honouring half: it remembers what code did before it was removed.

Demo

The 44-second video walks through a séance: Gemma's answer, the commit behind it, the answer spoken aloud, and the ofrenda. The wait for CPU inference is cut, and the video says so.

The demo repository is fictional and clearly labelled. poltergit demo creates it with six real commits, so anyone can reproduce every answer below. Here is line 13, time.sleep(3):

"My existence is tied to preventing a reconnect storm, as a three-second delay gives that reservation time to expire." [1]

Source [1] is the commit "fix: wait three seconds before reconnecting", whose message explains that the gateway keeps a closed session reserved for two seconds. The footer shows what the answer cost: 1,503 tokens, $0 in inference, and every quote matched.

Line 5, MAGIC_NUMBER = 43, was changed by a commit titled "update". The honest answer is the record is silent, and that's what Poltergit says. Once, in live testing, Gemma tried to give a reason anyway, with a citation that didn't match its source. The check caught it, threw the answer away, and showed the commit text instead, clearly labelled.

Code

CodeNeuron58 / Poltergit

A séance for your git history. Every ghost brings receipts.

The code is MIT-licensed Python. CI runs the tests on Ubuntu and Windows, including a pgvector integration test against a real Postgres database.

How I Built It

Everything that thinks runs on my laptop through Ollama. There's no API key and no cloud model.

1. The history walk: git

git log -L follows one line through every commit that changed it, even when its line number moved. Poltergit reads the committed HEAD only, warns you about uncommitted changes, and trims the prompt without dropping the line's oldest history.

2. The voice: Gemma 4 E4B

Gemma gets the line, the code around it and its history, and must answer in structured JSON: a list of claims, each with a source ID and an exact quote, or silent: true. Two rules are enforced in code, not just requested in the prompt:

every quote must be at least 12 characters long and appear word for word in its source;
the answer must speak as the code.

Break either rule and the answer is discarded. Matching quotes can't prove the reasoning is right, but it guarantees that every sentence you see points at words that really exist in the record.

3. The memory: Tiger Data, pgvector and EmbeddingGemma

Line history alone misses things. The retry loop on line 9 was only ever touched by the commit that introduced the client, so on its own the séance has nothing to say. The real reason lives in a different commit: the one that raised MAX_RETRIES from 3 to 7.

So poltergit index embeds the repository's history with EmbeddingGemma (768 dimensions, also local) and stores it in Postgres with pgvector on a free Tiger Cloud service. A single SQL query runs two searches and merges them with Reciprocal Rank Fusion:

vector similarity over the embeddings, using an HNSW cosine index;
keyword ranking over Postgres full-text search.

Every search is scoped to one repository, revision and embedding model, so histories never mix.

Line 9: `for attempt in range(MAX_RETRIES):`	What the line says
Line history only	The record is silent
With hybrid search on Tiger Data	"I exist to tolerate the gateway maintenance window, as seven attempts cover the gateway's eighteen-second maintenance window…", with a citation

4. The receipts for the receipts: Sentry Agent Tracing

Every séance is a Sentry transaction (gen_ai.invoke_agent, agent name "Poltergit") with a span for each step. Prompts and source code are never sent: send_default_pii is off, so Sentry sees timings, the model and token counts, not my code.

One trace tells the whole story. Walking the history took 677 ms and checking the quotes took 0.12 ms. Gemma took 2.89 minutes on my CPU-only laptop, for 728 tokens in and 834 out. Inference cost: $0.

How the traces helped me debug:

A timeout that looked like a broken model. My first cold run failed with a model error at 181 seconds. The trace showed the model was working, just slowly (6 to 11 tokens a second without a GPU), and my 180-second timeout was the real problem. It's now configurable, and the setup guide says to raise it on CPU-only machines.
Missing AI spans. A test of the exact data sent to Sentry showed the AI child spans weren't inside the transaction, because the SDK streams them separately by default. I turned that off, so each séance arrives as one complete trace.
Traces that never arrived. The command-line tool exited before the SDK sent anything. I'd disabled its default integrations, including the one that flushes on exit. One explicit flush() before exiting fixed it.

5. The rest

Kokoro, an open 82M-parameter text-to-speech model run through ONNX, reads the answer slightly slowed, with quiet delayed reflections for the séance-room echo.
FastAPI, Typer and Jinja2 power the local séance room, the CLI and the static ofrenda export. The server only listens on localhost and uses anti-CSRF tokens.
The ofrenda's birth dates are real. Function obituaries come from comparing Python syntax trees across up to 200 revisions of a file, so each function's birth date is when it actually appeared.

Why Does Open Innovation Matter?

Your history stays yours. A repository's history is a company's diary: messages, reviews, internal reasons. Gemma, EmbeddingGemma and Kokoro all run on the laptop, so no closed AI API ever reads it. The only things that leave are what you choose: embeddings in your own database, and traces with no content in them.
The safety net needs the whole loop. Checking every quote word for word only works because I control everything: the prompt, the structured output, and what happens when an answer fails. I could test that the net holds, and it did, catching a made-up citation in live testing.
It costs nothing to ask. Every séance is $0 in inference. A tool you consult on every confusing line in a legacy codebase can't charge per question.
The past should outlive the vendor. A tool for reading history shouldn't depend on an API that can be retired. The open weights on my disk will still be there in ten years.

The Spirit of It

The moment it landed wasn't on my demo repository. It was on request, the npm library that was deprecated in 2020.

I asked line 3 of its README why it exists. That's the line that reads "As of Feb 11th 2020, request is fully deprecated." Poltergit found the commit "doc: note full deprecation (#3267)" and the pull request behind it, whose entire description is two words: "It's time." There wasn't enough written down for Gemma to say more, so the séance showed me the excerpts, labelled, and fell silent. That felt right.

Then I asked line 49 of its package.json, the uuid dependency. Its history holds a 2016 commit: "using defunctzombie fork of uuid because node-uuid has been abandoned by developer". Gemma answered by citing that commit. A deprecated library, still carrying a line that only exists because another library was abandoned before it. That's exactly the kind of ghost I built this for.

Prize Categories

Best Use of Gemma: Gemma 4 E4B writes every answer locally through Ollama, as structured JSON that's checked quote by quote, and EmbeddingGemma creates the 768-dimension vectors behind the hybrid search. Two Gemma models, both local, $0 in inference.
Best Use of Tiger Data: the repository's history is embedded into pgvector on a free Tiger Cloud service, and one SQL query merges vector and keyword search with Reciprocal Rank Fusion, scoped by repository, revision and model. It turns line 9 from "the record is silent" into a cited answer.
Best Use of Sentry Agent Tracing: every séance is a gen_ai.invoke_agent transaction with spans for the history walk, the Gemma call (model, tokens, latency) and quote verification, and no prompts or code are sent. The traces found a timeout, missing AI spans and a bug where traces were lost on exit.

Thanks for reading. Which line in your codebase would you summon first? 🕯️

Tortoise: a slow agent that reads your council's planning applications so you don't have to

Biprayan Choudhuri — Mon, 26 Oct 2026 02:39:58 +0000

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

Most people find out what's being built next door when the scaffolding goes up.

It was never a secret. In the UK, every planning application is published on the council's website, and neighbours get a few weeks to comment. But "published" means a weekly list of twenty-odd entries in planning shorthand, each linking to a pile of PDFs, with the comment deadline tucked away in a separate tab. Nobody reads that website. I wouldn't either.

So I built Tortoise, an agent that reads it for you: slowly, once a week, one page at a time.

What I Built

Every Monday at 07:00 UK time, Tortoise:

Opens the council's weekly list of new planning applications in a real browser.
Keeps only the ones near you. You give it street names and postcode sectors.
Reads their documents: the application form, the design and access statement, the planning statement.
Emails you one card per application: what's proposed, why a neighbour might care, the date you can comment by, and a link to the council's page.

That's the whole product. One email you can read in a minute, instead of a website you would never open.

Who it's for: anyone who'd like a say in what gets built on their street but will never read a planning portal. That includes neighbours, residents' associations, local councillors and the local paper.

Why UK councils, when I live in India? More than 150 of them run the same planning software, Idox Public Access. An agent that understands one portal understands them all. The catch is that those portals block traffic from outside Europe, so Tortoise's browser runs in Frankfurt (more on that below).

How it rewards laziness: you do nothing. Tortoise does the reading, and it's deliberately slow about it: 5 to 10 seconds between pages, 8 seconds between applications, and only last week's list. In a normal week only one step costs money, and this week that step cost about a fifth of a cent.

Demo

Tortoise has no website to click around. It's a Monday-morning job that runs on my machine, so the demo is what it sends you.

Here is a real week: West Suffolk Council's list for 19 to 23 October 2026, with the York Road area of Bury St Edmunds as the watch zone. This is that run's brief and numbers in the current email design. I've removed house numbers; the real email has them.

Look at the York Road card. The council's listing says "single storey rear extension". The application form, the PDF nobody opens, says "rear and side extension". If you live on that side, that's the one sentence you needed, and Tortoise found it because it actually read the form.

On the tree card, the documents don't give a reason for cutting five metres off the crown, so the brief says "not stated" instead of inventing one.

Code

CodeNeuron58 / tortoise

A slow, steady agent that reads a UK council's weekly planning list and the PDFs behind it, then emails you a one-page brief: what's being built near your street, and the date to object by.

The code is MIT-licensed Python. CI runs 110 offline tests on every push, with no network, no browser and no model. The real run and all six failure tests have their evidence in docs/evidence/ (exported Temporal histories, plus CLI output for the duplicate-run test), so every number in this post has a file behind it.

How I Built It

Temporal workflow: WeeklyWatch (one per council, every Monday 07:00 UK time)
  └─ crawl_list ──▶ zone filter ──▶ fetch_application (+8 s pause) per app
        └─▶ gemma_filter (local, free) ──▶ write_brief (paid, counted)
              └─▶ send_email ──▶ record_run (the Lazy Payoff numbers)

1. The browser: Stagehand on Browserbase

The crawl is a Stagehand script running in a Browserbase session pinned to eu-central-1, because UK planning portals refuse traffic from other regions. The PDFs download through the same session, so every request comes from the same place.

Idox portals share one page structure, so the stable parts are read with direct selectors:

the weekly-list form,
the results table,
the Documents tab,
the Important Dates tab, where the real comment deadline lives.

Stagehand's plain-English act, extract and observe are the fallback for councils whose layout differs, with instructions like "set the list period to last week" and "click the Next page button". In this week's run the selectors covered everything, so the model that drives Stagehand was never called and the crawl cost nothing but browser minutes.

That driving model is pluggable. I wrote an adapter (crawl/llm_adapter.py) that sends Stagehand's model calls to any OpenAI-compatible endpoint: local Gemma through Ollama, or Ultramarine.

The politeness rules are in code:

It never opens the tabs that list applicants' names.
At most three text documents per application. Drawings, plans and photos are skipped by name, and scanned PDFs are detected and skipped.
Every session is released the moment its work is done. The whole week took 1.71 browser minutes across three sessions.

2. The slow part: Temporal

The whole agent is one Temporal workflow, WeeklyWatch, run per council per week by a schedule (0 7 * * MON, Europe/London). Temporal is what lets a slow agent also be a reliable one.

Crawling resumes mid-list. crawl_list heartbeats after every results page, and each page's rows are saved before the heartbeat. If the worker dies, the retry reads the last heartbeat and jumps straight to that page, since Idox page links carry the page number. Rows are upserted by council and reference, so nothing duplicates.
The politeness survives crashes. The 8-second pause between applications is a workflow.sleep, so a crash can't skip it.
Failures are handled honestly. Activities retry three times with backoff. A bad API key or empty credit is non-retryable, and the email says the brief was skipped and why. If Ollama stays down, every application is kept and the run is marked "unfiltered". Tortoise never silently drops an application.
No double emails. Manual runs use the workflow id watch-<council>-<week> with a reject-duplicate policy.

Then I broke it on purpose, six ways, against the live stack. Each test's evidence is in the repo. Here is test 1 in Temporal's timeline: the crawl's first attempt (red) died with the worker after page 2, and the second attempt picked up at page 2 on a new worker.

#	What I broke	What happened
1	Killed the worker after results page 2	Heartbeat timed out after 2 minutes; the new worker logged `resuming crawl from page 2`. 23 rows, no duplicates.
2	Ended the Browserbase session mid-crawl	`CDP connection closed`, then a retry in a fresh session from page 2
3	The brief failing	Three attempts, then an email saying the brief was skipped, and why. The exported run is a real failure: Ultramarine returned an empty reply.
4	Stopped Ollama	Gemma failed three times; both applications were kept and the run marked unfiltered
5	Ran the same week twice	`Workflow execution already started`, and one email
6	Stalled the crawl for 150 seconds, like a slow site	The first attempt was cancelled at 2:00; the retry crawled all 3 pages and finished

3. The free filter: Gemma 4, on my laptop

First, a plain-Python filter matches street names and postcode sectors. That took this week's list from 23 applications to 2 before a single application page was opened.

Then Gemma 4 E4B runs locally through Ollama's OpenAI-compatible endpoint, at temperature 0 in JSON mode. For each application it returns:

a type: extension, new homes, change of use, demolition, trees, mast or antenna, shopfront or advert, or other,
likely street impacts, such as parking, noise or daylight,
a relevance score from 0 (elsewhere) to 3 (on your street),
and a one-line summary.

Tortoise keeps 2 and 3. The JSON parsing is strict and tested against broken replies.

It took 82 seconds for two applications on my laptop. That's slow, and it's fine: it's a Monday-morning job, nobody is waiting, and it's free.

4. The one paid step: Ultramarine 1 Flash

Paper Instruments' Ultramarine 1 Flash is called through the standard OpenAI Python SDK; only the base URL, key and model name change. It receives each kept application's council listing plus the text of its documents, trimmed to a 60,000-token budget (the model accepts 131,072).

The prompt's rules:

Use facts from the listing and documents only.
Write "not stated" when a fact is missing.
Never name applicants, agents or any other private individual.
Reply in JSON.

The comment deadline and the link are filled in from the council's own pages, never from the model.

Every call is costed to the token and logged in SQLite, and the total goes in the email's footer:

cost (USD) = ( 0.15 × uncached input
             + 0.03 × cached input
             + 0.50 × output ) / 1,000,000

This week's brief used 4,187 tokens in and 2,852 out, for $0.0021. Every brief in the cost log, nine of them from my first test run to the last failure test, cost $0.012 together, out of the $5 Hacktoberfest credit.

5. The email: Brevo

The email goes out as designed HTML and plain text through Brevo's free plan. Cards are sorted by deadline, each with a countdown, and the run's numbers are in the footer. If the brief was skipped, the email says so instead of going quiet.

What broke on the way

A few things I got wrong before the run above, all fixed now:

The in-session PDF download built invalid JavaScript, so early runs read zero PDFs and their briefs had only the council's one-line listing to go on.
Comment deadlines came from the summary tab. The Important Dates tab is the one that's right.
The brief prompt never actually included the proposal text.
Browser sessions stayed open until Browserbase's timeout instead of being released.
Cached tokens were billed twice in my cost formula.
Ultramarine once returned an empty brief because its reasoning used up a small output cap. The cap is now 8,000 tokens.

The robots.txt lesson

After my live runs, I checked robots.txt properly. Every Idox portal I could reach, West Suffolk and Sevenoaks plus twelve more, says:

User-agent: *
Disallow: /

I should have checked before the first run, not after. A run reads about seven pages in four minutes, with pauses between them. But I ran it many times while testing, and a polite crawler is still a crawler.

So Tortoise ships with both example councils disabled, and a council with enabled = false cannot start a run. The README says to switch one on only with that council's permission. For a project whose whole point is helping people take part in local decisions, asking first is the only version that makes sense.

Why Does Open Innovation Matter?

The boring 90% costs nothing. The crawl logic, the zone filter, Gemma and the scheduler are all open source or open-weight and run on my laptop; only the browser itself is rented, by the minute. If every step went through a hosted model, I'd be paying to read every page of every council's list, every week. Here the only metered step is one short brief about the few applications that matter, which is what makes "every council, every week" thinkable for a residents' group with no budget.
I could fix the framework instead of working around it. Stagehand is open source, so I could read exactly how it calls its model and write an adapter that sends those calls to a local model instead. A closed browser agent would have made that choice for me.
Most of the data stays at home. Filtering the whole list, by street and then by Gemma, happens on my machine. Only the few kept applications' documents go to a hosted model, and the brief is forbidden to name anyone.
The rules are inspectable. Politeness and privacy are code, not a promise on a terms page: the pauses, the three-document cap, never opening the contacts tab. A council's IT team can read exactly what Tortoise will and won't do before saying yes.
Nothing is locked in. Gemma, Stagehand's driving model and the brief writer all sit behind OpenAI-compatible endpoints, switched with environment variables. Temporal runs locally with a database file.

The Lazy Payoff

The real week: West Suffolk, 19 to 23 October 2026	Result
Applications on the weekly list	23, over 3 results pages
On the watched streets	2 (York Road and Springfield Road)
Documents read for you	2 application forms, 13 pages; drawings skipped
Comment deadlines found	10 and 14 November 2026
Browser time	1.71 minutes, 3 sessions, all released
Gemma, running locally	82 seconds, $0
Ultramarine	7,039 tokens, $0.0021
The whole run	about 4 minutes, from start to email
Time a human spent reading	about a minute, on the email

Doing this by hand means:

opening the weekly list,
checking 23 addresses against your streets,
opening two applications and finding each deadline in its own tab,
and reading 13 pages of forms.

Call it half an hour a week. Mostly, though, people don't do it at all, and that's the real cost: the deadline passes without them.

To be honest about usage: so far, the only inbox Tortoise has emailed is mine.

Prize Categories

Best Use of Browserbase: Stagehand drives each council's live planning portal in a Browserbase session pinned to eu-central-1 (UK portals block other regions). It downloads the PDFs through that same session and releases it the moment it's done, so a full week took 1.71 browser minutes. Temporal turns that agent run into a repeatable Monday workflow.
Best Use of Ultramarine: Ultramarine 1 Flash, called through the OpenAI SDK, reads the kept applications' documents and writes the brief under strict "not stated, never guess, never name anyone" rules. Every call's tokens and dollars are logged: this week's run cost $0.0021, and every brief in the cost log, tests included, cost $0.012.
Best Use of Temporal: the whole agent is one durable WeeklyWatch workflow on a Monday schedule. It has per-page heartbeats so a crash resumes mid-crawl, a durable 8-second politeness sleep, non-retryable auth errors and duplicate-run rejection, proven by six live failure tests with their evidence in the repo.
Best Use of Gemma: Gemma 4 E4B runs locally through Ollama and labels every in-zone application (type, street impact, relevance 0 to 3) for free, so only the applications that matter reach a paid model. If Ollama is down, nothing is silently dropped.

Thanks for reading. If you live in one of those 150-odd council areas, I'd love to know what you'd want the Monday email to tell you that it doesn't yet. And if you work at a council, I'd love your permission to point a very polite tortoise at your weekly list. 🐢

Turnaround: an open-source hiking buddy that knows when you should turn back, and tells someone if you don't come home

Biprayan Choudhuri — Mon, 12 Oct 2026 03:12:09 +0000

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

Most hiking trouble isn't dramatic. Nobody falls off a cliff. Someone simply keeps going a little too long because the summit is "just around the corner", the sun sets earlier than they thought, and the only person who knows where they went is themselves.

Two things would fix most of that:

Knowing, before you leave, the time you should turn around, based on how fast you actually walk rather than a sign at the trailhead.
Someone you trust finding out automatically if you don't come back, without you having to remember to tell them.

So I built Turnaround. You spend about two minutes with it before a hike, then put your phone in your pocket.

What I Built

Turnaround is a hiking companion that runs entirely on your own laptop. Before a hike it gives you three times:

Turn around by: not at the top or the far end by this time? Head back.
Back by: 9 in 10 hikes like yours finish before this.
Sunset margin: how much daylight you have to spare.

Then it does four things:

Predicts how long you will take, as a range rather than a single guess. An open tabular foundation model (TabPFN) learns from 7,186 real recorded hikes and adjusts to your pace after every hike you finish.
Briefs you out loud. Gemma 4, running locally, turns the numbers into a short spoken briefing that sounds like a friend who hikes. It's saved to your phone before you leave, so it plays with no signal.
Watches. When you tap Start, a durable safety timer begins waiting for your check-in.
Tells someone. If you're well past your back-by time and still haven't checked in, your emergency contact gets an email with your plan, your route and a map link to where you set off. If you then check in late, they get a second email saying you're safe.

No GPX file? You just enter the three numbers every trail page lists (distance, elevation gain and trailhead), and Turnaround plans from those.

Who it's for: anyone who hikes alone or is new to it, and anyone with a parent, partner or friend who worries when they head out.

How it gets you off the screen: the screen part is the beginning and the end of the trip. Plan, listen, pocket the phone, walk. The next time you look at it is to tap Hike complete.

How it works

Demo

The video walks through the whole flow: planning a hike, the spoken briefing, starting the trip and the safety timer, and checking in.

Turnaround runs on my laptop, by design (more on that below), so there's no public link. The repo has one-command-per-terminal setup if you want to run it yourself.

Code

CodeNeuron58 / Turnaround

An open-source hiking companion

MIT-licensed. CI runs typechecks, the app build and two unit-test suites on every push. Everything I claim below has a file in the repo backing it.

How I Built It

Everything runs on one laptop:

Phone or browser → the app (React + Vite), reached over Wi-Fi or Tailscale
App → the prediction service (FastAPI + TabPFN + SQLite)
Prediction service → Gemma 4 (via Ollama) for the briefing, Kokoro for the voice, and the Temporal server to arm the timer and send check-ins
Temporal worker → the alert and all-clear emails to your contact

The only things that leave it are an anonymous weather lookup (coordinates only) and, if you're overdue, the alert email.

1. Predicting your hike time: TabPFN

The classic hiking-time rule is Naismith's rule: roughly 12 minutes per kilometre plus 1 minute per 10 m of climbing. It's on half the trail signs in the world, and it gives the same answer for everyone.

I wanted a range, and I wanted it to fit the person. TabPFN is an open tabular foundation model: you give it a table of examples and it predicts new rows in context, with no training loop. Crucially for a safety tool, it returns a full predictive distribution rather than one number.

The data is 7,186 GPS-recorded hikes from hikr.org (a public Kaggle dataset, CC0). The features are distance, climb, descent, highest point and the SAC difficulty grade (T1–T6). I held out 1,438 hikes the model never saw and compared it with Naismith:

On 1,438 unseen hikes	Naismith's rule	TabPFN v3.5
Average error	44.1 min	34.8 min
RMSE	69.1 min	54.5 min
Real times inside the predicted 90% band	—	89.5%
Hikers back before the "back by" time (P90)	—	90.4%

The last row is the one I care about most. A safety tool has to be honest about its uncertainty, not just accurate on average. When Turnaround says "9 in 10 hikes like this are done by 4:40", that turns out to be true for 90.4% of hikes. Average error being 21% lower is a nice bonus.

On a laptop CPU I serve TabPFN v2 by default. It's about 3x faster with nearly identical calibration (89.7%). The v3.5 checkpoint is one environment variable away.

How the prediction becomes decisions:

Back by = the 90th percentile + your planned breaks.
Turn around by = the share of that time you should spend heading out, assuming you retrace your steps. Climbing happens on the way out, so steep routes front-load it (Naismith's split, clamped between 50% and 70%).
Alert = the 95th percentile + breaks + 30 minutes of grace. I deliberately didn't make it the back-by time: your contact should only be emailed when you're genuinely late, not five minutes slow.

Learning your pace. The crowd isn't you. Every hike you finish compares your actual moving time with the model's median for the same route, and the ratios combine into a personal pace factor. It's shrunk toward 1.0 on purpose, so one bad day can't swing the safety timer. A hike that was 40% slower than predicted moves your next estimate up about 12%, not 40%. Hikes where you tapped I turned back early don't count, because a turned-back time says nothing fair about the whole route. All of these rules are in a small, unit-tested module.

2. A promise that survives a crash: Temporal

The scariest bug a safety app can have is a timer that silently dies. If the alert depends on a Node process staying alive for six hours on a laptop, it's not a safety feature, it's a hope.

So the safety timer is a Temporal workflow. One tripWorkflow per hike races a check-in signal against a durable timer set to the alert moment. Sending the email is an activity with retries. A late check-in after the alert triggers the all-clear. I run Temporal's free local dev server with an on-disk database, so timers survive a restart of the server itself, not just the worker.

Then I tried to break it. Each scenario has its workflow history or logs committed in docs/evidence/:

#	What I did	What happened
1	Checked in on time	Timer closed, nobody emailed
2	Missed the check-in while the mail server failed	Activity retried; alert went out on attempt 2
3	Killed the worker mid-trip, restarted it 25 s later	Alert still fired exactly on the deadline: 90.5 s after start, despite the worker being dead from second 20 to 45
4	Drill: missed check-in, then a late check-in	Alert on the deadline, then an all-clear
5	Killed the Temporal server mid-trip	Timer survived on disk; a check-in sent during the outage reported the failure honestly and landed when re-sent

Scenario 3 is the whole reason Temporal is here. The promise didn't notice the outage.

This is what your contact actually receives. Both emails below were delivered to my own phone through Brevo, using the same templates and code path the worker uses (sent with the preview command, which is why they're marked [PREVIEW]):

The alert says who, which route, when they set off and when they should have been back, with a one-tap map link to the starting point. The all-clear tells your contact they can stand down. Nobody has to decode a log file at 4 a.m.

The app is equally honest when something is wrong. If the timer fails to arm, the trail screen shows a red "safety timer NOT armed" banner with a retry button rather than pretending you're covered. If you check in with no signal, the check-in is saved on the phone and sent the moment it can reach the laptop, and re-sending is idempotent, so a flaky connection can't double anything.

3. A briefing that sounds like a friend: Gemma 4 + Kokoro

Numbers on a screen are easy to ignore. A voice in your ear saying "If you're not at the top by 1:40, turn around. The view will still be there next weekend" is not.

Gemma 4 (E4B) runs locally through Ollama's OpenAI-compatible endpoint. The service hands it the trip's facts (distance, climb, turn-around and back-by times, sunset, rain chance, trailhead) and asks for 4 to 6 short sentences "like a friend who hikes, not a robot", always including the turn-around rule. Kokoro, an open 82M-parameter text-to-speech model, reads it aloud on the same machine. The text and audio are generated once, stored, and saved to your phone while you still have signal.

Gemma is the voice, never the source of truth: every number it speaks comes from the prediction service, and if the sunset time is unknown, the prompt tells it to say so rather than invent one.

The app

React + Vite, three screens: Plan, On trail and Summary. Your phone reaches the laptop over the same Wi-Fi, or over Tailscale on mobile data, so nothing is exposed to the public internet. Weather and sunset come from Open-Meteo, with no API key and coordinates only. Alert emails go through a free Brevo account, and every email is also written to a local outbox as a record.

Why Does Open Innovation Matter?

Think about what a hiking plan reveals: where you'll be, that you'll be alone, and until when. I don't think that belongs on someone else's server, and with open models it doesn't have to.

Your location stays on your machine. Gemma 4, TabPFN and Kokoro all run on my laptop. A closed AI API would see every trailhead I start from and every hour I'm out alone.
It costs nothing to run. No subscription, no per-request bill, no key that expires mid-hike. A hiking club could host it for its members on one old laptop or a Raspberry Pi-class box.
The uncertainty is mine to inspect. With TabPFN's weights and a public dataset, I could measure calibration on 1,438 unseen hikes myself. A closed "estimated time" API gives you a number and asks for trust. For a feature that decides when your family gets an alarming email, I wanted the evidence.
Everything is swappable. The checkpoint is one environment variable (v2 for speed, v3.5 for accuracy), Gemma could be any model behind an OpenAI-compatible endpoint, and Piper is a drop-in fallback for Kokoro. Nothing in the stack can be deprecated out from under it.
The data is a commons. The model learns from thousands of hikers who shared their tracks publicly, and gives each new hiker something back.

Where open was genuinely better for me, not just cheaper: calibration. I needed to know that "back by" means 90%, and I could only know that because I could run the model myself on data I could see.

Honest limits. So far I've tested Turnaround at home, with sample routes and missed-check-in drills; taking it on a real trail is next. It's a prototype, not a replacement for telling someone your plan or carrying a satellite messenger in real backcountry. The laptop has to stay awake and online for the alert to send. The model knows hikr.org's mostly Alpine hikers best, and the pace factor exists precisely because you are not them.

Prize Categories

Best Use of TabPFN: TabPFN predicts each hike's moving time as a calibrated distribution. Its P90 becomes the back-by time, its P95 sets when your contact is alerted, and its median feeds your personal pace factor. On 1,438 unseen hikes it beat Naismith's rule (34.8 vs 44.1 min average error) with 90.4% of hikers back before P90.
Best Use of Temporal: the safety timer is a durable Temporal workflow that races a check-in signal against the alert deadline, retries the alert email, and sends an all-clear on a late check-in. Tested by killing the worker and the Temporal server mid-trip, with evidence in the repo.
Best Use of Gemma: Gemma 4 runs locally via Ollama and turns each trip's numbers into a short spoken briefing (voiced by Kokoro) that's saved to your phone before you lose signal.

Thanks for reading. If you hike alone, I'd love to hear what would make you actually use something like this, and what time you'd want to be told to turn around. 🥾

He asked for "fully secure" note sharing. Here's what I built instead.

Biprayan Choudhuri — Sun, 04 Oct 2026 23:23:42 +0000

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

He asked for "fully secure" note sharing. He wouldn't stop asking, honestly. So before writing a single line of code, I had to be honest with him about what that sentence actually means.

Fully secure note sharing is not possible. Not on the web, not anywhere. No website can stop someone from taking a screenshot, pointing a phone camera at the monitor, or retyping what they see. Anyone who promises otherwise is selling something.

But "fully secure" being impossible doesn't mean "secure" is. So I built the most controlled version of the idea I could, and named it SecureNote.

What I Built

SecureNote is end-to-end encrypted note and file sharing, and I built it for my friend. His notes aren't text, by the way: they're PDFs, scanned documents, photos of whiteboards. So files are first-class citizens here, and they're encrypted exactly like everything else.

What it actually gives you:

Notes and files (PDFs, docs, images, up to 10 MB) are encrypted in your browser with AES-256-GCM before upload. The database stores ciphertext: it cannot read your content, your titles, or even your filenames.
You share with a person, not a link. Pick someone by their account, set an expiry and a view limit. The note's key gets wrapped for their public key alone.
Revocation is instant. One click and their key stops working, even if they already read the note. Their open tab locks itself the next time it gets focus.
Every read is on the record. Each view is watermarked with the reader's email and written to an audit log: who, when, from which IP, on what device. Even pressing the PrintScreen key is logged as an attempt.
The AI never leaves your machine. Semantic search and "chat with your notes" powered by Gemma 3 (Google's open-weight model) running in the browser via WebGPU. Open the network tab while using it: nothing goes out.

So what about screenshots? Like I said: I can't stop them. Nobody can. What I can do is make sure a screenshot isn't anonymous. Every page a reader opens is tiled with their identity and a timestamp. If they leak it, they leaked a page with their own name on it, at a logged time, from a logged IP. You can also cap the views or expire the share in an hour.

My friend's response was something like "okay, fair."

Demo

Live app: https://securenote-j8b0.onrender.com

It's hosted on Render's free tier, so the very first load can take about 50 seconds to wake up. Every load after that is instant. Sign up with two accounts: write a note as A, share it to B with a 2-view limit, open it as B, then check A's audit log. Press PrintScreen as B and watch it land there too.

Code

The full source is on GitHub, MIT licensed: https://github.com/CodeNeuron58/SecureNote

The README covers the whole security model, including the threat model and the things no website can honestly promise.

How I Built It

No crypto libraries, just the browser's built-in WebCrypto:

Signup generates an ECDH P-256 keypair in your browser. The private key is encrypted with a key derived from your password (PBKDF2-SHA-256, 310,000 iterations) before it's ever uploaded. The server stores a bcrypt hash, a salt, your public key, and your sealed private key. It never sees your password.
Every note gets a random content key. Title, body, and uploaded files are encrypted client-side; the content key is wrapped to your own public key.
Sharing unwraps that key in your browser and wraps it for the reader's public key (ephemeral ECDH + HKDF). The server relays sealed blobs it cannot open, while still enforcing expiry and view limits.
The AI is the part I'm proudest of. Private notes plus a cloud AI API is a contradiction, so the AI runs in the browser: MiniLM embeddings and Gemma 3 1B (open weight) via transformers.js on WebGPU, with the vector store in IndexedDB. After the one-time model download, searching and chatting make zero network calls.

Stack: Next.js 15, TypeScript, Tailwind, MongoDB Atlas, hosted on Render.

Why Does Open Innovation Matter?

My friend's whole point was "my notes stay mine." Sending that data to a closed cloud AI would betray the entire premise, so an open-weight model running on-device wasn't a nice-to-have. It was the only architecture that made sense.

It also cost exactly nothing to run, it works with pluggable models (swap Gemma for any ONNX model without asking anyone's permission), and he can clone the repo and host the whole thing himself if he ever stops trusting me. The open approach didn't just work better than a closed one here. It was the difference between using software and owning it.

Prize Categories

Best Use of Gemma: Gemma 3 1B (open weight) powers the in-browser "chat with your notes" and semantic search, running locally via WebGPU
Best Use of Render: the whole app is hosted on Render's free tier
Best Use of MongoDB Atlas: Atlas is the data layer, deliberately storing only ciphertext, grants and audit events

It's built for one friend, but if you've ever needed to send something sensitive without losing control of it, it's for you too. Roast it, break it, tell me what you'd add.

I Built Yumii — An Open-Source AI Companion

Biprayan Choudhuri — Sun, 07 Jun 2026 14:45:43 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Yumii is an open-source, locally-run AI companion with a Live2D avatar, real-time voice, and six distinct personalities — and she now actually remembers you.

She listens to your voice. She responds through an animated avatar. Her face reacts to what you say. And as of this sprint, she builds a long-term memory of who you are — across every conversation, every session, every restart.

Beyond the core AI experience, Yumii focuses heavily on accessibility and ease of use. The project features a dedicated website, comprehensive documentation, a one-line installation command, and a streamlined CLI onboarding process that helps users get started quickly.

GitHub: https://github.com/CodeNeuron58/Yumi
License: MIT

Demo

Before vs After — at a glance:

Before	After
Forgot you on every restart	Persistent memory across sessions
One shared conversation, no history	Full session management — create, resume, rename
No user facts	Auto-extracts facts from every conversation turn
No CLI beyond launch	`/memory`, `/sessions`, `/resume`, `/forget` commands
Wiped on exit	Survives restarts
No dedicated website	Full documentation website
Basic audio capture	Active VAD — only speaks when you actually do
Manual setup	One-line installation

The Comeback Story

I saw Project Ava and a few other AI companion demos and thought — I could build that.

I enjoy anime. The idea of an anime-style AI that actually talks and reacts to you genuinely excited me. So I built a scrappy version that barely held together, it worked, I was happy, and I dropped it. I mean i just build it for fun so i didn't care that much .

Months later I saw the same concept being sold as a subscription product. That bothered me. I'd already built this, yeah a scrappy one , but still i built it. And i thought to myself that I could build it properly — and make it free or opensource .

So I restarted. Proper CLI. Web interface. Clean architecture. VAD, STT, LLM, TTS — the full real-time voice loop. And one hard rule: it has to run on a CPU. I don't have a GPU. Most people don't. If it needs one, it's not really for everyone.

That's what you're looking at now. Still alpha, still rough in places, not yet user-tested beyond myself. But it works, it's free, and it runs locally on your machine.

Note on the demo: I'm skipping a video walkthrough — the Live2D model I use locally has redistribution restrictions, so I can't share footage with it publicly. Voice, memory, and everything else works fine as much as i can tell , it works without an avatar if you want to try it yourself.

What's next

Making her actually do things.

Right now Yumii talks. What I want is for her to act — search the web, read your emails, help you shop, browse on your behalf. A real assistant, not just a companion.

It would be done by giving her tool access via mcp.

Contribute

Yumii is fully open source — MIT license. If you're a developer who builds with LangGraph, vector databases, voice pipelines, or just finds this kind of project interesting — contributions are genuinely welcome.

I'd love to hear what other developers think of the architecture, the approach, or what they'd build on top of it. Open an issue, start a discussion, or just drop a comment here. Every perspective helps.

Small Note

Yumii is still in a very early stage and actively being developed, so expect rough edges here and there.

This is my first time properly sharing the project outside LinkedIn, and I’d genuinely love feedback, ideas, or contributions from fellow developers while building it

My Experience with GitHub Copilot

Copilot was running throughout this sprint mostly through tab completion — and that's where it genuinely helped.

The repetitive async patterns across the session and memory modules are where it earned its place. Once it saw the structure of the first method, it completed the rest almost entirely — correct SQL, correct await placement, correct error handling. What would've taken an hour took fifteen minutes.

The SQLite schema was another moment. I typed CREATE TABLE sessions ( and it suggested the full schema, including columns I hadn't thought of yet but ended up needing.

It didn't make any decisions. The architecture, the three-database design, the fire-and-forget fact extraction, the async queue pipeline — all of that was thought through manually. But for translating decisions into correct boilerplate fast, it was genuinely useful.

I also used Claude for cross-checking integration points — particularly verifying the LangChain tool interface when I added web search. Both tools, different jobs.