Speko Routes Voice Models. Audiobooks Still Need a Studio

Launch HN on 18 August 2026 introduced Speko, a YC S26 company calling itself OpenRouter for Voice AI. One API key; speech-to-text, LLM, and text-to-speech each run on the provider their language-specific benchmarks currently rank first. Failover walks an ordered runners-up list if the primary errors.

For anyone turning an EPUB into a narrated book, that sentence is easy to over-read. A router can swap the TTS vendor when a new model wins a board. It cannot decide that Chapter 4's narrator is not the same person as the villain, or that a footnote should be omitted rather than spoken.

What the launch actually shipped

Speko's public story is measurement, then routing. Boards at benchmarks.speko.ai reportedly track word error rate, finalize latency, time to first token, and cost per minute, broken out by language and region. Docs describe a RoutingIntent on every call and response headers that say which provider ran.

They also published a MIT gateway (SpekoAI/gateway) so teams who do not want a second hop on the audio path can pin providers locally. In BYOK mode the sidecar reportedly never shares keys with Speko's cloud.

Those are real infrastructure answers to a real freeze: a LiveKit agent launched on last year's STT, a Spanish line that needed a different recognizer, a medical vocab test that the launch model failed. The founder, Beknazar Abdikamalov, has said the company exists because picking a voice stack felt like an R&D project.

Audiobook production is not a phone-call graph

A conversational agent is STT → LLM → TTS in a tight loop. An audiobook is a long, one-way render with editorial decisions baked in before the first byte of audio:

• Reading order. EPUB spine, hidden accessibility text, and image alt can all leak into a naive extract.
• Casting. Dialogue tags, first-person narration, and interior monologue are not the same voice. Auto-casting is a studio problem, not a provider-rank problem.
• Pronunciation. Proper nouns, invented names, and numbers need a guide the renderer will actually obey.
• Chapter artifacts. Silence at chapter boundaries, metadata, and m4b/mp3 export matter more than time-to-first-token on a 30-second clip.
• QC. ACX and similar programs care about RMS, peak, noise floor, and consistent headroom. A benchmark win on "naturalness" does not pass those meters.

Speko's own launch post draws a similar line in another domain: a 30-second demo is not minute eight of spontaneous speech. For books, a 30-second sample is not hour four of a consistent narrator. Rankings that move daily are useful for agents that can swap mid-call. They are dangerous for a 10-hour title that must sound like one production.

If you do use a multi-provider TTS router for narration, pin the winner for the title. Log the model id in the production notes. Do not let an overnight board update recast chapter 12.

A workable pin looks like a row in the production notes, not a comment in Slack:

• title and ISBN or filename
• language and region you routed for
• STT (if you transcribed a reference take), LLM (if you used one to clean dialogue tags), TTS (the narrator and each character)
• provider, model id, and the benchmark run id if the router returns one
• date the pin was frozen, and the person who signed off after listening to chapter one and a late-book sample

If the router exposes X-Speko-Provider / X-Speko-Model / X-Speko-Scores-Run-Id style headers, copy them into that row. Six months later, when a retailer rejects a replacement file, you will need to regenerate the same voice, not "whatever is ranked first this week."

Consistency is a different metric than WER

Phone-call benchmarks optimize for getting the next utterance out. Audiobook QC optimizes for the book not changing personality.

Listen for drift that a 30-second clip will never show:

• The narrator's pitch and pace in chapter 1 versus chapter 18
• A character who shares a voice with a walk-on in a later scene because the caster only looked at the first three chapters
• Numbers, foreign words, and invented names that the model guessed differently after a chapter break
• Room tone and limiter behavior that jump when a retry went to a different provider

Those are studio problems. A language-level WER board will not warn you. The mitigation is still analog: freeze the cast, freeze the renderer, listen to the joins, then export.

Where routing still helps a studio

There are adjacent jobs where Speko-shaped routing is the right layer:

• Pre-production listen. You want the current best English or Japanese TTS to proof a chapter extract before you commit the full book.
• Localization. The same EPUB in a second language may want a different vendor; a language-tagged router is built for that, provided you still recast rather than blindly reuse the English voice map.
• Agent-shaped extras. A "ask the book" demo, a storefront preview that answers one reader question, or an IVR that quotes a blurb — those are voice agents, and they are who Launch HN was written for.

They remain extras. The book itself is still a manuscript → narration script → multi-voice render → QC → export pipeline.

Keep the studio, optionally swap the engine

VoxForge turns an EPUB or text file into a chaptered, multi-voice audiobook: character casting, per-character voices, optional cloning, streaming, and mp3/m4b export. It does not claim to sit behind Speko, and it should not. The product is the studio workflow. The TTS vendor is a dependency that a router might one day swap.

If Speko's boards start listing narration-quality, long-form, and consistency metrics — not only phone-call WER and TTFT — then an audiobook stack would have something to route on. Until then, treat Launch HN as news about agent infrastructure, and keep doing the unglamorous work: clean the EPUB, lock the cast, listen to chapter one on good speakers, then export.

A router can pick a voice model. A book still needs a producer.

---

Cast the characters, then render the book. Start from an EPUB on VoxForge.