DEV Community

Cover image for Sidekick part 5 (finale): what four parts added up to
Irfan Wani
Irfan Wani

Posted on

Sidekick part 5 (finale): what four parts added up to

Sidekick Part 5 (finale): what four parts added up to

This series started with a bet — a terminal companion on your hardware, no account, no bill — and spent four parts defending it piece by piece. This is the last planned part: what it all added up to, what I deliberately left out, and where new parts come from here.

The arc in four sentences

Part 1: overview — sk is chat, voice, and 19 tools running locally via Ollama, with cloud as opt-in per key rather than structural. The decision: deterministic grounding over prompt instructions.

Part 2: grounding — small models ignore rules, so code injects facts before the model sees the prompt: hardware snapshot, auto directory listings, fetched URLs, recency-triggered search. Every past hallucination is locked in test_eval.py as a regression test.

Part 3: voice — push-to-talk transcribed on your CPU by int8 faster-whisper, recordings deleted after every take. Privacy as architecture: no upload path exists.

Part 4: safety — approvals at dispatch, a deception-assuming shell denylist, egress deny-by-default, one trust chokepoint, and sk audit as proof. Every ceiling documented with issue numbers instead of oversold.

What the parts share

Three through-lines showed up in every installment whether I planned them or not. First, local-first is load-bearing, not branding — grounding works because sysinfo is real, voice privacy holds because there's no server, audit means something because the ledger is yours. Remove "runs on your hardware" and most claims in this series collapse. That's how you test a principle: delete it and see what breaks.

Second, honesty about ceilings is a feature. The series documented guessed caps, dumb regex triggers, an unfenceable shell-curl path, and a 980-line neighbor file (that was another project, but same instinct). Readers trust "here's where it breaks" more than "it just works," and future maintainers — including me — need the ceilings written down more than the victories.

Third, everything is sedimentary. Grounding exists because instructions failed. Egress rules exist because prompts failed. Eval tests exist because answers failed in production. Nothing here was designed top-down; it accreted around real failures, each layer dated by the bug that forced it.

What's deliberately missing

Memory and skills, the background daemon, the MCP server beyond a mention, providers and spend caps, the TUI internals. Not oversights — scope control. Each deserves the same treatment (mechanism, tradeoff, breakage) and each gets a part when there's something real to say about it.

The deal going forward

This series is complete as planned. But software doesn't stand still: when new features land, or old ones break interestingly, they'll show up here as new parts — same contract (evidence, mechanism, what broke), same numbering continuing upward. A series that ends is better than one that trails off; a series that resumes for cause is best.

Thanks for reading all five. Go run it locally: uv tool install sidekick-agent and sk init.


Built by the Sidekick community. Repo: https://github.com/Faisal-Fayaz/sidekick

Top comments (0)