DEV Community: Jay Pokale

caveman vs ponytail vs Chisle: why I'd pick Chisle for Claude Code

Jay Pokale — Fri, 23 Oct 2026 04:23:36 +0000

If you've looked at cutting Claude Code's token use, you've probably found caveman and ponytail. Both are good. caveman makes Claude talk less. ponytail makes it build less.

I started Chisle as a mashup of the two, and both are credited in the README. Here's why I think it's now the better pick.

1. It gives the shortest answers

Same model, same prompts, only the ruleset changes. Answer length as a percentage of the model with no ruleset (lower is leaner):

	caveman	ponytail	Chisle
Claude Code, 26 prompts	65%	58%	56%
Pi, 6 tasks	56%	49%	37%

Here's one prompt from that set: "Implement an order state machine covering created, paid, shipped, delivered, cancelled and refunded."

no ruleset: 1,342 tokens, 125 lines, two classes, a custom exception and docstrings
caveman: 1,140
ponytail: 842
Chisle: 450

Chisle's answer is one dict of legal transitions and one method that checks it:

class OrderStateMachine:
    TRANSITIONS = {
        'created': {'paid', 'cancelled'},
        'paid': {'shipped', 'refunded'},
        'shipped': {'delivered', 'cancelled'},
        'delivered': {'refunded'},
        'cancelled': set(),
        'refunded': set(),
    }
    def transition(self, new_state):
        if new_state not in self.TRANSITIONS[self.state]:
            raise ValueError(...)
        self.state = new_state

Same behaviour. A third of the tokens.

2. It doesn't make Claude dumber

The fair worry with any of these tools is that tokens are where the model thinks, so fewer tokens means worse answers. I tested that without an LLM judge:

312 maths and coding problems, graded by exact match and hidden unit tests: no ruleset 155/156, Chisle 156/156
120 agent runs on real repos, graded by hidden tests: 49/60 vs 48/60

Statistically there's no difference (p = 1.000 on both). Shorter answers, same results.

3. It goes after the part of the bill the others don't touch

This is the big one. When I measured 171 of my own Claude Code sessions, Claude's replies weren't where the tokens were. Tool output was 67.5% of the context: build logs, test runs, giant grep results. And it doesn't get billed once. It rides along with every later request in the session.

caveman and ponytail only shape what Claude writes. Chisle also has a hook that trims big tool output before Claude reads it:

strips color codes and collapses repeated lines
keeps the start and end of long output, plus any error lines from the middle
replaces exact repeats with a one-line note

It never touches Read, Edit or Write, because edits need the exact bytes. On the output it does touch, it cuts about 46%. With npx chisle mcp wrap the same thing works for MCP servers in Cursor, Windsurf, Cline, Kiro, Gemini CLI and others.

There are also a few rules about reading: grep for the symbol first, read only the slice you need, and don't re-open a file that's already in context.

4. It's one install for every agent you use

npx chisle

It finds and sets up Claude Code, Cursor, Windsurf, Cline, Kiro, Codex, Gemini, Copilot, Copilot CLI, OpenCode, Antigravity, Hermes and Pi. Zero dependencies, MIT, and npx chisle --uninstall puts everything back.

5. You can check every number

Every raw transcript behind these tables is committed in benchmarks/results, including the runs where Chisle loses. The main one: on Pi, ponytail's total bill came in slightly lower (59% vs 61%), because the bill also counts hidden reasoning. I'd rather show you that than have you find it.

JayPokale / Chisle

Cut your AI coding agent's token bill on three axes: terse prose, YAGNI-first code, and tool-output compression. Claude Code, Pi, Cursor, Codex, Gemini + 4 more. Zero deps, published benchmarks including the runs it loses.

Chisle

Fewer tokens than caveman and ponytail. No accuracy lost.

Your AI talks less, builds less, reads less, and says more. Like a senior dev who bills by the syllable.

The only tool in this class that publishes the runs where it lost. Here's why.

Built for Claude Code: answers about half as long, shorter than caveman and ponytail · 13 agents · zero dependencies · one command

Chisle is a Claude Code plugin that makes Claude cheaper to run without making it dumber. It cuts what Claude writes: no filler, no hedging, no speculative abstractions, just the smallest code that works. It also cuts what Claude reads: a PostToolUse hook trims oversized tool output by ~46% before it re-enters the context window, where it would be re-billed on every later request. In agent-loop tests Claude with Chisle passes the same tasks as Claude without it. One npx chisle installs…

