DEV Community: chiragmangaldev3112

Torpor — Your Inbox, Summarized While You Sleep (Fully Local)

chiragmangaldev3112 — Fri, 23 Oct 2026 06:49:51 +0000

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

What I Built

Torpor — a lazy, fully-local overnight inbox digest. Instead of reading every message that came in overnight, you run one command and torpor reads them for you, using only open-weight models running on your own machine. Named after the energy-saving dormant state that animals — sloths included — drop into when there's no reason to spend effort.

Point it at a JSON file of messages and it: embeds each one locally, scores it against a handful of "this needs a human" reference phrases by meaning (not keyword matching), splits messages into "needs you" vs. "can wait" using the inbox's own score distribution, and asks a local model to write a genuine 2–3 sentence summary of what actually matters.

It also has a small local knowledge-bot mode: point it at any folder and ask it a question in plain English, and it'll find the relevant parts and answer with citations — the same local embed-and-answer pipeline, just pointed at files instead of messages.

Demo

$ ollama pull qwen3:8b
$ ollama pull nomic-embed-text
$ npm start

torpor: barely awake. 10 messages to get through, so I'll do it.

While you were asleep: 3 of 10 actually need you. The other 7 can wait.

In short (qwen3:8b, running right here):
Partner NDA requires your signature by Friday's kickoff call to avoid delaying
the start date. Overdue invoice #4471 ($3,200) risks service interruption if
not paid by end of day. Production deploy failed at 2am due to a database
migration error; no one has addressed it yet.

Worth getting up for:
  [0.64] legal@example.com — NDA needs your signature
  [0.59] billing@vendor-example.com — Invoice #4471 overdue
  [0.58] ops@example.com — Production deploy failing

Can stay asleep for these:
  [0.57] friend@example.com — lunch next week?
  [0.56] priya@example.com — Quarterly numbers due
  [0.55] security-alert@example.com — New sign-in detected
  ...

That whole run takes a few seconds, on a laptop, offline.

$ node src/index.mjs ask src "how does torpor decide which messages need attention?"

Torpor decides which messages need attention by using a scoring system based
on statistical thresholds. The `splitByAttention` function [5] calculates the
mean and standard deviation of attention scores for all messages. It then
sets a threshold at the mean plus 0.5 times the standard deviation...

From:
  [1] index.mjs:97
  [2] index.mjs:65
  [3] digest.mjs:65
  [4] index.mjs:33
  [5] digest.mjs:33

Code

https://github.com/chiragmangaldev3112/torpor

How I Built It

