Constraint Kitchen: A Local LLM That Says No

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

---

What I Built

Constraint Kitchen turns the junk in your cupboard into something worth building.

Type what you have — cardboard, string, tape, old notebooks — plus your time, budget, skill level and any restrictions (no sharp tools, no glue). A local Gemma 3 1B hands back three genuinely different DIY ideas that respect all of it. Pick one, get a numbered build guide. Changed your mind? Remix it four ways: zero-buy, use-it-up, remove a material, or simplify for a beginner.

Most idea lists assume a trip to the shop. This one starts where you already are.

Who pays: nobody. It runs on your own machine — no account, no API key, no usage meter. It's for makers starting a craft side hustle, teachers who need free classroom projects, and anyone who just bought a storage bin they don't want.

The hard part isn't making ideas. It's not lying about them. Show me "cut the cardboard" after I said no sharp tools and you've failed me, JSON-valid or not. So it refuses more often than it succeeds — and says exactly why.

Demo

⚠️ There's no deployed link, on purpose. It needs a local Ollama service and binds to 127.0.0.1 only. No hosted instance exists because there shouldn't be one.

→ github.com/ShashwatSinha03/HF_ConstrainKitchen — clone, four minutes, running.

1. Cardboard Box Garden        2. Paper Chain Support      3. String Bookmark
 Uses: cardboard, tape           Uses: paper, tape            Uses: notebook pages, string
   20 min · easy                  20 min · easy                20 min · easy

   [ Build This → ]  [ Zero-buy ]  [ Use-it-up ]  [ Remove a material ]  [ Simplify it ]

Measured on my Mac (M3, 8 GB, gemma3:1b): three ideas in ~10–20s, a guide in ~7–15s, a remix in ~3–8s. The model is nondeterministic — the same diagnostic scored 5/7 and 6/7 on identical code. And guides under no sharp tools land about 2 in 6. The gate refuses, on purpose.

Code

→ github.com/ShashwatSinha03/HF_ConstrainKitchen (MIT)

Two ideas did the heavy lifting:

Output is untrusted input. A 1B model will invent a glue gun you don't own. So Python checks, and the meaning is directional:

def _covered_by_inventory(item, inventory):
    """One shared word is NOT evidence — "cardboard" says nothing
    about "glue gun", and a substring isn't a match either."""
    return _significant(item) <= inventory

A deadline you can trust. requests' timeout isn't a total deadline — I measured 420s with timeout=120 never firing. So it streams and checks the wall clock per chunk. Forced timeout returns in 0.07s, zero leaked threads.

233 mocked tests, green on 3.10 / 3.12 / 3.14 in CI — with no Ollama present, which is what makes that evidence instead of decoration.

How I Built It

gemma3:1b via Ollama. Python + Streamlit + requests. Two dependencies. No LangChain, no vector DB, no agents, no cloud.

The 1B shaped everything. It gets grammar-constrained decoding, not prompt-begging — the schema does the work. It gets a prompt showing three objects, because a 1B copies the shape it can see, and my original template showed one, so the model faithfully returned one, every single time. And the invariants live in the schema itself: minItems: 1 on materials, maxItems: 0 on purchases at ₹0.

Six sprints. Honest version: the model was the hard part, the validation was the work — and three sprints in, the pipeline looked finished and failed every real request. I only found out because I finally pointed a real model at it. Four sprints of very confident documentation, none of it observed.

Why Does Open Innovation Matter?

Because the refusal model is the product, and a closed API can't support it honestly.

An app whose promise is "don't recommend what I can't build" is an app whose credibility lives in what it admits it doesn't know. No key means no floor on cost. No rate limit means no floor on latency. Lose signal and the feature is simply gone. This one works on a plane, costs nothing per idea, and needs no account.

Owning the stack also bought me permission to be honest. My README's first section is Known limitations: no sharp tools fails two times in three, the model is nondeterministic, nothing above ₹0 is price-verified, and nothing checks whether a project is actually buildable.

A closed API rewards a smooth happy-path demo. I'd rather ship something that fails loudly and tells you exactly why.