DEV Community: Khushighosh

Let It Die: The Lazy Email Agent on TabPFN, Gemma and Temporal

Khushighosh — Sun, 25 Oct 2026 06:45:27 +0000

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

What I Built

Most “lazy” agents do your chores faster. Let It Die asks whether the chore needs doing at all.

It reads incoming email and scores each message on how likely it is that ignoring it would cost you something. Then it does one of three things:

Need you (top 20% by score): a local Gemma model writes a two-line summary and a suggested action for a morning digest.
Low priority (middle 60%): left alone and counted in the digest.
Let it die (bottom 20%): parked on a durable Temporal timer. If the sender follows up within 7 days, the email is escalated. If nothing arrives, it is archived.

Anyone whose inbox is full of mail that sorts itself out gets to be a little lazier: the cheapest task to finish is the one you never started, as long as you can tell which ones those are. On my held-out test slice of 1,981 emails, 398 (20%) were parked, and about 85% of them really got no reply.

Demo

Real output from a run on held-out email:

397 need you | 1186 low-priority | 398 parked on a timer (let it die)
In the 'need you' bucket, 46% were actually replied to (overall: 30%)

- john.henderson@enron.com | Wharton Tm #3 Presentation | he replied
  Summary: John reviewed the Wharton Tm #3 presentation and found it to be a good start.

In the parking demo, 8 emails were picked at random from the let-it-die bucket. 7 were archived, and all 7 truly needed no reply. 1 was escalated, because the sender wrote again.

Code

Khushighosh / let-it-die

Let It Die: an agent whose main skill is deciding not to act

Built for the Hacktoberfest Open-Source AI Challenge, Week 3 ("Slow and Steady").

Most "lazy" agents do your chores faster. This one asks whether the chore needs doing at all. It scores each incoming email on how likely ignoring it is to cost you something, then:

Need you (top 20% by score): a local Gemma model writes a two-line summary and a suggested action for the morning digest.
Low priority (middle 60%): left alone, counted in the digest.
Let it die (bottom 20%): parked on a durable Temporal timer. If the sender follows up within 7 days, the email is escalated. If nothing arrives, it is archived.

emails ──> TabPFN score ──> triage ──┬─ need you ──> Gemma summary ──> morning digest
                                     ├─ low priority ──> counted only
                                     └─ let it die ──> Temporal timer (7 days)
                                                         ├─

…

View on GitHub

MIT licensed. The README has the run steps (Windows, Python 3.12).

How I Built It

emails -> TabPFN score -> triage -+- need you -> Gemma summary -> morning digest
                                  +- low priority -> counted only
                                  +- let it die -> Temporal timer (7 days)
                                                    +- follow-up signal -> escalate
                                                    +- timeout -> archive

TabPFN (Prior Labs) predicts whether the owner replied within 7 days, from features built only from information available before each email arrived: sender history, who it was addressed to, time of day, subject and body cues, thread length. It needs no training run.
Gemma (gemma3:4b through Ollama, running locally) writes the summaries and suggested actions for the need-you bucket.
Temporal runs one workflow per parked email. It waits for either a follow-up signal or a 7-day timeout, then escalates or archives. My demo uses Temporal’s time-skipping test server, so a week of waiting runs in seconds. When I made the first archive attempt fail on purpose, Temporal retried every one automatically, and all 7 archived emails logged attempt 2.
Sentry traces the whole run: the agent, the triage step, each Gemma call (model, token counts, full prompt and response) and the Temporal step. About 22 of the 23 seconds were the five local Gemma calls, each with an HTTP call to 127.0.0.1, my own machine. Triage took about a millisecond and parking eight emails about 1.3 seconds.

The data. I don’t have a two-sided mailbox of my own, so I used one mailbox of about 28,000 messages from the public Enron corpus (CMU, May 2015 release), which includes sent folders and lets me derive reply labels. The label is “the owner replied in the same thread within 7 days.” Sent mail stops being archived after May 2001, so every later email would look unanswered; I cut the timeline to Nov 1999 through May 2001, which left 9,902 usable emails. I trained on the earliest 80% (7,921 emails) and tested on the latest 20% (1,981 emails, 70.5% of which got no reply). The split is by time, so the model never sees the future.

Model	ROC AUC	Ignore lowest 10%: truly no reply / replied-to mail missed	Ignore lowest 20%
Sender reply-rate rule	0.579	68.2% / 10.8%	73.7% / 17.8%
Gradient boosting	0.662	92.4% / 2.6%	88.4% / 7.9%
TabPFN	0.687	92.9% / 2.4%	84.6% / 10.4%

