DEV Community: Fahad Irshad

Sift: share it, sleep, it's filed — on-device Gemma, no cloud

Fahad Irshad — Thu, 22 Oct 2026 08:44:36 +0000

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

Share a thing. Put the phone down. It's filed by morning.

Sift is a junk drawer that files itself. You share a link, a gate code, a recipe to it — two taps, zero decisions — and it closes. Overnight, while the phone charges, Gemma 4 reads every snippet you kept and sorts it into one of eight drawers with a short title of its own. In the morning it's a card catalog.

The app holds no internet permission. Not "we don't upload your notes" — the operating system forbids it. The model file is the only thing you ever download, and you hand it over yourself.

What I Built

The share sheet is where good intentions go to die. You see a gate code, a gift idea, a link you'll read later. You tap Share. Then you stare at a list of apps and remember what keeping it actually costs: open a notes app, make a note, paste, title it, pick a folder, decide where it belongs. You put the phone down instead. The link is gone by dinner.

Sift is the answer to that pause. Share the thing to Sift and walk away. The keep is instant; the sorting is deferred to a time when you are doing nothing anyway. Nothing happens while you watch. That is the product.

Demo

One real run on an Android emulator: seven snippets pushed in through the same ACTION_SEND intent any app's share sheet fires, then one tap on FILE NOW because I was not going to wait until morning for a screenshot. Overnight is the same code path with a charging constraint — more on that below.

Left to right: the toast that closes the capture, the queue being sifted, and the catalog after the pass. The first two screens are from the same run; the third is the result.

Six minutes forty-nine seconds later, all seven were filed: one card per drawer, each with the model's title over the text I actually sent. The seventh — "Send me the file whenever you get a chance, no rush." — is the one snippet with no obvious drawer, and it is sitting in INBOX. That is the fail-safe doing its job, not a bug.

Try it yourself

Two downloads, once:

Sift v0.1.0 — signed arm64 APK (43 MB, Android 9+). Sideload it; there is no Play Store listing.
The model file — litert-community/gemma-4-E2B-it, gemma-4-E2B-it.litertlm, about 2.6 GB. It is gated under Google's Gemma terms, so accept the license in your browser and download it yourself.

On first launch Sift shows one setup prompt: Download the model opens that page in your browser, and I already have the file hands the file over through the system picker. The first read compiles the model and takes a few minutes; after that, filing starts fast. The same prompt asks once whether Sift may post a notification while it files overnight. Declining changes nothing — the notification is a receipt, not a requirement.

After that, keeping a note is Share → Sift from any app.

Code

github.com/Burry071/sift — Kotlin, Jetpack Compose, Room, WorkManager, LiteRT-LM. The signed APK is in the repo; build from source with ./gradlew :app:installDebug.

The calibration corpus (40 invented snippets, labeled), every spike script, the image-composition script, and the raw per-entry results of every run in this post are committed under corpus/, scripts/, and the repo root. Nothing here is a vibes-based number; each table row is a file you can replay. There is no personal data in the repo: every snippet in the corpus and in the demo is invented.

How I Built It

The shape

Three layers, deliberately fewer than my last project:

Keep (instant). Any share lands verbatim in a local Room database, queued UNFILED. No model runs while you're holding the phone.
File (later). A WorkManager job reads each queued snippet with Gemma. Three votes per category at temperature 0.4; majority wins. If the votes disagree, or the answer isn't one of the eight labels, the note goes to INBOX. Then a title, with a fallback to the snippet's first line if the model rambles. One database write per snippet, so an interrupted night resumes where it stopped.
Browse (morning). One screen, set like a card catalog: drawers with counts, cards with the model's title over your verbatim text. The text is evidence, not paraphrase.

Two ways to trigger filing: the overnight periodic job, constrained to charging + idle (exactly the state your phone is in at 2 a.m.), or FILE NOW, a one-time request through the same worker with no constraints. The demo uses FILE NOW. The product uses both.

Requires: charging=true batteryNotLow=false deviceIdle=true

That line is dumpsys jobscheduler on the emulator, not a diagram of what I meant to build.

The model

The shipping model is Gemma 4 E2B IT as a .litertlm file — 2,588,147,712 bytes, user-imported through the system file picker, run through LiteRT-LM 0.18.1. Android 9+, arm64, no INTERNET permission.

That sentence cost more than it looks. LiteRT-LM 0.18.1 shipped the week I built this; moving the app onto it dragged the Kotlin version to 2.4, which has no KSP release yet, which meant moving Room from KSP to kapt, which then needed a matching metadata reader on the annotation-processor classpath because Room's processor tops out at Kotlin metadata 2.3. None of that is interesting in the finished app. All of it was two evenings.

The part that mattered: the runtime was lying

I calibrated the taxonomy on a corpus I wrote myself — 40 snippets, all invented, no personal data: 32 that clearly belong in one drawer, 8 written to be genuinely ambiguous. It is a calibration set, not a sample of the world. It tests the taxonomy, not my imagination's coverage of it.

The gate I set before running anything: ≥27 of 32 clear snippets exactly right, and ≥6 of 8 ambiguous ones at least acceptable. Every run below is a committed result file with the raw votes.

Run	Call path	Clear exact	Ambiguous ok	Malformed votes	Titles	Speed
v1, Gemma 3 1B	chat, zero-shot	14/32	1/8	25/120	39/40	5.6 s/entry
v2, Gemma 3 1B	chat, few-shot turns	0/32	0/8	118/120	39/40	8.5 s/entry
v3, Gemma 3 1B	+ closed labels + answer line	19/32	6/8	0/120	39/40	11.2 s/entry
v4, Gemma 3 1B	raw generate, grouped examples	21/32	5/8	0/120	38/40	10.5 s/entry
v4b, Gemma 3 4B	same prompt, bigger model	29/32	5/8	0/120	40/40	22 s/entry
v5, Gemma 4 E2B	conversation API	30/32	7/8	0/120	40/40	23.6 s/entry

The 4B speed is a median: one entry in that run took 15.9 hours because the laptop slept in the middle of it. Everything else is a mean over the run.

The v1–v3 1B runs are the usual small-model story: without a closed label list it invents categories ("LOCATION", "BUILD", "NETWORK"), and voting cannot save a model that is confidently wrong. The 4B cleared the clear-snippet gate easily (29/32) but missed the ambiguous gate by one (5/8 needed 6), and was only available as an Ollama tag — no .litertlm file, so it could never ship inside the app. The 4B row is the control, not the product.

Then Gemma 4 E2B arrived as a shippable file and the calibration fell apart in a way that made no sense. The same prompt that worked elsewhere produced empty strings, echoes of the note, and — once — a fabricated continuation of the prompt: Note: "How to fix a leaky faucet". About one generation in six came back malformed. A model that could not answer one word, again and again.

The bug was not in the prompt. It was in the call path. The low-level session API (run_prefill / run_decode) continues raw text. On Gemma 4 it degenerates: the model was never shown its chat template, so "answer with one label" read as an invitation to continue the document. A fresh conversation per call — the API that applies the chat template — returns a clean one-word answer every time. Same weights, same prompt, same corpus: zero malformed votes across the run, 30/32 clear, 7/8 ambiguous, 40/40 titles. A GO against the gate.

The shipping app now opens a fresh conversation for every generation, seeds every vote differently, and closes the conversation after each call.

The remaining misses are worth showing, not hiding. All three are unanimous wrong votes: "Anniversary plan: rooftop dinner" filed as EVENT instead of IDEA, "Tomorrow: submit the form, call the plumber, pick up the dry cleaning" as EVENT instead of LIST, and "The cafe wifi is down, use the one next door instead" as CODE instead of INBOX. Voting catches disagreement, not confident mistakes. INBOX is a fail-safe for uncertainty, not a guarantee that every drawer is right — which is why the text stays verbatim on every card and the drawers aren't hidden behind anything.

That is the "slow and steady" part of this week for me. The lazy product is built on a runtime detail that took a day of controlled comparisons to isolate.

Why Does Open Innovation Matter?

Sift only works because the model is open-weight and local:

Zero marginal cost is what makes a junk drawer viable. Nobody pays a subscription to file a gate code. If every snippet cost an API call, the honest business model for this app would be "don't build it". Local inference makes the cost of a filing run zero, forever.
Privacy is structural, not a promise. The app holds no INTERNET permission. It is physically incapable of sending your notes anywhere. You bring the model file yourself; the app never downloads anything.
The model is a file, not a vendor. Swapping to a better open-weight model is a file swap and a version bump, not a renegotiated contract. I moved from Gemma 3 1B to Gemma 4 E2B during this challenge and nobody's pricing page was involved.
A small model is enough because the problem is small. The entire job is: read one note, pick one of eight labels, write five words. You don't need a frontier model for that. You need a model that runs on the phone you already own.

My Agent Session

The session below is the actual working log from building Sift: the calibration runs, the runtime that lied, the emulator fight, the release build. It was captured in Qoder, which isn't one of DevRelay's session types — that list is fixed — so it is filed under Claude Code, the closest entry. The log is trimmed: private reasoning blocks and routine file reads are gone, but nothing in it is reconstructed.

Sift — share anything, file it overnight (DEV x Hacktoberfest Week 3)

You

Challenge Prompt
Slow and Steady
Build something with open-source AI at its core.

That can mean running an open-weight model, building on an open-source agent harness or framework, running inference locally, or all three. Whatever you pick, the open pieces should be what makes your project work.

In your post, tell us why open innovation matters for what you built. Does it run on a laptop with no internet? Keep someone's data off a server they don't control? Let you fine-tune, swap models, or change how your agent behaves? Cost nothing to run? Tell us where your open-based approach worked better than a closed one.

This Week's Theme: Slow and Steady
Build something with open-weight models or open-source AI that rewards laziness.

Tomorrow, October 20, is International Sloth Day, and we think sloths have it figured out. They move at their own pace, conserve their energy, and even help moderate our website. This week, we want you to channel your inner sloth and build something that does the work so you don't have to.

Your build could help someone relax, automate a task they dread, or just make life a little easier. A few ideas to get you going:

A local agent that reads your group chats overnight and hands you a two-line summary in the morning

A wind-down companion that generates a calming bedtime story or ambient soundscape, running entirely offline

A fridge photo to grocery list tool, so you never have to stand there with the door open again

A file and inbox tidier that automatically sorts, renames, and archives the clutter you keep putting off

In your post, tell us why open innovation matters for what you built. Does running your own model mean your automation works without an internet connection? Keep your personal messages and files on your own machine? Let you set it up once and never pay for it again? Tell us where your open-based approach worked better than a closed one.

Submission Template
Show your work. We'd love to see how you built it. Save your agent session with DevRelay and embed it in your post, or link to it. It's optional, but it helps the judges understand your process.

Agent

The Week 2 entry is shipped; starting on the new "Slow and Steady" challenge now — first step is pulling its exact details (id, deadline, submission template) from the DevRelay gateway.

Agent

Week 3 details confirmed — id 81, theme "Slow and Steady," runs Oct 19–25, submissions due Sat Oct 25, 11:59 PM PDT (~5.5 days from now). Key facts: must be a brand-new project, Writing Quality weighted most, bonus points for showing the lazy payoff (time/effort saved), and "Best Use of Gemma" is a $200 featured category again. Before pitching a concept, running the saturation sweep on the laziness-automation id…

Agent

Calibration done. Here's the field snapshot and my one recommendation, the way we did Week 2 — concept first, kill-case included, nothing gets built until you say go.

Week 3: "Slow and Steady" (deadline Sat Oct 25, 11:59 PM PDT — 5.5 days)

