DEV Community: Vedant Gajbhiye

Revenant: dead programming languages haunt my terminal, no internet required

Vedant Gajbhiye — Sat, 31 Oct 2026 22:16:53 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

Revenant is a ghost that moves into your terminal. COBOL, Fortran, Lisp and Perl, four languages people keep declaring dead, each get a voice and comment on the commands you run. Real lines from my laptop, generated locally by Qwen2.5:

Fortran, on chmod -R 777 .: Permissions set like this? Insecure, like an open door in Los Alamos.

Perl, on a failed docker build: Dockerfile issues? I'd have just s/Dockerfile/sourcecode/ and hoped for the best.

It comes in three parts:

The haunting. A bash/zsh hook sends each failed or dangerous command to a local model, and a spirit whispers back under your prompt. It never holds your prompt for more than 4 seconds, and if the model's reply isn't good enough, the ghost stays silent.
The Séance Room. A web page on localhost where you can talk to a spirit. The cartoon ghost's mouth moves with every token streamed from your own model, and a status bar shows "Network off, still haunting" when you pull the plug.
The Ofrenda. On Día de los Muertos families build an altar for the people they remember. ghost ofrenda builds one for the projects you stopped working on: it scans your git repos, writes each abandoned one an epitaph and an offering, and produces a single HTML page where you light a candle for each. I built this as a pair with Claude (Sonnet 5.5) in Claude Code.

Demo

Video (Wi-Fi visibly off): https://youtu.be/qdP6pVRpLjI
Live Ofrenda demo (fictional projects): https://revenant-ofrenda.onrender.com (a static page hosted on Render; the projects on it are made up so I don't publish my own repo names)
The Séance Room needs a local Ollama, so it can't be hosted. That is the point.

The Ofrenda: one candle per abandoned project

The Séance Room: chatting with a spirit, running locally

In the terminal: a spirit whispers after a failed command

Code

vee-1745 / vee-1745-revenant

Dead programming languages haunt your terminal. Local open-weight models, no cloud.

👻 Revenant

Dead programming languages haunt your terminal. Everything runs locally on open-weight models via Ollama. No API keys, no network, no command history leaving your machine.

Quick start (WSL / Linux)

git clone https://github.com/vee-1745/vee-1745-revenant && cd vee-1745-revenant

# 1. a local model
ollama pull qwen2.5:3b   # COBOL, Lisp
ollama pull qwen2.5:7b   # Fortran, Perl (they need the bigger model)

# 2. check the plumbing
python3 ghost.py doctor

# 3. meet a spirit
python3 ghost.py summon cobol
python3 ghost.py demo

# 4. let it haunt your shell (add to ~/.bashrc, then open a new terminal)
echo "eval \"\$(python3 $PWD/ghost.py hook bash)\"" >> ~/.bashrc   # run from this folder

After the hook is loaded, ghost is available as a command:

ghost spirits               # list the dead
ghost summon lisp           # swap the spirit
ghost summon perl --model llama3.2:3b   # swap spirit and model
ghost

…

View on GitHub

MIT licensed. Python standard library only, with no pip dependencies and no build step. Setup is git clone, ollama pull qwen2.5:3b qwen2.5:7b, python3 ghost.py doctor.

How I Built It

Stack. Ollama running Qwen2.5 3B and 7B, on a laptop with an RTX 3050 (6 GB VRAM) inside WSL2. The backend is plain Python, and the UI is vanilla JS and hand-drawn SVG with the fonts bundled.

A persona is not a system prompt. My first test was "say boo in the voice of a bitter COBOL ghost". The 3B model replied with a description of what such a ghost would sound like. The fix was a system prompt plus few-shot examples written as real chat turns, with a random 4 of 8 shown on each call so the model can't memorize one set. My first demo still parroted the examples back at me, because I had reused the example commands as demo commands.

Measure, don't trust vibes. My first quality metric said "100% usable" everywhere. It only checked that a reply existed, so it was useless. I wrote validators per spirit: COBOL must be at least 90% caps, Lisp needs an s-expression, Perl needs line noise, Fortran needs era vocabulary, and a global filter rejects advice-shaped phrasing, because a ghost that says "be careful with force pushes" has broken the spell. Then I benchmarked both models on commands the spirits had never seen:

spirit	3B first try	3B ≤3 tries	3B median	7B first try	7B ≤3 tries	7B median
COBOL	67%	100%	0.71 s	83%	100%	1.14 s
Lisp	92%	100%	0.57 s	100%	100%	0.78 s
Perl	42%	75%	1.15 s	67%	100%	0.93 s
Fortran	25%	42%	1.21 s	50%	83%	1.17 s

Medians are per generation attempt, so a whisper that needed retries takes longer. Two things I took from this. First, the retry loop is the feature: 7B Fortran passes only half the time on the first try but 83% within three, and 7B Perl goes from 67% to 100%. Second, the model should be chosen per persona. COBOL and Lisp pass 100% on the 3B model and it is 25-40% faster for them, while Fortran (42% on 3B) and Perl (75% on 3B) need the 7B one. Each spirit names its own model in its config file.

Caveats: that is 12 whispers per cell, so treat it as indicative, not statistics. I wrote the validators after reading samples from an earlier run, and "pass" measures form (caps, s-expressions, no advice), not whether a line is funny.

The Ofrenda is grounded in git. The scanner runs read-only git commands and collects the facts: dates, commit count, languages, the last commit message, and unsaved changes. The cause of death ("Died mid-refactor", "Died with 1 unsaved change") comes from plain heuristics on those facts, so the model never has to guess one. The model writes only the epitaph and the offering. Every epitaph is fact-checked: a digit that isn't in the repo's facts rejects the draft, and after three rejected drafts the page falls back to a plain template and says so in its footer. On my real repos the model passed on the first try.

Built as if the page would be exposed. The Séance Room binds to loopback only and rejects foreign Host and Origin headers. The Ofrenda is one self-contained HTML file with a Content-Security-Policy that allows a single hashed script and nothing from the network. Commit messages are untrusted input, so by design they only ever go into the page as plain text, never as HTML.

Why Does Open Innovation Matter?

Your shell history is private. The commands you type contain paths, project names, and sometimes secrets. A shell hook that sent them to a cloud API would be a bad idea. Revenant works with the Wi-Fi off, and the Séance Room page says so on screen.

Free inference changes the design. The hook fires on every failed command, and the retry-until-valid loop can generate three times per whisper. On a metered API that would be a bill and a rate limit. Here a generation costs about 0.6 to 1.2 seconds of my own GPU. The validate-and-retry approach only makes sense because retries are free.

I could pick a model per character. Because the weights are open, I benchmarked two sizes and routed each spirit to the one that worked, instead of taking whatever one model a service gives me.

The Ofrenda reads my project history. Repo names and commit messages stay on the machine that holds the repos. The epitaph is written by the same laptop.

It can't be switched off. This week's theme is honoring the past. A tool built on a hosted model dies when the service does. Open weights and a local runtime keep working after the vendor is gone, which seemed right for a project about things that outlived their eulogies.

Where a closed model would have done better: persona quality. The 3B model drifts into advice, and even 7B needs the retry loop. A frontier model would probably nail the voice on the first try. For this project, I took a slightly worse ghost that is private, free and offline.

The Spirit of It

One of the first whispers I got after installing the hook was about the command I used to summon it. The Fortran spirit looked at my python3 ghost.py and said:

Python dares to summon such spirits. Fortran would have used punched cards for this.

Another time, a mistyped tar command got this from Perl: "Path is wrong, or permissions fail. tar -f help?"

Every project in that altar started with someone excited to type git init. If one of yours is on the altar, light a candle for it.

Prize Categories

Best Use of Render: The Ofrenda demo page is hosted as a Render static site at https://revenant-ofrenda.onrender.com. To be upfront about the scope: Render only serves the finished page. The models run locally through Ollama, and the Séance Room can't be hosted because it needs a local model.

StudyLens: Notes to Study Kit

Vedant Gajbhiye — Mon, 26 Oct 2026 09:16:11 +0000

Tagline: Upload photos of your notes and get a summary, flashcards and a quiz in English, Hindi or Marathi.

Prize categories: Best Use of Gemma 4 | Best Open-Source AI Project

Links

Live demo: https://notes-to-study-kit.onrender.com/
GitHub: https://github.com/vee-1745/notes-to-study-kit
Demo video: https://drive.google.com/drive/folders/1YyzhiPwTskubGrTSP_SS-op8aK4WeyAW?usp=drive_link

Inspiration

Students already take photos of notes, whiteboards and textbook pages. Those photos pile up in a camera roll and never turn into revision. Making flashcards and practice questions by hand takes longer than studying itself, so most people skip it. We wanted a tool where the photo is the only input.