What I take from it:

Both models clearly beat a rule based on the sender’s past reply rate.
TabPFN’s AUC is higher by 0.024 (bootstrap 95% CI 0.003 to 0.043), but gradient boosting wins the 20% bucket. I call them comparable.
The practical headline: the agent can park about 1 in 10 emails and be right 92 to 93% of the time, missing about 2.5% of the mail that actually got a reply.
In the test slice, the need-you bucket was replied to 46% of the time against 30% overall, and the let-it-die bucket about 15%. It is a prioritizer, not an oracle.

What went wrong, and how I found it

Every file looked missing. Enron filenames end in a dot (1., 10.), and Windows quietly strips it, so Python saw an empty mailbox until I switched to Windows’ extended-length path prefix.
The first test set had no positives. The model scored a meaningless 98% accuracy. A month-by-month table showed replies falling to exactly 0 from June 2001, because the archive stops containing sent mail. I cut the timeline there.
Gemma summarized the wrong message. For an email where the sender wrote one line on top of a long forwarded chain, the summary described the oldest forwarded message. I found it by reading the cached email text next to the summary. Cutting each email at the first forwarded-message marker fixed that case: over five runs each (the last two of each at temperature 0 with a fixed seed), the unfixed version summarized the forwarded message every time and the fixed version summarized the sender’s reply every time. The prompt for that email also shrank from 649 to 90 tokens.

Limitations

“Replied within 7 days” is only a proxy for “needed action,” and “the sender wrote again” is a noisy follow-up signal. One escalated email in my demo came from a mailing list that re-sent the same subject line.
One mailbox, one time-based split. The bootstrap interval treats emails as independent, though threads and senders cluster, so it is probably a little too tight.
The parking demo uses 8 emails and a simulated clock, and “archive” writes to a log file instead of moving real mail.
Gemma output is not deterministic, and identical prompts varied about 2x in latency between runs, so I only quote token counts for the forwarded-chain fix. That fix is one email, not a benchmark, and suggested actions vary between runs.
Attachments aren’t in the email text, so suggested actions for attachment-only emails are generic.

Why Does Open Innovation Matter?

The model that reads my mail runs on my machine. Gemma runs locally through Ollama, and the Sentry trace shows every model call going to 127.0.0.1. There is no API bill and no third party reading the text.
The waiting is durable and I don’t run a scheduler. Temporal’s open-source tooling gave me timers that survive restarts and retries for flaky steps, with no cron job or home-made queue.
No training run. TabPFN fits a small personal mailbox without a training step. The honest caveat: I used the hosted API, so the 5,000 training rows went to Prior Labs’ servers. I only did that with the public Enron data, and a deployment on private mail would need local weights or to accept that tradeoff.
Anyone can reproduce the numbers. The data is public and the code is in the repo.

I didn’t test a hosted LLM, so I can’t claim open wins on summary quality. The case for open here is privacy, cost and not depending on a service staying up.

The Lazy Payoff

I haven’t pointed it at my own inbox, because I don’t have a two-sided mailbox, so these numbers come from public Enron mail, not from my own week. On the held-out slice of 1,981 emails, the agent would have taken 398 (20%) off the owner’s plate, and about 85% of those really got no reply. The price is the other 15%, about 60 emails that did get a reply and would have been archived unless the sender nudged again, which is about 10% of all the mail that was replied to. Each summary takes about 4 seconds on my laptop. I can’t honestly put a number on minutes saved, so I’m not going to.

Prize Categories

Best Use of TabPFN: the ignore-or-act predictor, compared with a rule and gradient boosting, with a bootstrap interval on the difference.
Best Use of Gemma: local gemma3:4b summaries and suggested actions, with a documented failure and fix.
Best Use of Temporal: one durable workflow per parked email, with a follow-up signal, a 7-day timeout and automatic retries.
Best Use of Sentry Agent Tracing: a trace of the whole run with token counts, prompts and responses, and the before and after of the forwarded-chain fix.

Using AI coding tools without losing your fundamentals

Khushighosh — Sun, 18 Oct 2026 18:21:17 +0000

AI can write a working login route in 10 seconds. That’s amazing, and also a little dangerous. If the tool always writes the code, you stop practicing the one skill the code depends on: understanding what it does and why it breaks.

