Zero waste kitchen

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

What I Built

Zero-Waste Kitchen is an AI-powered meal planner that builds a week of vegan meals around three inputs: what's already in your fridge, what's in season near you, and what's on sale at your local supermarket. It then generates an optimized grocery list that minimizes both food waste and CO₂e per calorie — while hitting your protein, iron, B12, and micronutrient targets on a plant-based diet.

Who pays for it:

• Health-conscious vegans and flexitarians who want to eat plant-based well without spending hours researching nutrition or letting spinach rot in the fridge. They pay €4.99/month for the Pro tier (unlimited plans, nutrition targets, receipt scanning).
• Small gyms and nutrition coaches who white-label meal plans for clients.
• Local zero-waste stores who sponsor "cook this with what we have" shopping lists.

The problem: People who try plant-based eating fail for two predictable reasons — nutrition anxiety ("where do I get protein?") and waste guilt (buying kale for one recipe, throwing half of it away). Both are planning problems, not willpower problems. Planning is exactly what an LLM with structured outputs and real data does well.

Code

The full stack is open source (MIT):

julian-st / zero-waste-kitchen

Sustainable zero waste kitchen ai model

Core repo layout:

├── agent/          # meal-planning agent (tools, planner loop, structured output)
├── models/         # CO₂e lookup tables (open LCA data), nutrition DB (USDA FDC)
├── api/             # FastAPI service
├── web/             # SvelteKit frontend
└── infra/           # Docker Compose, Ollama model pull script

How I Built It

The whole thing runs on open-weight models with local inference:

• Planner model: Qwen2.5-14B-Instruct served via Ollama, wrapped in an agent loop using the PydanticAI harness. The model never free-writes meal plans — it emits a strict, schema-validated plan object (Pydantic), so a bad generation fails validation and retries instead of hallucinating a recipe with imaginary macros.
• Vision model: Qwen2.5-VL-7B for receipt and fridge-photo scanning — you snap a photo of your vegetables drawer, it returns a structured inventory with estimated shelf life.
• Retrieval: sentence-transformers (bge-small) with a local Qdrant vector DB over an imported recipe corpus.
• Ground-truth data (no LLM involved): nutrition from the USDA FoodData Central API (open data), CO₂e factors from published life-cycle assessment datasets, seasonality tables for EU regions, and weekly discount scrapers.

The agent's trick is the optimization layer under the LLM: the model proposes a diverse set of candidate meals; a deterministic solver (PuLP, linear programming) then picks the combination that minimizes cost + CO₂e + leftover-ingredient waste subject to nutrition constraints. The LLM handles creativity and diversity; the solver guarantees the math is actually right. That split is what makes it a product instead of a demo.

Stack: FastAPI, SvelteKit, Postgres, Docker Compose — self-hostable in one command for the privacy-conscious.

Why Does Open Innovation Matter?

Three concrete reasons, not philosophy:

1. Privacy made the product possible. Users upload photos of their kitchen and their grocery receipts. With a closed API, every fridge photo would leave their home and hit a third-party retention policy. With local open-weight inference, "your food data never leaves your device" is a verifiable architectural claim — and it's our main marketing line.
2. Cost made the side hustle viable. At €4.99/month with closed-API token pricing (~$0.01–0.03 per planning session), margins would be razor-thin. Inference on a used RTX 3060 costs electricity. Open weights turned the unit economics from "hopeless" to "actually profitable at hobby scale."
3. Schema control. We needed a model we could constrain with strict JSON schemas, retry aggressively, and quantize to run on 8 GB VRAM. Open-weight quantization (GGUF) made that our decision, not a vendor's roadmap decision.

If the underlying model were a closed API, this exact product — private, cheap, and honest about its nutrition math — could not exist.

Prize Categories

• Ollama — local inference with Qwen2.5 models is the core of the stack
• Qdrant — vector search over the recipe corpus
• Hugging Face — open-weight models and datasets used throughout

---

Team note: solo submission by @julian-st.