We also wanted it to work in the languages students actually think in. Many students read English notes but revise more comfortably in Hindi or Marathi, so the kit can be generated in any of the three.

What it does

Upload one to four photos of handwritten notes or a printed page. Notes to Study Kit returns:

a title and a bullet-point summary
key terms with definitions
flashcards you can flip through
an interactive multiple-choice quiz with instant feedback, explanations and a score

You choose the output language (English, Hindi, Marathi), how many flashcards and questions you want, and which Gemma 4 model to use: a fast one for most pages, or a larger one for messy handwriting and dense pages. The kit is built only from what is visible in the photos, so it studies your notes, not a generic version of the topic. The interface is minimal and responsive, with System, Light and Dark themes.

How we built it

Gemma 4 is the core of the app. It runs through the Gemini API and reads the note photos directly, so there is no separate OCR step. One multimodal call turns the image into a structured study kit. Users can switch between gemma-4-26b-a4b-it (faster) and gemma-4-31b-it (higher quality). The server only accepts those two model names.
Flask backend with a structured prompt that asks for one JSON object. The server then validates it: every quiz question must have exactly four options and a valid answer index, malformed items are dropped, and unparseable output is retried once.
Vanilla HTML, CSS and JavaScript frontend with no build step: drag-and-drop upload, flip cards, a scored quiz, and a theme switcher that respects the device setting.
Hosted on Render with gunicorn, deployed from the GitHub repo. The API key lives in an environment variable, never in the code.
Open source under the MIT license, with a README, .env.example and contribution ideas.

Challenges we ran into

Getting dependable structured output from an open model. The model can wrap JSON in markdown fences or add a sentence before it. We extract the JSON object defensively, validate every field, and retry once before showing an error.
Trusting the output. A study tool that invents facts is worse than none. The prompt tells the model to use only what the notes say and skip anything unreadable, and the UI reminds students to check important facts.
Protecting a public demo. An open endpoint backed by an API key can be drained, so we added file type and size limits, an allowlist of models, and a per-IP rate limit.
Multilingual quizzes. Keeping questions, options and explanations all in the chosen language, while the answer index stays machine-readable, needed a strict output schema.

Accomplishments that we're proud of

A single photo becomes four study formats in one model call.
It runs end to end on free tiers: Gemma 4 through the Gemini API and a free Render instance.
The whole app is small enough to read in one sitting, which makes it a good base for contributors.

What we learned

Gemma 4's image understanding is good enough to replace a separate OCR pipeline for typical note photos.
With open-weight models, the validation layer around the model matters as much as the prompt.
Letting users choose between a fast and a higher-quality model is a simple way to trade speed for accuracy.

What's next

PDF and multi-page document input
Export flashcards to Anki
Saved kits and spaced-repetition scheduling
More languages
Self-hosting an open-weight model so the app does not depend on a hosted API

Built with

Gemma 4, Gemini API, Python, Flask, gunicorn, HTML, CSS, JavaScript, Render, GitHub

Sloth Commit: a local AI that writes your commit messages and splits the messy ones

Vedant Gajbhiye — Sun, 25 Oct 2026 06:02:58 +0000

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

What I Built

Writing a commit message is the smallest chore in programming and the one I put off the most. So I built Sloth Commit: a command-line tool where a local open-weight model reads your staged diff and writes the message for you.

git add .
git commit        # the editor opens with the message already written

The model runs on my own laptop through Ollama. The tool is plain Python with no dependencies beyond the standard library. A diff is just your unreleased source code, and it never leaves the machine.

Writing a message from a diff is a one-line idea, so I spent the effort on the parts around it:

Style Mimic. It reads your repo's last 30 commits and copies how you write: Conventional Commits or plain subjects, casing, trailing periods, emoji, typical length. There's no config file, and it adapts to whatever repo you drop it into.
Secret Guard. Before a diff goes anywhere, it scans the staged changes for API keys, tokens, private keys, .env files and huge binaries, then warns you.
Commit Splitter. If you staged a bug fix and a README tweak together, it proposes separate commits, each with its own message, and makes them after you confirm.
Slow-and-steady mode. A small model drafts the message in a second or two. With --slow, a bigger model polishes the draft. Speed is a dial you control.
Sloth Stats and Standup. A local tally of the time you saved, with a sloth, and sloth-commit standup, which turns your week of commits into a few bullets. Anyone who has typed fix stuff at 1 a.m. gets to be a little lazier, and the history still comes out readable.