I’m an engineering student who uses AI tools regularly. [One line on which tools you use and for what.] Here are the rules I follow to keep the speed without losing the skills.

The Problem: Code You Can’t Explain

The first warning sign is code that works but that you couldn’t rewrite. [Your example: a time AI-generated code ran fine, then broke, and you couldn’t tell why.]

When something fails, the AI can’t tell you whether the code matches what you meant. Only you can, and only if you understand it.

Attempt First, Then Ask

Spend 10 to 15 minutes on the problem before opening the tool. Even a failed attempt shows you where you actually get stuck, and it helps you judge the AI’s answer because you know what the question was.

Ask for Explanations, Not Just Code

Instead of “write a JWT logout route”, try “explain how logout works with stateless JWTs and what my options are.” Then write the code yourself. Use the tool as a tutor first and a code generator second.

Never Paste What You Can’t Explain

Before accepting generated code, explain every line to yourself, or to a rubber duck. If a line is a mystery, ask about that line. The test: could I recreate this tomorrow without the tool?

Read the Diff, Not Just the Result

“It runs” is not the same as “it’s correct.” Check these every time:

What happens on bad input, empty values, or a failed network call?
Did it add a dependency you didn’t need?
Does it match the conventions of the rest of your codebase?
Is anything hardcoded that shouldn’t be, like secrets or URLs?

AI is great at the happy path and often skips the rest.

Keep a No-AI Practice Habit

Pick one slot, such as one small project a month, where you work with no assistant. Think of it as gym time for your brain. It keeps your syntax recall, debugging and design instincts sharp.

Debug With Your Own Eyes First

Before pasting an error into a chat, read the stack trace and add logs or breakpoints. Reading errors is one of the most valuable skills you can have, and it’s the first to fade when you outsource it.

Verify Against the Docs

AI can confidently invent function names, options, and API behavior. When something looks unfamiliar, check the official documentation. [Optional: a time the tool gave you something that didn’t exist.]

Weekly Self-Check

Ask yourself:

Could I explain my last three changes to a teammate?
Did I fix my last bug by understanding it, or by retrying prompts until it vanished?
Could I build this feature without the tool, even if slower?

If any answer is “no,” slow down for a bit.

Final Thoughts

AI is good at producing code and bad at knowing what you need. That judgment is what makes you an engineer. Use the tool to move faster, but stay the person who understands the result.

What rules do you follow? Drop them in the comments.

6 Windows + Git traps I hit this week (and the 30-second fixes)

Khushighosh — Sun, 18 Oct 2026 06:55:19 +0000

I spent this week setting up a public GitHub repo on Windows. Almost every problem came from a tiny detail, and the error messages didn't explain any of them. Here are six, with the fixes.

1. `cd /d` fails in PowerShell

cd /d C:\Users\me\Desktop\project
Set-Location : A positional parameter cannot be found that accepts argument ...

/d is a Command Prompt option for switching drives. PowerShell doesn't need it. Check your prompt: if it starts with PS, you're in PowerShell, so just run:

cd C:\Users\me\Desktop\project

2. "Cannot find module" usually means "wrong folder"

Error: Cannot find module 'C:\Users\me\evaluate.mjs'

Read the path in the error. It shows the folder your terminal is in, not the folder you meant. Run cd into the project folder, then dir to confirm the file is really there.

3. Downloads quietly rename your files

Download the same file twice and Windows saves evaluate (1).mjs. Your code asks for evaluate.mjs and can't find it. Rename it:

ren "evaluate (1).mjs" evaluate.mjs

4. Notepad saves `.gitignore.txt`

Windows File Explorer hides file extensions by default, so a stray .txt is invisible. I ended up with both .gitignore and .gitignore.txt, and committed the wrong one by accident.

Turn on View → Show → File name extensions in Explorer.
In Notepad's Save As, put the name in quotes (".gitignore") and set "Save as type" to All files.
Run dir in the terminal. It shows the real names.

5. `git push` says "rejected (fetch first)"

! [rejected]  main -> main (fetch first)

It means GitHub already has commits your computer doesn't. This usually happens when you tick "Add a README / .gitignore / licence" while creating a repo, and then push your own project. Prevention: create the repo empty. If it's already happened:

git fetch origin
git log origin/main --oneline

Look at what's there. If you want to keep it, merge with git pull origin main --allow-unrelated-histories. If it's only auto-generated starter files you don't need, git push --force-with-lease replaces them, and it refuses if the remote changed since your last fetch. That makes it safer than a plain --force. Never force-push to a repo where other people have real work.

