I asked Claude Code to get an open-source speech model running. I expected it to work out of the box — download, configure, run. Instead I ended up designing the product I thought was going to ship with the model, before I understood what I was actually working with.
The model was the easy part. Chunking, sync, caching, and a UI I could trust are what made Cadence a product.
The prompt that forbade code
The opening prompt was 1,105 lines. Line nine stated plainly: "Do not implement the application in this task." I didn't ask for code. I asked for a repo audit, a product spec, architecture decision records, a phased roadmap, design requirements, and a handoff prompt for a separate design agent. All six deliverables exist.
That design went through a 19-entry reconciliation ledger. Every proposed feature got graded: Essential, Beneficial, or Decorative. About half were rejected before any implementation started.
The result: 368 backend tests passing, and 6.94 hours of narration rendered from a 63,000-word manuscript in 98.2 minutes of GPU time across 1,869 segments. Zero failures.
What the harness actually does
Cadence is a fully local, proofread-by-ear desktop app. It turns a folder of Markdown files into narration that highlights each paragraph as it's read. I'm dyslexic — the eye skips, autocorrects, and fills in what it expects to see — so I proofread by ear instead of by eye. It runs entirely on my laptop: no account, no subscription, no cloud upload.
The core is Electron with a Python/FastAPI sidecar. Documents parse into content-addressed blocks so highlighting, notes, change detection, and audio caching all line up on the same units. When a manuscript is revised, only changed paragraphs re-render. Notes follow the text that moved, flagged for review rather than silently reattached when a match is uncertain.
That diff-and-reconcile engine was the riskiest component, so it got a dedicated adversarial review. Three confirmed bugs, each fixed with a regression test, before I declared it safe to build on.
The failures that mattered
A Windows quirk failed silently. A hidden file attribute on an entire project folder made every chapter show as stale and refuse to regenerate. The JSON writes kept succeeding, so the app looked fine while the audio never updated. The worker couldn't log the failure either. Both are fixed now.
The speech model itself is not the constraint. I've rendered 2,995 segments across two real projects — 1,869 from that manuscript, 1,126 from 51 company knowledge-base documents (2.51 hours of audio) — with zero failures. The model does what it does. The harness is what makes it reliable.
The rule that came out of it
When a model "should just work" and doesn't, the missing piece usually isn't more model. It's the harness: a spec, decision records, and a design your own review can push back on. An agent will happily build that harness once you ask for it by name.
I ended up with a tool I use every day, built across three consecutive days in July with two later single days adding project management and a notes export. The roadmap existed before the first line of code. The tests existed before I trusted the diff engine. The audio pipeline is boring and reliable because I designed the failure modes first.
The full story is in Cadence: the proofreading tool I built because my brain is worst at proofreading. The receipts — test counts, render times, segment counts — are on the Cadence build page.
Corrected 2026-09-29: a Windows bug "failed silently for weeks" → the duration is no longer stated; three closing sections about other projects, which misstated their status → removed.