DEV Community: Anand B

logsloth reads the failing CI log so I don't have to

Anand B — Fri, 23 Oct 2026 05:34:58 +0000

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

What I Built

I'm Anand Biju. I built logsloth, a small command line tool for the most boring part of my week: a red CI run.

The red X is never the bad part. The bad part is opening the log. You get a few hundred lines of checkout, cache restore, dependency install and cleanup, and somewhere in the middle is the one line that matters. The last line, Process completed with exit code 1, tells you nothing. So you scroll, you search for "error", you hit forty false matches, and ten minutes later you find out a package was missing.

logsloth does that scrolling. Give it a log file, pipe a command into it, or point it at a failed GitHub Actions run:

logsloth ci.log
npm test 2>&1 | logsloth
logsloth --gh https://github.com/owner/repo/actions/runs/1234567890

It prints a short card with four lines. CULPRIT is the real error line. WHERE is the file and line. WHY is one sentence on what went wrong. FIX is the next thing to do. Below that are the handful of log lines it used as evidence, with their original line numbers, so you can check it instead of trusting it. --md prints the same thing as Markdown for a PR comment, and --json is there for scripts.

Demo

These are all real runs on my machine. The first three use real logs from public projects, pulled with gh run view --log-failed.

A ruff-format pre-commit failure in psf/requests. The log is 284 lines and the run ends with about forty lines of git cleanup after the error. logsloth skips that and lands on the hook that failed:

A mypy error in pallets/flask. The error message wraps over three lines, and logsloth joins them back together:

A failing vitest assertion in vitejs/vite. The log is 653 lines. Here Gemma got distracted by a pnpm store prune line in the excerpt and suggested running it. The validator threw that out, and the card shows the built-in hint instead. The footer says so.

And one of the bundled examples, a pytest run where httpx was never installed:

Code

Anandb71 / logsloth

Reads a failing CI log so you don't have to. Code finds the evidence, a local Gemma explains it.

logsloth

A small CLI that reads a long failing CI, test, or build log and tells you the one thing that broke.

Code finds the evidence and states the facts. A local open-weight model (gemma3:1b via Ollama) only explains why it failed and suggests a fix. The model never sees the whole log.

Why

When CI goes red you get a few hundred lines of setup, cache restores, and cleanup, with the real error somewhere in the middle. Finding it is boring and you do it many times a week. logsloth does the scrolling for you and runs entirely on your machine, so private logs never leave it.

Install

pip install -e .

You also need Ollama and the default model:

ollama pull gemma3:1b

OLLAMA_HOST defaults to http://127.0.0.1:11434.

Usage

# a log file
logsloth path/to/ci.log
# piped from a local command
npm test 2>&1 | logsloth

# a failed

…

View on GitHub

ollama pull gemma3:1b
python3 -m venv .venv && . .venv/bin/activate
pip install -e .
logsloth examples/pytest_httpx.log

python -m pytest -q runs 47 tests. They never call the model or the network.

How I Built It

The rule I followed: code finds the facts, the model only explains them.

My first version let Gemma 3 1B write everything. It went badly. On a cargo error it wrote the literal text "one sentence: what broke" as the culprit. On a jest log it pointed at the test file instead of the file that was missing the import. On the real flask and requests logs it blamed git config and safe.directory, because the cleanup lines at the end of a GitHub log look like errors. That third one is why I stopped testing only on my own example logs.

So the work is split.