6. A page that calls an API can't be opened by double-clicking

Opening index.html from your folder gives it an address starting with file://. If the page fetches data from a local server, you get Failed to fetch. Start the server, then visit http://localhost:PORT in the browser.

Bonus: check before your first `git add .`

Write .gitignore first. Adding a file to .gitignore after you've committed it doesn't remove it from history.
Run git status before committing and read the list. Anything private (data files, .env, exports) shouldn't be there.

None of these took long to fix, but each one cost me ten minutes of confusion. Hopefully this saves someone else those minutes.

Three things that surprised me while building this: Re-runs were identical - Same model, same prompt, `temperature: 0`: byte-for-byte the same failures every time. That turned prompt tweaking into real A/B testing. A regex beat the prompt. I

Khushighosh — Sun, 18 Oct 2026 06:43:25 +0000

Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle Submission 💸

Khushighosh

Oct 15

Order Ledger: a WhatsApp-to-ledger side hustle that runs offline on open models

#devchallenge #hf26challenge #ollama #ai

5 min read

Order Ledger: a WhatsApp-to-ledger side hustle that runs offline on open models

Khushighosh — Thu, 15 Oct 2026 12:45:33 +0000

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

What I Built

Small sellers run on WhatsApp. A home baker, a tiffin service or a tailor gets orders like this:

C: bhaiya kal subah 20 samosa aur 1 dozen kachori chahiye
S: ho jayega, 20 samosa 10 rs each = 200, kachori 12 x 15 = 180. total 380
C: thik hai, paise delivery pe dungi. Neha, 9000000002

Then they copy it into a notebook, and a week later nobody remembers who paid the advance.

Order Ledger turns that chat into a structured order, shortened here:

{
  "customer": "Neha", "phone": "9000000002",
  "items": [
    { "name": "samosa", "qty": 20, "unit": "pcs" },
    { "name": "kachori", "qty": 12, "unit": "pcs" }
  ],
  "delivery_date": "2026-10-14", "delivery_time": "morning",
  "amount": 380, "paid": 0, "status": "confirmed"
}

The seller checks it on a review screen, saves it, and gets:

a schedule grouped by day, with "today" and "overdue" markers
pending payments, with the total owed and a button that copies a polite WhatsApp reminder
an all orders table with a CSV export for the accountant

Who would pay? Anyone who takes orders in chat and tracks them by hand: home bakers, cloud kitchens, tailors, small shops. The pain is the retyping and the money that slips through. Customer names, numbers and prices are also private, which is why the whole thing runs on the seller's own laptop.

It handles English, Hinglish and Kannada in English letters, and it accepts exported WhatsApp chats as they are.

Demo

The demo shows: pasting a WhatsApp-style chat, reading the order, fixing a field on the review screen, the schedule and pending-payments tabs, and then Wi-Fi switched off with one more order processed.

Code

Khushighosh / Order-Ledger

Order Ledger

Turn messy WhatsApp order chats into a clean order book. It runs entirely on your own computer with an open-weight model, so customer names, phone numbers and prices never leave your laptop.

Built for the Hacktoberfest Open-Source AI Challenge, Week 2 (Side Hustle).

Who it's for

Home bakers, tiffin and cloud-kitchen sellers, tailors and small shops who take orders over WhatsApp and keep track in a notebook. Their chats are messy: English mixed with Hindi or Kannada, "kal subah", "advance 500 diya", orders that change halfway through. You paste the chat, and the app turns it into a structured order.

What it does

Reads a pasted WhatsApp chat (an exported chat, text copied from WhatsApp Web, or lines typed with C: for the customer and S: for you) and extracts the customer, phone, items, quantities, delivery date and time, total, amount paid and status.
Shows the result on…

View on GitHub

MIT licensed. There is nothing to npm install:

ollama pull qwen2.5:7b
git clone https://github.com/Khushighosh/Order-Ledger.git
cd Order-Ledger
node server.mjs      # then open http://localhost:3000

How I Built It

The open pieces

Runtime: Ollama, serving qwen2.5:7b (4.7 GB) as the default and llama3.2:3b for comparison
App: Node.js with no packages (built-in http and fetch), one HTML file for the UI, and a JSON file for storage
Tests: a small evaluation harness I wrote for this