View on GitHub

If you try it next to caveman or ponytail on your own work, I'd like to hear how it compares.

sloth-standup: a local Gemma reads my 43 open PRs overnight, and found the review I'd missed for a week

Jay Pokale — Thu, 22 Oct 2026 07:22:01 +0000

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

What I Built

I have 43 open pull requests in 23 repositories, 14 of them in ClickHouse. Keeping up means opening each one,
scrolling past CI reports and bot summaries, and working out whether anything actually needs me. Most days nothing
does. Some days one thing does, and it's buried.

sloth-standup does that reading overnight, on my laptop, with Gemma 4 through Ollama, and leaves me a short
digest: what merged, what needs me (and why, with a link to the comment), and what can wait.

It's for the contributor side: not a team's incoming PRs, but your own PRs spread across other people's projects,
where the maintainers are busy and the only one tracking them is you.

In its first two days it found two things I had missed:

a review comment on a ClickHouse PR, unanswered since the week before. It was a real bug: with case-insensitive matching, a named struct nested inside an unnamed one silently lost its values. I fixed it the same morning.
a PR of mine in Interledger's rhyza that had become conflicting the moment its sibling PR was merged.

Demo

The screenshot above is a real digest from 2026-10-22 (my PRs, unedited). It runs as a systemd user timer at 07:00,
or when the laptop wakes up if it was asleep, and pops a desktop notification with the PRs that need you.

ollama pull gemma4:e2b
python3 -m standup --hours 24 --notify

Code

JayPokale / sloth-standup

A local Gemma reads your open pull requests overnight and leaves a morning digest of the few that need you

sloth-standup 🦥

Reads every open pull request you have, overnight, with a local open-weight model, and leaves you a short morning digest of the few that actually need you.

If you contribute to several projects, a morning starts with opening dozens of PR tabs: CI reports, bot comments review threads. Most say nothing that needs you. sloth-standup reads them so you don't have to, and is built to be honest about what it can't tell: a failing check nobody has explained is listed as exactly that, not guessed at.

# Morning standup for @JayPokale
## 🎉 Merged (3)
## 🦥 Needs you (1)
- interledger/rhyza#355: Look at the failing checks (Check if admin changelog is up to date).
## 🧵 Still unanswered (0)
## 👀 FYI (2)
## 🔴 Checks failing, nobody said why (1)
## 🔒 Deploy preview not authorized (1)
## 💤 Quiet (36)

Run it

Needs…

View on GitHub

Python standard library only, plus the gh CLI and Ollama.

How I Built It

The model reads; the code decides

My first version asked Gemma one question per PR: "does this need the author?" It scored 8 of 11 on hand-labelled
PRs, and its mistakes had a pattern. When a PR had a failing check and a comment about something
else, the model forgot the failing check. And it ignored my own earlier comment explaining that a failure was a known
flaky test.

So I took away everything GitHub already knows. The code decides:

a merge conflict needs you; so does "changes requested", until the reviewer speaks again;
a review thread whose last word isn't yours needs you, however old it is (that's how the week-old comment surfaced: a "what's new since yesterday" digest would never have shown it);
a comment can only explain a failing check if it was written after the latest commit;
a failing check with no comment to read is listed as "nobody said why", never guessed at;
rollup checks (Mergeable Check), fork deploy previews and PRs untouched for six months are not news.

I'm not the first to land on this split: PR Focus
describes the same choice of a hybrid score over pure AI sorting for PR triage.

Gemma answers only two narrow questions, with a JSON schema and temperature 0: does a person or a review bot ask
the author for something they haven't answered yet? and has anyone explained the failing checks? Every name, link
and number in the digest comes from GitHub's data, not from the model.

Two small things mattered more than I expected. CI comments are full of links that are kilobytes of base64, and
stripping link targets halved the model time and fixed misreadings. And the network is not always awake at 7 a.m.,
so every GitHub call retries, and a PR that can't be read is listed as "couldn't read", not silently dropped.

Measuring it honestly

eval/ holds saved snapshots of real PR activity with hand labels, and eval/run.py scores any model against them,
including none: the rules alone.