Demo

I ran it on a real project of mine, a clinical NLP pipeline, on a laptop with 16 GB RAM and an RTX 3050 with 6 GB of VRAM, using qwen2.5-coder:3b:

PS> sloth-commit doctor
ok    inside a git repository
ok    Ollama is running at http://localhost:11434 (1 models)
ok    fast model qwen2.5-coder:3b

PS> sloth-commit style
Learned from 7 recent commit(s):
  format    plain subject lines
  casing    Capitalised first word
  period    no
  emoji     no
  length    ~60 chars (limit 91)

PS> sloth-commit msg
Asking qwen2.5-coder:3b...
Update README.md with detailed project information

The reply took a second or two. Style Mimic worked: my repo uses plain, capitalised subjects with no period, and that is exactly what came back, not the Conventional Commits default.

The message itself was only half right, and I'd rather show that than hide it. My test change was four comment lines added to frontend/app.py, plus a README edit that only removed a trailing newline. The model wrote about the README and ignored the code. My guess is it anchored on the first file in the diff, but I haven't tested that. This is the kind of mistake a 3B model makes on a tiny, odd diff, and it's why the tool shows the message and asks for confirmation instead of committing silently.

Code

vee-1745 / vee-1745-sloth-commit

sloth-commit

A lazy git commit assistant. A local open-weight model (via Ollama) reads your staged diff and writes the commit message, so you don't have to. Your code never leaves your machine, it works offline, and it costs nothing to run.

Zero Python dependencies: standard library only.

$ git add
$ git commit            # editor opens with the message already written

What makes it different

Feature	What it does
Style Mimic	Reads your repo's last 30 commits and copies the conventions (Conventional Commits or plain, casing, length, emoji). No config file.
Secret Guard	Scans staged changes for API keys, tokens, private keys, `.env` files and huge binaries before the model or your history sees them. Local regexes, so nothing is uploaded to check.
Commit Splitter	Spots unrelated changes in one staged diff (a fix plus a README tweak) and commits them separately, each with its own message. Splits

…

View on GitHub

How I Built It

The open pieces are what make it work:

Open-weight model via Ollama. The default is qwen2.5-coder:3b, which fits comfortably in 6 GB of VRAM. The slow model defaults to qwen2.5-coder:7b. Both are config, not code, so any model Ollama can run works.
A tiny Ollama client in the standard library. One HTTP call to /api/chat, with clear errors for the failures people actually hit: Ollama isn't running, or the model isn't pulled (it tells you the exact ollama pull command).
Diffs trimmed for small models. Lock files and binaries are summarised, each file and the total are capped, and the model is told when the diff was cut. A 3B model does much better with a focused diff than with 4,000 lines of package-lock.json.
Output cleaning. Small models love wrapping answers in code fences, quotes, "Here is the commit message:" or <think> blocks. All of that is stripped.
A hook that never gets in the way. sloth-commit hook install adds a prepare-commit-msg hook. It does nothing for -m, merges, squashes or amends, and if Ollama is down it silently lets you type the message yourself. It will never be why a commit fails, apart from one opt-in: SLOTH_GUARD=block stops commits that contain suspected secrets.
A splitter that fails safely. It groups whole files, never hunks. It refuses files that are partly staged, so it can't pull unstaged work into a commit. All the messages are written before the index is touched, so a model failure can't leave things half-rearranged, and if a commit fails mid-way the remaining files are staged again.
44 tests against a fake Ollama server. They run with no GPU and no network, and include real git commit runs through the installed hook.

Why Does Open Innovation Matter?

Your diff is your source code. Hosted commit tools have to upload it to work. Sloth Commit can't, because there is nowhere for it to go. For private or unreleased projects, that's the whole difference.

Secret Guard only makes sense locally. Checking a diff for leaked API keys by sending it to someone else's server is a good way to leak the keys. With a local model, the scan, the prompt and the answer all stay on the machine.

It's free and works offline. No API key, no per-token bill, no rate limit. It works on a train, on campus Wi-Fi, or on a plane.

It's swappable. If a better small coding model appears next month, it's one environment variable: SLOTH_MODEL=.... You can also point it at another machine on your network or at your own fine-tune. A closed API gives you whichever model the provider decides to serve.

