DEV Community: Ishaan

d43m0n lives in my terminal now

Ishaan — Sat, 31 Oct 2026 17:56:48 +0000

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

Somebody's been keeping notes on my shell. Every command for the last week: the successful ones, the midnight typos, the same failing build three times in a row. Yesterday, it started commenting.

$ false
👻 cargo finished now.

That's d43m0n. It lives in my terminal now.

What I Built

d43m0n (repo, MIT) is a local-only terminal haunting, and my read on the theme was boringly literal: the brief asked for a haunted terminal that possesses your shell and whispers back eerie commentary, so I built exactly that — then stayed up making the ghost good company.

A shell hook with a 40ms hard budget (it always exits 0; the shell never waits) sends each command over a unix socket to d43m0nd, a small Rust daemon. The daemon redacts the command in memory — family plus flags kept, everything else becomes <path>, <url>, or <arg> — stores the event in SQLite, and predicts the probability it fails. Risky command in, one dry line out. There is no TCP listener anywhere in the system.

It also keeps a ledger of the dead: d43m0n seance lists directories I abandoned months ago with their last commands attached. An ofrenda for unfinished work; apparently my shell has a better memory than I do.

Demo

A real session — fish, local daemon, warm model, no network needed:

~> false
~> false
👻 cargo is slow today.
~> npm test
~> echo done
done

Two fails, one deadpan remark, zero packets leaving the machine. Reproduce everything, numbers included:

cargo build --release
./target/release/d43m0n daemon start
eval "$(./target/release/d43m0n init zsh)"   # bash gets post-only; fish gets full pre+post
./target/release/d43m0n demo --seed && ./target/release/d43m0n demo --run
./target/release/d43m0n eval --demo          # reproduce the AUC table

Code

ishaan-jindal / d43m0n

Local-only terminal haunting: predicts failing commands with TabPFN, narrates with local Gemma

d43m0n 👻

A local-only terminal haunting. d43m0n watches your shell, learns your habits, predicts which commands are likely to fail before they run, and comments in the voice of a ghost. It also surfaces work you forgot was still waiting in old directories.

Nothing leaves the machine: prediction runs on TabPFN in a local sidecar (or the built-in Rust baseline), narration on a local Gemma model via Ollama (silence when it misses), and the event store is SQLite under ~/.local/share/d43m0n/. The shell hook has a 40 ms budget and degrades silently when the daemon is down.

Status: M3 — zsh and bash hooks, redacted event logging, secret guard, baseline + TabPFN prediction, Gemma narration, Echoes, Séance, demo replay, eval + latency benchmark, doctor, stats, purge.

Meet d43m0n

The default persona is d43m0n, a deadpan familiar with opinions — fonder of the terminal than it lets…

View on GitHub

How I Built It

Two open pieces do all the work, and the project is shaped around what they can do locally.

TabPFN (Prior Labs, tabpfn==9.2.0) predicts failure. The sidecar fits a classifier in-context on recent labeled shell history — up to 5000 rows, CPU only — and answers predict over a unix socket with a 300ms budget, refitting every 50 events. Under 200 labeled events, or if the sidecar ever dies, a Rust Beta-prior baseline answers instead. Time-ordered holdout, no shuffling:

history	split	TabPFN AUC	baseline AUC
seeded demo, 1600 events	1280 / 320	0.725	0.705
my real shell, 222 events	177 / 45	1.000	0.978

The tie is worth showing: a smoothed baseline is a strong prior for shell prediction, and TabPFN earns its keep on real habits. The daemon always reports which predictor answered.