41 hand-labelled PRs	correct	needs you: caught	false alarms	model time
rules only, no model	34/41	16/17	6/24	0 s
Gemma 4 E2B	40/41	16/17	0/24	357 s
Gemma 4 E4B	38/41	16/17	2/24	473 s

(18 of my PRs, 9 of an AI agent account and 14 of a maintainer; laptop GTX 1660 Ti.)

The caveats, because they matter:

I tuned the rules and the prompt on 27 of these 41 PRs, so those numbers flatter the tool. The first time I tried it on someone else's PRs (an AI agent account that contributes to ClickHouse) it scored 1 of 9: it treated an aggregate check as a real failure, and an explanation written for an older commit as current. Both became rules.
Then I labelled a fresh set, a ClickHouse maintainer's 14 most recently updated PRs, before running anything on it, and ran it once: the rules alone got 14/14 and Gemma 13/14. Most of those PRs are decided by the open-thread rule, so that set tests the rules more than the model.
What the model adds is reading explanations: every false alarm of the rules-only run is a failure someone had already explained in a comment. Its one held-out miss is the opposite mistake: it read an unrelated comment as an explanation.
The 2B-effective Gemma 4 E2B beat the 4B E4B here, and took half the time, so it's the default.

Why Does Open Innovation Matter?

It reads code review, which isn't mine to send anywhere. The comments on my PRs are other people's words on other people's projects. Running the model locally means none of that leaves my laptop.
Re-running is free, so I could measure instead of guess. Every rule above came from running the model on the same snapshots again and again, and comparing against the rules-only baseline. On a paid API I'd have stopped at "looks good on today's digest".
It has to be boring to run. A morning job that costs nothing and needs no key just keeps running. I set it up once.
Where closed would win: a frontier model would likely not need half of my rules. But the rules make the digest predictable, and with them a small open model is enough.

The Lazy Payoff

On the morning of 2026-10-22 it covered 43 open PRs and the 30 hours since the previous check: 3 merged, 3 new
comments, red checks on 6 PRs. Its answer: 2 need me, 5 are FYI with a one-line reason each, 1 is a deploy preview
waiting for a maintainer, 34 have nothing new. Two tabs instead of 43.

The bigger payoff was the first two days: the week-old unanswered review and the PR that had turned conflicting.
Checking tabs by hand had missed both.

It also changes what "done" means for a red check: once someone writes down why it failed (on the PR, after the
latest commit), the digest stops flagging it, so the explanation helps the maintainer and my next morning alike.

Prize Categories

Best Use of Gemma: Gemma 4 (E2B by default, E4B tested) runs locally through Ollama, with JSON-schema output, and is evaluated against hand labels and a rules-only baseline.

Built with heavy help from Claude Code (an AI coding agent): it wrote most of the code, labelled the evaluation
PRs by the rule written at the top of eval/labels.json, ran the evaluations, and drafted this post.

Dare2Solve Studio: fresh math puzzles a tutor can trust, written by a model on their own laptop

Jay Pokale — Sun, 18 Oct 2026 05:24:47 +0000

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

What I Built

Every tutor in India who runs a small coaching class has the same weekly chore: find ten new questions for Saturday's
test. Textbook questions are already solved on YouTube. Question banks cost money and still repeat. Asking a chatbot
gives you fresh questions, but you then have to solve each one yourself, because a wrong answer key in front of a
class costs you more than the time you saved.

Dare2Solve Studio writes fresh math puzzles and refuses to hand over any puzzle whose answer it couldn't confirm.
A tutor picks a topic (probability, remainders, time and distance...), an audience (classes 8–10, JEE, olympiad,
placement aptitude) and a difficulty, and gets:

puzzles that passed two independent checks, stored in a searchable bank that rejects near-duplicates,
a printable worksheet PDF with a name/score header and an answer key with worked solutions,
a square "puzzle of the day" card to post in the class WhatsApp group.

Who pays: a tutor or a small coaching centre making weekly tests, at about the price of a pizza a month
(₹299/month in my head). That only works because the model costs nothing to run (more on that below).

Demo

Code

JayPokale / dare2solve-studio

Fresh math puzzles a tutor can trust: a local Gemma model writes them, code and a blind re-solve check every answer, Tiger Cloud keeps a deduplicated bank