Two separate local-AI calls, both through Ollama: nomic-embed-text for embeddings, qwen3:8b for the summary. A naive fixed similarity threshold only caught 1 of 3 real urgent messages in testing — cosine similarity on short text clusters tightly — so the "needs you" split uses an adaptive threshold (the inbox's own mean + half a standard deviation) instead of a magic number.

The whole thing is model-agnostic by design: swap TORPOR_CHAT_MODEL to run it on a different model entirely, with no code changes.

Why Does Open Innovation Matter?

It runs with no internet and no API key. The whole pipeline — embeddings and the summary — happens on localhost:11434.
Your messages never leave your machine. An overnight digest is, by definition, a summary of everything you haven't read yet — sending that to someone else's model every night is a real privacy cost a local model avoids entirely.
It's free to run forever. No per-token billing on something meant to run every day, unattended.
You can swap the model. Nothing here is tied to one vendor — change an env var, use a different model you've pulled.

This idea grew out of a larger assistant platform I'm building separately, where open-weight models aren't a one-off choice — a repository gets searched with local embeddings, a small model can be fine-tuned on someone's own writing through a local LoRA pipeline, and step-by-step task decisions are made by a local model through the same provider-agnostic interface. Torpor builds the first of those — local code search and Q&A — from scratch, and it's real working code in this repo, not just a description: src/codesearch.mjs chunks any folder, embeds it locally, and answers questions with citations, the same embed-then-chat pattern the inbox digest uses on messages.

The Lazy Payoff

Before: open the inbox, scan every message, figure out what's actually urgent. After: run one command, read three sentences, know exactly what needs you — the overdue invoice, the failed deploy, the NDA deadline, not the lunch invite.

Honest caveat: the attention/FYI split is a simple statistical heuristic, not a trained classifier — it missed a security alert in testing (landed just under the threshold). Good enough for a weekend build, not a production safety net.

Prize Categories

Best Use of Gemma — Torpor is model-agnostic by design (TORPOR_CHAT_MODEL env var), and I tested it end-to-end against Google's Gemma 3 via Ollama: both the inbox digest and the code-search ask command work correctly. One honest note — Gemma 3 tends to answer in a numbered list even when asked for short prose, where qwen3:8b writes flowing sentences; still accurate, just a different style.

I made "verified" mean something for AI agent instructions — here's what that actually took

chiragmangaldev3112 — Fri, 18 Sep 2026 09:52:09 +0000

Every AI coding agent I used — Claude Code, Cursor, GitHub Copilot —
failed in the same few ways. It guessed at an ambiguous request instead
of asking. It graded its own work instead of checking independently. It
forgot a project's conventions the moment a new session started.

So I wrote the process down: 37 "playbooks" covering bug fixing, feature
development, code/security review, safe database migrations, incident
response, and more. One instruction set, installed once, read natively by
whichever AI tool you're using (15 supported so far).

That part's a straightforward pitch. What I actually want to write about
is the harder problem underneath it: once you claim something is
"verified," what does that actually have to mean before the word is worth
anything?

The trap: "verified" as a vibe

Early drafts of some of these playbooks said things like "this was tested
and works." That's not verification — it's a vibe wearing verification's
clothes. It has the shape of a checked claim without any of the
substance, and it's exactly the kind of self-assessment I was trying to
get an AI agent to stop doing in the first place. If I'm asking an agent
to never trust its own "looks right," I can't ship a project full of my
own unchecked "looks right"s.

So I went back through every playbook and either found the real evidence
behind every claim, or removed the claim. This is where it got
interesting, because actually running things — not re-reading code,
not reasoning about it — surfaced real bugs I would never have caught
otherwise:

A sparse-page detection script for scanned PDFs was off-by-one on page counting. It assumed "N form-feed characters means N+1 pages," but direct byte-level inspection of a real scanned PDF showed pdftotext emits one trailing form-feed per page, including the last one. The math only looked right until I actually counted bytes in a real file.
A file-extension parser detected format from the full path, not the filename — so a file sitting in a directory like v2.0/README (a dot in the parent directory name, not the file) got misdetected as extension 0/readme and routed to completely the wrong handler.
A security hook meant to scan every file-write for leaked credentials had a matcher that only covered Write and Edit tool calls — MultiEdit calls bypassed it entirely. Nobody wrote that gap in on purpose; it just never got exercised until a re-evaluation pass specifically tried to break it.

None of these were found by review. All of them were found by running
the actual thing against a real case and checking the actual output.

Independent review catches what self-review can't — even for an AI

The MultiEdit gap above is the one I want to dwell on, because of how
it was found. I had a separate pass — same underlying model, zero memory
of why the original hook was built the way it was — re-check the finished
work cold. It didn't know the design history, didn't know what the
original author was trying to protect against. It just tested the actual
behavior against the actual documentation and found they didn't match.

This is the same reason code review works on human teams: the person who
wrote something is the worst-positioned person to spot what's wrong with
it, because they already have a model in their head of what it's
supposed to do, and that model quietly overrides what's actually in
front of them. It turns out this holds for an AI agent reviewing its own
prior work too — a fresh pass with no attachment to the original
reasoning catches things a self-review pass structurally can't, not
because it's smarter, but because it isn't carrying the same blind spot.

Signing matters more once you think about what the content becomes

The playbooks aren't just documentation — once installed, they become
literal instructions an AI agent with shell access follows. That's a
different threat model than a typical doc site. If the backend serving
this content were ever compromised, a swapped file isn't a broken link,
it's an instruction an agent might actually execute.

So every release is signed with Ed25519 (ssh-keygen -Y sign/verify, not
OpenSSL — stock macOS ships LibreSSL, which can't verify Ed25519
signatures at all, confirmed by trying it directly rather than assuming),
and the installer re-hashes every fetched file against a signed manifest
before writing anything. The backend can withhold a release, but it can't
successfully substitute one, because it never holds the private key.

Where this leaves things

37 playbooks, MIT-licensed, free, no account needed:
https://github.com/chiragmangaldev3112/agent-playbooks

I don't think "verified" is a box to check once. It's a standing bar
that gets tested every time someone looks at the thing again with fresh
eyes — which is exactly what a second, independent pass is for, and
exactly what found every bug described above.

Happy to go deeper on any part of this — the signing setup, the
per-tool artifact generation, or the specific bugs — in the comments.