This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady
What I Built
Fridge to Dinner. You take a photo of your open fridge, it lists what it thinks is in there, you fix the list, and you get three dinner ideas with five steps or fewer each. No meal plan, no shopping list, no account.
The idea came from a lazy week. I didn't want to spend my evenings staring into the fridge, trying to figure out what to cook. I wanted something to take that small but annoying decision off my hands, so I built it.
It runs locally on my machine through Ollama with gemma3:4b. The photo never leaves my laptop.
Demo
Code
Fridge to Dinner
Take a photo of your open fridge or pantry. Get three different dinners that need few steps and use mostly what's visible (plus salt, pepper, oil and water).
Built for the Hacktoberfest Open-Source AI Challenge, theme Slow and Steady reward laziness. No shopping list, no meal plan, no account. Just dinner.
Everything runs on your machine through Ollama with an open-weight vision model. 100% local. Your photos never leave your machine.
How it works
Two model calls, same local model, nothing stored in between.
- Look. You drop in a photo, take one, or choose one from your library Take a photo asks for the camera on https. On http it does not open the camera; it shows “For security reasons the camera is not available. Choose a photo from your gallery or files.” and scrolls to it. The browser shrinks the photo to max 1024 px…
How I Built It
Model: gemma3:4b through Ollama. It's a multimodal model that runs locally. My hardware is a Ryzen 7 5800X3D, an RTX 3070 Ti, and 16 GB of RAM.
Stack: FastAPI with two endpoints and one static HTML file for the UI. No frontend framework. I built it with Cursor: I wrote the specs and prompts, it wrote most of the code, and I read and tested what came out.
Two model calls instead of one:
Look. The browser shrinks the photo to 1024 px, FastAPI sends it to Ollama's /api/chat with a JSON schema, and the model returns the ingredients it thinks it can clearly see. Anything it's unsure about goes into a separate maybe list.
Cook. The confirmed ingredient list goes back as text only. The model returns exactly three different dishes, each with a cooking time, at most five steps, and a missing list for anything the dish needs that isn't in the fridge.
Why the ingredient list is editable.
The model doesn't always get things right. One time, it identified yogurt as milk. That's a small mistake, but it matters when the next step is generating a recipe based on those ingredients.
So I added a way to correct the list between the two model calls. Ingredients appear as chips: click × to remove a wrong guess, click + to confirm a "maybe", or type in something the model missed.
This way, I don't have to accept everything the model says. I can correct its mistakes before they affect the recipes.
The recipe that surprised me.
One of the suggestions was a salad with yogurt, cucumber, and pesto. It's a simple combination, but not one I would necessarily have thought of myself. I actually made it after a coding session.
That's the kind of result I wanted from this project. Not a complicated meal planner, just a little help finding something different to eat with what I already have.
Smaller details: schema-constrained output keeps the JSON valid, a "show me 3 different ideas" button passes the dishes already shown so the model doesn't repeat itself, saved recipes live in localStorage, and the UI supports English, German, and Ukrainian.
I tested all three languages. The results aren't perfect, but they're reasonably good across them.
The camera button only works over HTTPS, so on plain HTTP it falls back to the file picker.
The version I threw away.
My first idea this week was a to-do triage tool that told you which tasks you could safely skip. A small model had to decide what was urgent and do date math. It told me my passport renews automatically and that a Monday deadline would solve itself.
I patched it with keyword rules, got 10 out of 10 on my own test list, and realized that only proved I'd fitted the rules to my 10 items. I wrote a 50-case evaluation and got roughly 80%. Going from the 3B to the 7B model changed almost nothing. I deleted the project.
What I took from it: small open models can be useful for looking at things and generating text, but I wouldn't trust them blindly with decisions that require careful reasoning or calendar math.
Fridge to Dinner gives the model a narrower job: recognize ingredients, then suggest recipes. And it lets the user correct the first step before moving on to the second.
Why Does Open Innovation Matter?
Privacy. A fridge photo shows more than food: the kitchen, the counter, sometimes a window or a person in the background. I don't want to send that to an API I don't control.
Offline and free. After ollama pull gemma3:4b, there's no API key, no usage quota, and no need to send photos to an external service. Running the model still uses electricity and your own hardware, but there's no per-request API bill.
You can experiment with the model. I also tried gemma3:12b, and it handled my use case reasonably well. Having the option to try a different model without rebuilding the whole application is one of the benefits of running it locally.
Where a closed model would have been better. Honestly, probably accuracy and speed. A hosted frontier model might recognize labels and ingredients more reliably. For a dinner suggestion, I'll take a local model and a few corrections over sending my fridge photos to an external API.
The Lazy Payoff
I built this because I was tired of spending time deciding what to cook. After a coding session, I used one of its suggestions to make a salad with yogurt, cucumber, and pesto.
It wasn't a complicated recipe, and that was the point. I wanted something easy that I probably wouldn't have thought of on my own.
The app doesn't need to solve cooking. It just needs to get me from "there's food in the fridge" to "I know what I'm having for dinner."
Prize Categories
Best Use of Gemma: The whole project runs on gemma3:4b locally, for both the vision step and the recipe step. I also tested gemma3:12b to see how another model size handled the same use case.
The project is open source, runs on your own hardware, and gives users a way to correct the model instead of blindly trusting its predictions.
That's the idea behind Fridge to Dinner: a small, practical use for an open model that makes one everyday task a little easier.
Top comments (0)