Dare2Solve Studio

Fresh math puzzles for tutors and coaching classes, with every answer checked by running code It runs an open-weight model (Gemma 4 E4B through Ollama) on your own computer.

Demo (2 minutes): https://youtu.be/MVTBaImAQBc

A tutor picks a topic, an audience (classes 8–10, JEE, olympiad, placement aptitude) and a difficulty. The studio writes new puzzles, rejects every one whose answer it can't confirm, and keeps the rest in a searchable bank. From the bank it prints a worksheet PDF with an answer key, or a square "puzzle of the day" card for WhatsApp or Instagram.

How a puzzle is checked

The model writes five things for each puzzle: the problem, its working notes, a Python solve() function that computes the answer independently (by brute force where possible), a worked solution, and the answer. The notes get their own field because a small model otherwise thinks inside the code: dozens…

View on GitHub

How I Built It

A model that's wrong a lot, wrapped in checks that aren't

The model is Gemma 4 E4B, running in Ollama on my laptop's 6 GB GTX 1660 Ti. A small model (about
4 billion effective parameters) writes fluent, well-set puzzles, and gets the arithmetic wrong surprisingly often. So the design assumes every
answer is wrong until proven otherwise. For every puzzle the model returns JSON (enforced with Ollama's JSON-schema
format) with the problem, the answer, a worked solution and a Python solve() function, and then:

The code check. solve() must compute the answer on its own, by brute force when possible, and must agree with the stated answer. It runs in a sandbox: an AST whitelist of imports, no dunder attributes, no open/exec/eval, an empty environment, and RLIMIT caps on CPU, memory, file size and file handles.
The blind re-solve. The model then sees only the problem text and must first say whether it's well posed, then solve it again with fresh code. (Its notes go in a separate reasoning field; see below for why.) This catches the failure the code check can't: a puzzle that is internally consistent with its own code but contradictory or missing a fact.
A real solution. At least three numbered steps, or it's rejected.

When the model's own arithmetic slips but its program runs, and the blind re-solve agrees with the program, two
independent derivations agree, so the puzzle is kept: the answer is corrected and the solution rewritten for it.

What the checks caught

I ran the pipeline on eight topics, one puzzle each, up to three attempts per puzzle, with Gemma 4 E4B:
8 of 8 topics produced a puzzle that passed every check, and 5 of 13 attempts were discarded on the way
(about 30 minutes on the laptop). The discards are the point. In this run they were:

two puzzles where the blind re-solve reached a different answer than the original,
one the blind solver called ill-posed,
one whose code disagreed with its own stated answer, and
one whose worked solution had only one step.

Earlier runs also caught solver code that didn't compile and a ₹ sign inside the Python code (the prompt asks
for Indian context with money in ₹; it now asks for ASCII-only code).

Then I checked the checker: I solved all eight puzzles by hand (and brute-forced them). Seven were correct. One
had no solution at all: both the original program and the blind one returned None, and None == None, so the
pipeline counted it as two derivations agreeing. That's fixed: a solve() that returns anything other than a number
now fails. One of the seven also gives its own answer away (it asks for a digit sum it already stated), which no
check catches yet; a tutor would skip that one.

My own bugs were caught too. An output limit of 1,500 tokens silently truncated the JSON in a whole evaluation
round; I threw that round's data away instead of reporting it. And in the round before this one, only 2 of 8 topics
verified. Reading the raw replies showed why: the model was thinking inside solve_code, writing forty lines of
comments ("Wait, let's re-read the problem…") and stopping before the function had a body. The checks rejected it
as a syntax error, correctly, but it wasn't a wrong answer, just nowhere to think. Giving the JSON a separate
reasoning field ahead of the code, and asking for code "not notes", fixed it: the four problems that had failed
this way all produced running code on the next try, and the numbers above are from the rerun with that fix.

A bank that doesn't repeat itself (Tiger Data)

Verified puzzles go into a Tiger Cloud hypertable with a 384-dimensional embedding of the problem text
(bge-small-en-v1.5 via fastembed, also local) and an HNSW index. Before a puzzle is stored, the bank looks up its
nearest neighbour; above 0.92 cosine similarity it's rejected as the same question in different words. The same
index powers "search by meaning", so a tutor can type "probability with coloured balls" and find matching puzzles
regardless of wording. Time-partitioning by creation date keeps "what did I make this month" cheap as the bank grows.

