DEV Community: Aman

I built a chore daemon that refuses to work while I'm using my laptop

Aman — Wed, 21 Oct 2026 16:42:46 +0000

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

What I Built

Every AI tool I have tried this year wants my attention at the exact moment it decides it has something to say. So I built the opposite: a worker that does its job only when nobody is looking, and puts the file down the instant I touch the keyboard.

slothd is a chore daemon. You point it at the folder you keep meaning to deal with — mine is a downloads folder full of files called Untitled document (3).txt — and it reads each file with a local open-weight model, decides what the thing actually is, renames it, and files it under sorted/<category>/.

The interesting part is not the filing. It is the pace. It only works when the machine is genuinely idle, and the moment you start using the computer it drops the file it is in the middle of and gets out of the way. You never wait for it, you never watch it, and you never pay for it. You walk away, and the mess quietly shrinks.

In the morning you get two lines, not a dashboard:

Filed 16 things while you were away (4 code, 4 money, 4 personal). That is ~5.3 minutes you did not spend.
Only 4 want a look from you: money files. Everything else can wait.

That is the whole interface. The web UI exists mostly so you can confirm it is not lying to you.

Demo

What to watch for, in order:

it is filing a file, one core busy, status working while you're away;
I start a build on both cores — within ~2 seconds the status flips to waiting for you to stop typing, the in-flight file is abandoned mid-inference, and nothing is left half-filed;
the build finishes, it resumes the same file from the start, and the ledger keeps growing;
the digest at the end is two lines.

The dashboard's times it gave the machine back counter is not a mock: it increments every time the model call is killed mid-stream because someone touched the machine.

Code

AmanDevelops/slothd — standard library only, no dependencies, no API key. Runs on Linux (and WSL) today; macOS needs the gate ported.

git clone https://github.com/AmanDevelops/slothd.git
cd slothd
python3 scripts/make_fixtures.py                       # the 16 messy files from this post
python3 -m slothd.server --inbox fixtures/inbox --var ./var

17 stdlib tests (python3 -m unittest discover -s tests) cover the parsing, the
category clamping, hash dedupe, undo, and the digest. The gate itself is exercised by
watching the dashboard flip to waiting for you to stop typing the moment you start a build.

How I Built It

The only prompt in the project

One question per file, four fields out, temperature 0, JSON-constrained:

You are a filing clerk with no sense of urgency. Read the file snippet and reply with
JSON only. Keys: title (max 6 words), category (exactly one of money, work, code,
personal, reference, junk), summary (max 12 words), confidence (0-1).

That is it. No agent loop, no tool calling, no planner. The job is narrow enough that a 4B model does it well, and every extra token is time I am spending on someone else's machine.

The gate is the hard part

"It runs when you are idle" is easy to write and hard to get right, because the worker is itself load. My first version read /proc/stat, saw the CPU at 100% (from its own inference), concluded the human was busy, and stopped forever. A worker that watches its own footprint is a worker that deadlocks.

The fix is to measure the machine minus itself:

d_own   = our_cpu_seconds + model_server_cpu_seconds   # from /proc/<pid>/stat
d_total = cgroup_cpu_seconds_delta                     # whole box, this session
human   = max(0, d_total - d_own)
idle    = 100 * (1 - human / (elapsed * cores))

So when Ollama pins one core for twenty seconds, the gate reads human uses 0.0 cores and keeps going, and when I pin both cores it reads human uses 2.0 cores and stops. The dashboard shows both numbers side by side (your cpu, this window / its cpu, this window) so the arithmetic is never a mystery.

Two things I got wrong and fixed, in case you are building something similar:

Load average is the wrong signal. It is a one-minute EWMA that counts your own past work, so the worker throttles itself for a minute after every file. I switched to cgroup CPU usage and dropped the load check entirely.
/proc/stat lies inside containers. It reports the host's CPUs, not your slice. On a shared VM the machine can read as 99% busy while your container is idle. cgroup v2 cpu.stat is per-slice and correct in both places; /proc/stat is the fallback for older systems.

Preemption, because "idle" changes while you are typing

Sampling the gate between files is not enough: one file takes ~20 seconds of inference, so a build that starts in the middle of a file waits 20 seconds for a courtesy.

The model call is streamed over a raw http.client connection, and every chunk is an opportunity to change my mind. A watchdog thread samples the gate once a second while a file is in flight; if the human comes back, it sets a cancel flag, the reader closes the socket, and the generation dies mid-token. The file has not moved — the move happens only after a complete verdict — so nothing is half-filed, and the ledger records the yield instead of the file.

