DEV Community: Abhishek gupta

Sloth Fridge: A Local Vision Model That Plans Dinner From One Photo

Abhishek gupta — Tue, 20 Oct 2026 06:59:51 +0000

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

What I Built

Sloth Fridge turns one photo of your fridge into a grocery list and a dinner plan, so you never have to stand there with the door open again.

You take a photo. It lists what's inside, asks you to fix anything it got wrong, then suggests what to buy and what to cook, including one "sloth pick": the laziest meal you can make right now.

I built it for hostel life. It knows my kitchen is a kettle and an induction plate, that I'm vegetarian, and that I have a budget. [Replace this with your own real moment, for example: "Last week I stood at the mess fridge at 11 pm for five minutes and still didn't know what to cook."]

Everything runs on my laptop. No cloud, no API bill, no photos leaving my machine.

Demo

In the video: [one line on what it shows, for example "a real photo of my hostel fridge goes in, I fix one wrong item in the table, and the grocery list and sloth pick come out. Everything runs offline on my laptop."]

Code

b25246-star / Sloth-fridge

🦥 Sloth Fridge

Take one photo of your fridge. Get back what you have, what to buy, and what to cook, without standing there with the door open.

Everything runs locally on open models through Ollama. No cloud, no API bills, and your fridge photos never leave your laptop. Built for the DEV Hacktoberfest "Slow and Steady" challenge.

Why open models

Private: photos of your room and food stay on your machine.
Free to run: set it up once, never pay per scan.
Works offline: no internet needed after the models are downloaded.
Swappable: change the vision or text model with one environment variable and benchmark them against each other.

How it works