Being kind to a laptop

My laptop froze twice while I was building this, under GPU heat and memory pressure. So the evaluation waits
whenever the GPU is above 78 °C, pauses between puzzles, and the web app runs one generation at a time on one
worker thread. Slow, but a tutor makes a worksheet once a week.

Why Does Open Innovation Matter?

The business only works at zero marginal cost. Each puzzle takes several model calls (write and re-solve, sometimes a code retry or a rewrite, up to three attempts). On a paid API that's a cost per puzzle that a ₹299/month price can't carry for a tutor making 50 puzzles a week. On an open-weight model on hardware the tutor already owns, it costs electricity.
Checks matter more than model size. Because I could run the model as many times as I liked, I could afford to distrust it: generate, verify with code, re-solve blind, retry. The open model plus cheap verification beats a bigger model I'd have to trust.
It works offline and stays private. A tutor's question bank is their product. It never leaves their machine, apart from the optional cloud bank they own.

Prize Categories

Best Use of Gemma: Gemma 4 E4B writes, solves and re-solves every puzzle, with schema-constrained JSON output.
Best Use of Tiger Data: the puzzle bank is a Tiger Cloud hypertable with pgvector HNSW search and near-duplicate rejection.

My speech-flaw detector flagged 41 false alarms a minute. One line of math fixed it.

Jay Pokale — Tue, 06 Oct 2026 20:04:50 +0000

I built Podium, a tool that compares your reading of a speech with a great delivery of the same text (JFK, Reagan) and tells you exactly where you drift and why: "14.3 syllables/s here vs 7.7 in the reference (+85%)", pinned to a time range.

The first version worked beautifully on my test set. Then I gave it a different speaker, and it flagged 41 "flaws" per minute on a perfectly clean recording.

This post covers why that happened, the one-line fix, and the evaluation set-up that caught it.

Step 1: put both recordings on the same word grid

Comparing two deliveries frame by frame is hopeless: they never line up. Comparing them word by word is easy, as long as both are force-aligned to the same transcript. I used torchaudio's MMS_FA (a wav2vec2 CTC aligner):

bundle = torchaudio.pipelines.MMS_FA
model, tokenizer, aligner = bundle.get_model(with_star=False), bundle.get_tokenizer(), bundle.get_aligner()
emission, _ = model(wav)
spans = aligner(emission[0], tokenizer(words))   # one span list per word

Now word 17 of your reading is word 17 of JFK's. For every word I compute speaker-normalised features with Praat (via Parselmouth) and librosa:

pitch in semitones relative to your own median (a deep and a high voice with the same intonation give the same curve);
loudness in dB relative to your own level;
articulation rate, syllables per second of actual speech, pauses excluded, over a 5-word window;
the pause before the word, and voiced sound inside that pause (more on that below);
high-frequency energy above 2.5 kHz, which drops when consonants get swallowed.

Step 2: build a dataset where the answers are exact

There's no public dataset that pairs a good delivery with bad deliveries of the same words. So I made one: 207 recordings, starting from three public-domain speeches.

The trick is that I inject the flaws myself, so every label is sample-accurate:

Flaw	How it's injected	Severity 1 / 2 / 3
rushed / dragged	phase-vocoder time-scale of 4–9 words	×1.3/1.6/2.0 · ×0.8/0.65/0.5
monotone	WORLD vocoder, pitch contour squashed toward its mean	50/75/95% removed
mumbled	gain down + low-pass	−6 dB @ 3 kHz … −16 dB @ 1.1 kHz
awkward pause	room-tone silence inserted mid-phrase	0.7 / 1.3 / 2.2 s
missing breath	a natural pause squeezed out	50 / 20 / 0% kept
stutter	word onset repeated	1 / 2 / 3 repeats

Edits are joined with 5 ms fades that preserve length, so the label times never drift. My first version used 15 ms crossfades, which quietly shifted every later label by 15 ms per edit.

I also had the same texts read by open Piper TTS voices, with flaws injected into those too. That's the "different speaker" test.

And I split it honestly: thresholds are tuned only on JFK, then frozen and tested on Reagan plus an unseen voice.