Triage is plain Python. It strips ANSI colours, including the literal ^[[36m that gh run view --log-failed leaves in, plus the timestamps and the job<TAB>step prefix on every line. It folds repeated lines and then scores lines against known failure patterns: Python tracebacks and pytest E lines, Cannot find module, rust error[E...] with its --> location, mypy and ruff style path:line: error:, pre-commit hooks that print Failed, pip's No matching distribution, docker's failed to solve, and a few more. The final exit code 1 line can never be the main finding if anything else matched. CULPRIT and WHERE come straight from this step, so they are always lines that really are in the log.

Gemma only writes why and fix. It gets a short excerpt, between 6 and 15 lines in the runs above, not the whole log. The prompt only includes the rules that apply to this failure. When I listed every rule at once, the 1B model copied them, and suggested "install httpx using pip or npm".

Every answer gets checked. Why and fix are validated separately. They have to be non-empty and short. They can't repeat the prompt or the example. They can't tell a git story when the failure isn't about git. They have to name the real package, symbol or hook. If the fix says to install something, that name has to appear in the log. That check caught Gemma telling me to "include lodoc" when the log said lodash. A field that fails is replaced by a built-in hint for that error type, and the footer says which parts came from the model and which from the hint, for example why from gemma3:1b, fix from hint.

In my final runs over the seven logs, Gemma's why was kept in six and its fix in three. On the vite log both fields fell back to hints. On this shared, CPU-only box a call took between 1.9 and 34 seconds, and most were around 10.

It is standard-library Python. Ollama serves the model over HTTP on localhost. I built it this week with the Cursor CLI agent doing a lot of the typing, while I wrote the spec, ran it against real logs, and kept tightening the validator.

Why Does Open Innovation Matter?

CI logs are full of things you shouldn't paste into a hosted chatbot: internal hostnames, paths, package names from a private registry, sometimes a token someone forgot to mask. With an open-weight model on my own machine, the log stays here. Nothing gets uploaded, there's no API key to manage, and running it a hundred times a day costs nothing.

It also changed how I built it. A 1B model running locally is fast and cheap enough to call on every failure, but it is wrong often enough that I had to treat its output as a suggestion to check, not an answer. Because I control the prompt, the temperature, the retry and the validation, I could build that checking around it. Swapping in a different model is one flag, --model.

The Lazy Payoff

Before: open the run, expand the failed step, scroll past setup, search for "error", skip the false matches, find the real line, then work out which file it means.

After: logsloth --gh <run url>. I read four lines, then check the evidence lines if I don't believe them. On the 653-line vite log the card had the failing spec file and line, and the expected and received values, in the evidence block. I didn't have to open the log.

Prize Categories

Best Use of Gemma. logsloth runs Gemma 3 1B (gemma3:1b) locally through Ollama. It writes the why and fix, and the validator decides which of its answers to keep.

Portion Cut: paste your exam portion, read only the pages that matter (EmbeddingGemma, in the browser)

Anand B — Tue, 20 Oct 2026 04:13:22 +0000

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

What I Built

Every semester goes the same way. The professor posts the exam portion as a block of syllabus text, the textbook is a 400-page PDF, and the night before the exam I am flipping between the two trying to work out which chapters actually count. The book never uses the syllabus's wording, half the topics are spread across three chapters, and at least one line on the portion is not in the book at all. You only find that out after twenty minutes of searching.

Portion Cut does that matching for you. Paste the portion, drop in the textbook PDF, and it tells you which pages to read, grouped by syllabus line, with the section names next to each range. It then builds a smaller PDF with only those pages. When a syllabus line probably is not covered by the book, it says so plainly instead of guessing, so you know to look somewhere else.

It is a tool for studying less, which felt right for Sloth Day. It does not summarise the book or write notes for you. It just stops you reading pages you did not need to read.

Everything runs in the browser tab. The PDF is never uploaded, there is no backend, and there is no API key.

Demo

Live: https://anandb71.github.io/portion-cut/

Add ?demo=1 to try it without the 220 MB model download. Demo mode uses page vectors for a sample book that were computed by the same model with the same settings. It is labelled on the page and cannot build the cut PDF, because there is no PDF loaded.

The real run, with the model doing the work in the browser on the full 397-page book:

On that run, Portion Cut said to read 99 of 397 pages, found 7 of the 9 syllabus lines, and flagged the other two (sets and regular expressions) as probably not in the book. The book's table of contents confirms neither is covered. The raw log is in screenshots/browser-real-1.json.

Code

Anandb71 / portion-cut

Paste your exam portion, drop the textbook PDF, read only the pages that matter. EmbeddingGemma runs in the browser.

Portion Cut

Paste your exam portion, drop the textbook PDF, and Portion Cut tells you which pages to read. It also builds a smaller PDF with only those pages, and it says plainly when a syllabus line is probably not in the book at all.

Everything runs in the browser tab. The PDF is never uploaded. There is no backend and no API key.

Live: https://anandb71.github.io/portion-cut/ (add ?demo=1 to try it without downloading the model)

Why an open-weight model, on the device

The matching is done by EmbeddingGemma 300M, Google's open-weight embedding model, using the 4-bit ONNX build from onnx-community/embeddinggemma-300m-ONNX and Transformers.js on WebAssembly.

The textbook stays with you. Course PDFs are often shared files you should not be pushing to someone else's server. Here the text is pulled out with pdf.js in the tab, embedded in a Web Worker, and stored only in this browser's IndexedDB.
No per-page…

View on GitHub

How I Built It

The core is EmbeddingGemma 300M, Google's open-weight embedding model, using the 4-bit ONNX build from onnx-community/embeddinggemma-300m-ONNX and run with Transformers.js on WebAssembly inside a Web Worker.

The pipeline is short:

Read. pdf.js pulls the text out of every page. Blank pages, the table of contents and the index are skipped with simple rules. PDF bookmarks become section page ranges.
Embed. Each page goes through EmbeddingGemma with its document prompt, truncated to 512 tokens and, using the model's Matryoshka training, cut down to 256 dimensions so the per-book cache stays small. This is the slow part. The vectors are saved in IndexedDB, so the second portion for the same book is instant.
Match. Each syllabus line is embedded with the query prompt. Comma lists are split into facets, so List: slicing, comprehensions also searches for List slicing and List comprehensions separately. Otherwise one strong facet would hide the others.
Decide. This part is plain code, not the model. A line is reported as "probably not in this book" when its best page does not stand out from the rest of the book, meaning the best score is less than 3.35 standard deviations above the average page. Otherwise it keeps the pages close to its best score, plus the best pages for each facet, and snaps them to whole bookmarked sections, because nobody reads page 137 on its own.
Cut. pdf-lib assembles the smaller PDF in the tab.

Vite, TypeScript and Vitest. The decision logic in src/match.ts has unit tests, and GitHub Actions runs the tests and deploys to Pages on every push.

Did it actually work?

I wanted a number I could defend, so I measured it on one free textbook, OpenStax's Introduction to Python Programming (397 pages), against two portions copied word for word from a public university Python syllabus. I labelled which sections each line needed by hand, from the book's contents, before running the model. I tuned the settings on the first portion only and kept the second for a held-out check.

	Modules 3â€“5 (tuning)	Modules 6â€“7 (held out)
Pages to read	99 of 397	75 of 397
Needed sections found	18 of 21	12 of 16
Kept pages that are on topic	95%	89%
Missing lines flagged	2 of 2	1 of 1
Lines wrongly flagged as missing	0	0

For comparison, a keyword (BM25) baseline with the same page rules, tuned the same way, found 8 of the 16 needed sections on the held-out portion and did not flag any of the missing lines. Keyword search falls apart exactly where the syllabus and the book use different words, which is most of the time.

To be honest about the limits: this is one book and two portions. The "not in this book" threshold was chosen after looking at scores from both, so those three catches are a fit, not a test. It also misses some sections; 12 of 16 on the held-out portion means you should still glance at the contents page.

Why Does Open Innovation Matter?

The book stays on your machine. Course PDFs are often files a classmate shared, or a scan the department put on a drive. Uploading them to someone else's API is not great. Here the text is extracted, embedded and cached without leaving the tab. The network panel shows nothing going out after the model download.

It costs nothing to run, including at 1 AM. A 400-page book is 400 embedding calls, and every new textbook is another 400. With the weights in the browser that costs me nothing to host and the student nothing to use. A static GitHub Pages site is the whole deployment.

It works offline after the first visit. The model is cached by the browser and a small service worker keeps the app shell, so it still works on hostel Wi-Fi or with no connection at all.

Open weights let me fix things myself. The default 4-bit model file used an operator the WebAssembly runtime does not support, so it would not load. Because the weights are open, I switched to the model_no_gather_q4 variant in the same repository and carried on. With a closed endpoint I would have been waiting on someone else. The same goes for Matryoshka truncation: I could choose 256 dimensions because I control how the vectors are stored.

It is slow, and that is fine. The first read of the full book took about 15 minutes on CPU with four WebAssembly threads. A hosted API would be faster. But it is a one-time cost per book, it runs while you make tea, and every portion after that is instant. Slow and steady, as promised.

The Lazy Payoff

On the sample portion, the reading list covered 99 of 397 pages, so about three quarters of the book could be skipped, and two syllabus lines were flagged before I wasted time hunting for them. On the held-out portion it was 75 pages. I have only tried it on this sample book and syllabus so far.

Prize Categories

Best Use of Gemma: EmbeddingGemma 300M does all of the matching, on the device, in the browser.

KadaCard: WhatsApp listings from a product photo, scored offline with open-weight CLIP

Anand B — Tue, 13 Oct 2026 04:16:42 +0000

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

What I Built

KadaCard (കട means shop) is a small browser tool for Kerala micro-sellers. You photograph what you sell — banana chips, pickle, spices, handloom, bakery — and an open-weight CLIP model running on your phone picks a niche. The app then fills a bilingual English and Malayalam WhatsApp listing template. You type the price and WhatsApp number, tap copy, and paste into WhatsApp Business.

It is aimed at the people I actually see selling from home in Kochi: a neighbour with a jar of mango pickle, someone packing banana chips for Onam orders, a handloom stall that still writes every Instagram caption by hand. They do not need another SaaS account. They need something that works on a phone, keeps product photos private, and costs nothing to run.

There is no backend. Photos are scored in the tab and discarded. Only the listing text you choose to save stays in localStorage.

I have not put this in front of a paying user yet. That is next, once the write-up is out.

Demo

Live: https://anandb71.github.io/kadacard/

Add ?demo=1 to try the flow without downloading the model. Demo mode is labeled on the page and uses a sample match.

Real model runs on the same fixtures. A mango pickle jar is classified as pickles at 99%. A banana chips pack is classified as banana chips at 100%. A handloom textile is classified as handloom at 100%.

Code

Anandb71 / kadacard

KadaCard — offline WhatsApp product listings for Kerala sellers, powered by on-device open-weight CLIP

KadaCard

KadaCard (കട, a shop) helps a Kerala micro-seller turn a product photo into a WhatsApp listing. Homemade snacks, pickles, spices, coconut products, handloom, bakery, produce, crafts, and oils each have a short bilingual template. The seller types the price and phone number, then copies the text. There is no backend.

Why open-weight and on-device

The category check is Xenova/clip-vit-base-patch32, an ONNX build of CLIP, loaded with Transformers.js. The weights are open, so the check does not depend on a proprietary vision API, an account, or a server that can see the product photo.

The model is downloaded once and cached in the browser. A small service worker then keeps the app shell available, so later visits can open offline. The first visit still needs a connection to fetch the model.

Privacy

Photos are read locally, resized in memory, scored on the device, and discarded. They are not…

View on GitHub

How I Built It

Model: Xenova/clip-vit-base-patch32, an ONNX export of open-weight CLIP, run with transformers.js (@huggingface/transformers) on WebAssembly in the browser.
Classification: zero-shot image classification against nine seller niches (banana chips, pickles, spices, coconut, handloom, bakery, produce, crafts, beauty). The manual “other” niche is left for the seller to pick; it is not a CLIP label, so a broad “grocery pack” prompt cannot steal snack matches. A match is accepted when the top niche scores at least 0.22, or when the seller’s chosen category is the top label at 0.18 or above. The UI always shows the top three so you can override.
Listing copy: templates, not generated text. Each niche has an English title pattern, a Malayalam blurb, a short detail line, and hashtags. CLIP only picks the niche. Price and phone stay blank until the seller fills them.
Offline: the model downloads once and is cached. A small service worker caches the app shell.
Stack: Vite, TypeScript, Vitest. 41 unit tests cover the catalog, classify decision, listing builder, storage, and export. npm run build is clean. GitHub Actions deploys to Pages.
Proof: I ran the real model both in Node (transformers.js on the fixtures) and in headless Chrome against the built site. First browser check took about 34 seconds including the download; later checks were a couple of seconds.

Why open innovation matters here

The photos that matter to a small seller are inventory, kitchen counters, and half-finished batches. Those should not leave the phone.

Privacy. A closed vision API would upload every product shot. Here the image is resized in memory, scored on the device, and thrown away. History stores listing text only.
Cost. WhatsApp sellers already live on thin margins. An open-weight model on static hosting means there is no per-image bill and no server for me to keep alive. That is what makes a free or ₹99 tool realistic.
Offline and bad signal. Many home kitchens and weekly markets have weak data. Cached weights are the only reason the checker can keep working after the first visit.
Swap and tune. The niche prompts and templates are plain code. If someone wants a fish-fry card or a card in Tamil, they can fork it and change the list without waiting on an API vendor.

I build Arbor (getarbor.dev), a PR-native security tool that stays on your side of the network. The same instinct applies here: keep the sensitive bit local, keep the open bits readable.

What's next

Show it to one Kochi seller and watch them list five products. I will only claim a first user when that actually happens.
Let sellers save their own WhatsApp number and default “Made in …” town once.
Add a couple more niches (seafood fry, flower garlands) if people ask.
Optional: a tiny fine-tune or prompt pack for Kerala snack packaging, still on-device.

Prize Categories

None. This is an entry for the overall prize.

Grass Bingo: a daily nature card your phone checks offline, with an open-weight model

Anand B — Sat, 10 Oct 2026 06:44:32 +0000

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

What I Built

Grass Bingo is a daily 4x4 bingo card of small things to find outside: a pinecone, a red leaf, moss, a snail, a cloud shaped like something. You tap a square, take a photo, and an open-weight CLIP model running in your browser checks whether the photo matches. Get four in a row and you have a bingo.

It is for anyone who wants a small reason to go for a walk. Kids, parents, someone on a lunch break, me after a long day of reviewing pull requests. Everyone gets the same card on the same day (it is seeded by the date), so you can compare with a friend without signing up for anything.

I wanted the screen to be the shortest part. You open the card, look at it once, put the phone away, and take it out again only when you find something. There is no feed or account, and nothing to scroll. A small timer counts how long you've been out, and at the end you can share a text-only summary.

Demo

Live: https://anandb71.github.io/grass-bingo/

Add ?demo=1 to try it at your desk. Demo mode accepts any photo and skips the model download.

Real model runs, same pinecone photo. Uploading it to "Snail" gets rejected. Uploading it to "Pinecone" is accepted:

Code

Anandb71 / grass-bingo

Daily nature bingo for getting outside. Photos are checked on your phone by an open-weight CLIP model (transformers.js). Nothing is uploaded.

Grass Bingo

A daily 4×4 nature bingo card that gets you outside. Tap a square, photograph what you found, and an open-weight CLIP model running in the browser decides whether the photo matches. There is no backend.

Why open-weight and on-device

The checker is Xenova/clip-vit-base-patch32, an ONNX build of CLIP, loaded with Transformers.js. The weights are open, so the check does not depend on a proprietary vision API, an account, or a server that can see your pictures.

The model is downloaded once and cached in the browser. A small service worker then keeps the app shell available, so later visits work offline.

Privacy

Photos are read locally, resized in memory, scored on the device, and discarded. They are not uploaded, not stored in localStorage, and not included when you share. The only saved data is which squares you found, when today's card started, and the season…

View on GitHub

How I Built It

Model: Xenova/clip-vit-base-patch32, an ONNX export of OpenAI's open-weight CLIP, run with transformers.js (@huggingface/transformers) on WebAssembly, right in the browser.
How it checks a photo: zero-shot image classification. Instead of just asking "is this a pinecone?", I give CLIP the target label plus a few distractor labels taken from other squares on the card. The photo counts if the target is the top label, or if its score is at least 0.35. That logic lives in a tiny pure function sitting behind a classifier interface, so I could unit test it with fake scores.
Offline: the model downloads once and the browser caches it. A small service worker caches the app shell, so after the first visit it keeps working where you have no signal.
The rest: Vite and plain TypeScript, a seeded card generator (45 outdoor items, filtered by season), bingo line detection, and progress saved in localStorage. No backend.
Tests: 32 Vitest tests across card generation, bingo lines, the verify decision, storage, and the share summary. All pass, and npm run build is clean.
Deploy: GitHub Actions builds the app and publishes it to GitHub Pages.

I built it with Cursor's agent and then checked it myself in headless Chromium. On my box, the first real check (which includes downloading and loading the model) took about 25 to 30 seconds. After that, a check took about 2 seconds.

Why Does Open Innovation Matter?

Most of my working life is about not sending things where they don't need to go. With Arbor, the security tool I'm building, the whole point is that the analysis is deterministic and stays on your side. I wanted the same feeling here.

Your photos stay on your phone. Pictures of your backyard, your street, and your kid's hand holding a leaf never reach a server. Everything happens in the browser tab, and then the image is thrown away. With a closed vision API, every square on the card would mean an upload.
It works without signal. Parks, trails, and the back of a garden are exactly where reception gets bad. Open weights you can cache are the only reason the offline story works at all.
It costs nothing to run. No API key, no per-image bill, and no backend for me to keep alive. Static hosting is enough, so the project can stay free and online for as long as GitHub Pages exists.
You can change it. The labels, the threshold, and the model are all in plain code. If you want a birding card or a card in your own language, fork it and change the list.

This month I've had PRs merged into flake8-bugbear, scalar, pylint, pyscn, iamb, and wordpress-static-site-exporter. Open code is how I learned most of what I know, so it felt right to build something here that anyone can read, run, and change.

Prize Categories

None. This is an entry for the overall prize.

Disclosure: I used AI assistance (Cursor's agent) to build the code and help draft this post. I tested, reviewed, and edited all of it.

Still Good — four steps from what is left in the fridge

Anand B — Sat, 03 Oct 2026 20:13:43 +0000

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

What I Built

I'm Anand Biju. I built Still Good for my friend Sathguru.

He lives on his own. He buys groceries with good intentions, then a weeknight shows up, he is short on time, and he ends up staring into the fridge and ordering takeout while the spinach quietly goes bad. He is vegetarian. I wanted one page for that moment: tap what is actually there, star up to three things that should be eaten soon, and get a yellow sticky note. A title, one sentence of why, and four short steps.

The profile stays in this browser. No account. Diet can be vegan, vegetarian, eggetarian, or eats everything. Allergies are hard stops. A few "won't eat" foods, 15 or 30 minutes, and a skill setting (boil water, follow steps, or improvise) sit beside that. A pantry staple counts only if you tap it. "What's still good?" writes the note. "Another" walks to the next match. Python chooses the dish. A small model on the same machine only writes the words.

When I showed it to him, he said:

"lol nice this is great, i think I might just use it everyday thank you so much"

Demo

There is no hosted demo. It listens on 127.0.0.1:8765 and talks to Ollama on that same machine. The demo profile is set up for Sathguru: vegetarian, 15 minutes, follow steps. It includes a nut allergy so the hard-stop filter is visible. The header says "Four steps for Sathguru will actually cook." His name is in Who is cooking.

Empty fridge. The note is still waiting.

Rice, oil, garlic, yogurt, spinach, tomato, and lemon are tapped. Spinach and yogurt are starred to use soon.

Gemma wrote this note. The badge says From Gemma. The title is "Quick Spinach & Rice," and the why line is "A simple, nourishing meal." The steps rinse the spinach thoroughly and roughly chop it, heat the oil and sauté the minced garlic until fragrant, add the spinach with a pinch of salt and let it wilt slightly, then pour in the yogurt and stir. Spinach and yogurt, the two starred foods, are both used in the steps. The card shows the server-measured time, gemma3:1b · 10.6s.

Code

Anandb71 / still-good

Still Good: one dinner from what's left in the fridge, written by Gemma 3 1B running locally via Ollama. Hacktoberfest 2026 DEV weekend challenge.

Still Good

Still Good turns what is left in Sathguru's fridge into one dinner he will actually cook tonight: a four-step sticky note that obeys his diet, allergies, time, and skill.

It is for Sathguru, who shops with good intentions and then stares at the crisper around 8pm. One profile, stored in the browser. No account.

Screenshots

Friend card: vegetarian, nut allergy, 15 minutes, skill "follow steps."

Fridge: chips selected, spinach and yogurt starred "use soon."

The note after a real Gemma reply on this machine. The card says whether the words came from Gemma or from the fallback, and it shows the model name plus the generation time the server measured.

Setup

Install Ollama, then pull the small model:

ollama pull gemma3:1b

From this directory, use the existing virtualenv and install the app plus the test tools:

./.venv/bin/pip install -r requirements.txt -r requirements-dev.txt

Playwright is listed in requirements-dev.txt…

View on GitHub

ollama pull gemma3:1b
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
uvicorn app.main:app --host 127.0.0.1 --port 8765

The tests never call Ollama. python -m pytest tests -q runs 29 tests on the filter, the ranker, and the note parser.

How I Built It

Code picks the dish. Gemma only writes the note.

Gemma 3 1B (gemma3:1b) runs through Ollama on a CPU-only box. I have 38 handwritten skeletons, each with a fallback note. Python filters by diet, allergies, won't-eat foods, time, skill, and ingredients on hand. Stars change the ranking.

I send Gemma the chosen skeleton and an allow-list, and ask for a title, a why, and four steps. The call streams at temperature 0.2 with num_predict 90, and I stop it early. A step that names a disallowed food or an allergen gets dropped. Starred use-soon foods have to appear in the steps. If they do not, I retry once, then show the handwritten note: "Gemma skipped the yogurt; here's the sure version." A malformed reply says "Gemma mumbled; here's the sure version." No answer says "Gemma didn't answer; here's the sure version." The card shows the time the server measured.

On an idle CPU one note took about 6.7 seconds. Another, while the shared machine was heavily loaded, took 213.3 seconds. I wait five minutes before that fallback, so a slow run can still finish. No build step. The profile lives in localStorage.

Why Does Open Innovation Matter?

Sathguru's diet stays on the laptop. The app runs offline on localhost, the prompt never leaves the machine, and a note has zero per-request cost. OLLAMA_MODEL swaps the weight when a bigger local model fits. Gemma 3 1B was small enough for the only box I had.

The trade-off is right there in the timings. A loaded CPU is slow, and a 1B model sometimes writes a flat sentence, which is why the card shows the real server time and the handwritten note is ready when the wording fails.

I built the app with the Cursor agent, using Grok 4.7 High as a coding assistant. The app itself runs on open pieces: Gemma 3 1B through Ollama for the note, FastAPI for the server.

Prize Categories

Best Use of Gemma. Gemma 3 1B is the only writer of the sticky note, running locally through Ollama. The prompt, the stream cutoff, the allow-list, and the handwritten fallback exist so a 1B model can title the dish and write four short steps, while Python keeps the diet, the allergy, and the fridge honest.