That is also why the answer to "what happens if I shut the laptop lid?" is boring: files move with os.replace and then one line is appended to var/ledger.jsonl. Kill -9 mid-run and the in-flight file is simply still in the inbox, to be retried on the next pass.

The unglamorous parts that make it safe to leave running

Dedupe by content hash. Restarting the daemon cannot file the same receipt twice.
Undo. POST /api/undo walks the last run backwards and puts every file back where it came from. --undo-all does the ledger.
It cannot wedge. Model down, model returns prose, model returns a category I did not ask for — it clamps the category, or falls back to a keyword classifier, and marks the ledger entry source: fallback. Two failed attempts on one file and it gives up and leaves the file alone, rather than looping forever (which my first version cheerfully did).
It yields rather than shares. os.nice(19). If it is ever running while you need the machine, it is the least important process on it.

Why Does Open Innovation Matter?

Three things, all of them things a hosted API structurally cannot give me:

It runs on the pile of personal files you would never upload. A folder like this one has bank statements, invoices with your address on them, and a to-do list with your mother's birthday in it. A local 4B model means the answer to "who can read this" is "whoever can read my disk", full stop. The process opens exactly two sockets: 127.0.0.1:8010 for the UI and 127.0.0.1:11434 for the model. The dashboard's bytes uploaded counter is 0 B because there is no code path that could make it anything else.

The cost of a chore is zero, which changes what counts as worth doing. Filing a file by hand costs me 20 seconds of attention. Filing it with a paid API costs a fraction of a cent plus a key to manage plus a service that can deprecate the model next quarter. When inference is free and local, "automate this boring thing" stops being a budget decision. I left it running for hours because there was nothing to meter.

I can swap the brain. The model is one string in --model. gemma3:4b gets the subtle ones right; gemma3:1b filed the same 16 files in 162 seconds against the 4B's 307 — 1.9x faster on this 2-core box — and disagreed on the five vaguest ones, nearly all of them by falling back to reference. On a slow machine that is the difference between "overnight" and "over lunch", and it is my call to make, per machine, per afternoon. A closed endpoint lets me pick from whatever tier the vendor keeps in stock; an open-weight model lets me pick quantisation, size, and hardware — and lets me fine-tune it later on my own categorisation without asking permission.

The numbers, since claims deserve them


files filed	16
total model time	307 s (~5.1 min), spent while I was not using the machine
average per file	19 s (one local 4B call, temperature 0)
tokens generated	823
bytes uploaded	0
dollars spent	$0.00
human clicks	0
mis-filed on review	0 flatly wrong, 2 arguable

The reproduction is two commands, and the second one re-derives the model comparison:

python3 scripts/make_fixtures.py          # writes the 16 messy files
python3 scripts/compare_models.py gemma3:1b

The run above is 16 files, so treat the accuracy as a spot check rather than a benchmark; it is a holdout the size of one evening's clutter.

The Lazy Payoff

The person who gets to be lazier is me, at 11pm, with a folder of 16 files I keep avoiding.

What it did, measured: 16 files, unattended, on a 2-core ARM VM, with gemma3:4b Q4_K_M running locally through Ollama. Total model time ~5.1 minutes, spread across the evening while I was not using the machine. Human clicks: 0. Files uploaded: 0. Dollars: $0.00.

What it saved: the dashboard uses a deliberately conservative 20 seconds per file — open it, read enough to know what it is, decide, rename, move. 16 files × 20s ≈ 5.3 minutes of the specific kind of attention that is hardest to schedule: small, boring, interruptible, and always deferred to tomorrow. The estimate is probably low, and I would rather understate it.

What it got wrong: a grocery list went to personal instead of reference, which is arguable, and a page of project musings in a file called Untitled document (3).txt went to code because the contents mention a deploy and a cache. No file landed somewhere I would call flatly wrong, nothing was deleted, and everything is reversible in one call. That is the bar I wanted: a tired intern, not an oracle.

The honest bit: the folder in this post is a synthetic one I put together to make the run reproducible (scripts/make_fixtures.py), because my real downloads folder is full of invoices with my address on them and I am not publishing those. The code does not care which folder it points at; --inbox is the only thing that changes.

When it finished I opened the folder once, saw money/, work/, code/, personal/, reference/, junk/, and closed it again. That is the entire product: it removes a decision I did not want to make, at a time I was not using the computer, for free.

Slow and steady. Mostly slow.

Prize Categories