pasted chat ──► convertChat()  WhatsApp export → "C:" / "S:" lines (in the browser)
            ──► annotateDates() "kal" → "kal (2026-10-14)"
            ──► Ollama (qwen2.5:7b, temperature 0, JSON-schema output)
            ──► clean()         validate phone, units, dates (server)
            ──► review screen ──► orders.json ──► schedule / pending / CSV

1. Structured output, not "please reply in JSON"

Ollama accepts a JSON schema as format, so the model's reply always parses and uses only allowed values:

unit:   { anyOf: [{ type: "string", enum: ["kg", "pcs", "litre", "box"] }, { type: "null" }] },
status: { type: "string", enum: ["confirmed", "tentative", "cancelled"] },

The schema guarantees the shape of the answer, not that it's right. That gap is why there's a review screen and a test harness.

2. Let code do code's job

Small models are unreliable at date arithmetic, so the date lookup happens in code and the model only reads the result:

export function annotateDates(text, cal) {
  const rules = [
    [/\bday after tomorrow\b|\bparso\b/gi, cal[2].iso],
    [/\b(?<!after )tomorrow\b|\bkal\b|\bnale\b/gi, cal[1].iso],
    [/\baaj\b|\btoday\b/gi, cal[0].iso],
  ];
  let out = text;
  for (const [re, iso] of rules) out = out.replace(re, (m) => `${m} (${iso})`);
  return out;
}
// "nale 2 litre dosa hittu"  →  "nale (2026-10-14) 2 litre dosa hittu"

Phone numbers are cleaned in code too, because the model kept returning +91 90000 00009.

3. Measure everything

I wrote 18 synthetic WhatsApp-style chats (fake names and numbers) and hand-labelled the expected JSON for each. evaluate.mjs scores 9 fields per chat and breaks results down per field and per kind of chat (Hinglish, Kannada, same-day orders, "same as last time", and so on). With temperature: 0, re-running an unchanged prompt gave identical results, so every prompt change could be A/B tested.

Test set	Model	Before the date fix	After the date fix
12 chats (I tuned on these)	qwen2.5:7b	11/12 orders correct · 99% of fields	9/12 · 96%
12 chats	llama3.2:3b	1/12 · 82%	2/12 · 84%
6 fresh chats	qwen2.5:7b	3/6 · 91%	5/6 · 96%
6 fresh chats	llama3.2:3b	3/6 · 89%	3/6 · 91%

On a laptop the 7B model takes about 14 seconds per order once loaded (about 50 seconds for the first order while the model loads). The 3B takes about 7.

4. What went wrong (the useful part)

One extra example made the prompt worse. Adding a fourth few-shot example dropped the 7B from 10/12 to 7/12 orders correct. With that example in the prompt, the 3B answered "same as last time" by inventing a pineapple cake order. I removed the example and the score came back.
A date bug hiding in my prompt. For "aaj" (today) the 7B answered 2026-10-20, and for "nale" (Kannada for tomorrow) it answered 2026-10-17. The cause was that the date table in my prompt listed "Tuesday: 2026-10-20" (next week), and the test day was a Tuesday. The model read "today is Tuesday" and looked it up. I fixed it by labelling that row "next Tuesday" and moving the relative-date lookup into code. The fresh set went from 3/6 to 5/6.
Two of my labels were debatable. Is "2 meals" an item named "meal" in pcs, or "tiffin" in boxes? I left those as known misses instead of tuning them away.
The 3B is fast and wrong. Only 42% of its items were right on the 12-chat set, so I didn't ship it.

An honest note on the numbers: I used both test sets to tune the prompt, and the date fix came after looking at the fresh set's failures. Treat these as indicative, not a benchmark. That's the reason the review screen exists.

Why Does Open Innovation Matter?

Privacy by default. A chat contains customer names, phone numbers and prices. Here it never leaves the laptop: the server only listens on 127.0.0.1, and orders live in a local file.
No per-order cost. The marginal cost of an order is the electricity on the seller's laptop, so a small seller can use it as much as they like.
I could test and choose. In an afternoon I ran two models through the same harness, saw that the 3B wasn't good enough, and kept the 7B. Swapping a model is one setting (MODEL=...). With a closed API I couldn't have inspected the setup this way, and an API-side model update could silently change the results.
Reproducible. The same model, prompt and temperature: 0 gave identical results on re-runs, which made the debugging above possible.

