Should I Bother? Gemma 4 bets on you doing nothing

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

What I Built

Should I Bother? (The Lazy Bookie) turns weather chores into bets on doing nothing.

You type your chores in one sentence: "water the plants, hang the laundry, rinse the car". A Gemma 4 bookmaker running on my own laptop reads the forecast and gives you odds that the sky does the job for you:

• Water the balcony plants? Showers are possible overnight: toss-up, 50 %.
• Rinse the car? Barely any rain: unlikely, 35 %.
• Clean the windows? Gemma picks the best window to do it, so the rain doesn't undo your work.

You bet on doing nothing. The odds and the payout are locked in. At settle time, you answer with one tap or an after photo, and Gemma judges the result: "Still moist, all fine", and the receipt is stamped PAID OUT. The Score screen shows your rank (from Hyperactive squirrel up to Koala and beyond), what the sky saved you (minutes, litres of water, kWh), and how honest Gemma's odds really are next to a simple rule's.

Who gets to be lazier? Anyone with a balcony, a washing line, a car on the street or a terrace, in a city where the weather keeps changing. It doesn't tell you to skip a chore blindly: safety (heat, frost, storms) is never a bet, and a fixed backstop always overrides Gemma.

What's in it:

• Plants and laundry bets: water the balcony plants, line-dry today, laundry overnight, and a laundry planner for the best drying day.
• City rain bets: rinse the car, the bike or the terrace, and fill the rain barrel.
• Advice cards: clean the windows, sweep the leaves, paint outdoors, feed the lawn.
• Rescue: cash out when the forecast turns against your bet.
• Appeals, ranks, achievements, and an onboarding with a GPS button or a place search.
• "How Gemma decided" on every bet: the prompt version, the tool call, and the exact forecast hours Gemma saw.

Demo

41 seconds, recorded from the real app with sample data. Voice: Piper "Ryan" (RyanSpeech dataset, CC BY-NC-SA 4.0). Music: original.

Try it yourself in two minutes, with no GPU and no model, using sample data, a fake model and fake weather:

git clone https://github.com/adricasi/ShouldIBother.git
cd ShouldIBother
npm ci && npm run build && npm run sib -- demo

Open the link it prints. Every screen carries a "Sample data · fake model" label, so nothing pretends to be Gemma.

The real thing runs at home: Gemma 4 E4B in Ollama on the laptop, and the phone pairs over home Wi-Fi with a one-time link.

Code

adricasi / ShouldIBother

Should I Bother?

The Lazy Bookie: a bookmaker that bets on doing nothing. Tell it a weather chore, and Gemma 4, running on your own laptop, reads the forecast and quotes odds that the sky will do it for you. Bet on the weather or do it yourself; every bet settles on evidence.

Try the demo → · How it works · Gemma · Run it yourself · Hosted mode · Contributing

---

Contents

• Why Should I Bother?
• Features
• Screenshots
• How it works
• Quick start
• Run it on your laptop, step by step
• Configuration
• Hosted mode
• Architecture
• Privacy and security
• Testing and quality
• Project structure
• Status and roadmap
• Hacktoberfest challenge
• Later commits
• Contributing
• Licences and acknowledgements
• Documentation

Why Should I Bother?

On the right day, the weather does some chores for you: the rain waters the balcony, the sun and wind dry the washing, a cool night stands in for the…

View on GitHub

• Stack: TypeScript (strict) on Node 24: Fastify, React + Vite, zod, better-sqlite3, sharp.
• Fine-tune pipeline: a Python training/ folder (uv, QLoRA).
• Licence: MIT.
• Docs to start with:
  • README;
  • how Gemma is integrated;
  • architecture, with 13 diagrams;
  • how it was built;
  • the spec and the ADRs.

How I Built It

Gemma decides, code executes

How Gemma is integrated: the jobs, the JobRunner, the ModelClient runtimes, and the code that executes

Gemma 4 E4B runs locally in Ollama on 127.0.0.1. Every model call goes through one ModelClient interface with four runtimes:

Runtime	Used for
Ollama	Gemma 4 E4B at home
llama.cpp	Gemma 4 audio, for voice capture (behind a flag)
DigitalOcean Serverless Inference	The optional hosted mode
Fake	Recorded, synthetic fixtures for tests and the demo

Gemma does seven jobs, each with a versioned prompt file (prompts/<job>.v<n>.md), a zod schema, a retry budget and a deadline:

1. Listener: splits your sentence into chores and chore types.
2. Inspector: reads a before photo (soil, wilting, laundry) into observations.
3. Bookmaker: calls the get_forecast tool and answers with an odds band (very likely, likely, toss-up, unlikely, very unlikely = 85/70/50/35/15 %), a short reason and a settle time.
4. Safety guard: checks for heat, frost and storms before a bet opens.
5. Judge (and appeals): reads the after photo or your tap, plus the recorded weather, and returns the verdict.
6. Laundry planner: picks the best drying day out of four.
7. Advisor: picks the best window to clean the windows, sweep or paint, from a 72-hour forecast.

The important part is what code does around Gemma:

• Gemma never returns a raw percentage. It names a band, and code maps it to odds and computes points: win = (100 − odds) × evidence multiplier (photo ×1.0, tap ×0.5); losses are −25 / −50 / −150.
• A rule baseline is computed for every card and stored on every bet. If Gemma is two or more bands away from the rule, it must explain why or ask a question. If it skips the forecast tool, it gets one retry, and then the card shows labelled rule odds.
• Safety is never a bet. A fixed heat, frost and storm backstop overrides Gemma.
• Settlement is always a Gemma verdict. If Gemma is offline, the bet waits, and it auto-settles at ×0.5 only after 24 hours. Odds are locked at bet time, with undo only within 5 minutes.
• Everything typed or photographed is untrusted data, fenced off from the instructions in every prompt, and every answer is schema-validated before it touches the database.
• Every decision is logged in gemma_decisions: model, digest, prompt version, tool mode, retries, latency, and the forecast hours get_forecast returned. That log is what the "How Gemma decided" panel shows.
• Calibration is measured, not assumed. The Score screen compares Gemma's bands with what really happened, next to the rule's figure. Bets priced by the rule never count toward Gemma's calibration.

Evaluation and fine-tune

• Evaluations: sib eval <job> runs an eval set per job (seven sets).
• Backtest: replays past weather using only forecasts that were available at decision time, so there is no lookahead.
• Fine-tune (QLoRA): a full pipeline for the bookmaker. A dataset is built from a weather snapshot with a fixed synthetic habit profile; the build fails if anything from my real household config appears in it, and the September–October data is held out. The pipeline trains, merges, exports to GGUF with a Modelfile for Ollama, and compares base and fine-tuned models on the hold-out.

Spec-driven, with AI agents

I built it spec-first:

1. Idea brief. An ideation session produced the brief and a Go verdict.
2. Spec in docs/spec/. It covers product, requirements, design and tasks, with stable IDs: 32 requirements, 149 acceptance criteria in EARS style, 13 non-functional requirements, 42 tasks and 11 ADRs. Every later change went through the spec first: the city rain bets, the advice cards and the hosted mode were each a spec change before any code.
3. Implementation. Claude Code coordinated parallel worker agents, one task each. Tests were written from the acceptance criteria first, against a fake Gemma with recorded, synthetic fixtures, so CI never needs a GPU.
4. Review. Every pull request was reviewed by specialised reviewer agents (code, game rules, security, UX and spec), then got one round of fixes.
5. Result. 56 merged pull requests, around 2,600 automated tests plus browser end-to-end tests, and a security review with no Critical or High findings.

Optional hosted mode. The same app can also run on a small DigitalOcean Droplet, with Gemma from DigitalOcean's Serverless Inference:

• Caddy for HTTPS, and a read-only container;
• no accounts: a device is linked once and remembered;
• a daily cap on model calls;
• a one-command release with short-lived registry credentials and automatic rollback.

It says clearly on screen that Gemma runs at DigitalOcean in that mode. Home mode stays the default.

Why Does Open Innovation Matter?

Because the whole idea depends on it.

• Privacy is the product. The app sees my balcony, my laundry, my habits and photos of my home. With open weights, Gemma runs on my laptop and the photos never leave it. The only outbound call is to Open-Meteo, and the coordinates are rounded. A closed API would need all of it sent to someone else's server.
• I can change the model, not just the prompt. Open weights let me fine-tune the bookmaker with QLoRA on my own GPU, export it to GGUF and serve it in Ollama, then measure base against fine-tuned on a held-out season.
• I can inspect it. I pin the model digest, log every decision and replay a backtest. A model that changes silently behind an API would break the calibration numbers.
• No per-call cost, and it works offline. At home there are no tokens to pay for. If the internet drops, the weather comes from the cache and Gemma keeps working.
• No lock-in. The same ModelClient runs Ollama, llama.cpp or a hosted endpoint. When I wanted a public version, I moved to an open-model endpoint without touching a single Gemma job.
• It's open all the way down: Gemma 4, Ollama, llama.cpp, Open-Meteo (CC BY 4.0), and Piper for the demo voice.