Best Use of Gemma — the whole project is built on Gemma running locally: gemma3:4b (Q4_K_M, via Ollama) does every classification, with gemma3:1b as the speed option in the same code path, and a deterministic keyword fallback when the model is unavailable. There is no other model provider in the project.

I am not entering any other category, because the build does not use any other partner technology — no hosting, no cloud inference, no auth, no database. The point of this one is that it runs on the machine it is sitting on.

Frostline: a planting planner that decides on your own machine

Aman — Mon, 12 Oct 2026 06:42:50 +0000

Frostline: a planting planner that decides on your own machine

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

Theme: Touch Grass.

What I built

I have a small balcony in Delhi NCR. Every October I do the same thing: buy coriander seeds, sow them, and watch them bolt in the heat — because October in Delhi is not autumn, it is a second summer with shorter days. The advice I was following came from gardening sites written for England.

Frostline answers one question — what should I sow this week, where I actually live — and it answers it from my own weather history, on my own laptop, with no account and no API keys.

You open it, pick your town, press one button. It tells you the next seven days of temperature for your coordinates and which of 30 crops fit that window. This week for Delhi it says: bush beans, cucumber, okra, marigold, basil, mint, bottle gourd and sunflower all fit at 100%. Radish, fenugreek, spinach, coriander and mustard greens score zero, and the app says so out loud instead of hedging.

Then you close the laptop and go plant.

The demo

Here is the app running — 29 seconds, no mockups:

One honest note about the clip: TabPFN refits on every run, and on this two-core box a full fit takes minutes, so the recording shows the button press and then cuts the wait. What appears after the cut is the output of a completed run — the same run whose numbers are below, rendered by the app itself. Nothing in the clip is staged, but the waiting is not real-time.

Why open innovation matters for this

A planting calendar is a small, personal thing. The closed version of it is worse in five specific ways, and every one of them is why this is built the way it is.

The model runs on the machine. TabPFN does its inference on CPU, in the same process as the web server. My latitude, my garden, my plans are never sent anywhere to be scored. I do not have to trust a vendor's retention policy to ask what to plant.

It works with the network unplugged. Weather history is cached in one SQLite file — 5,761 days of daily min/max for Delhi, back to 2011. After the first fetch, the whole planner runs offline. I tested this properly: I stubbed the archive fetcher so it raised on every call, and the app served the cached history and produced the full plan anyway. That matters for a tool you would actually take outside.

The advice is inspectable. The crop table is a plain Python list of temperature envelopes, not a black box. If okra is mis-scored for your microclimate, you open frostline/crops.py and change a number. No retraining, no waiting on a vendor.

The model is swappable, and optional. Gemma sits behind a single function. If Ollama is not running, Frostline falls back to a deterministic template-written plan and keeps working. Nothing 500s because a model is missing.

It costs nothing to run. No per-request price for asking what to plant, and no ceiling on how often you ask.

How it works

Open-Meteo archive (free, no key)  →  SQLite cache  →  20 engineered features
   →  TabPFN regressor (CPU, local)  →  7-day min/max forecast
   →  crop scoring against temperature envelopes
   →  Gemma 3 4B via Ollama writes the plan in plain language

Two things I care about in the design.

The forecast is recursive. TabPFN predicts day one, that prediction is fed back in as a lag feature, then day two, and so on for seven days. The 20 features are the day-of-year (raw, plus sine/cosine so December and January are neighbours), year, lags at 1/2/3/7 days, and rolling windows up to 30 days.

The model has to justify itself. Frostline holds out the last seven days of history, predicts them, and scores the mean absolute error against a day-of-year climatology baseline. The UI has a panel literally titled "Did the model earn its place?" — if the model cannot beat "the average for this date over 15 years", that is what it says.

Did the model earn its place?

Yes — and here is the number that decides it. Frostline holds out the last seven days of real history, predicts them, and scores itself against the simplest thing that could work: the average for that same date over 15 years.

Held-out week: 3–9 October 2026. 5,724 days of training history, fitted on the most recent 2,500.

Min temperature: 1.024 °C MAE, against 2.797 °C for the climatology baseline — 63% better
Max temperature: 1.152 °C MAE, against 1.808 °C — 36% better

The model also earns its place in shape, not just in error. A day-of-year average cannot see a trend by construction — it is the same number every year for that date. This week Delhi cools from 32.7 °C down to 28.2 °C, and TabPFN called the slide; the baseline sat flat at 32 °C for all seven days. That is the difference between a calendar and a forecast.