I didn't run a head-to-head benchmark against a hosted model, so I won't quote a number. A frontier model would very likely have described the app.py change that my 3B model missed. For me, a message that is good most of the time, is instant, and is free and private beats one that is slightly better but sends my code to a server I don't control. Where it isn't good enough, --slow and the confirm step catch it.

The Lazy Payoff

The model answers in a second or two on a 6 GB laptop GPU, which is faster than I can think of a message, let alone type one. I used it on my own repo this week, and the tool keeps a local tally (sloth-commit stats) of characters you didn't type and time saved. That estimate is based on assumed typing speed, so treat it as a rough figure. What I really gained is a repo history in a consistent style that I no longer have to think about.

Prize Categories

Gemma: Sloth Commit is model-agnostic, so I swapped Google's open-weight Gemma into it with one environment variable (SLOTH_MODEL=[the exact Gemma model name you pulled]) and compared it with Qwen on the same staged diff. [One or two honest sentences on what you saw, for example whether it described the app.py change that Qwen missed, or which one was faster on the RTX 3050.]

A huge shoutout to claude and shreyashkakad for contributing (https://dev.to/shreyashkakad)

BillSift: a local GST bill sorter that double-checks its own AI

Vedant Gajbhiye — Sat, 17 Oct 2026 06:20:38 +0000

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

What I Built

BillSift turns a folder of bill photos and PDFs into a clean spreadsheet for your CA, entirely on your own laptop.

Anyone in India who runs a small shop, freelances, or works with a Chartered Accountant ends up with a pile of GST bills: petrol pumps, restaurants, hardware shops, online orders. Someone has to read each one and type the vendor, GSTIN, date, taxable amount, CGST/SGST/IGST and total into a sheet. That someone is usually the CA's staff, once a quarter, and a wrong digit causes trouble at filing time.

Who would pay: freelancers and small shops who want to hand their CA clean data, and small CA practices that spend staff hours on data entry. I haven't sold it yet, so this is a prototype and not a business. But a per-client price only works if the cost per bill is close to zero, and local models give you that.

What it does:

Drop in photos or PDFs of bills (PNG, JPG, PDF).
A local model reads each bill, then plain code checks the result before anything is exported.
Bills where something doesn't add up are marked ⚠️ with the exact reason, and you fix them in a table.
Correct a category once and every bill from that vendor gets it, past and future.
Export one Excel file: Bills, a GST summary by financial year / quarter / month, a By Category sheet, and a Needs Review sheet. CSV too.

Demo

Live demo: https://billsift-demo.onrender.com

Press Try it with 11 sample bills to see it work: most pass every check, and 3 are flagged for review, with the reason shown for each. It runs on Render's free tier, so the first visit after a quiet spell can take about a minute while the server wakes up.

The hosted copy is deliberately limited. A free server has 512 MB of RAM and no GPU, so it has no AI model, it only shows pre-processed synthetic sample bills, and uploads are switched off. That also means nobody's real bills ever reach a server. The full version runs on your own laptop with a local model.

Code

vee-1745 / billsift

🧾 BillSift

A local, privacy-first GST bill sorter for freelancers, small shops and their CAs.

Drop in photos or PDFs of bills. BillSift reads them with open-source OCR and a small open-weight LLM running on your own laptop, then checks the result with plain code before anything reaches your spreadsheet. Your clients' financial documents never leave your machine and there is no per-page API bill.

Why a verification layer?

Small local models make small mistakes: a swapped digit, a wrong field. In accounting a silently wrong digit is worse than a missing one. So the model's output is never trusted as-is:

Check	What it catches
GSTIN format + official mod-36 checksum	mistyped or misread GSTINs
Tax maths (rate x taxable = CGST+SGST / IGST)	wrong amounts, wrong rate
CGST = SGST, not mixed with IGST	swapped or misread tax lines
Taxable + tax = total (₹1 round-off allowed)	tampered or

…

View on GitHub

Run it: pip install -r requirements.txt, ollama pull qwen2.5:3b, streamlit run app.py. Setup steps are in the README.

How I Built It

photo / PDF -> RapidOCR (open source, CPU) -> small LLM via Ollama (JSON-schema constrained)
            -> verification layer (plain code) -> SQLite -> review UI -> Excel / CSV

Open pieces: RapidOCR for text, Ollama serving open-weight qwen2.5:3b and gemma3:4b, PyMuPDF for PDFs, SQLite, and Streamlit.

The idea: the model is an untrusted component. Small models make small mistakes, like a swapped digit or a wrong field, and in accounting a silently wrong number is worse than a missing one. So nothing the model returns is trusted until code has checked it:

Check	What it catches
GSTIN format + the official mod-36 checksum	mistyped or misread GSTINs
Tax maths: rate x taxable = CGST+SGST or IGST	wrong amounts, wrong rate
CGST = SGST, never mixed with IGST	swapped or misread tax lines
Taxable + tax = total (with round-off tolerance)	misread or tampered totals
Grounding: every amount, GSTIN and invoice number must literally appear in the OCR text	numbers the model invented
Duplicate detection	the same invoice uploaded twice
Date sanity	future dates, and years that look misread

It also repairs what it can safely repair. OCR reads the letter O as a zero, or a thousands comma as a dot (3.339.40), and a GSTIN fix is only accepted if the checksum confirms it.

A real example: on my first run, gemma3:4b read a café bill's CGST 2.5% + SGST 2.5% as a GST rate of 2.5% instead of 5%. The checker caught it ("2.5% of 660.00 is 16.50, but bill shows 33.00"). I then taught the code to recognise the half-rate mistake, so now it fixes it and leaves a note instead of flagging a correct bill. A genuinely wrong rate still gets flagged.

Testing: I made 11 synthetic hard bills with invented vendors and valid-checksum GSTINs: thermal receipts, skewed phone photos with shadows and JPEG noise, a digital PDF, a scanned PDF, a discount, IGST, buyer and seller GSTINs, and one with a deliberately wrong tax. The test that matters is whether a wrong value ever passes unflagged.

First run, rule-based extraction with no AI model: 10 of 11 handled safely, and one silent error. My date reader turned 2026/10/11 into 2011-10-26.
I fixed that and added a check that flags dates over 3 years old. I also fixed OCR slips (a misread "Payable", dot-as-comma amounts) and made digital PDFs read label and value on one line.
Now: 11 of 11 handled safely. 8 bills come out fully correct, 3 are flagged for a human, 0 silent errors, and 52 of 55 fields are right. The 3 flagged are two with genuinely damaged OCR and the deliberately wrong tax.

On my laptop (RTX 3050 6 GB, 16 GB RAM), both models process a batch of 7 bills in about a minute. My first run took 2-3 minutes. Keeping the model loaded between bills and capping the output length fixed that.

Limits, honestly:

All my test bills are synthetic. I haven't tested on a stack of real bills yet.
It handles English bills. Marathi and Hindi are on the roadmap.
The checker assumes one GST rate per bill, so multi-rate invoices need a human look.
Some fields can't be checked by maths, like an invoice number where OCR reads S as 5.

Why Does Open Innovation Matter?

Privacy is the product. A GST bill carries a vendor's GSTIN and what you paid them. With a local model and local OCR, nothing leaves the laptop, which is the only way I'd ask an accountant to feed client documents into a tool like this.
Cost per bill is zero. Cloud OCR and LLM APIs charge per page, which makes a cheap per-client price hard to sustain. Here the cost is electricity.
I could swap models in one dropdown. I ran both qwen2.5:3b and gemma3:4b through the same pipeline and compared them, with no code changes and no pricing or API terms to renegotiate.
Control over the output. Ollama's JSON-schema constrained output and temperature 0 give me a model I can run over every bill and treat as a component to verify, not a black box to trust. I haven't benchmarked against a closed API, and a bigger closed model would probably misread fewer bills. But BillSift is designed around the model being wrong sometimes, so a better model would only mean fewer bills in the review list. The open, local setup is what lets this run offline, at no cost per page, on data the user never has to hand over.

My First User

A friend of mine who is a CA, went through this and gave mee a positive response. She found BillSift useful in calculations, managing accounts and bills. She did not pay but considered using BillSift in future. Another user I got was a Shop vendor, I loaded BillSift on his desktop and showed him how he can manage his Bills. And he was happy with the results. He did not pay as well.

Prize Categories

Render: the live demo's front end is hosted on Render (free web service, Docker). The hosted copy runs the rule-based extractor over pre-processed samples. The AI model runs locally, not on Render.
Gemma: the AI extraction runs Google's open-weight gemma3:4b locally through Ollama (next to qwen2.5:3b), constrained to a JSON schema, with every result checked by the verification layer.

A huge shoutout to shreyashkakad for contributing (https://dev.to/shreyashkakad)

Queue the next turn: a tiny Snake game in vanilla canvas JS

Vedant Gajbhiye — Thu, 15 Oct 2026 15:42:59 +0000

I wanted a snake game for GHW and here's what cursor did for me withing 5 min. Cursor is fast, gives great results and kind of COOL I assume.

vee-1745 / snake-game

Snake

Browser Snake game. Move with arrow keys or WASD, eat food, and avoid walls and your own tail.

Play

Open index.html in a browser, or from this folder run:

python -m http.server 8080

Then visit http://localhost:8080

Controls

Arrows or WASD: move
Space: pause / resume
Enter: restart after game over

View on GitHub

Grass Coach: a local Gemma agent that gets you off the screen in 10 seconds

Vedant Gajbhiye — Mon, 12 Oct 2026 05:58:35 +0000

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

What I Built

Grass Coach is a tiny agent whose only job is to make the screen the shortest part of your day.

Most "go outside" apps have the same flaw: they're another app that wants your attention. So I built the opposite. You run one command, spend about ten seconds reading one card, and leave. The card tells you:

When to go: the best free window in the next 24 hours, scored from forecast, air quality, UV, wind and daylight, routed around your calendar, with a bonus for golden hour and sunrise.
Why that window: written by a local open-weight model, in a voice you pick (park ranger, anime training-arc sensei, worried grandma, pirate, or deadpan British naturalist).
A rule to play by, which turns a walk into a side-quest: "Count flower colours; stop at 7." / "No headphones. Name 3 distinct sounds before you turn back." / "Photograph nothing. Memorise one thing and describe it to someone later."
A Touch-Grass Ledger (grass done, grass stats) with streaks and levels, from Seedling up to Ancient Banyan.

If the weather is bad or your calendar is a wall, it doesn't pretend. It prescribes a five-minute "doorstep reset" at an open window instead.

It's for anyone who knows they should go outside and keeps not doing it. Me included.

Demo

This is a real run on my laptop at 4:35 AM in Nagpur, Gemma 3 4B via Ollama, live Open-Meteo data:

🌿 GRASS COACH · Mon 12 Oct · Nagpur
──────────────────────────────────────────────────────────
  CHASE THE DAWN IN NAGPUR!
  The sunrise is painting the sky with beautiful hues, and
  it's the perfect time to witness it before the day gets
  busy. We've got a lovely 30 minutes to enjoy!

  WHEN   6:00 AM – 6:30 AM  (today, in 89 min)  🌅 sunrise
  SCORE  67/100 ███████░░░ good
  SKY    27°C feels-like · rain 0% · UV 0 · wind 5 km/h
  AIR    AQI 105 (unhealthy for sensitive groups)
  RULE   Let's count seven different flower colors – a
         delightful little challenge!
  BRING  A light jacket, A water bottle, A small notebook
  ALSO   today 8:00 AM (52/100)
  ALSO   today 4:30 PM (29/100, golden hour)

  — Get out there and soak it up, friend!
──────────────────────────────────────────────────────────
Screen time for this card: ~10 seconds. Now close the laptop. 🚪
[model: gemma3:4b · forecast: live (Open-Meteo) · calendar: no calendar loaded]

Anyone can try it with no internet and no model:

git clone https://github.com/vee-1745/grass-coach
cd grass-coach
python -m grass --demo --no-llm

Code

vee-1745 / grass-coach

🌿 Grass Coach

A tiny agent that runs on a local open-weight model and has exactly one job: get you off the screen.

It reads the forecast, air quality, sunset time and your free calendar slots, finds the single best window to go outside, and hands you a side-quest card with a little rule to play by You spend ~10 seconds on the screen. Then you leave.

🌿 GRASS COACH · Sat 10 Oct · Nagpur
──────────────────────────────────────────────────────────
  CHASE THE GOLDEN HOUR
  Ranger's orders: The sun sets at 5:43 PM, so 5:00 PM is
  when the light turns soft and everything looks like a
  film. It's 29°C and the air is moderate (AQI 58)
  WHEN   5:00 PM – 5:30 PM  (today, in 80 min)  🌇 golden hour
  SCORE  83/100 ████████░░ prime
  RULE   Photograph nothing. Memorise one thing and
         describe it to someone later.
  ...
Screen time for this card: ~10 seconds.

…

View on GitHub

Python 3.11+, standard library only. No pip install, no API key, no account.

How I Built It

Open pieces: Gemma (via Ollama) as the default writer, Open-Meteo for open weather and air-quality data, and an OpenAI-compatible adapter so llama.cpp, LM Studio or vLLM work too. Swapping the model is one line in grass.toml.

The interesting part isn't the model. It's what I don't let the model do.

1. Code owns the facts, the model owns the flavour. Small models are bad at arithmetic and good at tone. So the Grass Score (0-100), the window times and the quest rule are all computed in plain Python. The model receives them as JSON and writes only a title, a pitch, a re-worded rule, a packing list and a sign-off. (You can see the exact facts it gets with grass --json.)

2. Schema-constrained output. The request carries a JSON schema (Ollama's format field, or response_format on OpenAI-compatible servers), so even a 4B model returns the right shape. Every live Gemma run I did returned a valid card.

3. A number guard. Every number the model writes is checked against the facts it was given. If the model says "it's a lovely 42°C", that's rejected, the model is told exactly why, and it gets one retry. This targets the failure small models actually have: confident, plausible, wrong numbers. It's covered by unit tests that script a fake Ollama server returning hallucinated numbers, malformed JSON and no response at all.

4. It always answers. If the model server isn't running or fails twice, a rule-based writer produces the card. If there's no signal, the last good forecast is cached and reused, labelled as stale. I tested those paths in unit tests; I haven't yet tried it on a trail with no signal.

5. The calendar stays on your machine. A tiny .ics reader finds your busy slots locally. Nothing about your schedule is sent anywhere.

There's also grass compare --models gemma3:4b,qwen3:4b,llama3.2:3b, which runs the same facts through several local models side by side. That only works because the model is a config line, not an API contract.

What the first real run taught me

I wrote the code against a fake model server, so the real Gemma run was the actual test. It worked first time, and it also showed me where a 4B model is weak:

It ignored the voice. My default voice is "park ranger", but Gemma wrote a generic cheerful "Get out there, friend!". Ironically, the dumb rule-based fallback ("Ranger's orders: ... Leave only footprints.") has more character than the model does.
It ignored common sense. It told me to pack "a light jacket" (and on another run "a warm scarf") at 27°C. My number guard checks numbers, not sense. Next step: constrain the packing list by temperature.
It didn't mention the air. AQI was 105 and the card shows it, but the model's pitch never says so. The score and data are honest; the prose isn't always.
The facts never wavered; the prose did. Same inputs, three runs, three different texts. But the time, score and rule were identical every time, which is the whole point of the design.
One thing I'd fix: the "ALSO" list happily showed a 29/100 option. It should hide weak alternatives.

Why Does Open Innovation Matter?

It can work where the grass is. A trail with no signal is exactly where a closed API stops. Local weights plus a cached forecast are designed to keep working there.
Your calendar and location stay yours. An agent that knows when you're free and where you live is the kind of data you don't want on someone else's server. With a local model, the prompt never leaves the laptop.
I could change how it behaves. Constraining output with a schema, adding a verification layer around the model, swapping models and comparing them on identical input are all things I could do in an afternoon because the model is mine to run.
It costs nothing to run. No key, no quota, no bill. A tool meant to be used every day can't have a per-call cost.

My Outing

The card above came out at 4:35 AM and pointed me at a 6:00 AM sunrise window.

I headed out into the cool Nagpur dawn around 6:00 AM for a 30-minute sunrise walk, bringing along a light jacket, my water bottle, and a small notebook to log what I found. I took the challenge seriously (I got to a nice morning walk anyways) and kept my eyes peeled, successfully spotting seven distinct flower colors: bright marigold orange, deep bougainvillea magenta, soft yellow, pure white, crimson red, lavender purple, and tiny wild blue petals nestled along a garden hedge. The AQI sitting at 105 gave the sky a slightly hazy quality, so I adjusted by keeping my pace relaxed and steady rather than turning it into a brisk workout. Stepping away from the laptop after just ten seconds of screen time was a complete breath of fresh air; swapping my usual morning routine (watching reels and youtube on laptop/tab) of mindless scrolling for real sunlight and quiet streets left me feeling remarkably calm, grounded, and present. And also, flowers helped me talk to my crush.

Prize Categories

Gemma: runs Gemma locally by default (gemma3:4b through Ollama), with schema-constrained output and a verification layer around it.

A huge shoutout to shreyashkakad for contributing (https://dev.to/shreyashkakad)