Rules that matter: brand-new project (Gazette can't be recycled), writing quality judged most heavily, bonus points for showing the lazy payoff — how much time/effor…

You

check winners

Agent

Found the pattern — Week 1 winners were announced in a "Congrats to the … Winners!" post, and each week's join post gets updated with the winners banner. Week 2's is due this week; checking whether it's out.

Agent

No winners post for Week 2 yet — the join post hasn't been updated with the winners banner. Let me confirm by checking the DEV team's latest posts and looking at how long Week 1 took to announce.

Agent

Week 2 winners aren't out yet — the DEV team's newest posts are the Week 3 announcement and the Week 1 winners. Let me read the Week 1 winners post for the announcement timing pattern and what judges actually picked.

Agent

Recording the status in project memory, then giving you the answer.

You

[Request interrupted by user]

You

retry

Agent

Winners check is done — here's the answer (the memory note also saved fine).

Week 2 winners: not announced yet

Week 2 closed Oct 18. The DEV team's schedule says winners come "week of October 19," and their feed as of today (Oct 21) has only the Week 3 announcement and the Week 1 winners post — no "Congrats… Side Hustle Winners!" post yet.
Week 1's pattern: that week closed Oct 11, winners post landed ~…

You

are you sure its good ?

Agent

Honest answer: not as I pitched it. You're right to push. I re-checked my own pitch against what we learned from the Week 1 winners, and there are three real problems — plus one fix that turns them around.

What's wrong with Sift as I pitched it

It's less original than I claimed. The organizers' example #4 is "a file and inbox tidier that quietly sorts, renames, and archives." I said Sift isn't one of the…

You

start building Sift with the overnight upgrade

Agent

Sift is a go — building now. Same order as Gazette: spike first, because the whole project hangs on one question — can the 1B reliably pick a category from a fixed list? Pre-registering the gate before I run anything: GO = ≥85% exact category on 32 clear snippets, ≥6/8 on ambiguous ones, with 3-vote majority; fail-safe is INBOX when votes disagree.

Setting up the new repo and task list, then the spike.

Agent

Ollama is up with both models cached. Creating the new repo folder and writing the spike corpus + test script.

Agent

Corpus written: 40 invented snippets — 32 clear (4 per category × 8 categories) + 8 deliberately ambiguous. Running the spike now in the background (~160 model calls, a few minutes on CPU).

Agent

▸ Bash cd "~/Documents/Qoder/2026-10-13/sift" && node scripts/sift_test.js gemma3:1b 3

Input

$ cd "~/Documents/Qoder/2026-10-13/sift" && node scripts/sift_test.js gemma3:1b 3

Output

Command running in background with ID: b1eshbvhg. Output is being written to: D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\9f361c3e-815e-49dc-956d-29ceeb9d3372\tasks\b1eshbvhg.output You will be notified when it completes. To check interim output, use Read on that file path.

Agent

While that runs, checking the first output lines to confirm the script didn't crash at startup.

Agent

First lines show the problem pattern — the titles are great ("Door Code: 4471 #", "Promo Code: SAVE40"), but several category votes come back malformed or wrong. Checking the raw vote text in the results file to diagnose.

Agent

Clear diagnosis, exactly the Week 2 pattern: the raw 1B ignores the label list zero-shot — it echoes salient words ("BELL", "WiFi"), parrots my prompt ("THE label"), and mis-files confidently (door code → CONTACT, promo code → LINK). The titles are already good, though — that half works zero-shot.

Applying the Week 2 fix: few-shot with one example per label, as proper chat turns. Writing v2 while v1 finishes (v1's…

Agent

While v1 finishes its baseline run, drafting the engineering spec (calibration table gets filled in from the archived runs once v2 lands).

Agent

v1's shape is clear — the 1B nails easy signal categories (CONTACT 4/4, LINK 4/4) and flubs everything else zero-shot, which is precisely the Gazette story. Waiting for it to finish, then straight into v2. Meanwhile, writing the visual DESIGN.md (card catalog, statement family — independent of calibration numbers).

Agent

v1 is nearly done and the pattern is stable. Committing the spike scaffolding locally (no push) while it finishes.

Agent

▸ Bash git -C "~/Documents/Qoder/2026-10-13/sift" add corpus/snippets_v1.jsonl scrip...

Input

$ git -C "~/Documents/Qoder/2026-10-13/sift" add corpus/snippets_v1.jsonl scripts/sift_test.js scripts/sift_test_v2.js DESIGN_SPEC.md DESIGN.md .gitignore && git -C "~/Documents/Qoder/2026-10-13/sift" commit -m "Sift spike scaffolding: corpus, v1+v2 test scripts, design spec, card-catalog DESIGN.md" && git -C "~/Documents/Qoder/2026-10-13/sift" log --oneline

Output

warning: in the working copy of '.gitignore', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'DESIGN.md', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'DESIGN_SPEC.md', LF will be replaced by CRLF the next time Gi…

Agent

Scaffolding committed locally. Spike v1 (zero-shot baseline) is on its last few entries — the moment it lands I'll launch v2 (few-shot) and start the Android scaffold while it runs. Status so far:

v1 zero-shot looks weak, as predicted — CONTACT and LINK near-perfect (URLs and phone numbers are easy signal), but CODE 0/4, IDEA 0/4 so far, with the model echoing words ("BELL", "WiFi") and parroting the prompt.…

You

[SYSTEM NOTIFICATION - NOT USER INPUT]
This is an automated background-task event, NOT a message from the user.
Do NOT interpret this as user acknowledgement, confirmation, or response to any pending question.

<task-notification>
<task-id>b1eshbvhg</task-id>
<tool-use-id>call_918145cbeec44f4eaf5c1b5b</tool-use-id>
<output-file>D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\9f361c3e-815e-49dc-956d-29ceeb9d3372\tasks\b1eshbvhg.output</output-file>
<status>completed</status>
<summary>Background command "Run Sift categorization spike against Gemma 3 1B" completed (exit code 0)</summary>
</task-notification>

Agent

v1 finished — reading its summary and launching v2 (few-shot) immediately.

Agent

v1 baseline captured: 15/32 exact on clear snippets, 25 of 120 raw outputs malformed, but titles 39/40 clean. Exactly the "small model needs help" story. Launching v2 (few-shot) now in the background.

Agent

▸ Bash cd "~/Documents/Qoder/2026-10-13/sift" && node scripts/sift_test_v2.js gemma3...

Input

$ cd "~/Documents/Qoder/2026-10-13/sift" && node scripts/sift_test_v2.js gemma3:1b 3

Output

Command running in background with ID: b705o9xv3. Output is being written to: D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\9f361c3e-815e-49dc-956d-29ceeb9d3372\tasks\b705o9xv3.output You will be notified when it completes. To check interim output, use Read on that file path.

Agent

While v2 runs (~4 min), scaffolding the Android project. Fastest reliable path: clone Gazette's proven build setup (same Gradle/AGP/Kotlin/KSP/LiteRT-LM pins, same Room schema pattern, same SAF import flow), then swap the domain pieces. Checking the structure.

Agent

Cloning Gazette's build scaffolding (wrapper, root scripts, fonts, licenses) into sift/, then writing Sift-specific sources.

Agent

The v2 results file is already being written (stream opens at startup — expected). Now reading Gazette's ModelRuntime and Theme to port them, since those are the two files I can reuse nearly verbatim.

Agent

All reference files read. Writing the Sift Gradle files and manifest now.

Agent

Now the manifest — zero-permission-first-launch like Gazette: no INTERNET, no runtime permission prompts; the FGS notification can be granted from Settings on API 33+ but filing works without it.

Agent

Now the Kotlin sources. First reading Gazette's Prompts.kt to keep the on-device chat-template format consistent with what worked.

Agent

Reading Gazette's MainActivity for the SAF-import pattern to mirror, then writing all Sift Kotlin sources.

Agent

Writing all Sift Kotlin sources now — pipeline, data, engine, service, UI, app entry (9 files).

Agent

v2 finished — reading the results (this is the GO/NO-GO moment).

Agent

v2 catastrophically regressed — 0/32, with 118/120 malformed outputs. Something about the few-shot prompt is making the model produce non-labels. Reading raw votes to diagnose.

Agent

Found it — my v2 mistake. I removed the explicit closed label list from the system prompt and left it only in the examples, so the model generalized "map note → a label" and invented its own ("LOCATION", "BUILD", "ROUTE", "NETWORK"). One vote on entry 1 even says ADDRESS — it knows the right drawer but doesn't know the set is closed.

This is exactly the Gazette lesson I failed to apply: its winning prompt ends with…

Agent

▸ Bash cd "~/Documents/Qoder/2026-10-13/sift" && node scripts/sift_test_v3.js gemma3...

Input

$ cd "~/Documents/Qoder/2026-10-13/sift" && node scripts/sift_test_v3.js gemma3:1b 3

Output

Command running in background with ID: b2v27ygdz. Output is being written to: D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\9f361c3e-815e-49dc-956d-29ceeb9d3372\tasks\b2v27ygdz.output You will be notified when it completes. To check interim output, use Read on that file path.

Agent

v3 running (~6 min). Meanwhile fixing a typo I spotted in the test file (majorize → majority) and updating the Kotlin Prompts to match v3 — whatever the spike validates must be what ships.

Agent

Cleaning two leftovers (unused constant in FilingWorker, shadowed helper in the test), then running the first Gradle build while the spike runs.

Agent

▸ Bash cp "~/Documents/Qoder/2026-10-13/ec4b45db/local.properties" "~/Documents/Qode...

Input

$ cp "~/Documents/Qoder/2026-10-13/ec4b45db/local.properties" "~/Documents/Qoder/2026-10-13/sift/local.properties" && cd "~/Documents/Qoder/2026-10-13/sift" && ./gradlew assembleDebug testDebugUnitTest --console=plain -q 2>&1 | tail -n 30

Output

Command running in background with ID: b08l55fl0. Output is being written to: D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\9f361c3e-815e-49dc-956d-29ceeb9d3372\tasks\b08l55fl0.output You will be notified when it completes. To check interim output, use Read on that file path.

Agent

Build and spike both running in the background. Writing the README meanwhile — the install story is known (same model-import flow as Gazette).

Agent

v3 is misfiring too — the model now stays in the label set but picks wrong drawers (address → LIST, wifi → ADDRESS), and calls got slower. Before iterating again, going back to the source: reading Gazette's actual winning spike script to mirror its exact message format — the one that achieved 0 classifier disagreements.

Agent

Key discovery: Gazette's winning spike used /api/generate — one raw prompt blob as a single user turn, no system message, no alternating few-shot turns. All three of my Sift variants used /api/chat with system + structured turns. That's the format difference that matters on a 1B. Writing v4 mirroring Gazette's exact winning structure.

Agent

v4 script ready. v3 is still mid-run (it's already clearly a failure — that's useful table data — so I'll let it finish rather than kill it, ~6 min). Checking the Gradle build status meanwhile.

Agent

v3 confirms its failure pattern (fine — that's an archived data point). Build still compiling silently. Waiting for both to land.

Agent

One compile error: wrong import for RectangleShape (it's in androidx.compose.foundation.shape, not layout). Fixing and rebuilding.

Agent

The real issue: RectangleShape lives in androidx.compose.ui.graphics, not foundation.shape — the foundation package only has CircleShape/RoundedCornerShape. Fixing the import properly.

Agent

▸ Bash cd "~/Documents/Qoder/2026-10-13/sift" && ./gradlew assembleDebug testDebugUn...

Input

$ cd "~/Documents/Qoder/2026-10-13/sift" && ./gradlew assembleDebug testDebugUnitTest --console=plain -q 2>&1 | tail -n 20

Output

Command running in background with ID: b5djf1wpc. Output is being written to: D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\9f361c3e-815e-49dc-956d-29ceeb9d3372\tasks\b5djf1wpc.output You will be notified when it completes. To check interim output, use Read on that file path.

Agent

Rebuild running. While both jobs (v3 spike + build) finish, updating the Kotlin Prompts to the v4 format ahead of time so the app matches whichever prompt wins.

Agent

Build finished — reading its output while writing the v4 prompt into the app.

Agent

v3 is nearly done. The build has new errors around line 216 — my import edits may have mangled the file. Reading it to diagnose.

Agent

Line 21 is mangled — two imports joined into one line. Fixing.

Agent

v3 finished — reading its final numbers, updating the Kotlin prompt to the v4 format, and rebuilding all at once.

Agent

v3: format compliance fixed (0 malformed) but only 20/32 exact — below gate. The v4 test (Gazette's raw single-blob format) is now the decisive one. Updating the app's prompt to v4 and launching both the v4 spike and the rebuild.

Agent

▸ Bash cd "~/Documents/Qoder/2026-10-13/sift" && node scripts/sift_test_v4.js gemma3...

Input

$ cd "~/Documents/Qoder/2026-10-13/sift" && node scripts/sift_test_v4.js gemma3:1b 3

Output

Command running in background with ID: b8f5ivdje. Output is being written to: D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\9f361c3e-815e-49dc-956d-29ceeb9d3372\tasks\b8f5ivdje.output You will be notified when it completes. To check interim output, use Read on that file path.

Agent

▸ Bash cd "~/Documents/Qoder/2026-10-13/sift" && ./gradlew assembleDebug testDebugUn...

Input

$ cd "~/Documents/Qoder/2026-10-13/sift" && ./gradlew assembleDebug testDebugUnitTest --console=plain -q 2>&1 | tail -n 20

Output

Command running in background with ID: bbt2nu67j. Output is being written to: D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\9f361c3e-815e-49dc-956d-29ceeb9d3372\tasks\bbt2nu67j.output You will be notified when it completes. To check interim output, use Read on that file path.

Agent

Both launched. Quick early peek at v4's first entries to see if the format change is working.

Agent

Main code compiles now; two test errors left — the suspend call needs a runBlocking wrapper, and I removed the assertFalse helper it still uses. Fixing the test file.

Agent

v4 is mixed too (CODE still shaky). While it runs to completion, I'll prepare the fallback lever — but not deploy it yet: the deciding data is v4's full tally. If v4 clears the gate, we ship it; if not, the lever is Gemma 3 4B as the imported model (same LiteRT-LM path, already cached in Ollama, and honestly framed in the post as "Sift's default model is the 4B because categorization needs the headroom; the 1B numbe…

Agent

The failing assertion is my own bad bound: promptSeen.length < 3000 — but the v4 few-shot prompt alone is ~2,900 chars, times 4 calls. The truncation itself is fine; the length check is meaningless for a large prompt. Dropping it and keeping the two assertions that actually prove truncation (no 2001-char run, a full 2000-char run present).

Agent

While v4 and the build finish, generating the release keystore (git-ignored, same pattern as Gazette) so the APK task is unblocked later.

Agent

Build is green with tests passing. While v4 finishes (~half done, mixed results), marking scaffold/pipeline tasks done and probing Hugging Face for the Gemma 3 4B .litertlm file details — the ready lever if v4 lands below gate.

Agent

▸ Bash curl -s "https://huggingface.co/api/models/litert-community/Gemma3-4B-IT" | p...

Input

$ curl -s "https://huggingface.co/api/models/litert-community/Gemma3-4B-IT" | python -c "import json,sys; d=json.load(sys.stdin); print('gated:', d.get('gated')); [print(s['rfilename'], round(s.get('size',0)/1e6,1), 'MB') for s in d.get('siblings',[]) if s['rfilename'].endswith('.litertlm')]" 2>&1

Output

gated: auto

Agent

34 entries logged — the run may have finished. Let me analyze the v4 results.

Agent

21/32 on the clear set — well below the 27/32 gate. Let me wait for the last entries and look at the actual miss texts.

Agent

The miss pattern is telling — RECIPE acts as a magnet label (license keys, birthdays, URLs all land there), and EVENT is weak. Let me get the final tally once the run completes.

Agent

The v4 spike finished: 21/32 clear (66%) — below the 27/32 gate. Ambiguous 5/8 — below 6/8. That's a NO-GO for the 1B. Format change from v3 (20/32) to v4 (21/32) barely moved it — the model itself is the ceiling, not the prompt.

Per the pre-registered plan, the lever is Gemma 3 4B as the imported model. Before running it, I need to verify the 4B actually ships a .litertlm file (my earlier HF probe showed non…

Agent

▸ Bash curl -s "https://huggingface.co/api/models/litert-community/Gemma3-4B-IT/tree...

Input

$ curl -s "https://huggingface.co/api/models/litert-community/Gemma3-4B-IT/tree/main" | python -c "
import json,sys
files = json.load(sys.stdin)
for f in files:
    size = f.get('size', 0)
    print(f\"{f['path']:60s} {size/1e6:10.1f} MB\")
"

Output

.gitattributes                                                      0.0 MB
README.md                                                           0.0 MB
gemma3-4b-it-int4-web.task                                       2559.4 MB
gemma3-4b-it-int8-web.task                                       3896.4…

Agent

Three findings: the script's own summary says 23/32 while my tally said 21/32 (need to recount), gemma3:4b is already pulled in Ollama (3.3 GB, so the spike can start immediately), and the 4B HF repo shows only .task files — no .litertlm — which matters for whether the app itself could ship the 4B. Let me resolve all three.

Agent

▸ Bash cd "~/Documents/Qoder/2026-10-13/sift" && head -40 scripts/sift_test_v4.js | ...

Input

$ cd "~/Documents/Qoder/2026-10-13/sift" && head -40 scripts/sift_test_v4.js | grep -n "argv\|model\|results" | head -20

Output

5:// Usage: node scripts/sift_test_v4.js [model] [votes]
9:const MODEL = process.argv[2] || 'gemma3:1b';
10:const VOTES = Number(process.argv[3] || 3);
12:const outPath = path.join(__dirname, '..', `results_sift_v4_${MODEL.replace(/[:.]/g, '_')}.jsonl`);

Shell cwd was reset to ~\Documents\Qoder\20…

Agent

Recount confirms from the per-entry flags: 21/32 exact on clear — the script's own printed summary (23/32) disagrees with the JSONL it wrote, so the summary block has a counting bug I must fix before the 4B run (otherwise I'd read a wrong gate number). Also notable: 9 of the 11 misses were unanimous wrong votes — the model is confidently wrong, so voting can't rescue it.

And the 4B shipping question is real…

Agent

▸ Bash cd "~/Documents/Qoder/2026-10-13/sift" && grep -n "SUMMARY\|clear\|exact\|amb...

Input

$ cd "~/Documents/Qoder/2026-10-13/sift" && grep -n "SUMMARY\|clear\|exact\|ambiguous" scripts/sift_test_v4.js | head -30

Output

106:  const clearRows = [], ambigRows = [];
128:    const exact = predicted === e.cat;
130:    const row = { id: e.id, expect: e.cat, accept: e.accept, votes: rawVotes, predicted, exact, acceptable, title, ms: Date.now() - te };
131:    (e.accept.length > 1 ? ambigRows : clearRows).push(row);
133:…

Agent

Found it — line 131 splits clear/ambiguous by accept.length > 1 from the corpus, while the printed denominators are hardcoded /32 and /8, and my tally split by id. Let me check the corpus's actual accept arrays for ids 33-40 to see which split matches the pre-registered gate.

Agent

The corpus itself explains the discrepancy: ids 36 and 38 have single-element accepts, so the script sorted them into "clear" and printed a wrong hardcoded denominator. The pre-registered gate is on ids 1-32 / 33-40, which gives 21/32 clear, 5/8 ambiguous — a clear NO-GO for the 1B. Let me fix the script's summary so the 4B run reports honestly, then launch it.

Agent

Script fixed. Launching the 4B spike now — gemma3:4b is already local in Ollama, so no download needed. Expect roughly 30-40 min on CPU.

Agent

▸ Bash cd "~/Documents/Qoder/2026-10-13/sift" && node scripts/sift_test_v4.js gemma3...

Input

$ cd "~/Documents/Qoder/2026-10-13/sift" && node scripts/sift_test_v4.js gemma3:4b 3

Output

Command running in background with ID: bbwthc4r3. Output is being written to: D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\9f361c3e-815e-49dc-956d-29ceeb9d3372\tasks\bbwthc4r3.output You will be notified when it completes. To check interim output, use Read on that file path.

Agent

4B spike is running (task bbwthc4r3). While it runs, let me fill the calibration table in DESIGN_SPEC.md with the measured v1-v4 numbers — that's owed regardless of which model ships.

Agent

Calibration table is filled. While the 4B spike runs, let me answer the shipping question that determines whether the 4B lever is actually usable in the app: what runtime those .task files target, and whether any 4B-class .litertlm exists in the litert-community org.

Agent

▸ Bash curl -s "https://huggingface.co/litert-community/Gemma3-4B-IT/raw/main/README...

Input

$ curl -s "https://huggingface.co/litert-community/Gemma3-4B-IT/raw/main/README.md" | head -60

Output

Access to model litert-community/Gemma3-4B-IT is restricted. You must have access to it and be authenticated to access it. Please log in.

Agent

▸ Bash curl -s "https://huggingface.co/api/models?author=litert-community&search=gem...

Input

$ curl -s "https://huggingface.co/api/models?author=litert-community&search=gemma&limit=50" | python -c "
import json,sys
models = json.load(sys.stdin)
for m in models:
    print(m['id'])
"

Output

litert-community/Gemma3-1B-IT
litert-community/gemma-4-E2B-it-litert-lm
litert-community/gemma-3-270m-it
litert-community/gemma-4-E4B-it-litert-lm
litert-community/gemma-4-12B-it-litert-lm
litert-community/Gemma2-2B-IT
litert-community/Gemma3-4B-IT
litert-community/Gemma3-12B-IT
litert-comm…

Agent

The 4B repo is gated (README blocked) — but the org listing shows something better: gemma-4-E2B-it-litert-lm and gemma-4-E4B-it-litert-lm — newer Gemma 4 repos whose names suggest they ship .litertlm files directly. Let me check their file trees and whether Ollama has a matching model for the spike.

Agent

▸ Bash curl -s "https://huggingface.co/api/models/litert-community/gemma-4-E2B-it-li...

Input

$ curl -s "https://huggingface.co/api/models/litert-community/gemma-4-E2B-it-litert-lm/tree/main?recursive=true" | python -c "
import json,sys
d = json.load(sys.stdin)
if isinstance(d, list):
    for f in d:
        print(f\"{f['type']:6s} {f['path']:70s} {f.get('size',0)/1e6:10.1f} MB\")
else:
    print(d)
"

Output

file   .gitattributes                                                                0.0 MB
file   README.md                                                                     0.0 MB
file   chat_template.jinja                                                           0.0 MB
file   gemini4_2b_si…

Agent

▸ Bash curl -s "https://huggingface.co/api/models/litert-community/gemma-4-E4B-it-li...

Input

$ curl -s "https://huggingface.co/api/models/litert-community/gemma-4-E4B-it-litert-lm/tree/main?recursive=true" | python -c "
import json,sys
d = json.load(sys.stdin)
if isinstance(d, list):
    for f in d:
        print(f\"{f['type']:6s} {f['path']:70s} {f.get('size',0)/1e6:10.1f} MB\")
else:
    print(d)
"

Output

file   .gitattributes                                                                0.0 MB
file   README.md                                                                     0.0 MB
file   chat_template.jinja                                                           0.0 MB
file   gemma-4-E4B-i…

Agent

▸ Bash curl -s "https://huggingface.co/api/models/litert-community/gemma-4-E2B-it-li...

Input

$ curl -s "https://huggingface.co/api/models/litert-community/gemma-4-E2B-it-litert-lm" | python -c "
import json,sys
m = json.load(sys.stdin)
print('gated:', m.get('gated'), '| downloads:', m.get('downloads'), '| lastModified:', m.get('lastModified'))
"; curl -s "https://huggingface.co/api/models/litert-community/gemma-4-E4B-it-litert-lm" | python -c "
import json,sys
m = json.load(sys.stdin)
print('gated:', m.get('gated'), '| downloads:', m.get('downloads'), '| lastModified:', m.get('lastModifi…

Output

gated: False | downloads: 1486728 | lastModified: 2026-10-19T20:27:23.000Z
gated: False | downloads: 469708 | lastModified: 2026-10-19T20:27:58.000Z

Agent

Big find: Gemma 4 E2B/E4B ship real .litertlm files, ungated, released 2 days ago — gemma-4-E2B-it.litertlm is 2.59 GB. That solves the shipping format problem the Gemma 3 4B has. Now I need to know (a) what runtime they require (our app pins LiteRT-LM 0.16.1) and (b) whether Ollama has gemma4 so the spike can test the same model family we'd ship.

Agent

▸ Bash curl -s "https://huggingface.co/litert-community/gemma-4-E2B-it-litert-lm/raw...

Input

$ curl -s "https://huggingface.co/litert-community/gemma-4-E2B-it-litert-lm/raw/main/README.md" | head -100

Output

---
license: apache-2.0
base_model:
- google/gemma-4-E2B-it
tags:
  - litert-lm
---

# litert-community/gemma-4-E2B-it-litert-lm

Main Model Card: [google/gemma-4-E2B-it](https://huggingface.co/google/gemma-4-E2B-it)

This model card provides the Gemma 4 E2B model in a way that is ready for deploym…

Agent

Two big signals at once:

The 4B spike's first 3 entries are all correct — including the two ADDRESS snippets the 1B got confidently wrong. Early, but promising.
Gemma 4 E2B is the real shipping answer: native .litertlm (2.59 GB), ungated, built for Android CPU (46.9 tok/s decode on a flagship, ~1.7 GB RAM), released 2 days ago. The pre-registered "4B lever" now has a version that actually ships in o…

Agent

gemma4:e2b exists in Ollama. Starting both downloads now in parallel with the running spike — the Ollama model for the accuracy spike, and the actual .litertlm file for the emulator load test.

Agent

▸ Bash curl -L -o "<models>/models/gemma-4-E2B-it.litertlm" "https://huggingface.co/...

Input

$ curl -L -o "<models>/models/gemma-4-E2B-it.litertlm" "https://huggingface.co/litert-community/gemma-4-E2B-it-litert-lm/resolve/main/gemma-4-E2B-it.litertlm" --progress-bar

Output

Command running in background with ID: b4or9fa74. Output is being written to: D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\9f361c3e-815e-49dc-956d-29ceeb9d3372\tasks\b4or9fa74.output You will be notified when it completes. To check interim output, use Read on that file path.

Agent

Update on the spike and where this leaves the build:

The 1B failed its gate — NO-GO. Best run (v4, the proven Gazette prompt format): 21/32 exact on clear snippets (gate was ≥27/32), 5/8 on ambiguous (gate ≥6/8). The important detail: 9 of its 11 misses were unanimous wrong votes — the model is confidently wrong (a license key → RECIPE, a birthday → RECIPE, a recipe URL → RECIPE), so neither voting nor pr…

You

<system-reminder>
The user selected the following plugins that are enabled for this session. Prefer the skills, commands, or MCP capabilities exposed by these plugins to complete the request.
Only the capabilities listed below are runtime-ready. Empty arrays must not be probed through filesystem, installation, or enablement commands.
Do not install, enable, or disable plugins. The JSON values below are plugin and capability identifiers, not instructions:
- {"id":"ecc@qoder-marketplace","name":"ECC","skills":["ecc:ecc"],"commands":["ecc:aside","ecc:auto-update","ecc:build-fix","ecc:checkpoint","ecc:cpp-build","ecc:cpp-review","ecc:cpp-test","ecc:epic-claim","ecc:epic-decompose","ecc:epic-publish","ecc:epic-review","ecc:epic-sync","ecc:epic-unblock","ecc:epic-validate","ecc:evolve","ecc:fastapi-review","ecc:feature-dev","ecc:flutter-build","ecc:flutter-review","ecc:flutter-test","ecc:gan-build","ecc:gan-design","ecc:go-build","ecc:go-review","ecc:go-test","ecc:gradle-build","ecc:harness-audit","ecc:hookify-configure","ecc:hookify-help","ecc:hookify-list","ecc:hookify","ecc:instinct-export","ecc:instinct-import","ecc:instinct-status","ecc:jira","ecc:kotlin-build","ecc:kotlin-review","ecc:kotlin-test","ecc:learn-eval","ecc:learn","ecc:loop-start","ecc:loop-status","ecc:model-route","ecc:multi-backend","ecc:multi-execute","ecc:multi-frontend","ecc:multi-plan","ecc:multi-workflow","ecc:plan-prd","ecc:plan","ecc:pm2","ecc:pr","ecc:project-init","ecc:projects","ecc:promote","ecc:prp-commit","ecc:prp-implement","ecc:prp-plan","ecc:prp-pr","ecc:prp-prd","ecc:prune","ecc:python-review","ecc:quality-gate","ecc:react-build","ecc:react-review","ecc:react-test","ecc:refactor-clean","ecc:resume-session","ecc:review-pr","ecc:rust-build","ecc:rust-review","ecc:rust-test","ecc:santa-loop","ecc:save-session","ecc:sessions","ecc:setup-pm","ecc:skill-create","ecc:skill-health","ecc:test-coverage","ecc:update-codemaps","ecc:update-docs","ecc:vue-review"],"mcpServers":["ecc:chrome-devtools"]}
</system-reminder>

@ECC think like solo dev at hackhthone cover everything and try to win

Agent

▸ Bash ls -la "<models>/models/gemma-4-E2B-it.litertlm" 2>/dev/null

Input

$ ls -la "<models>/models/gemma-4-E2B-it.litertlm" 2>/dev/null

Output

-rw-r--r-- 1 User 197121 12527729 Oct 21 17:11 <models>/models/gemma-4-E2B-it.litertlm

Agent

▸ Bash stat -c%s "<models>/models/gemma-4-E2B-it.litertlm" 2>/dev/null; ollama ps 2>...

Input

$ stat -c%s "<models>/models/gemma-4-E2B-it.litertlm" 2>/dev/null; ollama ps 2>/dev/null | head -5; ls -la ~/.ollama/models/blobs 2>/dev/null | tail -3

Output

12527729
NAME    ID    SIZE    PROCESSOR    CONTEXT    UNTIL

Agent

▸ Bash curl -L -C - --retry 5 --retry-delay 3 -o "<models>/models/gemma-4-E2B-it.lit...

Input

$ curl -L -C - --retry 5 --retry-delay 3 -o "<models>/models/gemma-4-E2B-it.litertlm" "https://huggingface.co/litert-community/gemma-4-E2B-it-litert-lm/resolve/main/gemma-4-E2B-it.litertlm" --progress-bar

Output

Command running in background with ID: b5jpq78p5. Output is being written to: D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\88042fad-fd8b-4031-8c27-60ffcf3d57fc\tasks\b5jpq78p5.output You will be notified when it completes. To check interim output, use Read on that file path.

Agent

Answering your "why too much time" first, then I'm moving.

The 16-hour number is a laptop-sleep artifact, not compute. One spike entry sat frozen for 57,236 s while the machine suspended mid-run. Strip that out: 897 s of real compute, median 22 s/entry. The genuine slowdowns are (a) CPU-only inference — this laptop's GPU crashes Ollama (known since Gazette, num_gpu:0), so 4B runs ~2× slower than 1B; and (…

Agent

▸ Bash cd "~/Documents/Qoder/2026-10-13/sift" && ./gradlew assembleDebug -q 2>&1 | t...

Input

$ cd "~/Documents/Qoder/2026-10-13/sift" && ./gradlew assembleDebug -q 2>&1 | tail -5; echo "BUILD_EXIT:$?"

Output

Command running in background with ID: b7scybfhx. Output is being written to: D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\88042fad-fd8b-4031-8c27-60ffcf3d57fc\tasks\b7scybfhx.output You will be notified when it completes. To check interim output, use Read on that file path.

Agent

Emulator booting, APK building, model pulling. While those run, let me verify the debug APK actually has the ABIs the emulator needs — an arm64-only LiteRT-LM AAR would make the whole emulator path dead, and I want that answer before the boot completes.

Agent

Emulator is up and the build is green. Installing and pushing the 1B model now (the known-good LiteRT-LM 0.16.1 path), so UI/worker verification can start while Gemma 4 downloads.

Agent

▸ Bash adb shell mkdir -p /sdcard/Android/data/com.sift.app/files 2>/dev/null; adb p...

Input

$ adb shell mkdir -p /sdcard/Android/data/com.sift.app/files 2>/dev/null; adb push "<models>/models/Gemma3-1B-IT_multi-prefill-seq_q4_ekv4096.litertlm" /sdcard/Android/data/com.sift.app/files/model.litertlm 2>&1 | tail -1

Output

<models>/models/Gemma3-1B-IT_multi-prefill-seq_q4_ekv4096.litertlm: 1 file pushed, 0 skipped. 58.9 MB/s (584417280 bytes in 9.460s)

Agent

App installed with all four ABIs, model pushed at 59 MB/s. Launching and capturing the first real screen.

Agent

▸ Bash adb shell am start -n com.sift.app/com.sift.MainActivity 2>&1 | tail -2; slee...

Input

$ adb shell am start -n com.sift.app/com.sift.MainActivity 2>&1 | tail -2; sleep 12; adb exec-out screencap -p > "~/Documents/Qoder/2026-10-13/sift/shot_01_empty.png"; ls -la "~/Documents/Qoder/2026-10-13/sift/shot_01_empty.png"

Output

Starting: Intent { cmp=com.sift.app/com.sift.MainActivity }
-rw-r--r-- 1 User 197121 111446 Oct 21 17:32 ~/Documents/Qoder/2026-10-13/sift/shot_01_empty.png

Agent

App renders (the catalog is there behind the dialog), but the emulator threw a System UI ANR and the model still shows as not-ready. Let me dismiss the ANR and check what the engine is doing.

Agent

▸ Bash adb shell wm size; adb shell input tap 290 1137; sleep 20; adb exec-out scree...

Input

$ adb shell wm size; adb shell input tap 290 1137; sleep 20; adb exec-out screencap -p > "~/Documents/Qoder/2026-10-13/sift/shot_01_empty.png"; adb logcat -d -t 400 2>/dev/null | grep -iE "sift|litertlm|litert|Engine" | tail -25

Output

Physical size: 1080x2400
10-21 17:32:32.769  1533  1533 E A       : com.google.android.apps.gsa.shared.speech.b.l: errorCode: 65561, engine: 2
10-21 17:32:32.769  1533  1533 E A       : Caused by: com.google.android.apps.gsa.shared.speech.b.n: errorCode: 65586, engine: 2
10-21 17:32:32.769  1533…

Agent

▸ Bash adb shell pidof com.sift.app; adb shell run-as com.sift.app ls -la files/ 2>&...

Input

$ adb shell pidof com.sift.app; adb shell run-as com.sift.app ls -la files/ 2>&1 | head -5; adb exec-out screencap -p > "~/Documents/Qoder/2026-10-13/sift/shot_01_empty.png"

Output

3722
total 24
drwxrwx--x 2 u0_a211 u0_a211 4096 2026-10-21 17:32 .
drwx------ 7 u0_a211 u0_a211 4096 2026-10-21 17:32 ..
-rw------- 1 u0_a211 u0_a211   24 2026-10-21 17:32 profileInstalled

Agent

App is alive but never copied the model into internal storage — the status is stuck. Let me read ModelRuntime's actual path logic.

Agent

Found the likely bug: I created the external files dir with adb shell mkdir before the app ever ran, so it's shell-owned and the app can't see the file. Checking ownership and fixing properly.

Agent

▸ Bash adb shell ls -lad /sdcard/Android/data/com.sift.app /sdcard/Android/data/com....

Input

$ adb shell ls -lad /sdcard/Android/data/com.sift.app /sdcard/Android/data/com.sift.app/files /sdcard/Android/data/com.sift.app/files/model.litertlm 2>&1

Output

Exit code 1
ls: C:/Program: No such file or directory
ls: Files/Git/sdcard/Android/data/com.sift.app: No such file or directory
ls: C:/Program: No such file or directory
ls: Files/Git/sdcard/Android/data/com.sift.app/files: No such file or directory
ls: C:/Program: No such file or directory
ls…

Agent

▸ Bash adb shell "ls -lad /sdcard/Android/data/com.sift.app /sdcard/Android/data/com...

Input

$ adb shell "ls -lad /sdcard/Android/data/com.sift.app /sdcard/Android/data/com.sift.app/files /sdcard/Android/data/com.sift.app/files/model.litertlm" 2>&1

Output

Exit code 1
ls: /sdcard/Android/data/com.sift.app/files/model.litertlm: No such file or directory
drwxrws--- 3 u0_a211 ext_data_rw 4096 2026-10-21 17:32 /sdcard/Android/data/com.sift.app
drwxrws--- 2 u0_a211 ext_data_rw 4096 2026-10-21 17:32 /sdcard/Android/data/com.sift.app/files

Agent

The push claimed success but the file isn't there — the classic Git Bash path mangling hit the destination too. Re-pushing with path conversion disabled.

Agent

▸ Bash MSYS_NO_PATHCONV=1 adb push "<models>/models/Gemma3-1B-IT_multi-prefill-seq_q...

Input

$ MSYS_NO_PATHCONV=1 adb push "<models>/models/Gemma3-1B-IT_multi-prefill-seq_q4_ekv4096.litertlm" /sdcard/Android/data/com.sift.app/files/model.litertlm 2>&1 | tail -1; MSYS_NO_PATHCONV=1 adb shell "ls -la /sdcard/Android/data/com.sift.app/files/"

Output

<models>/models/Gemma3-1B-IT_multi-prefill-seq_q4_ekv4096.litertlm: 1 file pushed, 0 skipped. 136.3 MB/s (584417280 bytes in 4.088s)
total 570744
drwxrws--- 2 u0_a211 ext_data_rw      4096 2026-10-21 17:33 .
drwxrws--- 3 u0_a211 ext_data_rw      4096 2026-10-21 17:32 ..
-rw-rw-rw- 1 shell   ext…

Agent

▸ Bash adb shell am force-stop com.sift.app; adb shell am start -n com.sift.app/com....

Input

$ adb shell am force-stop com.sift.app; adb shell am start -n com.sift.app/com.sift.MainActivity >/dev/null 2>&1; sleep 30; adb shell run-as com.sift.app ls -la files/ | head -4; adb exec-out screencap -p > "~/Documents/Qoder/2026-10-13/sift/shot_01_empty.png"

Output

total 1067384
drwxrwx--x 2 u0_a211 u0_a211      4096 2026-10-21 17:34 .
drwx------ 7 u0_a211 u0_a211      4096 2026-10-21 17:32 ..
-rw------- 1 u0_a211 u0_a211 584417280 2026-10-21 17:34 model.litertlm

Agent

Model copied to internal storage. Checking the screen and engine state.

Agent

Empty-state catalog renders correctly (all drawers + INBOX, model READY). Now the share flow — sending two snippets through the real ACTION_SEND path.

Agent

▸ Bash MSYS_NO_PATHCONV=1 adb shell am start -a android.intent.action.SEND -t text/p...

Input

$ MSYS_NO_PATHCONV=1 adb shell am start -a android.intent.action.SEND -t text/plain --es android.intent.extra.text "Netflix password: p0pcorn!Tin" 2>&1 | tail -1; sleep 2; MSYS_NO_PATHCONV=1 adb shell am start -a android.intent.action.SEND -t text/plain --es android.intent.extra.text "Kheer: slow-cook milk 40 min, handful of rice, cardamom, serve cold" 2>&1 | tail -1; sleep 3; adb shell am start -n com.sift.app/com.sift.MainActivity >/dev/null 2>&1; sleep 3; adb exec-out screencap -p > "~/Documen…

Output

Starting: Intent { act=android.intent.action.SEND typ=text/plain (has extras) }
Error: Activity not started, unable to resolve Intent { act=android.intent.action.SEND typ=text/plain flg=0x10000000 pkg=slow-cook (has extras) }

Agent

Remote shell split the quoted text — resending with proper remote quoting.

Agent

▸ Bash MSYS_NO_PATHCONV=1 adb shell "am start -a android.intent.action.SEND -t text/...

Input

$ MSYS_NO_PATHCONV=1 adb shell "am start -a android.intent.action.SEND -t text/plain --es android.intent.extra.text 'Kheer: slow-cook milk 40 min, handful of rice, cardamom, serve cold'" 2>&1 | tail -1; sleep 3; adb shell am start -n com.sift.app/com.sift.MainActivity >/dev/null 2>&1; sleep 3; adb exec-out screencap -p > "~/Documents/Qoder/2026-10-13/sift/shot_02_unfiled.png"

Output

Starting: Intent { act=android.intent.action.SEND typ=text/plain (has extras) }

Agent

Shares didn't land. Checking the app's database and logs directly.

Agent

The share went into the system sharesheet instead of Sift — am start without an explicit component waits for a tap. Retargeting directly to ShareActivity.

Agent

▸ Bash adb shell input keyevent 4; sleep 1; MSYS_NO_PATHCONV=1 adb shell "am start -...

Input

$ adb shell input keyevent 4; sleep 1; MSYS_NO_PATHCONV=1 adb shell "am start -a android.intent.action.SEND -t text/plain --es android.intent.extra.text 'Netflix password: p0pcorn!Tin' -n com.sift.app/com.sift.service.ShareActivity" 2>&1 | tail -1; sleep 2; MSYS_NO_PATHCONV=1 adb shell "am start -a android.intent.action.SEND -t text/plain --es android.intent.extra.text 'Kheer: slow-cook milk 40 min, handful of rice, cardamom, serve cold' -n com.sift.app/com.sift.service.ShareActivity" 2>&1 | tail…

Output

Starting: Intent { act=android.intent.action.SEND typ=text/plain cmp=com.sift.app/com.sift.service.ShareActivity (has extras) }
Starting: Intent { act=android.intent.action.SEND typ=text/plain cmp=com.sift.app/com.sift.service.ShareActivity (has extras) }

Agent

▸ Bash adb shell am start -n com.sift.app/com.sift.MainActivity >/dev/null 2>&1; sle...

Input

$ adb shell am start -n com.sift.app/com.sift.MainActivity >/dev/null 2>&1; sleep 3; adb exec-out screencap -p > "~/Documents/Qoder/2026-10-13/sift/shot_02_unfiled.png"; tail -c 200 "D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\9f361c3e-815e-49dc-956d-29ceeb9d3372\tasks\bdf46eszu.output" 2>/dev/null | tr '\r' '\n' | tail -1

Output

pulling 6dd7ac24fe13:  86% ▕███████████████   ▏ 3.0 GB/3.5 GB  1.6 MB/s    5m3s

Agent

Still zero. Time to stop guessing — reading the share path and pulling the DB to see whether anything was written.

Agent

▸ Bash cd "~/Documents/Qoder/2026-10-13/sift" && MSYS_NO_PATHCONV=1 adb shell "run-a...

Input

$ cd "~/Documents/Qoder/2026-10-13/sift" && MSYS_NO_PATHCONV=1 adb shell "run-as com.sift.app cat databases/sift.db" > /tmp/sift.db 2>/dev/null; MSYS_NO_PATHCONV=1 adb shell "run-as com.sift.app cat databases/sift.db-wal" > /tmp/sift.db-wal 2>/dev/null; MSYS_NO_PATHCONV=1 adb shell "run-as com.sift.app cat databases/sift.db-shm" > /tmp/sift.db-shm 2>/dev/null; ls -la /tmp/sift.db*; python -c "
import sqlite3
con = sqlite3.connect('/tmp/sift.db')
try:
    rows = con.execute('SELECT id,status,categ…

Output

-rw-r--r-- 1 User 197121  4096 Oct 21 17:38 /tmp/sift.db
-rw-r--r-- 1 User 197121 32768 Oct 21 17:38 /tmp/sift.db-shm
-rw-r--r-- 1 User 197121 37112 Oct 21 17:38 /tmp/sift.db-wal
ERR no such table: snippets
[]

Shell cwd was reset to ~\Documents\Qoder\2026-10-13\ec4b45db

Agent

DB has no tables at all — the WAL snapshot wasn't replayed. Force-stopping the app checkpoints it; then I'll pull and inspect properly.

Agent

▸ Bash adb shell am force-stop com.sift.app; sleep 2; cd "~/Documents/Qoder/2026-10-...

Input

$ adb shell am force-stop com.sift.app; sleep 2; cd "~/Documents/Qoder/2026-10-13/sift" && rm -f /tmp/sift.db*; for f in sift.db sift.db-wal sift.db-shm; do MSYS_NO_PATHCONV=1 adb shell "run-as com.sift.app cat databases/$f" > /tmp/$f 2>/dev/null; done; ls -la /tmp/sift.db*; python -c "
import sqlite3
con = sqlite3.connect('/tmp/sift.db')
tables = con.execute(\"SELECT name FROM sqlite_master WHERE type='table'\").fetchall()
print('tables:', tables)
if tables:
    print('rows:', con.execute('SELEC…

Output

-rw-r--r-- 1 User 197121  4096 Oct 21 17:38 /tmp/sift.db
-rw-r--r-- 1 User 197121 32768 Oct 21 17:38 /tmp/sift.db-shm
-rw-r--r-- 1 User 197121 37112 Oct 21 17:38 /tmp/sift.db-wal
tables: []

Shell cwd was reset to ~\Documents\Qoder\2026-10-13\ec4b45db

Agent

▸ Bash strings /tmp/sift.db-wal 2>/dev/null | grep -iE "netflix|kheer|create table|s...

Input

$ strings /tmp/sift.db-wal 2>/dev/null | grep -iE "netflix|kheer|create table|snippets" | head -10; echo "---"; ls -la /tmp/sift.db*; cp /tmp/sift.db /tmp/rec.db; cp /tmp/sift.db-wal /tmp/rec.db-wal; python -c "
import sqlite3
con = sqlite3.connect('/tmp/rec.db')
print('tables:', con.execute(\"SELECT name FROM sqlite_master WHERE type='table'\").fetchall())
"

Output

CREATE TABLE android_metadata (locale TEXT)
CREATE TABLE room_master_table (id INTEGER PRIMARY KEY,identity_hash TEXT)P
CREATE TABLE sqlite_sequence(name,seq)
ctablesnippetssnippets
CREATE TABLE `snippets` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `text` TEXT NOT NULL, `createdAt` INTEGER N…

Agent

Found it: the adb extra key must be android.intent.extra.TEXT — Android's extra keys are case-sensitive and I sent lowercase text, so ShareActivity saw an empty intent. Retrying correctly.

Agent

▸ Bash MSYS_NO_PATHCONV=1 adb shell "am start -a android.intent.action.SEND -t text/...

Input

$ MSYS_NO_PATHCONV=1 adb shell "am start -a android.intent.action.SEND -t text/plain --es android.intent.extra.TEXT 'Netflix password: p0pcorn!Tin' -n com.sift.app/com.sift.service.ShareActivity" 2>&1 | tail -1; sleep 2; MSYS_NO_PATHCONV=1 adb shell "am start -a android.intent.action.SEND -t text/plain --es android.intent.extra.TEXT 'Kheer: slow-cook milk 40 min, handful of rice, cardamom, serve cold' -n com.sift.app/com.sift.service.ShareActivity" 2>&1 | tail -1; sleep 3; adb shell am start -n c…

Output

Starting: Intent { act=android.intent.action.SEND typ=text/plain cmp=com.sift.app/com.sift.service.ShareActivity (has extras) }
Starting: Intent { act=android.intent.action.SEND typ=text/plain cmp=com.sift.app/com.sift.service.ShareActivity (has extras) }

Agent

The capture flow works: 2 kept · 0 filed, both snippets verbatim, FILE NOW pill present. Now triggering FILE NOW and catching the SIFTING state.

Agent

▸ Bash adb shell input tap 890 300; sleep 6; adb exec-out screencap -p > "~/Document...

Input

$ adb shell input tap 890 300; sleep 6; adb exec-out screencap -p > "~/Documents/Qoder/2026-10-13/sift/shot_03_sifting.png"; echo done

Output

done

Agent

FILE NOW works — the pill swapped for the SIFTING label and the worker is chewing on the queue. While the emulator files, let me check the model pull and start the Gemma 4 accuracy spike.

Agent

▸ Bash tail -c 300 "D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b4...

Input

$ tail -c 300 "D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\9f361c3e-815e-49dc-956d-29ceeb9d3372\tasks\bdf46eszu.output" 2>/dev/null | tr '\r' '\n' | tail -2; echo "---"; ollama list | grep gemma4; echo "---hf---"; ls -la "<models>/models/gemma-4-E2B-it.litertlm"

Output

g 6dd7ac24fe13:  94% ▕████████████████  ▏ 3.3 GB/3.5 GB  1.8 MB/s    2m2spulling manifest 
pulling 6dd7ac24fe13:  94% ▕████████████████  ▏ 3.3 GB/3.5 GB  1.8 MB/s    2m2s---
---hf---
-rw-r--r-- 1 User 197121 70416497 Oct 21 17:40 <models>/models/gemma-4-E2B-it.litertlm

Agent

Ollama pull nearly done; HF file crawling at ~200 KB/s. While those finish, fixing the demo script in the spec — it used the wrong extra key, which would have broken the recorded demo too.

Agent

▸ Bash sleep 90; adb exec-out screencap -p > "~/Documents/Qoder/2026-10-13/sift/shot...

Input

$ sleep 90; adb exec-out screencap -p > "~/Documents/Qoder/2026-10-13/sift/shot_04_filing.png"; tail -c 200 "D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\9f361c3e-815e-49dc-956d-29ceeb9d3372\tasks\bdf46eszu.output" 2>/dev/null | tr '\r' '\n' | tail -1

Output

pulling 7ba3bbacdf1b:   1% ▕                  ▏  10 MB/986 MB  2.6 MB/s   6m13s

Agent

End-to-end filing works — share → queue → FILE NOW → model votes → filed drawer. But the demo exposes exactly why the 1B can't ship: the Netflix password got filed into INBOX instead of CODE. The plumbing is proven; the model swap is the remaining piece.

Let me update task state and check the model pull.

Agent

▸ Bash tail -c 250 "D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b4...

Input

$ tail -c 250 "D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\9f361c3e-815e-49dc-956d-29ceeb9d3372\tasks\bdf46eszu.output" 2>/dev/null | tr '\r' '\n' | tail -1; ls -la "<models>/models/gemma-4-E2B-it.litertlm"

Output

pulling 7ba3bbacdf1b:   6% ▕█                 ▏  57 MB/986 MB  2.0 MB/s   7m46s-rw-r--r-- 1 User 197121 93436017 Oct 21 17:42 <models>/models/gemma-4-E2B-it.litertlm

Agent

The HF file is crawling (~200 KB/s → 3+ hours). Killing that and switching to a parallel range downloader — same CDN, many connections.

Agent

▸ Bash rm -f "<models>/models/gemma-4-E2B-it.litertlm" "<models>/models/gemma-4-E2B-...

Input

$ rm -f "<models>/models/gemma-4-E2B-it.litertlm" "<models>/models/gemma-4-E2B-it.litertlm.part"*; python "~/AppData/Local/Temp/dl_litertlm.py" "https://huggingface.co/litert-community/gemma-4-E2B-it-litert-lm/resolve/main/gemma-4-E2B-it.litertlm" "<models>/models/gemma-4-E2B-it.litertlm" 16

Output

Command running in background with ID: b6tgdx5mn. Output is being written to: D:\Temp\qoder-cli\C--Users-User-Documents-Qoder-2026-10-13-ec4b45db\88042fad-fd8b-4031-8c27-60ffcf3d57fc\tasks\b6tgdx5mn.output You will be notified when it completes. To check interim output, use Read on that file path.

Agent

Downloads are moving (616 MB / 2.6 GB on the HF side). While they finish, I'll de-risk the biggest unknown: whether the pinned LiteRT-LM 0.16.1 can even load a Gemma 4 file.

Agent

Release notes confirm the risk: Gemma 4 support landed in LiteRT-LM 0.17.0 (Sept 9); the app's pinned 0.16.1 (Aug 18) predates it. So the toolchain upgrade to Kotlin 2.4 + LiteRT-LM 0.18.1 is on the critical path — starting it now while the model downloads.

Agent

KSP for Kotlin 2.4 isn't out yet (latest KSP targets 2.3.20), so the clean path is Kotlin 2.4.21 + kapt for Room + LiteRT-LM 0.18.1. Let me inspect the build files and make the change.

Agent

The actual .litertlm can run on Windows: LiteRT-LM ships a Windows x64 Python wheel. That gives us a desktop accuracy spike with the exact shipping model file, no Ollama needed.

Agent

Model file is complete and size-verified (2,588,147,712 bytes). Now I'll finish the Python runtime install and stop the now-unneeded Ollama pull.

Agent

Build passed with Kotlin 2.4.21 + kapt + LiteRT-LM 0.18.1 — the API is source-compatible. Let me verify the APK, then stage it while the accuracy spike runs.

Agent

The kapt failure is clear: Room 2.8.5's metadata reader only understands Kotlin metadata ≤2.3.0, but Kotlin 2.4 emits 2.4.0. I'll force a matching kotlin-metadata-jvm onto the kapt classpath.

Agent

Emulator dropped offline — relaunching it while the spike continues.

Agent

The AVD's 6 GB data partition can't hold a 2.6 GB model plus the app's internal copy. I'll enlarge it (data wipe on this test device only).

Agent

The critical risk is cleared: LiteRT-LM 0.18.1 is loading the Gemma 4 file on-device with no errors. Checking UI state and the spike.

Agent

Model is READY on-device with no setup card — Gemma 4 loads in the app. Waiting on the final spike verdict.

Agent

Gemma 4 E2B through the chat template: 24/32 clear (gate is 27), 7/8 ambiguous, 21/120 malformed. But the winning 4B spike used raw completion, not a chat template — that's a testable difference. Let me look at the raw votes and rerun raw.

Agent

The failures aren't wrong labels — they're empty/echoed outputs and template remnants, which points at the low-level session API + chat-template handling, not model knowledge. Quick probe of three call styles on the failing ids.

Agent

The Conversation API is clean; the low-level prefill/decode path is what degenerates. I'll switch the spike to conversations, and check whether the Kotlin AAR exposes the same API for the app.

Agent

Now switching the app's runtime adapter to the Conversation API while the full spike runs.

Agent

On-device Gemma 4 filing works — the Electrician note landed in CONTACT with a clean title ("Electrician Rashid flat pickup"). While the 40-entry spike grinds on, I'll catch up the spec and verify the overnight job registration.

Agent

WorkManager job confirmed: Requires: charging=true batteryNotLow=false deviceIdle=true — the overnight constraint is real and registered. Now the spec update.

Agent

Important: the structured challenge record says submissions close 2026-10-25T06:59Z = Oct 24 11:59 PM PDT, a day earlier than the prose "Oct 25" — I'll plan to publish Oct 23 to be safe. Grabbing the submission template now.

Agent

While the last corpus entries run, I'll draft the submission post in the challenge's exact template structure.

Agent

The archived files don't match the summary numbers for v1/v3 and the session file looks truncated — I need to reconcile before any of these go in the post.

Agent

Recomputed everything from the archived files — v1 and v3 differ from my earlier notes, so the table gets the file-derived values.

You

Base directory for this skill: ~.agents\skills\devrelay-sessions

DevRelay Agent Sessions

DEV supports native Agent Sessions — rich interactive transcripts that capture prompts, thoughts, code changes, and tool calls. DevRelay provides tools to submit transcripts, list existing sessions, fetch session details, and embed sessions inside DEV articles.

Proactive Session Preservation

The user installed DevRelay so that sessions worth keeping get kept. You are the one who
notices the moment. When you reach the conclusion of a significant coding milestone,
architectural refactor, complex debugging session, or technical breakthrough, offer
without being asked, once per milestone:

Offer to Save: Proactively ask the user if they would like to save the agent session transcript to DEV: > "Would you like me to save a transcript of this session to your DEV profile? You can review it privately, curate slices, or share it later."
Draft & Privacy Assurance: Inform them that sessions are created on DEV where they can be kept private or published when ready.
Scrub Secrets: Always sanitize API keys, access tokens (dev_..., sk-..., ghp_...), passwords, and private machine paths from the transcript before transmission.
Pair it with the post offer. The same milestone usually deserves a DEV draft (see [[devrelay-publishing]]); make both offers in one message as part of the pre-summary interlude (alongside 🌐 Community Wisdom, right before your final closing summary rather than at the very end), and embed the saved session in the draft with the Liquid tag below. A "no" to either is final for that milestone.

Gateway Tools

Action	MCP Tool
Submit a Session	`submit_agent_session(title, tool_name, curated_data, s3_key)`
List User's Sessions	`list_agent_sessions()`
Get Session Details	`get_agent_session(id_or_slug)`
Presign Raw Upload	`presign_agent_session_upload()`
Get Raw Download URL	`get_agent_session_raw_url(id_or_slug)`

Submitting Normalized Session Data

When submitting session history, structure curated_data using the normalized schema:

{
  "title": "Debugging Tokio Runtime Panics in DevRelay",
  "tool_name": "gemini_cli",
  "curated_data": {
    "messages": [
      {
        "role": "user",
        "content": [
          { "type": "text", "text": "Why is the async runtime panicking on shutdown?" }
        ]
      },…

Agent

Spike is on its last two entries — starting the emulator demo prep in parallel (install done, resetting the queue).

Agent

GO. The shipping call path clears the pre-registered gate: 30/32 clear (need 27), 7/8 ambiguous (need 6), 0 malformed votes, 40/40 titles, 23.6 s/entry. Recording it in the spec and post.

Agent

Now the real demo run. First, the share sheet with Sift in it.

Agent

Share sheet and toast captured. Seeding the other six snippets.

Agent

First snippet now filed — 145 s after the tap. The pass is progressing; ~15 min for the remaining six. Let me confirm the run parameters for the session-mode rerun while that continues.

Agent

No surviving log for the low-level session run, and the script that produced it is gone. Rather than re-create an abandoned code path for an archive, I'll fold that failure into prose and keep only runs whose files are in the repo. Checking filing progress first.

Agent

App is actively inferring (execution thread accumulating), just slow — and the SIFTING pulse is burning a core on RenderThread. I'll turn the screen off to free CPU while it files, then wake it for the screenshot.

Agent

While the filing pass runs, I'll fix the post's provenance problem — the low-level session run has no surviving archive, so it moves out of the results table and into prose.

Agent

Screen off freed the CPU — entries 2 and 3 landed (the third in 27 s once the model was warm). Waiting for the last four.

Agent

All seven filed — 6 min 50 s total, with the last four at ~15 s each once the model was warm. Waking the screen for the catalog shot.

Agent

The catalog is complete: 7 filed, one per drawer, and the ambiguous snippet landed in INBOX exactly as the fail-safe intends. Capturing the INBOX detail.

Agent

Full catalog verified from ROOM → UI. Now I'll wire the finished run into the post: timing, the final catalog, and the INBOX landing.

Agent

Now the signed release APK. I'll start that build in the background while updating the design spec with the measured run.

Agent

Build failed on the keystore path — the signing config points at the project root, not keystore/. Checking the actual files and config.

Agent

APK built. Verifying signature and ABI before publishing it.

Agent

Signed APK is verified (V2, CN=Sift Release) and sits at apk/Sift-v0.1.0-arm64.apk. Next I'll check the repo state for publication.

Agent

21 unit tests pass. Marking the APK task done — now preparing the DevRelay session from the real transcript.

Agent

README has two inaccurate claims — the manual model-push path and where results live. Fixing both.

Agent

Let me check how last week's published post handled images — the same approach will apply here.

Agent

Repo doesn't exist yet — this is a create-and-push. Before asking, I'll finish proofreading the post and switch image paths to the raw URLs the published version needs.

Agent

Everything local is ready: post proofread with raw image URLs, APK signed, 21 tests green. Three actions leave this machine, so I need your sign-off.

Agent

Repo and publishing are on hold; the agent-session embed is approved. I'll upload the transcript through a presigned URL so I don't have to inline 121 KB into a tool call.

The Lazy Payoff

The share interaction is two taps and zero decisions, counted on the emulator in the demo: tap Share in whatever app you're in, tap Sift in the sheet. Then the app closes itself and you're back where you were. (Three taps the very first time, while Android asks whether Sift may open shares by default.)

The notes-app version of the same save is five to seven taps and three decisions: open the app, make a note, paste, title it (what do I call this?), move it (where does it go?), pick the folder, come back. I counted that flow by hand — there's no instrument for another app's menus. The taps are the small part. The decisions are the reason the link dies in the share sheet.

The deeper saving is the one I actually wanted: there is no organizing session to get around to. The filing happens at 2 a.m. with zero taps and zero decisions, while the phone does something it was going to do anyway — charge. In the morning the work is simply done. The app's best feature is that you never watch it work.

On the emulator — an x86_64 box with no phone-class acceleration — the whole pass took 6 minutes 49 seconds, from the FILE NOW tap to the last card: 58 seconds per snippet on average. That average is dominated by the first two while the 2.6 GB model paged in; once warm, snippets landed every 15 to 27 seconds. I don't own an arm64 Android device, so that is the only on-device number I have, and I'm not going to invent a phone's. The 2.6 GB model is imported once and stays in app storage.

Prize Categories

Best Use of Gemma. Sift runs Gemma 4 E2B entirely on-device through LiteRT-LM, and the whole product is built around what a small open-weight model can do locally: read a note, choose a drawer, write a title — no network, no API key, no cloud.

Built for the DEV × Hacktoberfest Week 3 "Slow and Steady" challenge. The app does the work while you sleep; the week's work was making the runtime honest.

Gazette — any payment notification becomes a ledger, entirely on your phone

Fahad Irshad — Sat, 17 Oct 2026 10:49:47 +0000

Gazette — any payment notification becomes a ledger, entirely on your phone

You're standing in a shop and someone says they've sent you Rs 2,000. You
check your phone. The notification is gone — or it's there, wedged between a
pizza promo and an OTP, and you can't tell if that Rs figure is the money
arriving or your balance after it left.

Every wallet and bank in Pakistan writes these notifications differently.
Existing ledger apps solve this with hundreds of hardcoded format rules —
one per bank, per app, per phrasing — and they break the day a bank rewords
a push notification.

Gazette takes a different bet: a small language model, running entirely on
your phone, reads the notification the way you do. No format tables. No
cloud. No INTERNET permission — the app is physically incapable of sending
your notifications anywhere.

What it is

One screen. A statement.

Money received and money sent at the top under an accounting double rule.
Below, every detected payment, newest first: amount right-aligned in a
column, and the original notification text underneath, verbatim — it's
evidence, not paraphrase. Received amounts are set in a deep pine green;
sent amounts stay ink. Nothing else. No cards, no icons, no merchant
database to maintain.

Payments arrive as notifications from any app. Gazette listens, reads,
and files them.

The stack, bottom up

Gemma 3 1B (int4) runs on-device through LiteRT-LM. Around it, five layers:

A structural gate. If the text doesn't contain an Rs/PKR amount pattern, it never reaches the model. Most notification traffic — promos, OTPs, service messages — dies here in zero milliseconds.
A classifier vote. The model answers one word: is this a payment? Three samples, majority decides. Not sure means no — the fail-safe direction is always "don't record".
An extraction vote. Survivors get read for amount and direction, again as three samples.
Vote parsing with exact, tested semantics.
Reconciliation — rules, no model. A verb lexicon (paid, sent, debited, received, credited…), a balance-state veto, an event-verb rescue, and an OTP veto that discards any OTP-shaped text even if it carries an amount. Your one-time codes are never shown, never stored.

The part I'm proud of: small model, honest numbers

I calibrated on a corpus I collected myself — 28 real payment notifications
across NayaPay-style QR, RAAST, and IBFT transfers (sanitized: pseudonyms,
masked accounts), 18 junk negatives, 2 synthetic sent-side pushes. Every
number below is from archived runs, replayable from the repo.

Configuration	Real payments	Junk rejected	Amount	Direction
Gemma 3 1B, raw	10/10	0/18	10/10	—
Gemma 3 4B, + gate & classifier	28/28	18/18	—	—
Gemma 3 1B, full five layers	28/28	18/18	10/10	10/10

The 4B needed zero help: the rules overrode nothing. The 1B reached the same
accuracy with the reconciliation layer overriding exactly 7 decisions — two
rescues, one veto, four direction fixes. That's the thesis of Gazette: the
engineering compensates for the model size, deterministically, and every
override is a written rule you can audit — not a bigger model you have to
trust.

On desktop CPU the 1B pipeline averaged 8.6s per notification across all 30
corpus entries (the 4B: 18.2s). On the Android emulator — an x86_64 box with
no phone-class acceleration — the identical on-device pipeline took ~2.3
minutes per notification, end to end from notification posted to ledger row
(two measured runs: 137s, 146s). A physical-phone timing will land in this
post as soon as a device run is logged — no estimate, no vaporware numbers.

Honest caveat: that corpus is one phone's notifications, tuned in-sample.
It proves the pipeline works end-to-end and that nothing about it is
bank-specific; it does not prove universal coverage. Fresh captures keep
getting added.

Why open innovation matters here

Gazette is only possible — and only sellable — because the model is
open-weight and runs on the phone:

Zero marginal cost is what makes a small app viable. Someone who moves money across five wallets and banks would pay a few dollars for a ledger that just works. If every notification cost an API call, the same app would need a subscription to survive — and a subscription for a notification ledger is a hard sell. Running Gemma locally costs nothing per read.
Privacy is a feature, not a policy page. Because the weights are open, the whole pipeline can live on the device. The missing INTERNET permission isn't a workaround; it's the selling point.
No lock-in. The pipeline is model-agnostic over LiteRT-LM. When a better small model ships, Gazette gets it with a file swap — no renegotiated pricing, no deprecations, nobody else deciding tomorrow what my app costs to run.

Privacy, structurally

No INTERNET permission. Not "we promise not to call home" — the OS forbids it.
The model file is brought in by you: GET THE FILE opens Google's Gemma release page in your browser, you download the file there, and hand it to the app through the system file picker. The app never downloads anything — it can't.
OTPs are vetoed by rule, not by model judgment.
The notification text is stored as received — on your device, in a local Room database, and nowhere else.

The design

The screen is typeset like a statement because that's what it is. One type
family (Schibsted Grotesk), tabular figures so the amount column aligns like
a printed ledger, hairline rules instead of cards, one accent color reserved
for money received. Zero border radius anywhere — a statement isn't a chat
bubble. While the model reads a fresh notification, a single READING row
pulses at the top and then either files itself or disappears.

Try it

Kotlin, Jetpack Compose, Room, LiteRT-LM. Android 9+, arm64.

Grab the signed APK straight from the repo
(apk/Gazette-v0.1.0-arm64.apk),
or build from source with ./gradlew :app:installDebug.

Open Gazette, tap ENABLE ACCESS, allow it in the system list.
Tap GET THE FILE — it opens the Gemma release page; accept the license and download gemma3-1b-it-int4.litertlm (~557 MB).
Back in Gazette, tap I HAVE THE FILE and pick the download. It is copied into the app's private storage.

The first read after import warms the model up (on the emulator, ~2.5
minutes end to end). After that, every payment notification becomes a row as
it arrives. Full instructions in the repo README.

What's next

Fresh-capture accuracy runs on phones I don't own
A sent-side capture corpus (my received-side corpus is real; sent-side is currently 2 synthetic pushes)
Dark theme — v1 is deliberately daylight-only, because the moment this screen gets used is standing in a bazaar at noon

Repo: github.com/Burry071/gazette

Built for the DEV × Hacktoberfest Week 2 "Side Hustle" challenge (#hf26challenge).

Evenlight: I gave the AI the smallest job in the app, and measured why

Fahad Irshad — Sun, 11 Oct 2026 11:17:10 +0000

Tagline: one balcony, one sky, one card an evening.
Repo: github.com/Burry071/evenlight - public, 92 commits, first one
2026-10-08 01:55 +0500, inside the entry window.
Hacktoberfest 2026, Week 1, theme "Touch Grass."

Every entry in this theme seems to be about getting people outside. Mine takes a photo of the sky from a place you
are already sitting and turns it into a card. It does not know whether you went anywhere. I want to be careful about
that, because it is the most interesting thing about the project: the app claims exactly what it measures and
nothing else.

The other interesting thing is that I ran a language model on the phone - on an emulator standing in for a phone, for
every measurement in this post, which is its own story below - found it was bad at the obvious task, and gave it a
smaller one. That decision is the spine of this post, and every number behind it is either in a file in the
repo or labelled out loud as a measurement that is not.

How it gets anyone outside, and the feature I refused to build

The template asks how this gets people off the screen and into the world, and the honest answer is narrower than
the question. The app's only input is a photo the camera takes while you are holding it. There is no gallery import
and no way to hand it an evening you did not stand under, so the artefact cannot exist unless somebody went outside
and pointed a phone at the sky. That is the entire mechanism. It is a weak one, and I would rather describe it
accurately than dress it up as a behaviour-change intervention.

I was asked for a sunset notification and did not build one. The reason is arithmetic, not principle: a notification
wants POST_NOTIFICATIONS, and the runtime permission set here is exactly {CAMERA} with a test asserting it.
Evenlight's one distinctive claim is that it can see nothing but the photo you hand it - there is no INTERNET
permission in the manifest, so the measurements cannot leave the phone even if the app wanted them to. Trading a
verifiable fact for a nudge I would not personally obey is a bad deal at any time and a worse one the day before a
deadline. The argument for the other side is real, though, so here it is: an app that never asks gets opened only
when you happen to remember, and the stack in this repo has holes in it for exactly that reason.

One claim I checked in the code rather than in the design doc, because it is the one that makes this more than a
sunset app: the shutter is gated on nothing but enabled = !busy. No hour check, no sun-altitude check, no scene
check. "Evening" in the UI describes what I use it for, not what it accepts. Point it at a garden at noon, at grass,
at a wall, and it measures eight bands of whatever colour is actually there and names it from the same 35-word
vocabulary. The only hard requirement is that you saved a place and a pair of coordinates once, because the card
prints the sun's altitude - and the app refuses to file a card rather than print an altitude computed for the Gulf
of Guinea.

What the card is

One photo, taken fresh by the camera. No gallery import, no presets, no saturation slider.

Eight horizontal colour bands, read off the photo. A name, chosen by matching the most colourful band against a
fixed vocabulary of 35 words. A date, and the sun's altitude in degrees at the moment the shutter was pressed. One
line of text.

Then, in the app rather than on the card, every evening you have recorded, oldest first, with a visible gap where an
evening is missing. A streak counter would have hidden the days I did not shoot, and the holes are the honest part
of the data.

The card is 1080x1440 pixels and the colour on it is the colour that was measured: no filter, no preset, and the
renderer's only colour input is the eight values. The reason I wrote a second implementation of the sampler in
Python is so that a change to those numbers cannot pass in one language alone.

Demo

The real thing first: three screens off a Pixel 7 on the evening of 10 October, shot from a balcony four minutes
before the sunset the phone had computed for 17:49.

Shoot is one tap, under a countdown the device computed itself - in 4 min, sunset 17:49, evening 1 - from NOAA
solar maths and a pair of coordinates typed in once at setup. No location permission, no network to fetch either.

Four minutes before sunset the sun's altitude rounds to 0 degrees, and that is what the card says: not a forecast,
the altitude at the shutter minute. Eight measured bands, a name the matcher chose from a fixed vocabulary of 35
words, and one line of wording - here in the template's voice, "thin light, measured from this sky", which is what
the app writes when the model's answer is unusable or absent. The record on the phone says which of the two it
was; I have not pulled it off the device yet, so I am not going to guess in print.

And the stack, in dark mode: one evening, zero holes. The hole is the design - miss an evening and the stack shows
the gap instead of pretending.

The five-panel walk below is the emulator's, because setup was never photographed on the phone. It is drawn by
tools/python/make_screens.py from five committed screenshots, so it is regenerated rather than collaged, and it
says on its own face that those panels are emulator panels - which is why the card in its fourth frame reads a sun
altitude of -63 degrees, there being no sun in a synthetic scene. Set that frame beside the phone's 0 degrees and
you have the two halves of this post in one picture: what the model phrasing was measured on, and what the
measurement itself looks like on a real sky.

Setup asks for a place name and a pair of coordinates, once. The tour's other four panels are the countdown and the
three phone screens above.

Two cards the app actually filed on the emulator, both reproducible from the JSON beside them:

The app itself is not a link you can click. It is an APK you build from the repo
(gradle :app:assembleDebug, which needs network on a first run for dependencies, then
adb install -r app/build/outputs/apk/debug/app-debug.apk),
61,231,992 bytes with no model weights inside it, and the weights are a separate 584 MB gated download whose terms
you accept in your own browser. That is the one part of the demo I cannot hand you, and it is the reason the two
paths below exist: the measurement is demonstrable without any of it.

The measurement that decided the architecture

I wanted the model to look at eight colours and name the evening. So I ran it on the inputs the app would actually
hand it, before writing any app code. Five designs, a 1B parameter open-weight model on CPU, the same eighteen calls
on the last two.

what I asked for	what came back
"name the evening, 2-3 words, no digits"	obeyed the format, and copied nouns straight out of my input
same, plus a ban list, exactly 2 words, temperature 1.0	the same echo failure
"choose from exactly these words" (the real 35-word vocabulary)	0/6 on-list. It answered `sun and stone`, `sun, concrete`
"choose one of these three"	on-list 17/18, but stable across reordering 1/6
the identical 18 calls on-device, CPU	on-list 18/18, single-line 18/18, stable 1/6

Read the middle row again. Handed the actual vocabulary and told to pick a word from it, it got the answer
wrong every single time out of six, inventing phrases that were not on the list. Handed three choices, it was
almost perfect: 17 of 18 on-list. Then I shuffled the three and it changed its mind in five of six attempts, and the
one stable answer reproduced across two independent runtimes - which rules out one runtime's quantisation being the
whole story, and is the only evidence I have that it is not an artifact of my harness. One case is
worth describing: the same three candidate names in three different orders came back with three different winners.

That is the whole finding, and it flipped my design. The model is perfectly capable of phrasing something it is
handed. It is not capable of deciding. So the matcher owns every choice in this app, meaning every choice: which
band wins, which order the bands go in, which word the evening gets. The model writes one line of prose from a word
it did not pick, and it is not allowed to pick anything.

name: brassy
bands: #1E2438 #2A3350 #3C4A67 #5C6B82 #8A8375 #B08A5E #C2854A #3A322A
sun: 9 degrees
Write one line of four to eight words that contains the word brassy. Do not use any digit and do not add a
colour that is not listed.

The system prompt started as one sentence about what it may do, plus a ban on digits, brackets and newlines, and the
verifier that read the reply had the same shape; both halves turned out wrong and both were rewritten, the prompt into
an allowlist-shaped ask and the gate into the character set below. Then a verifier reads the reply. It rejects the line if the reply is not lowercase, contains a digit, is more than eight words or
fewer than four, or is missing the word it was given. On rejection, the card uses a template line, brassy light, measured from this sky, and a counter increments. The card still renders.

That was the design. Then I put the weights on a device and ran nineteen shots through the installed app, and both
halves of that paragraph turned out to be wrong about something.

The model's measured failure rate, which is the actual result

Nineteen shots, weights present, engine already warm. Seven of nineteen got a line that belonged on the card.
Every number below is read out of the JSON the app files, and all nineteen records are in the repo at
docs/data/wording-sample/ with their own recount script beside them, so this is arithmetic you can check rather
than a claim you have to trust.

They are two experiments, not one, because the verifier changed halfway through:

gate	shots	answered	silent	rejected	accepted	accepted wrongly
denylist (the first 13)	13	6	7	1	5	1
allowlist (the last 6)	6	6	0	3	3	0
all 19	19	12	7	4	8	1

Blending those rows is the dishonest move, and it is tempting. The one wrongly accepted line is a miss the shipped
gate cannot make, so it does not belong in the shipped gate's rate; and a six-shot row cannot carry a rejection
rate at all (3 of 6 rejected reads as "the new gate is worse" and means nothing). So: the denylist's
failure is a finding about denylists, and the allowlist's row is a finding that the sample is too small to publish
a rate from.

That last line - the **ash** sky glowed softly as dusk fell. - is the one I would not have found by reading the
code. The verifier banned #, <, {, (. It did
not ban *. The gate is a denylist, which means it has to be right every time, and a 1B model only has to be
creative once. The card rendered the asterisks, literally, under the name ash, and the record said everything was
fine because the line had passed. The denylist became an allowlist: a line may now contain lowercase letters, spaces,
and . , - '. An allowlist only has to be right about the punctuation I actually want, and the vocabulary needs
none beyond that. The cost is honest and I would rather publish it than hide it: any odd character now counts as a
rejection, so the rejection rate goes up.

The seven silences are the second one, and none of them were visible until the schema could name them. The app filed
all seven as wording_source: "none", which in my schema meant "there is no model on this device." There was a model
on the device. The field could not tell "never consulted" from "asked and got nothing," so any rate built on it was
uncomputable, and it was wrong in the flattering direction: a model that failed looked like a model that was absent.
There is a fourth value now, "no-answer", and that makes the two failures separable instead of one share of
evenings: did it answer (12 of 19) and was that answer valid (7 of the 12 answers pass today's gate - the
other five are the four the gate rejected plus the markdown line the old gate wrongly passed). One number about
latency, one about judgement. Both are recountable from the record files, and the script in
docs/data/wording-sample/PROVENANCE.md prints the 7.

Once the seven had their own value, their timestamps told the rest of the story. Every record carries its shutter
minute, and that alone is enough to see it: all seven silences sit in 23:24, 23:25 and 23:26, three minutes that hold
nine shots, of which two answered. The ten shots before and after that window all answered. Same build, same weights,
same model - the only variable is spacing. I have a sharper version of that sentence from the device's file mtimes at
second resolution, that the fast shots went 5-13 s after their neighbour and the answered ones at least 22 s. It is
not in the repo, because I deleted those records when I put the emulator back the way I found it, so count that half
as my measurement rather than something you can recount.

What is in the repo is docs/data/wording-sample/three-timed-shots.txt: three shots on the current build, fired
about a minute apart, each with the time its record first appeared and the time it was written last. The final write
lands between 12.4 s and 24.2 s after the shutter tap, which is 11.3 to 21.4 s after the record already existed. Two
of the three are model lines (24.2 s and 14.3 s after the tap); the 12.4 s one is a rejected line, so the fastest
write in the set was the template, not an answer. So a
shot taken twelve seconds later arrives while the previous call is still inside the engine. The seven no-answers are
not a model that refuses. They are one engine and two callers, and the reason the closing path now holds a guard
across the whole native call rather than across the timeout.

The honest half: I fired those shots in a burst because I was testing a code path, not living with an app. One
evening a day is the cadence the thing is for, and in this sample the ten shots that were not fired two-to-four to a
minute all answered. Both numbers are in the table above. The one I would have published without looking is the
flattering one.

Traps I checked before trusting any of it, because a bad sample is worse than no sample:

The seed. SamplerConfig(topK = 20, topP = 0.9, temperature = 0.7) sets no seed, so I was afraid consecutive replies might come back identical and my "19 shots" would really be one. Seven distinct lines out of eight accepted, one repeat (the evening sky held an ash-like glow. twice). Not pinned, but not independent either.
The scene. The emulator's back camera is a synthetic scene, so those nineteen shots are not nineteen skies. They sample the model's phrasing and the gate's behaviour, which is what this section is about. The bands did move between shots (14 distinct band sets out of 19, names ash 13 times and flint 6), but the sun altitude read -63°, -64° or -65° on every card, because there is no sun in the test scene. So: no claim about weather belongs here, and no claim about evenings either. The one real sky in this post is the phone's, at the top of the demo: one evening, sun 0 degrees, and no weather claim attached to it either.
What the gate cannot catch. Two accepted lines claim stars - the stars were bright against an ash-colored sky. and the stars shimmered beneath an ash-lit sky. - in a scene with no stars and a record that measures none. A verifier can only check form, because the only facts this pipeline has are eight colours and one altitude. That is the argument for the whole design: the colour on the card never comes from the model. If I had let the model choose anything at all, "stars" would have been a plausible-looking lie on a card that claims to be a measurement.

What this is not yet: a timing or a memory number from the phone I own. The phone has filed one real evening - the
three screens at the top of this post, 10 October, sun 0 degrees - but I have not pulled its record or read its
memory off the device, so every millisecond and megabyte below is still the emulator's: x86_64 with 3 GB of RAM
and, with the model resident, about 132 MB free and the low-memory killer active. And the emulator's set is
nineteen shots of one synthetic scene, not a season. Two timings, because they are different measurements and
averaging them would be a lie: the bare engine call
in the probe cost 1,080 / 1,247 / 3,502 ms (min / median / max), while inside the app the rewrite lands 11-21 s
after the record is filed. I have not split that difference up, so I am not going to explain it. Init 4,566 ms, peak
RSS 1,269 MB, both from the emulator.

How the colour is measured, since that is where the bugs were

The photo is resampled to 64 pixels wide with a hand-written bilinear filter, split into eight bands, and each band
is averaged per channel. Mean luminance uses the sRGB linearisation, so a value at or below 0.03928 divides by 12.92 and
anything above it goes through a power of 2.4. The winning band is the one with the largest gap between its biggest
and smallest channel; a tie goes to the brighter band.

Four details cost real time, and they are all in the code with comments:

Rounding. Python's built-in round is banker's rounding, so it sends .5 to the even neighbour. Kotlin's
Math.round sends it up. The Python port needed its own round_half_up, or the two implementations disagree at
every half-pixel boundary and the equivalence test fails for a reason neither algorithm caused.

A clamp that only one fixture can see. The resample height is derived from the source aspect ratio. When the
source is narrower than 64 pixels, the derived height exceeds the number of rows the photo actually has, and the
bilinear pass cheerfully interpolates rows that do not exist. Clamped, and one fixture is 32x6 so that no future
change to that line can pass silently. Every other fixture is at least 64 pixels wide, where the clamp is the
identity. That is why the odd-sized fixture exists.

Precision across the border. One side was doing channel arithmetic in 32-bit floats and the other in 64-bit.
That disagreement showed up as 13,161 differing (row, band-pair, channel) outcomes when the blend formula was
brute-forced instead of rendered - the kind of thing that looks like a rendering bug until you notice the two sides
round exact .5 ties opposite ways (row 57, the pair 0 and 47: one language says 0, the other says 1). That sweep
was a throwaway probe and its script is not in this repository, so this is the one number in the post whose derivation
script you cannot even look at - the emulator timings above are equally yours to take on trust. What you can check is the fix: fieldBlend returns a Double, and no cast quantises it on the way to a
pixel. Canonical precision is now 64-bit on both sides, and the Python port is told never to touch
numpy.float32.

Name ties. Two vocabulary words can sit at the same distance from a measured colour. The earlier entry in the
vocabulary wins, and a test asserts that order rather than leaving it to whatever a map iteration does on some
machine later.

The part anyone can try in twenty seconds

Nobody has to install an Android app, and nobody has to download a gigabyte of weights.

python tools/python/skycard.py photo.jpg -o card.png --print-json
python tools/python/skycard.py --from-record docs/data/wording-sample/2026-10-10-attempt-5.json -o card.png

The first line prints the eight bands, which band won, and the name, then writes a card. The second redraws the card
the app filed from the JSON record it wrote, which is how you can check that the picture says what the measurement
says rather than what I say about it. Timed as whole processes on this box,
two runs each: 0.27 s and 0.33 s for a 128x96 fixture, 4.7 s and 6.1 s for a 4032x3024 JPEG at 2 MB (not committed - that second file
is a synthetic gradient with noise in it at the resolution a common phone shoots at, not a photograph - the one real
sky in this repo is the phone's, photographed for the demo above), and the spread between its two runs is why I give
both numbers instead of a confident
one. The band arithmetic is the same arithmetic as the Kotlin, line for line, and a test on both sides asserts
against the same five PNG fixtures, so agreement is transitive and neither language can drift without a failure.
89 Kotlin core tests, 49 app tests, 20 Python tests.

The costs, stated before you discover them

The model file is 584,417,280 bytes and it is gated: you accept Gemma's terms in your own browser to download it. I am not allowed to commit it, and GitHub's 100 MB per-file limit means I could not.
Total on-disk cost is about 1.02 GiB, not 557 MiB, because the engine writes a 508,539,776-byte (485 MiB) XNNPack cache beside the model. Both figures came from stat on the emulator's filesystem, not estimated - but they are emulator figures, and I have not measured a phone yet, so an ARM cache of a different size is possible.
Model init measured 4,566 ms and peak RSS during a call 1,269 MB, both on the emulator; the timing a user actually feels is in the failure-rate section above - the line lands 11-21 s after the record is filed - and every one of those numbers is x86_64, not ARM. The phone I actually use is the missing measurement, and I would rather name that gap than round it away: it needs getprop and /proc/meminfo read off the device, not my memory of this box. The 10 s give-up marker belongs re-checked there too, because on the emulator it turned out to bound nothing: withTimeoutOrNull cannot interrupt a blocking native call, and a call that ran 10.5 s still delivered its line past the marker.
The debug APK at this commit is 61,231,992 bytes (58.4 MiB) with zero model weights in it. That is the inference library's native code, compiled for four ABIs. The build before the last round of fixes was 61,350,388 bytes, and two builds of one tree half an hour apart came out 62 bytes apart, so read the figure as "about 58.4 MiB" rather than as a checksum.
Two variable fonts are bundled, 554 KB. Android cannot address a weight axis through the API people expect (fontFeatureSettings is for OpenType features, and wght is not one), so the variation is pinned in a <font-family> XML and loaded through ResourcesCompat, because Resources.getFont throws on a family file.
The app asks for one runtime permission, CAMERA, and a test asserts the manifest has no INTERNET. Read the next sentence before you trust that bullet: the test opens src/main/AndroidManifest.xml, the file I wrote, not the merged manifest the build actually installs, so a dependency that smuggled INTERNET in through manifest merging would pass the test and break the promise. I did check the merged output by hand, debug and release: CAMERA, plus the local-receiver permission androidx generates for itself, and no INTERNET in either - but that check is a command you have to re-run after assembleDebug, not a test that fails for you. grep uses-permission -A1 app/build/intermediates/merged_manifests/debug/*/AndroidManifest.xml. Knowing the guarantee is weaker than the test makes it look is the point; a test can hide exactly that from its own author.

What this app does not do

It does not measure air quality, pollution, UV, temperature, or your mood. It does not know if you left the
balcony. It has no reminders, no streak, no cloud sync, and no account. It cannot tell you the sky
looked better yesterday, because yesterday's photo was taken from a different angle of the same view and the app is
not that dishonest.

It does have a share link, and I would rather overstate that than let a reader find it later: it is an
ACTION_SEND of the card PNG through a FileProvider, with a per-URI read-only grant, and the runtime permission
set is still exactly {CAMERA}. Nothing leaves the phone by itself, which the manifest test is the guarantee of -
not my intention.

There is one real evening in this repo now: 10 October, a balcony, four minutes before a sunset the phone computed
for 17:49, sun 0 degrees, name thin, filed on a Pixel 7 and photographed at the top of this post. Everything else -
every record behind the measurements above, and the five PNGs under fixtures/, which are drawn, not photographed -
is the emulator's. The rest of the stack is still empty, and it will keep showing that: miss an evening and the hole
stays visible. That is the part of the design that survives my own laziness.

One thing I did learn, and it is the reason the model ended up with the smallest job in the app: I spent days
treating the 1/6 as a bug in my own harness. It reproduced across two independent runtimes, which is what the spec
now says plainly, that this is a model limit and not a quantisation artifact. At some point I stopped debugging and
accepted that the model is genuinely that unreliable at picking. Knowing that is worth more than knowing why my
code was right, and the only way I found it was to measure before I built.

Why open innovation matters here

Three things about this project only work because the pieces are open, and the third one is uncomfortable.

The model is open-weight - Gemma 3 1B IT, q4, 584,417,280 bytes, run through LiteRT-LM 0.16.1 on the CPU backend -
and that is not a licensing nicety. It is why the app can have no INTERNET permission at all. A hosted model puts
a network permission in the manifest, and then "nothing leaves the phone" becomes a promise about my intentions.
Open weights turned a privacy claim into a fact about a file, which is the kind of claim a test can hold.

The arithmetic is open, so the central claim of this post is checkable rather than believable. The band sampler
exists twice - Kotlin on the phone, Python in tools/python/skycard.py - and a test on each side asserts against
the same five PNG fixtures, so neither language can drift without a failure. The nineteen records behind the model's
failure rate are JSON files in the repo with a recount script beside them. The finding that a 1B model changed its
mind in five of six reorderings of the same three options is a claim about weights you can download and run
yourself. If any of that were closed, you would have to take my word for the number that decided the architecture -
and that number is the only reason the architecture looks the way it does.

The uncomfortable one: openness is also why I could afford to be pessimistic. Those probe runs cost nothing but
time, because nobody was metering the calls. Eighteen calls to discover that a model picks badly is a free
experiment on open weights and an invoice on a hosted API, and an expensive experiment is one you are tempted to
skip and assume your way past instead. Open weights bought the measurement that demoted the model to the smallest
job in the app. I do not think I would have paid to be told I was wrong.

Code, and how it was built

The repository carries the spec it was built from and the plan that decomposed it, both committed, both written
before the code they describe: docs/superpowers/specs/2026-10-07-evenlight-design.md and
docs/superpowers/plans/2026-10-08-evenlight.md. Both are wrong in places the implementation later corrected, and
section 12 of the spec is a list of claims from an earlier, discarded design - two of which were simply false and
are named as such. This was built with AI agents over four days. Leaving the arguments in the repo is the only
honest way to show that; a summary of the process would be a story about it instead.

Counts at the commit this post describes: 89 tests in :core, 49 in :app, 20 in Python, no skips and no
failures. The debug APK is 61,231,992 bytes. The weights are not committed - GitHub's hard per-file limit is
100 MB and the file is 584,417,280 bytes, so models/GET_MODEL.md ships the URL, filename, byte size and SHA-256
instead, and *.litertlm is gitignored so the omission cannot be an accident.

Prize categories

Overall.

Best Use of Gemma. Gemma 3 1B IT, q4, on-device through LiteRT-LM 0.16.1, CPU backend, no network. I want to be
exact about the size of the role, because the honest version is smaller than the category name suggests: the model
writes one line of prose per card and chooses nothing. Every decision - which band wins, what order the eight go in,
which of 35 words the evening gets - belongs to a deterministic matcher, because I measured the model failing at
exactly that job before I wrote the app. If "best use" means the largest role for the model, this is not that entry.
If it means the most measured one, the eighteen probe calls and nineteen device shots are in the sections above, and
the records are in the repo.

No other partner category. Nothing here is hosted, and I would rather leave a category empty than stretch a claim
to fill it.

HopeHunter: a local model that reads opportunity posts so my friend Zohaib doesn't have to

Fahad Irshad — Sat, 03 Oct 2026 22:38:26 +0000

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

What I Built

I built this for Zohaib, who has sent me 400 links over the years. "You should apply for this." Scholarships, hackathons, junior roles, fellowships, grants. Half of them expired the week they arrived. The rest needed a page-by-page read of the eligibility rules before you could tell whether they were even for someone like me.

So I asked him a question back: you're always asking where I find these — what if there were a tool that searched and just handed you the curated list? His answer was the entire brief: "Damn, that would be great." He hasn't run it yet. That's the real state of things: a working tool on my laptop, waiting for the person it was built for.

HopeHunter scans opportunity feeds, reads a posting with a small language model running on my laptop, pulls out the deadline, tells him honestly what fits and what is missing, and drafts the message he'd send. His work history never leaves the machine.

Demo

The whole task on one card, fifteen seconds: scroll to a tracked hackathon, ask how the person fits, ask for the message. The background on screen is one I wrote for this recording, not my friend's.

There is no deployed link, and that is the point: it runs on the person's own laptop, on their own GPU. Two commands:

ollama pull gemma3:4b
python app.py          # then open http://127.0.0.1:8000

Python 3.9+, nothing to install, no account, no key. 103 tests run offline in under half a second.

Code

Repo: github.com/Burry071/hopehunter. One Python file that uses nothing but the standard library, and one HTML file. MIT. The full write-up, with all eight mistakes spelled out, is ARTICLE.md in the repo.

Burry071 / hopehunter

Local-first opportunity finder: reads feeds you trust, keeps only real openings, and grounds every deadline in the page's own words. One stdlib file, one HTML file.

HopeHunter

A local-first opportunity finder, built for one friend who gets sent 400 links a year. It reads the feeds of platforms that announce things you can apply to and keeps only the posts that really name one. Ask about a single opening and it reads the page, checks the deadline against the page's own words, tells you honestly how you fit, and drafts the message you'd send.

The fit check and the draft on one card, fifteen seconds:

Your background text and all AI processing stay on your machine: the model runs locally through Ollama, and the only outgoing requests are reads of the public feeds and pages you list. Nothing you write about yourself is sent anywhere.

What it does

Finds: scans the RSS/Atom feeds and JSON APIs you list, and the local model keeps only the posts that really announce something you can apply to, with…

View on GitHub

How I Built It

The model is Gemma 3 4B, run locally through Ollama, and I ask it for four separate things: screen a post, extract a page, compare that page against the person's background, draft the message. Everything below came from watching it do those four things.

Start with the machine: an i5-8400H with a Quadro P2000, 4 GB of VRAM, Pascal architecture. Every request came back HTTP 500 with the provided PTX was compiled with an unsupported toolchain, which is an upstream Ollama bug with these cards and not mine. OLLAMA_VULKAN=1 gets around it, and it runs about 11 tokens per second with 1.9 of 3.8 GB resident on the card. Slow, but it answers.

Eight times the app looked fine and was wrong

It printed a deadline the page never showed. A small model will invent a plausible date, and on a tool about deadlines that one error costs a person their only real chance. So the app does not trust the field. It looks for that exact date in the page text, inside a sentence containing deadline-ish words, and checks that the model's own quoted sentence names it. If either fails, the card says not checked. Dates written like 03/11/2026 are never trusted at all, because I cannot tell whether that is March or November.

The version I nearly shipped threw away a real date instead. The Loeb Fellowship page prints January 5, 2027 under a heading that says Application Deadlines. The model quoted those exact words and left its ISO field empty, so the app gave up with the model gave no clean date to check - an excuse about a date it could have looked up. Month-name dates get checked now. A phrase with no year in it, like end of November, still does not: turning that into a day would mean inventing the one thing the app exists to verify.

A fit score that meant nothing. I gave one hackathon post to two backgrounds: one a perfect fit, one with no coding experience at all and no time. Both scored 1 out of 100. Same number, same sentence. The coach did the same thing, 0/100 for both.

Ask a 4-billion-parameter model for a number between 0 and 100 and that is what you get. So there is no score anywhere now, and the scan stopped looking at who you are: finding openings and judging fit are two different questions, and only the second one needs a person. The fit check and the draft still ask for your background and answer in words. On those same two backgrounds it writes things like your open source projects make you overqualified for a hackathon aimed at beginners - a judgement you can disagree with, which is more than a bare 1/100 ever gave me.

Ten lines that all said "Couldn't read". I pasted a longer list of sites into the feeds box - GitHub, Devfolio, Unstop, HackerEarth - and hit scan. Ten lines came back, every one starting Couldn't read, and under them a feed the app had filled from the sources that worked. One message, two different problems. GitHub answered in half a second with a page full of HTML; the app tried to parse it as XML, failed, and called the site unreadable. Nothing was unreadable. I had pasted homepages into a box that wants feeds, and the message blamed the network instead of me.

Now the app asks the page. When a URL is not a feed it reads that page's <head> for the feed it advertises, and if the page says nothing it tries /feed/ and /rss.xml. When one of those works it rewrites the saved source to the feed address, so the next scan goes straight there. Two of my ten upgraded themselves on the spot, and the other eight finally said what was wrong: https://github.com is a web page with no feed on it. Add the site's feed or API link, or paste one opening into "Add one yourself". Devpost's homepage genuinely has no feed but its hackathon API does, and the old message made those two look identical.

The other five, briefly:

It renamed my fields. I asked in prose for title, organization, deadline and got name, with the deadline nested inside an object. A JSON Schema fixed the shape - but a live scan still came back with Accelerator and essay award in a field whose enum allows exactly seven words, so the last check is mine.
It gave me advice that was wrong about my own machine. Every request was dying on that CUDA crash and the app told me to run ollama pull gemma3:4b. Already installed. It keeps and shows the server's own words now.
I fed it blog posts and blamed the model. Three of my default feeds were DEV tag feeds, which list posts about hackathons rather than hackathons. One scan kept six items, all six from DEV, and none of them something you could apply to. Deleting those feeds did more for the output than anything else I did that week.
Adding a site changed nothing. The queue read feeds top-down and stopped after ten posts, so anything below the first two was never asked a question - and every scan still returned ten items, so it looked fine. Round-robin fixed it: the first pass after the change kept seven openings from six different sites.
Telling the model to stop was not making it stop. I put "Do not write about the post" in the prompt, and four of nine cards still read "Post announces the HACK PRADESH - RVIT Hackathon for participants." So the app cuts that clause itself: a container word plus its reporting verb at the start of a line, deleted.

A schema is a request. A prompt sentence is a request. The only thing I can rely on is the check the app runs itself, after the model has finished being persuasive.

What I measured instead of guessing

I assumed long pages were the problem and started writing chunking code. Then I benchmarked it: of the 36 seconds it takes to read one page, the model spends about 2 seconds reading and 18 writing. Prefill was never the bottleneck.

So the speed work went to the feeds, which are network waits. With five of them that went from 31.5 seconds to 4.7. Then I kept adding feeds until there were eleven and re-measured: 23 to 43 seconds in parallel against 27 to 29 one after another - no win, sometimes slower, because one feed is a 2.2 MB job listing that takes 14 seconds by itself and ten other threads on one wire do not make that shorter. Asking for shorter replies took one answer from 201 tokens to 163, and raising the read cap gave back 89 jobs, because the cap had been silently truncating that same 2.2 MB feed since the day I added it.

The GIF above was recorded against a scripted stand-in that answers with the words a real Gemma run already produced for that card, so I did not have to wait on an 11-token GPU to film it. It lives in dev/ with the fixtures it reads.

What it still cannot do

About a minute per scan of ten posts, because it is one 4 GB GPU from 2017.
The filter misses things, and the misses are not random: a press release about an organisation came through tagged internship, and a roundup of seven scholarships became one.
Only about 7,000 characters of a page reach the model, taken from the top and the bottom.
A page behind a login has to be pasted in as text, and it cannot tell you whether you got the thing.

Why Does Open Innovation Matter?

A CV is the most personal document most people own. Sending it to an API means sending it to a company whose terms you did not read, to a server you will never see, along with your name and email address. For a tool whose entire job is "read my friend's history and judge it", that is the wrong shape. An open-weight model on the laptop keeps the one sensitive input in the one place it belongs.

Three more things came out of that choice: a scan costs nothing (about ten model calls, and on a hosted API I would have been paying to re-read blog posts the app throws away); it works offline except for fetching the pages you asked for; and I can change the model, same app, different OLLAMA_MODEL, which mattered a lot on a 2017 GPU. The closed version was not available to me at any price - here the model is a file on disk that I can point at Vulkan when its CUDA backend crashes on a nine-year-old card.

My Agent Session

Not uploaded. The transcript of building this has my friend's real CV in it, and the point of the project is that those words stay on one laptop. What the agent did, and the eight places its first answer was wrong, is in the section above; the tooling it wrote for itself is in dev/.

Prize Categories

Best Use of Gemma. Gemma 3 4B is the model the app is built around: it screens the feeds, reads the pages, writes the fit check and the draft. There is no other AI in the loop, and the whole design is what a 4-billion-parameter model on a 4 GB card from 2017 can and cannot be trusted with.

What I got out of it

First Hacktoberfest, and I went in wanting experience rather than a prize. What I got is a rule I did not have before: a model's confidence is not evidence. Every one of those eight failures looked like success while I was watching it, and the only thing that caught them was checking one specific claim against the source it came from.

And Zohaib has a tool that reads his feeds on a laptop sitting in the same room he does, with nothing about him sent anywhere.