The trade-off, honestly: I didn't benchmark a closed API, so I'm not claiming open models are more accurate. A hosted frontier model is probably better at the tricky chats and faster per order. What open models gave me is privacy, a zero running cost and full control. For a seller who handles customers' private data on a laptop, that was the better deal.

My Agent Session

I built this in a long chat session with Claude as a pair programmer. It drafted the first versions of the prompt, server and UI, and I ran everything on my own laptop, pasted the failures back, and made the decisions: which idea to build, which model to keep, what to revert. The best moments came from the failures, like the 2026-10-20 date bug.

Prize Categories

Overall winner (Side Hustle theme). Open-weight models (Qwen2.5 and Llama 3.2) running locally through Ollama are the core of the product, and the code is MIT-licensed on GitHub.

Go Outside, Take a Photo, Let a Tiny AI Argue About It 🌇

Khushighosh — Fri, 09 Oct 2026 20:36:06 +0000

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

I asked a small AI model on my laptop to tell me how the sky changed between two sunsets. It told me there were more clouds in the first photo. Then I swapped the photos, and it said the exact same thing.

What I Built 🌇

Same Spot is a "what changed?" machine for the sky. 🌤️

Every evening the sky puts on a different show. Same terrace, same skyline, completely different mood. I wanted to know whether a small AI model running on my own laptop could notice those differences the way I do: more clouds, a pinker sky, a hazier horizon, or the camera simply pointing somewhere else.

How it gets you outside 🚶‍♀️
The photos are the whole point. You step outside at sunset, take a picture from the same spot, and go back to your life. The laptop only comes in afterwards, so the screen is the shortest part of the experience.

Who it's for 🌿
Anyone who keeps a loose record of a place: gardeners watching a patch of soil, hikers returning to a viewpoint, bird watchers, or people who just like watching the same sky.

The twist 🔄🧐
I don't trust the model's first answer. Every pair of photos is compared twice, in both directions, and I then check each claim against my own eyes. That's how I caught it inventing shadows, missing camera movement, and giving the same answer no matter which photo came first.

Everything runs offline on a CPU-only laptop, with no cloud, no account and no uploads. ☁️🚫

Demo

Code

Khushighosh / same-spot

# Same Spot

A local, no-cloud tool that compares photos of the same outdoor spot taken on different evenings, using an open-weight model (Gemma 3 4B via Ollama) on a CPU-only laptop.

## How it works

- run\_all.py sends each pair of photos to Gemma 3 in both directions (forward and reversed)

- results are saved to SQLite and rendered in results.html

- a claim only counts if it survives the swap AND matches what I can see

## Run it

1. Install Ollama and run ollama pull gemma3:4b

2. pip install ollama pillow

3. Edit the PHOTOS list in run\_all.py, then python run\_all.py

Findings

Brightness and warmth: often right, but not always (it once called the 9 Sept sky more orange, which was wrong).
Framing: after the prompt fix it notices the framing differs in every run, but understates it ("slightly different").
Position bias: in one pair it…

View on GitHub

Screenshots of the comparison

How I Built It 🛠️🤖

Model: Gemma 3 4B, an open-weight model that can read images, run through Ollama.
Hardware: an Intel i7-13620H laptop with 16 GB RAM and no GPU. Each comparison took about 60 seconds (58 to 64 s across my runs).
Pipeline: a Python script resizes each photo, sends a pair to Gemma, saves the result in SQLite, and builds a plain results.html page with the photos and findings side by side.
The method that mattered: every pair is compared in both directions (A to B, then B to A). A real finding should flip when I swap the order, and I then check each claim against my own eyes.

What went wrong first. My first prompt made the model invent shadows in silhouette scenes, say "city skyline remains consistent" when the foreground had completely changed, and treat a placeholder I forgot to replace ("EDIT TIME") as a real time of day. It also mixed up two causes: my photos were taken on different days and at different minutes relative to sunset, so "brighter" could mean either.

What I changed. I told the model roughly when sunset is, asked it to say whether the framing differs before comparing anything, removed shadows from the prompt, and made it put anything it couldn't judge into an "uncertain" list.

Results after the fix 📊, scored by me against the photos:

Pair	Direction	✅Correct	⚠️Debatable	❌Wrong
9 Sept to 16 Sept	forward	3	1	1
9 Sept to 16 Sept	reverse	2	2	0
16 Sept to 19 Sept	forward	4	1	0
16 Sept to 19 Sept	reverse	2	1	2

11 of 19 claims correct, 5 debatable, 3 wrong: useful, but not trustworthy on its own.