My Agent Session

This is the session where the idea went from a brief to an approved spec:

Should I Bother? (The Lazy Bookie): from idea brief to approved spec in one session (Claude Code)

You

/spec

Agent

▸ Read docs/discovery/idea-brief.md, product-concept.md, design-handoff.md, docs/spec/*

Input

docs/discovery/idea-brief.md, product-concept.md, design-handoff.md, docs/spec/*

Output

Spec files are empty templates; idea brief (verdict: Go with a cut scope) covers most of Phase 1.

▸ Bash git switch -c docs/spec

Input

$ git switch -c docs/spec

Output

Switched to a new branch 'docs/spec'

Pre-filling product.md from the brief (local target, TypeScript, desktop/voice/rescue out of MVP). It's Wednesday 21 Oct and no spike results exist yet. Four questions: were the day-1 spikes run, how should scope change now we're a day behind, how are odds produced (Q-4), and what's the live-week bet target?

You

Spikes not run: T-001 is a time-boxed spike (E4B photo+forecast -> JSON < 15 s and >= 19/20 valid; phone upload over plain HTTP via WSL mirrored networking; Historical Forecast for Gracia; QLoRA smoke run), each with a fallback. No features cut: scope is ordered in 6 tiers, unfinished work ships behind flags. Gemma is the protagonist: it calls the Open-Meteo tool, reads the photo, returns one of five odds bands; code maps bands to fixed odds; the rule model is a baseline to beat; fine-tune the bookmaker with QLoRA on public weather. Availability: Thu PM, Fri PM, Sat; publish Sat 23:00 Madrid; >= 8 settled live bets, >= 3 by photo.

Show more

Agent

▸ Write docs/spec/product.md

Input

docs/spec/product.md

Output

Goals G-1..G-5, success metrics with numbers, 6-tier ordered scope, non-goals, constraints, glossary, Q-2..Q-11, assumptions A-1..A-8

Phase 1 written. One risk: tiers 1-4 already include a fine-tune and its evaluation in ~15 h of builder time; Phase 4 will place it so it can drop out without blocking the post. Approve scope, non-goals and the local target?

You

approve

Agent

Four decisions change the acceptance criteria: band -> odds mapping, what happens when Gemma is down, who may use the app on the LAN, and photo retention.

You

Odds 85/70/50/35/15. Rule odds as a labelled provisional fallback that Gemma replaces; rule-odds bets excluded from Gemma's calibration; settlement never falls back to the rule. Hardened pairing token (>= 128-bit, HttpOnly SameSite=Strict cookie, token-free redirect, Origin check, rate limit, Ollama on [REDACTED] only). Photos kept until deleted, EXIF stripped, resized to 1024 px, data folder git-ignored, export + delete-all.

Agent

▸ Write docs/spec/requirements.md

Input

docs/spec/requirements.md

Output

REQ-001..029 with EARS acceptance criteria (Must = tiers 1-2 + safety/security/privacy), NFR-001..012 with numbers

Flagged: the fixed safety backstop is Must although safety alerts were tier 3; undo window 5 min (A-9); new Q-12: Open-Meteo's archive lags by days, so next-morning settlement needs another source.

You

approve

Agent

▸ Skill llm-features (open-weight section), adr

Input

llm-features (open-weight section), adr

Output

Runtime ADR + spike, pinned model digests, localhost-only runtime, recorded-fixture tests

Three design choices: app architecture (one Node process + React SPA recommended), model runtime (Ollama + llama.cpp for audio), and recorded weather for settlement (forecast API past hours).

You

Recommended options for all three.

Agent

▸ Write docs/adr/0002..0008, docs/spec/design.md

Input

docs/adr/0002..0008, docs/spec/design.md

Output

Local target; Fastify + React + SQLite + in-process scheduler; Ollama behind a ModelClient with a fixture fake; Gemma bands + rule baseline; Python training/ for QLoRA; pairing token; weather sources. Gemma job schemas, rule thresholds, data model, API, threat table, testing, traceability.

You

Design approved with changes: pin Node 24 (lts/* may move to 26 and break native modules); Q-13 labels from Apr-Aug only, templated reasons; enforce bookmaker tool use in code and record the miss rate; CSP img-src blob: data:, Host allowlist from active interfaces; test a real iPhone photo, 415 for unsupported formats.

Agent

▸ Write docs/spec/tasks.md

Input

docs/spec/tasks.md

Output

T-001..T-029 in 5 milestones, walking skeleton first, schedule over the builder's slots, coverage table

Moved the dataset builder to Thursday morning (training starts Thursday night), and noted settlement lands Friday.

You

Plan approved with: stacked PRs (I'm the only merger and away mornings), agents kicked off Wed night, T-011 fixture-based, backtest unattended Fri night, a post-skeleton task, and a slot table. T-002..T-006 and T-008 merged Thu PM so I place the first real bet from the phone Thu evening.

Agent

▸ Edit docs/spec/tasks.md, AGENTS.md

Input

docs/spec/tasks.md, AGENTS.md

Output

Stacked-PR rules, slot-per-task table, T-029 post skeleton; AGENTS.md overview, architecture, project and domain rules

▸ Agent spec-reviewer (Opus) on docs/spec + ADRs

Input

spec-reviewer (Opus) on docs/spec + ADRs

Output

READY WITH FIXES. Blockers: Historical Forecast stitches the first hours of each run (near-actual, lookahead risk); fine-tuned model and rule thresholds evaluated in-sample; T-010 depends on photos merged Friday; T-008 overlaps T-004 and the Thu checkpoint is at risk. Plus 10 should-fixes (token lifetime, portproxy, 45 s job deadline, training rows missing the tool call...).

Applied all fixes: backtest decides on the Previous Runs API at day-1 lead; headline numbers on the Sep-Oct hold-out; T-030 split out for photo eval; T-008 moved into W1's stack; Thu PM merge budget ~90 min; training rows mirror the live bookmaker conversation.

▸ Bash git commit docs(spec): write product, requirements, design and task plan

Input

$ git commit docs(spec): write product, requirements, design and task plan

Output

1ac185e

You

I approve the spec files.

Agent

▸ Bash git commit docs(spec): mark product, requirements, design and tasks approved

Input

$ git commit docs(spec): mark product, requirements, design and tasks approved

Output

40e67f2

Spec approved. ADRs stay Proposed until the T-001 spike confirms runtime and weather sources. Next: push docs/spec, write the W1/W2 briefs, /project-kit.

18 of 20 messages · some content was hidden by the author

From there, the build followed the spec task by task. Each pull request maps to task and requirement IDs, so you can trace any feature back to the acceptance criteria that asked for it.

The Lazy Payoff

Every figure in the app shows its assumption, and savings count only on wins:

Chore the sky does for you	Saved per win
Watering 5 balcony pots	~5 min, ~4 L of water (typical estimate)
Rinsing the car	~40 min, ~75 L, the low end of a car wash (sourced)
Rinsing the terrace	~15 min, ~30 L (typical estimate)
Rinsing the bike	~10 min, ~20 L (typical estimate)

For example, if the rain rinses the car twice a month and waters the plants twice a week, that's roughly 2 hours and 185 L of water a month I don't spend (about 1 h 58 min net, because the app subtracts the 30 seconds each bet takes). And when Gemma says "unlikely", I do the chore myself and earn +5 if the sky really wouldn't have helped.

The bigger payoff is the guilt-free part. Doing nothing is now a decision with odds, a receipt and a calibration chart.

Prize Categories

• Overall
• Best Use of Gemma: Gemma 4 E4B runs locally as the decision maker for seven jobs, with tool calling, schema-checked answers, a rule baseline, calibration tracking, a logged "How Gemma decided" trail on every bet, and a QLoRA fine-tune pipeline. Gemma decides; code executes.

@adricasi Adrià Casals Espax

---

Credits: weather data by Open-Meteo (CC BY 4.0). Gemma 4 by Google. Demo voice: Piper "Ryan" (RyanSpeech, CC BY-NC-SA 4.0). Demo music: original.

Comments

[arcwrightai]

The details here matter more than the headline, honestly.