photo ─► [Pass 1: vision model]  lists distinct items + freshness guess
      ─► [Pass 2: vision model]  one focused "how many X?" question per item
      ─► [You]                   fix anything wrong in an editable table
      ─► [Text

…

View on GitHub

How I Built It

Stack: Ollama running qwen2.5vl:3b (vision) and llama3.2:3b (text), Streamlit for the UI, SQLite for memory, Pydantic for strict JSON output. All of it runs on an RTX 4050 laptop GPU with 6 GB of VRAM.

The pipeline has four steps:

Pass 1, describe. The vision model lists the distinct items it can see, as schema-constrained JSON.
Pass 2, count. For each item, the vision model gets one focused question: "How many separate tomatoes are visible?"
You correct. An editable table lets you delete wrong items, add missed ones, or fix counts.
Plan. A separate text model takes the corrected list, your usual items, and your constraints, and returns a grocery list, a few meals, and the sloth pick.

Small models are decent at spotting things and weak at reasoning, so the vision model only describes and a second model plans.

What broke, and what I did about it:

Empty answers. My first vision model returned nothing at all. It looked like a "thinking" variant that spent its whole budget reasoning. I switched to a non-thinking model and added a clear error message for empty responses.
Runaway loops. The next model got stuck repeating items until it produced a 1,300-line JSON that was cut off mid-item. Fixes: a hard cap on output tokens, a small repeat penalty (pure greedy decoding made loops more likely), a prompt that says "mention each item once", and a salvage parser that recovers every complete item from broken output.
Bad counts. Asking one model to list and count everything in a single JSON answer gave confident wrong numbers. Switching to coarse levels (one / few / many) was honest but too vague, so I added the second pass with one counting question per item. It's slower, but numbers are only filled in when the model gives a sensible answer. Otherwise the field stays blank rather than wrong.
It learns from corrections. Every item you delete or add is logged in SQLite. Delete the same false item twice and it's filtered from future scans.

Why Does Open Innovation Matter?

Four things mattered for this project, and a hosted API would have changed each of them:

Privacy. A photo of your fridge is a photo of your room and your life. Here it never leaves the laptop.
Cost. Set it up once and scanning is free forever. For something I'd use daily, per-scan pricing would defeat the point of being lazy.
Offline. After the models are downloaded, it needs no internet, which matters on patchy hostel Wi-Fi.
Control. When models misbehaved, I could change the things that fixed them: swap models with one environment variable, constrain the output with a JSON schema, cap tokens, and tune sampling. Several of my fixes above came from that control.

Where closed models still win: [Fill in after your benchmark. For example, whether a closed model counted or recognized items better, and by how much.] For this project, the trade was still worth it, because [your honest reason].

Model	Item recall	Precision	Avg seconds / photo	Offline	Cost per scan
qwen2.5vl:3b	[ ]	[ ]	[ ]	Yes	Free
[second open model]	[ ]	[ ]	[ ]	Yes	Free
[closed model]	[ ]	[ ]	[ ]	No	[ ]

Measured on [N] real fridge photos on an RTX 4050 laptop GPU (6 GB).

My Agent Session

[Optional: embed or link your DevRelay session here. If you didn't record one, delete this section.]

The Lazy Payoff

[Only keep this if it's true. For example: "I used it on my hostel fridge for [N] days. Deciding what to cook went from about [X] minutes to about [Y]." If you haven't used it yet, delete this section.]

Prize Categories

[Only list a category if you actually used that partner's technology. If not, delete this section.]

I Built a Trek Planner That Works Where Your Phone Doesn't

Abhishek gupta — Wed, 07 Oct 2026 06:02:38 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Trail Buddy is a trekking companion for the hills around Mandi, Himachal Pradesh. You tell it where you're starting and where you want to go, and it gives you a stage-by-stage roadmap with distance, climb, elevation profile and realistic timings. A local AI model then adds short, practical tips for the trek.

The problem is simple. The best trails here are exactly where mobile signal disappears. Most "smart" trip planners need a connection at the one moment you're standing at a fork with no bars. Trail Buddy does the cloud-dependent part once, at home or at the bus stand, and saves the route as a plain GPX file. After that, the roadmap, the notes and the AI chat all work with no internet.

It's built for beginners and families doing day treks like Prashar Lake, and for anyone who'd rather look at the hills than at a phone.

Demo

Code

b25246-star / trail-buddy

Trail Buddy 🥾

An offline-first trekking companion for the hills around Mandi, Himachal Pradesh, powered by a local open-weight LLM.

Plan a route between any two places while you have internet, save it, and reuse it later with no signal. The chat assistant runs entirely on your own machine through Ollama, so nothing about your trip is sent to a cloud AI.

Built for the Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.

Why this exists

The best trails are exactly where mobile signal disappears. Most trip planners need a connection at the moment you are standing at a fork with no bars. Trail Buddy does the internet-dependent part once, at home or at the bus stand, saves the route as a plain GPX file, and everything else (roadmap, notes, AI chat) keeps working offline.

Features

Stage-by-stage roadmap with distance, climb, high point and estimated up/down times.
Plan…

View on GitHub

The project is small on purpose:

trail_buddy.py: the command-line chat and planner
rag.py: a tiny local retrieval system over my trail notes
route.py: the route engine (GPX to roadmap, SVG map, HTML export)
online.py: one-time online planning for any start and destination
webapp.py and web/planner.html: the interactive map planner with live GPS
data/trails/: plain Markdown notes and GPX files

How I Built It

The open pieces

Ollama runs everything locally.
qwen2.5:3b is the open-weight chat model. It's small enough for an ordinary laptop.
nomic-embed-text is the open embedding model for search.
OpenStreetMap supplies the walking, bike and road routing and the map tiles, and Open-Meteo supplies elevation.
Leaflet draws the live map, and the rest is the Python standard library.

Grounded answers instead of confident guesses. A 3B model will happily invent a tea stall that doesn't exist, which is dangerous on a mountain. So the chat uses a tiny retrieval pipeline. Each trail's Markdown notes are split into sections, embedded, and searched by cosine similarity. The top three chunks go to the model with a strict system prompt: answer only from the notes, and otherwise say "I don't have that in my notes" and suggest asking a local guide. The index is cached in a JSON file and rebuilt only when the notes change, using a SHA-256 fingerprint of the notes and the embedding model name.

A route engine with no dependencies. route.py parses GPX, smooths the elevation, snaps waypoints to the track with haversine distance, and splits the route into stages. Time estimates use a simple rule of thumb: 4 km/h on the flat, plus an extra hour for every 500 m climbed. The same data feeds an elevation profile and an inline SVG map. That map works with no internet at all, and upgrades itself to a live Leaflet map with a topographic layer when tiles can load.

Plan once, reuse offline. For a new trek, online.py geocodes both places, asks the OSM foot router for a path, samples elevation along it, auto-generates checkpoints, and saves the result as a GPX file. Next time, even with no signal, /roadmap prashar lake opens it straight from disk.

An interactive planner. Typing /web serves a browser planner from localhost, which browsers treat as a secure origin, so live GPS works. You can choose walk, bike or cab, compare alternative routes, and scrub along the elevation profile to see each point light up on the map. Tracking shows distance left and warns you when you drift off the route. The "tips" button talks directly to the Ollama instance on your machine, so no data leaves your computer for the AI part.

I also made the AI's job deliberately narrow. It never invents the route. Distances, climbs and times are calculated by code, and the model only turns those facts and my notes into tips.

Why Does Open Innovation Matter?

Because of the trail itself. A closed API needs a connection, and the whole point of this project is the place where there isn't one. With an open-weight model on my own laptop:

It works where the signal doesn't. The chat, retrieval and saved roadmaps all run with no internet.
Local knowledge stays local. The "knowledge base" is a folder of Markdown files that a villager or guide can read, correct and extend. I'm not sending their knowledge to someone else's server to be retrained on.
I can swap the model freely. One environment variable (TB_CHAT_MODEL) changes the model. When a better small model appears, Trail Buddy gets better without a rewrite.
It costs nothing per question. A family asking twenty questions on a hike shouldn't be metered.

An honest limit: the AI is small, so it's only as good as the notes behind it. That is also why I think the open approach fits. When the model says "I don't have that," the fix is to add a line to a text file, not to wait for a vendor.

[Add your real field-test story here: where you took it, what worked, what the model got wrong, and what you changed. This is the "touch grass" part, and judges will want it.]

Thanks for reading, and go outside. 🥾

My friend asked for interview practice, so I built an AI interviewer that runs locally

Abhishek gupta — Sun, 04 Oct 2026 18:07:57 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

FRIEND is in placement season and told me one thing scares them most: SPECIFIC FEAR, e.g. "I freeze when they ask about my own project." Paid mock interview tools cost money and want a full resume uploaded to someone else's server.

So I built Mock Interview Partner: upload a resume, pick a role, and it interviews you. It asks questions about your actual projects, pushes back on vague answers with follow-ups, scores each answer strictly from 1 to 5, and writes a report with weaknesses and a practice plan. It runs completely on a laptop.

Demo

(Optional: a 30 to 60 second screen recording.)

Code

b25246-star / mock-interview-partner

Free, private mock interview partner for placement season. Runs fully offline on a local open-source model (Ollama).

🎤 Mock Interview Partner

A free, private mock interviewer for placement season. Upload a resume, choose a target role, and get tailored questions, follow-ups, strict per-answer feedback and a final report. It runs entirely on your own laptop with an open-weight model, so nothing is sent to a server.

Built for the Hacktoberfest Weekend Challenge: Build for a Friend.

Why local and open-source

A resume contains a phone number, address, grades and email, and a mock interview records someone's honest mistakes. Neither belongs on a server you don't control. Running a local open-weight model means nothing leaves the laptop, and no internet is needed once the model is downloaded.

Open source also gives you:

Free practice: no per-token cost, so a student can do 20 sessions without worrying about a bill.
Swappable models: pick any model you have pulled in Ollama from the sidebar dropdown.
Editable behaviour: the interviewer's…

View on GitHub

How I Built It

Model: llama3.2:3b through Ollama, fully on a 6 GB RTX 4050
Backend: Python, Pydantic for validating the model's JSON, SQLite for session history
UI: Streamlit with a sidebar for model, persona, focus and level
Voice (optional): faster-whisper, with filler-word counts

The flow is: resume text → structured profile → question plan → answer → score and feedback → optional follow-up → final report.

Everything behavioural lives in plain text: the prompts, three interviewer personas and a rubric.yaml with score anchors.

What went wrong: WRITE ONE REAL FAILURE. Ideas: the model gave 4 or 5 out of 5 to weak answers until I added explicit score anchors and told it to grade like a strict interviewer. Or the 7B model split between GPU and CPU on 6 GB of VRAM and was painfully slow, so I moved to the 3B model (X seconds per answer instead of Y).

Why Does Open Innovation Matter?

Privacy: a resume holds contact details and grades, and a mock interview records someone's honest mistakes. With a local open-weight model, none of it leaves the laptop.
Cost: practice only works in volume. With no per-token cost, FRIEND can do as many sessions as they want.
Swappable models: I compared MODEL A and MODEL B. INCLUDE A REAL OBSERVATION, e.g. speed and feedback quality.
Editable behaviour: the interviewer's strictness, persona and rubric are text files. I changed FRIEND's interviewer from one persona to another in seconds without touching code.
Offline: it works in a hostel with bad Wi-Fi.

What my friend said

I ran a mock interview with FRIEND_NAME, who is preparing for placements, and asked for honest feedback afterwards.

Their first reaction was a simple "wow."

What they found most useful was the improved sample answers and the review after each question. When I asked what the tool showed them that they hadn't noticed, they said: "I missed too many things, and this app pointed them out. I improved my answer."

I also asked whether any scoring felt unfair, since a strict grader is only useful if it's fair. They said no, the feedback looked fair to them.

Their verdict on using it again before placements: "Yes, it will help me a lot."

That last answer is what I built it for: a free place to practise as many times as they need, without a resume or answers going to anyone else's server.