What improved: no more invented shadows, the model now notices that the framing differs in every run, and it names specific foreground objects correctly (a dark metal beam in one photo, a blue roof in another).

What still fails: it understates the framing change ("slightly different" when the camera angle is clearly different), and in one pair it said "more clouds in Image 1" in both directions, attaching the claim to whichever photo came first. It also got the sky colour wrong in one run. That is exactly the kind of mistake the both-directions check exists to catch.

What I'd try next: describe each photo on its own first, then compare the two text descriptions, so the model never sees two images in a fixed order. I'd also mount my phone in one spot on the terrace, so the framing stays the same and the sky is the only thing that changes.

Why Does Open Innovation Matter? 🔓💻

Because the best thing I found only happened because I was allowed to poke the model. 🔄

Catching the position bias meant running every pair twice, rewriting the prompt again and again, and reading the raw output. With Gemma on my laptop, each extra run cost me about a minute and nothing else. Free to re-run meant free to doubt.

🔒 My sunset photos never left my laptop. The only copies online are the ones I chose to publish here.
🔁 I could cross-examine it. I controlled the model and the prompt, so I could swap the photo order, read what it actually said, and spot the invented shadows and the "more clouds in Image 1" habit.
📡 It works anywhere. No account, no connection, and no GPU, just a CPU-only laptop.

A bigger closed model would probably describe the sky better, and I'd rather say that than hide it. But I'd have had to trust its answer. With this one, I could check it.

Prize Categories

Best Use of Gemma 🤖: Gemma 3 4B is the whole engine. It's small enough to run locally through Ollama on a CPU-only laptop (about 60 seconds per comparison), and it reads images, so it could compare my sunset photos directly. I then tested it by running every pair in both directions and scoring 19 of its claims against the photos. That showed what Gemma gets right (named foreground objects), where it struggles (understating camera movement), and where it shows position bias.

Study Buddy: an offline GATE study partner for my friend, built with Ollama

Khushighosh — Sun, 04 Oct 2026 20:47:08 +0000

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

What I Built

Study Buddy is an offline exam study partner I built for my friend Anushka, who is preparing for GATE.

GATE has a huge syllabus, and she wanted quick answers and practice questions from her own notes. I also wanted her study material to stay on her laptop and not go to someone else's server.

You add your notes (PDF, text or markdown) to a folder, and Study Buddy does three things:

Answers from your notes only. Every answer cites its source, like [notes.pdf p.3]. If the notes don't cover a question, it says so instead of guessing.
Quizzes you on your own material. It writes multiple-choice questions from the notes and explains each answer with a pointer to the source.
Tracks your weak spots. It remembers which topics you get wrong and lets you practice them, so it works like a study partner and not just a chatbot.

Everything runs on a laptop. After the one-time download of the models, nothing is uploaded anywhere and it works with Wi-Fi off.

Demo

What Anushka said after using it:

I usually spend a lot of time searching through my GATE notes whenever I get stuck on a topic. With Study Buddy, I can just ask a question and get an answer directly from my own notes, along with the page where it came from.

The quiz feature is my favorite because it helps me figure out which topics I actually don't understand instead of just rereading everything. And knowing that my notes stay on my laptop makes me much more comfortable putting all my study material into it.

Code

Khushighosh / study-buddy

Offline exam study buddy: ask questions and get quizzes from your own notes, using Ollama, local embeddings and ChromaDB. Nothing leaves your laptop.

Study Buddy

An offline exam study partner built for a friend. It answers questions and generates quizzes from their own notes, running entirely on a laptop with open models. Nothing is uploaded anywhere.

Features

Ask questions and get answers with citations to the notes
Says "This isn't covered in your notes" instead of guessing
Multiple-choice quizzes generated from the notes
Tracks weak topics and offers to practice them

How it works

ingest.py splits your notes into chunks and embeds them with nomic-embed-text into a local ChromaDB store.
For each question, the closest chunks are retrieved and passed to qwen2.5:7b with strict instructions to answer only from them and cite the source.
Quiz mode asks the model for one multiple-choice question per chunk as JSON, validates it, and logs each result in SQLite so weak topics can be practiced again.

Stack

Ollama (qwen2.5:7b and nomic-embed-text), ChromaDB, SQLite, FastAPI, plain HTML.

Tested

…

View on GitHub

How I Built It

The whole thing is open-source and local:

Ollama runs the models on the laptop.
qwen2.5:7b (open-weight) writes the answers and quiz questions.
nomic-embed-text (open-weight) turns notes into embeddings.
ChromaDB stores the vectors locally; SQLite stores quiz results.
FastAPI serves a small plain-HTML page, so it's used in a browser and not in a terminal.

How it works:

ingest.py extracts text from the notes, splits it into overlapping chunks, and stores each chunk with its file name and page number so answers can cite sources.
For each question, the closest chunks are retrieved and passed to the model with strict instructions: answer only from these notes, cite them, and say so if the answer isn't there.
For quizzes, the model is asked for one question as JSON (topic, question, four options, answer_index, explanation). The code validates the JSON and retries once if it's malformed.
Each answer is logged in SQLite by topic, so "Practice my weak topic" picks the topic with the lowest accuracy.

Tested on: a Windows laptop with 16 GB RAM, an Intel Core i7-13620H and no dedicated GPU, so everything runs on the CPU. Timings were about 55 s for the first answer after starting the server (the model has to load), about 42 s for a normal answer, and about 35 s per quiz question. That's slower than a cloud chatbot, but it works on an ordinary laptop.

Limitations: a 7B model can still misread a passage, so every answer shows its source for checking. Answers are slow on a CPU-only laptop, and notes are added through a folder and an indexing command, not an upload button.

Why Does Open Innovation Matter?

Privacy: notes never leave the laptop. With a closed API, every question would have sent her study material to a server I don't control. Here I could demo it with Wi-Fi off.
Cost: it costs nothing per question, so people can ask as much as they like during revision.
Control: the models are open weights, so swapping one is a one-line change (CHAT_MODEL in rag.py), which lets someone with a weaker laptop trade answer quality for speed. I also wrote the prompts so the model refuses when the notes don't cover something, which matters for exam prep.
Reproducible: anyone with a similar laptop can run it from the README. There are no API keys or accounts.

DEV Community: Khushighosh

Let It Die: The Lazy Email Agent on TabPFN, Gemma and Temporal

What I Built

Demo

Code

Khushighosh / let-it-die

Let It Die: an agent whose main skill is deciding not to act

How I Built It

Why Does Open Innovation Matter?

The Lazy Payoff

Prize Categories

Using AI coding tools without losing your fundamentals

6 Windows + Git traps I hit this week (and the 30-second fixes)

1. cd /d fails in PowerShell

2. "Cannot find module" usually means "wrong folder"

3. Downloads quietly rename your files

4. Notepad saves .gitignore.txt

5. git push says "rejected (fetch first)"

6. A page that calls an API can't be opened by double-clicking

Bonus: check before your first git add .

Three things that surprised me while building this: Re-runs were identical - Same model, same prompt, `temperature: 0`: byte-for-byte the same failures every time. That turned prompt tweaking into real A/B testing. **A regex beat the prompt.** I

Order Ledger: a WhatsApp-to-ledger side hustle that runs offline on open models

Order Ledger: a WhatsApp-to-ledger side hustle that runs offline on open models

What I Built

Demo

Code

Khushighosh / Order-Ledger

Order Ledger

Who it's for

What it does

How I Built It

1. Structured output, not "please reply in JSON"

2. Let code do code's job

3. Measure everything

4. What went wrong (the useful part)

Why Does Open Innovation Matter?

My Agent Session

Prize Categories

Go Outside, Take a Photo, Let a Tiny AI Argue About It 🌇

What I Built 🌇

Demo

Code

Khushighosh / same-spot

Findings

Screenshots of the comparison

How I Built It 🛠️🤖

Why Does Open Innovation Matter? 🔓💻

Prize Categories

Study Buddy: an offline GATE study partner for my friend, built with Ollama

What I Built

Demo

Code

Khushighosh / study-buddy

Offline exam study buddy: ask questions and get quizzes from your own notes, using Ollama, local embeddings and ChromaDB. Nothing leaves your laptop.

Study Buddy

Features

How it works

Stack

Tested

How I Built It

Why Does Open Innovation Matter?

1. `cd /d` fails in PowerShell

4. Notepad saves `.gitignore.txt`

5. `git push` says "rejected (fetch first)"

Bonus: check before your first `git add .`

Three things that surprised me while building this: Re-runs were identical - Same model, same prompt, `temperature: 0`: byte-for-byte the same failures every time. That turned prompt tweaking into real A/B testing. A regex beat the prompt. I