The caveat, stated plainly. A seven-day holdout is a small sample, and the two targets disagree about how much the training cap matters. Re-running the same holdout with a 200-row cap gives 57% on min temperature but 76% on max — so read "36% better on max temperature" as a point estimate from one week, not a settled figure. A walk-forward evaluation over many holdout windows is the honest next step; at roughly six minutes per fit on this CPU it is an overnight job, not a footnote.

Both numbers are reproducible on your own machine:

.venv/bin/python scripts/evaluate.py

What broke

Five things, all worth writing down.

Gemma invented weather. My first prompt got back a plan that warned about frost protection. There were zero frost-risk nights in the window — the coldest night was 19.9 °C. A small model will happily describe a hazard the data says is absent, and that contradiction is the first thing a reader notices. The fix was to put every fact in as a list, state the exact date range and that there is no data beyond it, and forbid the specific invention: "Frost-risk nights: NONE. Do not mention frost, frost cloth, or frost protection." It now writes "no risk of anything needing protection from the cold."

The plan was a week stale. The cache top-up had an early return: if more than five years of history was already cached, it skipped fetching entirely. So the app kept serving whatever week the cache was first filled in. On 11 October it produced a forecast for 4–10 October, and Gemma faithfully wrote "start planting your bush beans today, October 4th." The model was not wrong — my pipeline was handing it last week's data. Now every run requests only the missing tail, which also makes the offline path explicit instead of accidental.

A 4B model needs 4.1 GB of RAM and does not negotiate. The Ollama runner kept dying mid-load. I initially blamed the CPU repack path, and I was wrong — the log line still read REPACK = 1 with the flag set, and the real cause was the OOM killer: the process was inside a 4 GB memory cgroup. It now runs detached with a 6 GB budget. I mention this because "run a model locally" has a resource floor, and the honest number is more useful than a mystery crash.

The bug that only existed once the model worked. _run() in forecast.py built its recursive walk from a variable it had never been passed. Every code path that could reach it was gated behind a working TabPFN licence, so it was unreachable — and therefore invisible — until the day the licence cleared. The first real run fitted the model, then died with NameError: name 'df' is not defined, and the broad exception handler I wrote on purpose ("the model is not usable here, never a broken request") swallowed it and quietly served the climatology fallback. The fallback design that makes the app robust is the same design that hid the bug. I only caught it because I read the run log instead of the UI.

TabPFN on a 2-core ARM box is not fast. The full run — two evaluation fits, two product fits, and seven recursive one-day-ahead predictions — took 68 minutes on two CPU cores. TabPFN is a transformer that does its learning in-context, so every prediction re-reads the whole training set: the cost is per-prediction, not per-training-run. Lowering the row cap to a few hundred cuts that dramatically, and on this holdout it did not hurt accuracy. I shipped the 2,500-row default because it is the stronger claim, and I would rather state the honest runtime than pretend a 7-day forecast is free.

Honest gaps

The TabPFN licence needs a one-time interactive acceptance per model version, and the weights are 876 MB. That is a real gate on anyone cloning this — on a fresh machine the accuracy panel honestly reads "TabPFN is not active, so there is no model to score" until that is done. The app never hard-fails either way: no TabPFN token falls back to climatology, no Ollama falls back to a template plan, and both fallbacks are labelled in the UI rather than hidden.
Gemma 3 4B is the largest model this machine can serve.

Try it

The code is here: https://github.com/amandevelops/frostline

git clone https://github.com/amandevelops/frostline.git && cd frostline
python3 -m venv .venv && .venv/bin/pip install -r requirements.txt
printf 'TABPFN_TOKEN=%s\n' "<your key>" > .env    # free: ux.priorlabs.ai -> Licenses tab
.venv/bin/python scripts/evaluate.py               # prints the accuracy table above
.venv/bin/python server.py                         # then open http://127.0.0.1:8000

The server is one standard-library file — no framework, no build step, no container. On a slow machine set FROSTLINE_MAX_ROWS=400 in .env and a full run drops from about an hour to a couple of minutes.

Built with TabPFN (Prior Labs, CPU inference), Gemma 3 via Ollama, and Open-Meteo's free archive.

SplitBasket: a local-first grocery ledger I built for my flatmate

Aman — Mon, 05 Oct 2026 06:19:30 +0000

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

What I Built

My flatmate Akshay and I split groceries constantly. One of us pays for the dal, the other for the gas cylinder, and by the end of the month neither of us remembers who owes what. We tried a shared spreadsheet twice and both times it was dead within two weeks — logging a purchase meant opening a file, finding the right row, and doing the arithmetic yourself, which is exactly the friction that makes people stop bothering.

