Fridge-to-Table: an offline kitchen agent that plans dinner, schedules the thaw, and reads the plan aloud

Mark Martin — Mon, 26 Oct 2026 06:51:33 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3.

Fridge-to-Table: an offline kitchen agent that plans dinner, schedules the thaw, and reads the plan aloud

Demo video: all shots were recorded today; the edited cut lands in this same post within 24 hours (the entry is being submitted inside the entry window — this line will become the video link).

Code: https://gitlab.com/storycrafter/fridge-to-table (public, MIT)

What I Built

My wife, being the self-appointed cook in the house (it was an uncontested appointment), often struggles with all the duties of being a mother, teacher, wife, home keeper, volunteer, coach, counselor, and all around nurse. Our family has a few food allergies to contend with and fasting rules during certain seasons of the year. Keeping track of what frozen meats to thaw and prepare, what meals to serve that follow the fasting rule (when the rule is in effect), and what pre-packaged foods might cause discomfort or illness because of their ingredients has previously been a chore. Planning what to prepare and when, and tracking what's in the fridge, freezer, or pantry has been an open source of stress for years.

Fridge-to-Table is a small agent that closes that loop so my wife never thinks about it:

Plans the week's dinners against a real constraint set — a liturgical fasting calendar (which days permit what), a household allergy matrix encoded as hard constraints the planner cannot override, and the actual contents of the freezer and pantry.
Schedules the thaw. It works backward from each meal: meat needs 36+ hours of refrigerator thawing, so if Thursday is shepherd's pie, Tuesday at 6 AM you get one Telegram message: "Pull 2 lb ground beef from the freezer today."
Reads the plan aloud. A spoken briefing of today's defrost list and tonight's dinner, generated on-device, for the kitchen counter.

The whole thing runs on a home server: open-weight models served by llama.cpp, inventory in SQLite. No cloud AI account is involved at runtime. If the internet is down, dinner still gets planned.

The laziness quotient: the family's entire involvement is answering one question a week ("anything new in the freezer?"). The agent does the calendar math, the constraint checking, the thaw scheduling, and the reminding.

The kiosk: a UNO Q board that boots into a talking console

The briefing got a body. kiosk/ in the repo turns an Arduino UNO Q (4 GB, ~$79) into a headless kitchen appliance:

Local LLM on the board — Qwen3.5-0.8B Q8_0 GGUF (~880 MB) behind llama.cpp, warm replies in 4–6 s, ~2.5 GB of RAM still free.
A wall tablet as the interface — a one-file Flask app with big buttons (dinner, lights, timer, joke), typed input, and browser voice input, served over HTTPS with a self-signed cert (browsers only grant microphone access in a secure context — a detail that cost us an evening).
Rolling conversation memory — follow-ups like "what about a dessert that goes with that?" work within the session.
Boot-to-talking — the bootstrap leaves the board headless with linger on, and systemd units bring up the model server, the web app, and a 30-second Bluetooth reconnect/keep-warm timer. Power cord in → talking console in ~2.5 minutes. No login, ever.

The Bluetooth part taught us the most: the stock desktop session quietly registers the A2DP profile first, so every audio stack you actually run gets UUID already registered and the speaker stays silent — the fix is documented in kiosk/RUNBOOK.md so nobody debugs it twice.

Code

The public repo (created in-window, 2026-10-21): https://gitlab.com/storycrafter/fridge-to-table

planner/ — constraint-checked meal plan generation (fasting calendar + allergy matrix as data files, not prompts)
thaw/ — backward scheduling from meal date → pull date, with the 36-hour rule as a config constant
extraction/ — decisive-first few-shot protein extraction, keyword-fallback union (recall-biased)
voice/ — TTS briefing generation: ElevenLabs eleven_multilingual_v2 as the demo voice, on-device piper as the offline fallback (FTT_TTS_ENGINE=piper)
inventory/ — SQLite inventory service with YAML interop
run.py / weekly.py — one-day and full-week runners
benchmarks/ — honest extraction trap suite: Gemma 3 4B vs the production Qwen3-4B baseline, real results committed
schemas/ — the constraint schema as a reusable artifact: JSON Schemas for both constraint files, a dependency-free validate.py, and a fork guide — point it at a kosher, halal, or lent-calendar kitchen
kiosk/ — the UNO Q kitchen console: bootstrap, tablet web app, systemd units, board runbook
data/sample/ — synthetic freezer inventory and meal plan (the real household data stays private)

How I Built It

The stack is open end to end:

Inference: Gemma 3 4B IT (gemma-3-4b-it, Q4_K_M GGUF) behind llama.cpp's OpenAI-compatible server on 127.0.0.1. Quantized to Q4 so it fits the existing home-server hardware. The benchmark suite ran this head-to-head against the Qwen3-4B GGUF that serves the household's production bot.
The core trick — deterministic first, LLM second. The thaw schedule is plain date arithmetic; no model involved. The model is used only where judgment is needed: extracting which ingredients in a planned meal are freezer proteins, and proposing meals that satisfy the day's constraints. When the model is unsure, a keyword fallback runs and the two answer sets are unioned. A frozen block of beef is a worse failure than a slightly clumsy message, so the design biases toward recall.
The constraint set is data, not prompts. The fasting calendar and allergy matrix live in versioned YAML. The planner treats them as hard filters; the LLM proposes within the filtered space and can never "argue" an allergen into a plan.
Extraction: decisive-first few-shot protein extraction with a keyword-fallback union, so recall is preserved when the model hedges.
Voice: the briefing is ElevenLabs (eleven_multilingual_v2) with on-device piper as the offline fallback — pull the WAN cable and the plan still gets read aloud.

Why Does Open Innovation Matter?

Three reasons this specific job needs open:

The data can't leave the house. A household food system contains medical-adjacent information — allergen lists, eating patterns, who's home which nights. That belongs on a machine the family owns, behind their own firewall, not in a third-party inference log. Open weights make the privacy real.
It has to work when everything else doesn't. The freezer is most relevant exactly when a storm takes the internet out. The planning core — constraints, proposals, extraction, thaw math — is fully local and fails none of its duties with the WAN cable pulled; even the voice briefing degrades gracefully to the on-device piper engine. Open weights are what make that degradation a design property instead of a prayer.
The marginal cost of a reminder must be zero. An agent that nudges you 200 times a year cannot have a per-call price, or you'll stress about the costs. Running a 4B model quantized on existing hardware makes the nudges essentially free — the difference between a system the family keeps and one they turn off.

And because the harness, models, and scheduler are all open, anyone can fork this and point it at their own constraint set — a different fasting calendar, different allergies, a kosher or halal kitchen. The rules are data files. The constraint schema is a standalone artifact in the repo: JSON Schemas for both files, a dependency-free validator, and a fork guide.

The Lazy Payoff

Measured during the build (honest numbers, not estimates):

Extraction accuracy, head-to-head trap suite (7 adversarial cases: dairy-only day, hidden shrimp in curry, multi-protein cookout, fish fry, tofu false-positive bait, eggs-excluded day, PB&J): Gemma 3 4B 6/7, production Qwen3-4B 7/7 — and Gemma's one miss is a rule violation (listed eggs on an eggs-excluded day). Recorded honestly rather than tuned away; see benchmarks/benchmarks.md in the repo.
Latency: median 0.379s (Gemma) / 0.371s (Qwen) per extraction call after warmup; a full one-day plan-to-message run completes in seconds on the home server.
Cost: the planning core is $0.00 per reminder — a quantized 4B model on hardware the family already owns. The ElevenLabs briefing is 370 characters; a daily briefing consumes ~9% of a Creator account's 131k-char monthly quota (measured live via the API), and the on-device piper engine covers any no-budget fallback at literally $0.
Test coverage: 119 unit tests, zero model calls (LLM client is injectable), so the deterministic core is verifiable offline.

Prize Categories

Best Use of Gemma — SHIPPED. Gemma 3 4B IT Q4_K_M is the planner/extractor, benchmarked head-to-head against the production Qwen3-4B baseline with committed results (benchmarks/).
Best Use of ElevenLabs — SHIPPED. The briefing voice is ElevenLabs (eleven_multilingual_v2), with the on-device piper engine as the offline fallback — pull the WAN cable and the plan still gets read aloud.
Best Use of Uno Q — SHIPPED, implemented and verified end-to-end. The UNO Q is the whole appliance: the model (Qwen3.5-0.8B Q8_0, ~880 MB behind llama.cpp), the Flask web server for the tablet, and the voice stack. Concretely shipped: headless bootstrap with linger (power cord in → talking console in ~2.5 min, no login), HTTPS tablet UI with buttons/typed/browser-voice input, rolling conversation memory, preloaded dinner context reproducible across reboots, ElevenLabs-primary voice with automatic per-request Piper fallback, and a 30 s BT reconnect + keep-warm timer. Self-contained except the wireless link. Repo: kiosk/.
Best Use of Tinker — NOT entered this week (attempted, honest no). Built a veto-distillation dataset (294 verified-clean examples from our own hard filters) and ran three Qwen3.5-4B LoRA SFT runs via Tinker; no eval improvement over the already-at-ceiling base model (suspected LoRA-not-applied-at-sampling). Deferred to Week 4 with a diagnosis plan — see tinker_train/README.md in the repo. The post stands on the three shipped categories.

DEV Community: Mark Martin

Fridge-to-Table: an offline kitchen agent that plans dinner, schedules the thaw, and reads the plan aloud

Fridge-to-Table: an offline kitchen agent that plans dinner, schedules the thaw, and reads the plan aloud

What I Built

The kiosk: a UNO Q board that boots into a talking console

Code

How I Built It

Why Does Open Innovation Matter?

The Lazy Payoff

Prize Categories