Step 3: the bug that wasn't a bug

Version 1 scored each word by how far it departed from the reference, as a robust z-score (median/MAD) after removing your overall offset. On Reagan's own audio with injected flaws it got F1 0.64 with zero false alarms.

On a TTS voice reading the same text:

	F1	False alarms on clean audio
Same speaker	0.64	0 / min
Different speaker	0.03	41 / min

A synthetic voice doesn't breathe where Reagan breathes or lift the words he lifts. Measured against Reagan, everything it does is a deviation. Technically correct, but useless as feedback: nobody wants to hear that every sentence is wrong because they aren't Reagan.

The fix was to separate style from flaws. A flaw is something that's off compared with the reference and off compared with your own delivery. So every word gets two scores:

z_ref  = robust_z(participant - reference)   # departs from the reference, beyond your overall style
z_self = robust_z(participant_feature)       # stands out within your own recording
flaw   = np.fmin(z_ref, z_self)              # a soft AND

A consistently different voice moves z_ref everywhere but z_self almost nowhere, so it's reported once as style ("33% faster and flatter than the reference") instead of 40 times as flaws.

False alarms on clean different-speaker recordings went from 41/min to 3/min.

Step 4: a stutter that looked like a pause

Injected stutters kept being reported as "awkward pause". The cause: the aligner usually places the word at its last restart, so "w- w- we" becomes a long gap followed by a normal "we".

The fix was one feature: seconds of voiced audio inside the gap. A real pause is silent; a gap full of voiced sound is a restart.

gap_voiced = np.sum(~np.isnan(f0[prev_end:word_start])) * HOP

Long pauses now require gap_voiced < 0.15 s, and stutters can trigger on gap_voiced > 0.12 s. Stutter recall went from 0.11 to 0.44 on the held-out set.

Results on the held-out set (Reagan + an unseen voice)

detected regions overlap the true flaw with mean IoU 0.81; overall F1 0.51;
awkward pauses, missing breaths, mumbling and stutters are located within 0.00–0.06 s;
0 false alarms per minute on untouched audio of the reference speaker;
the rubric score falls monotonically from L0 to L4 on every excerpt (Spearman ρ = −1.00).

What doesn't work yet:

Pacing is weakest (F1 0.29–0.35). Slowing a phrase also stretches its pauses, so "dragged" is often reported as "awkward pause"; the confusion matrix shows exactly that.
Different speakers are still hard (F1 0.21). Fixed noise floors are the next thing to replace with learned ones.

Three things I'd tell anyone building an evaluator

Make your labels exact before tuning anything. Injecting the flaws yourself turns an argument about subjective judgement into a number.
Hold out a speaker, not just files. My calibration F1 (0.62) and held-out F1 (0.51) are close because the split was honest. Same-speaker numbers alone would have hidden the 41-per-minute problem.
Decide what shouldn't count before deciding what should. The hardest part wasn't detecting deviations, it was deciding which deviations matter.

Code, dataset (207 labelled recordings) and the full evaluation are open source:

JayPokale / podium

Contrastive speech delivery analytics: find exactly where a delivery drifts from a great speech, and why. Multimodal AI Hackathon 2026, Track C.

🎙️ Podium: contrastive speech delivery analytics with temporal flaw grounding

Read a great speech. Podium shows exactly where your delivery drifts from it, to the tenth of a second and explains each flaw with the numbers behind it.

Built for the Multimodal AI Hackathon 2026, Track C: Contrastive Speech Analytics & Temporal Flaw Grounding.

What it does