So I built SplitBasket for him. You log a purchase once — item, amount, who paid, the date — tick which flatmates shared it, and that's the whole job. It categorises the item on its own, computes the equal split, and keeps a running balance of who owes whom.

What it actually does:

Log a purchase in one small form: item, amount, payer, date.
Tick who shared it — the equal split is worked out for you.
Auto-categorise into staples, cooking, fresh produce, dairy & eggs, gas & utilities, snacks & drinks, household, personal care, or other.
See the month at a glance — total spend, your share, your live balance, and a spend-by-category breakdown.
Settle up — a plain snapshot of who owes whom, no interpretation needed.
Export to CSV whenever you want the raw numbers.

The part that matters most to us: it all runs on the laptop. The entire ledger lives in a single SQLite file on the machine, and the app works with no internet connection at all.

Demo

The clip walks through logging a grocery run: I type the item, the category appears as I type, the split is computed across all three flatmates, and the new entry lands in the settle-up view.

I handed it over last week — he stopped asking me what he owes, which was the entire point.

Code

https://github.com/AmanDevelops/SplitBasket

How I Built It

The whole thing is deliberately small. It's a Node.js app (Node ≥ 22.5) with zero runtime dependencies, and the open-source AI is the core of how it thinks, not a decorative add-on.

Storage — node:sqlite. Node now ships SQLite in the standard library, so the database is the built-in driver: no ORM, no install step, no external service. Three tables — members, transactions, and transaction_shares — with foreign keys on and the split stored as rows, so a purchase and its shares are always consistent.

Categorisation — local rules first. A grocery-aware rule set maps keywords to categories. It's tuned for how people in an Indian flat actually write their shopping lists, so it recognises Hinglish alongside English: dal, atta, chawal, sabzi, pyaz, doodh, paneer, tel, haldi, namak, chai, gas cylinder. Type "Toor dal 1kg" and it lands in Staples without asking anyone.

Categorisation — an open-weight model when there's one to use. If Ollama is running locally, the server first asks Gemma 3 (1B) — Google's open-weight model, pulled with ollama pull gemma3:1b — to classify the item. The request asks for a strict JSON shape (category, confidence, reason), runs with a 3.5-second timeout, and is parsed defensively. If the model is missing, slow, or returns anything unusable, the code falls back to the local rules automatically and the app keeps working exactly as before.

npm start                     # then open http://localhost:3000
ollama pull gemma3:1b         # optional: richer categorisation
OLLAMA_MODEL=gemma3:1b npm start

The front end is plain HTML, CSS, and JavaScript served by the same Node process — no build step, no framework, nothing to install.

Why Does Open Innovation Matter?

This is the part where open wasn't a preference — it was the right engineering call for this particular project.

The data never leaves the device. A grocery ledger looks harmless, but it's a detailed record of what three people eat, when they cook, and what they spend. With local inference, my flatmate's habits stay on our laptop instead of sitting on a server neither of us controls. For something this personal and this small, "we promise we won't look" isn't a good enough answer.

The behaviour is inspectable and changeable. The categoriser is plain rules in a plain file. When my flatmate told me "that's personal care, not household," I changed one line and it was fixed — no retraining, no prompt-tuning against an opaque model, no waiting on a vendor to improve a black box. With a closed API I'd have had a category I couldn't argue with.

The model is swappable, and its absence is survivable. It runs Gemma 3 (1B) today. If we want a larger model, a different one, or a fine-tune, we change a model name — the product doesn't care, because the model sits behind one function with a working fallback. That fallback is the real win: the app is fully functional with the model switched off entirely. A closed API can't offer that. If it's down, rate-limited, or repriced, your app is down with it.

It costs nothing to run. A flat's grocery ledger should not have a per-request cost. There's no key to rotate, no quota to watch, no bill that grows as the flatmate count does. The only running cost is the laptop we already had.

It works offline. No internet, no problem — which matters more than it sounds, because the moment the ledger stops working is the moment it stops being used.

None of this would have been possible with a closed hosted API without giving something up: the privacy, the inspectability, the offline behaviour, or the cost. Open-weight models and local inference let me hand a friend a tool that is private, honest about how it works, and genuinely his.

Prize Categories

Best Use of Gemma — SplitBasket uses Google's open-weight Gemma 3 (1B) via Ollama as its primary categoriser, running locally on the machine, with a rule-based fallback so the app stays fully functional when no model is available.