Gemma (open weights, served by Ollama on localhost) narrates. The daemon sends only structured facts — tool family, failure bucket, streak, hour, level. Never arguments, never paths, never raw text. Output is validated (one line, ≤12 words, no markdown, no parroting the prompt's field labels) and anything else is silence: I deleted the entire 56-line canned bank. When d43m0n speaks, it is always the model. Hook path costs pre p50 0.18ms and post 0.16ms; warm inference takes 1–3s fully async, so the shell never feels it.

Along the way the build got leaner: five dependencies deleted (tokio, reqwest, tracing among them — the standard library was enough), 46 tests, zero warnings.

Why Does Open Innovation Matter?

Shell history holds paths, hostnames, project names, and a steady stream of pasted secrets. A closed-API version of this tool would ship all of that to someone else's server for "inference" — a keylogger with extra steps.

The open version keeps everything home: redaction in memory, no raw-text column anywhere, secret-matching commands dropped before counting, works with the internet off, no key to rotate, no pricing page, no sunset. Weights in ~/.cache, model in ~/.ollama, history in SQLite. That privacy story can't be a paragraph bolted onto a cloud API. It only works because the models live here — which is also why the tool keeps working when the network doesn't, and why no provider decision can ever switch it off.

The Spirit of It

Generic spooky was the first thing to die. Canned lines made the ghost less alive with every showing, so the bank went in the fire and d43m0n got a personality instead: a deadpan familiar, fond of the terminal it lives in. It names your tools, notices your streaks, judges your late hours.

👻 cargo is slow today.

Give it your history and it stops sounding like Halloween decor. It sounds like something watching you work — fondly, and with opinions. It is, in fact, watching you work.

Two fails, one deadpan remark, zero packets leaving the machine. Happy Halloween. 👻

Prize Categories

Best Use of TabPFN: in-context failure prediction on shell history, served over a unix socket with a Rust baseline fallback and an honest time-ordered eval (1.000 vs 0.978 AUC on real habits).
Best Use of Gemma: local narration through Ollama — structured facts in, one validated line out, silence on a miss — giving a terminal daemon a voice without anything leaving the machine.

Sloth: commit messages from a model that lives in the binary

Ishaan — Sun, 25 Oct 2026 06:17:57 +0000

I am slow at writing commit messages. Not the code — the one-line summary. In honor of International Sloth Day, I built the tool I wanted: stage your changes, run one command, and a message comes back that reads like your repository wrote it. The model runs on your machine, inside the process. Nothing leaves it.

What I Built

Sloth is a small Rust CLI with two commands: sloth commit and sloth release. You stage your changes and run one command; it proposes a message, and nothing is committed or tagged without a keypress from you.

git add -A
sloth commit

One keypress: accept, edit in $EDITOR, regenerate, or cancel. sloth release computes the version bump from the commits, writes a changelog section, and creates an annotated tag. It never pushes — it prints the command for you to run.

The lazy payoff, measured in the only unit that matters: writing a conventional commit message by hand takes me about a minute of staring, plus a trip through git log to check how this repo formats things. Sloth does both in one command and one keypress. Across a normal day of commits, that is the difference between staying in flow and context-switching into changelog-brain a dozen times.

Demo

Real terminal output from the shipped binary. First, what Sloth sees in a repository — the mined convention, dumped without calling any model:

$ sloth prompt --json
keys: ['schema', 'style', 'system', 'user', 'variables']
pattern: ^(feat)(\([a-z0-9._/-]+\))?!?: .{1,72}$
body maxLength: 0
style shape: conventional | scope_rate: 1.0

That pattern is generated from the repo's own history, and the model server compiles it into a grammar — a subject that breaks the convention is unreachable rather than merely invalid. Then the proposal:

$ sloth commit --dry-run
sloth: convention: conventional (high, 100% of 3 commits); prose bodies 0%, trailers 0%, scopes 100%

  src/lib.rs | +1 -1
  1 file(s) changed, +1 -1

--- proposed message ---
feat(core): update function f5 to f6
------------------------

dry run: nothing was committed.

Code

https://github.com/ishaan-jindal/sloth — MIT licensed.

Rust, four direct dependencies, one embedded inference engine (llama.cpp via the llama-cpp-2 crate, CPU-only). Default model is qwen3:0.6b — deliberately the smallest thing on the ladder. No server, no port, no network connection; the model file is memory-mapped, not uploaded.

How I Built It

The whole design is one sentence: the model decides as little as possible.

Sloth reads the repository's last 300 non-merge commits and mines how that repository writes: Conventional Commits, gitmoji, ticket prefixes, or freeform, plus the actual type and scope vocabulary, subject-length habits, and body structure. The model never decides the format, the type, the scope vocabulary or the version number — those are computed from history by code.

Three things earned their place the hard way:

The schema is a constraint, then a check. A pattern on the subject and maxLength on both fields, enforced by the grammar compiler. But a grammar is a nudge, not a proof — escaped characters can slip past it, and an unsupported pattern silently degrades to a free string with one stderr warning. So the output is parsed and re-checked in code (full regex on the unescaped value, same length bound) before anything else happens, and a degraded grammar is a hard error, not a fallback.
A local tool cannot know a pull-request number, so any (#1234) the model invents is removed in code. Same for bodies a repo never writes: the schema cap is zero, which makes them unwritable rather than discouraged.
A 3,000-line refactor is a normal commit, so there is no "diff too big" error. The tool raises its context window, and past that, summarises the diff in pieces and combines them — telling you which it did.

I am not the first person here to make a machine write these. The thread I am joining includes lazycommit, Auto-generate Commit Messages with LLMs in Your Terminal, and Stop Writing Boring Commit Messages. Sloth's bet is different: when the tool determines everything deterministic, the model is left with the one thing it is actually asked to do, which is wording.

Why Does Open Innovation Matter?

Every load-bearing piece is open: the weights (any GGUF works — nothing in the tool is tied to one lab's model), the inference engine (llama.cpp), the prompt, the schema, and the convention miner. That is not decoration, it is the mechanism. A closed per-token API would make "a commit message with zero marginal cost" impossible; a closed model would make "the grammar enforces your repo's format" unverifiable. And privacy is structural, not promised: there is no HTTP client in the binary and no endpoint to misconfigure, so unreleased code cannot leave the machine by construction, not by policy.

Prize Categories

None — Sloth runs on open-weight models through llama.cpp with no partner technology involved, so this is an entry for the overall prize. The lazy payoff above is the whole pitch: a tool for the task every developer dreads, in honor of the slowest animal with the best ideas about energy conservation. 🦥

What this post does not claim

I did not benchmark models against each other. The repo contains a benchmark harness with a pre-registered protocol and 80 real commits, and it was deliberately never run — so I am not telling you a 0.6B model is good enough. Try a bigger model and a smaller one and see which one you stop noticing. That difference — the point where you accept without reading — is the real benchmark, and it happens at your keyboard, not in my table.

Disclosure: this post was written with AI assistance. The tool it describes was also built with AI assistance, which feels worth saying plainly.

Shop Rate Bot: a one-page shop FAQ bot

Ishaan — Fri, 16 Oct 2026 04:14:23 +0000

What I Built

Shop Rate Bot: a one-page shop FAQ bot. A shopkeeper sets a small rate card (atta, rice, milk, chai, sugar, eggs); customers ask "rice price?" or "open?" and get an instant answer. A status dot shows whether the answer came from the local model (green, Gemma via Ollama) or the built-in stub (grey).

Someone would pay for this: a neighbourhood kirana that fields the same rate/hours questions all day. No app to install, no per-query bill, answers in seconds.

Demo

Live: https://shop-rate-bot.onrender.com/
Try: "rice price?", "open?", "chai price?"
Note: Render free tier serves the deterministic stub (no Ollama there, no per-token budget). Run ollama run gemma3n:e2b locally and the same questions get warmer Gemma-written answers, dot flips green.

Code

https://github.com/ishaan-jindal/shop-rate-bot

FastAPI + one HTML page, no DB, no auth. MIT licensed.

How I Built It

src/brain.py tries Ollama first ($OLLAMA_HOST, $GEMMA_MODEL, default gemma4:e2b) with a strict short-JSON prompt grounded in the rate card, and falls back to a keyword stub on any failure — the endpoint never 500s and the app boots with zero keys. src/app.py exposes /health, /api/ask, /api/status. The page is 15 lines of inline JS. Docker image deploys to Render free tier with /health as the healthcheck.

Why Does Open Innovation Matter?

Two reasons this only works open. First, cost: a closed per-token API makes a Rs 499/month price for a kirana impossible; a local Gemma costs nothing per query. Second, privacy and offline: rate questions and customer patterns never leave the shop laptop, and the stub keeps answering with the Wi-Fi off. Open-weight models turn a shop laptop into the whole backend.

Prize Categories

Best Use of Render, Best Use of Gemma

Pincode Garden: what to plant this week, from your pincode

Ishaan — Wed, 07 Oct 2026 15:32:35 +0000

Pincode Garden: what to plant this week, from your pincode

Live demo: https://pincode-garden.onrender.com/
Repo: https://github.com/ishaan-jindal/pincode-garden (MIT)

The problem

I have killed every plant I ever touched. The advice online is always "zone 9b, last frost March" — useless when your pincode is 110016 and your garden is a balcony with three hours of sun.

So for Hacktoberfest Week 1 (Touch Grass) I built the smallest thing that answers one question: given my pincode, my minutes per week, my sun, and my experience, what should I sow this week?

You enter four fields, you get up to three crops with a sow-by date, one short tip, and the frost window it was grounded in. Then you are supposed to close the laptop and go sow something. The screen part takes twenty seconds. That is the point.

What it does

Input: pincode, minutes per week, sun (full / partial / shade), experience (new / some / green).

Output: three ranked crops, each with why it fits, a sow-by date, and a fit score — plus one tip line, the last/first frost for your prefix, weeks left in the window, and two flags: smart advice on/off, yield check on/off.

Example — 110016, 30 min, partial sun, new gardener — returns coriander, lettuce, marigold with a tip like "Sow coriander 3in apart; keep moist, harvest in about 35 days." Completing a planting logs a streak in a flat file. No accounts, no database, no keys.

The read-aloud button reads the tip plus the top pick, so you can listen once and put the phone away.

How open-source AI is at the core

Two open pieces do the actual work, both with the same honest pattern: try the real model, fall back to a deterministic stub, label which path ran.

Gemma 4 via Ollama writes the tip. The prompt is grounded in the top-ranked crops only, strict JSON, one line. Model and host come from GEMMA_MODEL (default gemma4:e2b) and OLLAMA_HOST. No cloud calls, no keys, no per-token bill.
TabPFN V2 (CPU) ranks the candidates. Features are tabular and small: sun match, frost-window fit, harvest fit, experience, month. The training table (data/history.csv, 32 rows) is reference outcomes encoded from planting guides, not fake telemetry. Fit happens once and is cached; any failure falls back to a weighted stdlib scorer over the same features.

Why open mattered here: the whole brain runs on-device or not at all. Nothing about your pincode or garden leaves your network. The stub path means the demo works with Wi-Fi off — Gemma makes tips warmer when home, TabPFN sharpens ranking when torch is around. On Render free the deployed demo runs the deterministic fallback by design, and the UI says so. Locally, uv sync --extra tabpfn plus ollama run gemma4:e2b enables both real paths with zero code changes.

Frost dates without an API

data/frost.csv is ten rows: pincode prefix to first/last frost (MM-DD), plus a fallback row for unknown prefixes. North prefixes get a real window; southern ones get year-round. All math is stdlib dates. No fetch, no keys, no outage mode.

Crops live in data/crops.csv (14 rows). Candidates are filtered by sun, difficulty, time budget (under 30 min/week keeps easy herbs/greens only), and whether the sow-by date is still inside the window. Unknown pincodes never crash; they get the fallback window.

Stack and shape

FastAPI plus stdlib. No ORM, no auth, no image uploads, no weather API, no geolocation. Streaks are a JSON file. Frontend is one 74-line HTML file, system font, no framework, speech synthesis for read-aloud. Tests are five offline pytest cases with stubs forced. Docker plus render.yaml on the free tier.

What I would add with more time

A second frost source with provenance per row, and a photo log for the streak instead of a counter. Neither fits a four-day window without adding a database I would have to maintain.

BOSS vs YOU: I Built a Boss Fight for My Bored Friend — and an Open LLM Plays the Boss

Ishaan — Sun, 04 Oct 2026 16:15:58 +0000

BOSS vs YOU: I Built a Boss Fight for My Bored Friend — and an Open LLM Plays the Boss

My friend is bored by every game I show him. Too easy, too grindy, too predictable — the boss does the same three moves, so why keep playing? Fair. So for the Hacktoberfest Weekend Challenge (Build for a Friend), I built him a boss fight where the boss is played by an open-weights LLM that studies how he plays and adapts. Same three moves? Not anymore.

Play it: https://boss-vs-you.onrender.com (free tier — give it ~50s to wake up)
Code: https://github.com/ishaan-jindal/boss-vs-you (MIT)
Challenge: https://dev.to/challenges/hacktoberfest-weekend-2026-10-01

What it is

BOSS vs YOU is a real-time pixel-dungeon boss battler in the browser. You descend room by room through a cramped gothic dungeon. Each room: kill the minions, crack the boss phase, draft a level-up card, go deeper. The twist: one transforming boss (four forms), driven by a model brain, with a memory.

Roughly every 8 seconds the server sends the full fight state — HP, positions, your habit profile, the room — to the model, which returns tactics (pressure / bait / bombs weights), whether to transform, what to open with, and even a taunt. A rules-based stub stands behind every call: model fails, times out, or returns garbage, and the deterministic floor takes over. The game never 500s, and it plays fully offline with no keys at all.

And the part built to hook him: it learns whoever plays. The server distills the last 60 fights — turtle ratio, dash spam, potion timing, preferred range, causes of death — into a habit profile the boss prompt reads. Camp in the corner and the boss starts baiting. Dash everywhere and it starts punishing.

His honest review: "addictive... but a little easy" — then, a few descents later, the dungeon thrashed him. Boredom: cured.

How it's built

flowchart LR
    UI[Pixel Canvas client] --> API[FastAPI server]
    API --> Brain[brain: contract + stub]
    Brain --> Habits[habits: 60-fight profile]
    Brain --> Gemma[(Gemma 4 primary)]
    Gemma -.failover.-> DI[(DeepInfra Gemma)]
    Brain -.fallback.-> Brain

The stack is deliberately boring: FastAPI + uvicorn, raw httpx to the model APIs (no SDK), vanilla JS + Canvas 2D (we deleted a 1.3MB vendored Three.js mid-weekend for a 210-line pixel renderer), procedural sprites and Web Audio so there are zero asset files. The server is fully stateless — persistence is browser localStorage. Python is the tuning ground truth; the JS client mirrors four formulas, pinned by a parity test (93 tests, all green).

Why open matters

This game only works because the model is open:

Swappable by design. Primary and failover are both Gemma 4 served two different ways (Google REST, DeepInfra OpenAI-compatible). Point the brain at any weights-compatible endpoint — including a locally-run Gemma — with a two-constant change. Try that with a closed API.
Free to run, online or off. No keys, no internet? The stub brain plays a real game. The whole weekend cost $0: open weights, free-tier Render, MIT everything.
Inspectable opponent. Anyone can read the exact prompt the boss sees and the exact counters it keeps on them. A black-box boss that adapts is marketing; an open one is a rivalry.

Tracks

Best Use of Gemma: Gemma 4 is the boss's brain — tactics, transforms, taunts — with thinking capped to MINIMAL after measuring full reasoning at 20-40s per tick.
Best Use of Render: Docker deploy, health checks, secrets in the dashboard. (Shipped a real Dockerfile bug along the way: installing before src/ existed silently produced an empty editable install — reorder plus a non-editable build fixed it.)

Built this weekend for one bored friend. If he finally stops complaining, I'll consider it a win bigger than any prize.