Pick a reference: an excerpt of a great public-domain speech (JFK, Reagan).
Give your delivery: record yourself reading the same text in the browser, upload a file, or try one of the 207 dataset samples.
Get grounded feedback
- a deterministic 0-10 rubric for pacing, pauses, pitch, volume and fluency;
- flaw regions with exact start/end times, shaded on time-series overlays of your pitch, loudness and pace against the reference (time-warped onto your timeline word by word);
- a causal explanation for every region, built from the measured delta ("14.3 syllables/s here…

View on GitHub

Built for the Multimodal AI Hackathon 2026 (Track C), with heavy help from Claude Code, an AI coding agent, for implementation and evaluation runs.

Outside Quest: I asked a local Gemma to name birds. It couldn't, so it sends you on a scavenger hunt instead

Jay Pokale — Tue, 06 Oct 2026 06:05:08 +0000

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

What I Built

Outside Quest is a photo scavenger hunt that runs on Google's open-weight Gemma 4, entirely on a laptop with Ollama. It's designed so the screen is the shortest part of the experience:

Before the walk (about 2 minutes): type where you're going. Gemma writes a six-item quest card that fits the real place and season. Print it, or glance at it once. Then a full-screen "Phone away 🌳" card takes over.
On the walk (an hour): the phone stays in your pocket. You only take it out to photograph a find.
Back home (a few minutes): drop in your photos. Gemma checks which quests each photo completes and says what it saw. You get points, badges and a walk journal: a timeline from the photos' timestamps and a small route map drawn from their GPS tags, with no map tiles and no internet.

It's for anyone who says "I should go outside more" and then doesn't: families with kids, friends who need an excuse for a walk, or me after a day of staring at code.

The quest card adapts to where you are. For Ambazari lake garden, Nagpur, India in October it asked for "a seed pod or fruit on the ground" and "moss or damp earth" (post-monsoon tropical). For Central Park, New York it asked for "crimson leaf under a sturdy oak" and "a squirrel busy gathering nuts". That only happened after I told the prompt to think about the real local climate; the first version cheerfully asked Nagpur for "autumn colour change".

Demo

The results above use six Wikimedia Commons photos (credited in the repo) with made-up timestamps and GPS points, so I could test the journal and map.

Code

JayPokale / outside-quest

Two minutes on a screen, an hour outside: an offline photo scavenger hunt powered by Gemma 4 + Ollama. Hacktoberfest 2026 Touch Grass.

Outside Quest 🌿

Two minutes on a screen, an hour outside. An offline photo scavenger hunt powered by Google's open-weight Gemma 4, running on your own computer with Ollama.

Before you go: tell it where you're walking. Gemma writes a 6-item quest card that fits the real local season ("a seed pod on the ground" in tropical Nagpur in October, "crimson leaves under an oak" in New York) Print it or glance at it once.
On the walk: phone in your pocket. You only take it out to snap a photo of each find.
Back home: drop in your photos. Gemma checks which quests each photo completes, with the visible evidence and builds a walk journal: a timeline from the photos' timestamps and a little route map from their GPS tags.

No account, no upload, no internet needed. Your photos (and their location data) never leave the computer.

…

View on GitHub

Try it

ollama pull gemma4:e2b
git clone https://github.com/JayPokale/outside-quest && cd outside-quest
pip install -r requirements.txt && python3 server.py   # http://127.0.0.1:8777
# optional, for durable checking:
temporal server start-dev --db-filename ~/.outside-quest/temporal.db

No account, no API key. There's also a Quick card button that works with no model at all.

How I Built It

Stack: gemma4:e2b through Ollama on a 6 GB GTX 1660 Ti laptop GPU · a Python standard-library server plus Pillow (for EXIF) · an optional local Temporal server for durable checking · one HTML file, no framework. A quest card takes ~30 seconds, checking a photo ~30 seconds.

Plan A failed, and that's the most useful thing I learned

My first idea was the obvious one: a bird and plant identifier that works on the trail with no signal. Before building the UI, I tested the model on six photos: a Common Myna, a neem tree, a Monarch butterfly, a fly agaric mushroom, a peacock and a storm cloud.

Photo	gemma4:e2b said	gemma4:e4b said
Common Myna	"Jackdaw", confidence high	"Weaver Bird", confidence high
Monarch butterfly	"butterfly, undetermined"	"Heliconius"
Neem leaves	"deciduous trees, undetermined"	"trees / forest canopy"
Peacock	Peacock ✓	Peacock ✓

Asking for a top-3 list didn't rescue it: the Myna never appeared. Gemma 3 4B did worse and broke its JSON. A tool that names the wrong bird with high confidence is worse than no tool, especially outdoors, where people make decisions about mushrooms and berries.

But in every run, the coarse answer was right: there's a bird, a butterfly on a flower, red-capped mushrooms, a storm cloud, a canopy of leaves. So I flipped the design: the model only answers the question small open models are good at, "does this photo show a bird?", and the naming is left to you and a field guide. A scavenger hunt turned out to be a better way to get people outside anyway.

Making the judge strict

The first judge was too generous: it gave "a leaf" points for the butterfly photo because there were leaves in the background. Word-matching heuristics made it worse (it then rejected the peacock for "a bird"). What worked was asking Gemma, through a JSON schema, two explicit yes/no questions for every quest on every photo:

{ "id": "q2", "evidence": "A butterfly (an insect) is clearly resting on the flower.",
  "is_main_subject": true, "completed": true }

A quest only counts if both are true. On a test card (a bird, an insect on a flower, a mushroom, a stormy cloud, leaves up close, something red) and the six test photos, that gave 5 correct matches and no false ones. The miss was the storm cloud, which it read as a seascape. It isn't perfect: in the run shown above it gave "a leaf bigger than your hand" to a canopy photo, where nobody can judge leaf size. But it errs strict far more often than generous, and for a game that's the right way round.

Safety lives in code, not in the prompt

Quests the model writes pass through plain-code filters before anyone sees them. Anything about climbing, entering water, touching, picking, eating, feeding or chasing animals, roads, railway tracks, private land or night walks is dropped and replaced from a safe built-in pool. Mushrooms, berries, nests and eggs always get "(photo only, don't touch)". If the model is down or returns junk, the card fills from the same pool, and there's an instant "Quick card" button that skips the model entirely.

Making the photo check durable with Temporal

Checking is the slow part: about 30 seconds per photo, so a 40-photo walk is 20 minutes of a laptop GPU working. The first version looped over photos in the browser. Close the tab, let the laptop sleep, or have Ollama run out of memory on photo 23, and the rest of the batch was simply gone.

So the Gemma judge now runs inside a Temporal workflow, on the open-source Temporal dev server on the same laptop. Each walk is a CheckWalk workflow and each photo is a check_one activity:

Photos are saved to disk first, so you can close the tab as soon as the upload finishes. Reopen the page later and it picks the walk back up.
If Ollama is down, out of memory, or returns broken JSON, the activity is retried with backoff (5 seconds up to 2 minutes, 30 attempts) instead of being skipped.
If the server dies, the workflow resumes from the next unchecked photo. Each answer is cached next to its photo, so nothing is checked twice.

To test it, I stopped Ollama in the middle of a six-photo walk and then killed the app server too. The red bar is the photo that kept failing while Ollama was down. Attempt 4 succeeded once it came back, and the walk finished with all six photos checked:

If Temporal isn't running, the app works exactly as before. Durable mode is an extra, not a requirement.

What a Reddit reader caught

After I shared Outside Quest on Reddit, a reader pointed out something I hadn't tested: WhatsApp strips EXIF data, and iPhone sharing can leave location out. So for many people the route map and timeline would just be empty, with no error. The journal now says so ("no location in 2 of 5 photos") and suggests copying the originals over USB or AirDrop. Fixing that also turned up a bug: the walk length mixed camera times with file dates, which made one test walk "3175 minutes" long. It now uses camera times only.

They also asked whether the card changes with the season. It does. Same place, Central Park, three months: October asked for "a fallen maple leaf", January for "ice crystals on a puddle", and April for "a daffodil or early tulip bloom".

Why Does Open Innovation Matter?

Your photos are a map of where you were. Walk photos carry GPS coordinates and timestamps. Sending them to a cloud API would hand someone a log of when and where you walk. Here the model and the photos stay on your laptop.
It works where the walk is. No API key, no signal needed, no per-photo cost, so a family can check a hundred photos after a holiday without a bill.
I could test it honestly and change course. Because the model runs locally and is free to call, I could benchmark e2b against e4b and Gemma 3 on the same photos in an evening, see exactly where it fails, and design around that instead of trusting a demo.
Where closed would win: a frontier cloud model would almost certainly name the Myna. For this app that's the wrong trade: I'd rather have a private, free, offline game that's honest about what it knows.

My Agent Session

Built with heavy help from Claude Code (an AI coding agent): it ran the model benchmarks above, wrote most of the code, and drove the UI in a browser to test it. The design decisions (dropping species ID, strict judging, code-level safety filters) came out of those test runs.

Prize Categories

Best Use of Gemma
Best Use of Temporal