Speko Launches Voice AI Router

Speko (YC S26) is Bek’s YC S26 project for choosing a production voice AI stack across speech-to-text, an LLM, and text-to-speech. It deals with a real evaluation problem: each layer has many credible vendors, and the “best” stack changes when latency, price, language, voice quality, or reliability constraints change. The useful takeaway is simple: Speko launches as a reminder that model choice is now a measurement problem, not a one-time vendor decision. That same habit matters in agentic coding, where Codex, OpenAI’s coding agent, Codex, Anysphere’s AI code editor, and MCP-connected tools all need repeatable eval loops instead of vibes.

A voice AI router is a decision layer that compares model combinations against constraints and explains why one stack fits a job better than another. Speko’s pitch is close to “OpenRouter for Voice AI,” but with an extra twist: voice agents are not one model. They are a pipeline.

Start with the three-model pipeline

A typical production voice agent has three moving parts.

Speech-to-text turns the user’s audio into text. The LLM decides what to say or do. Text-to-speech turns the response back into audio.

That sounds tidy until you ship it. A faster STT model can help latency but hurt transcription quality in noisy rooms. A stronger LLM can improve task completion but raise cost. A nicer TTS voice can make the agent feel better while adding enough delay to make the whole call awkward.

Speko’s launch caught developer attention because it treats that stack as one object. The question is not “which TTS vendor is best?” The better question is “which STT + LLM + TTS combination meets this product’s constraints today?”

The trap is evaluating one layer in isolation. If you benchmark TTS quality without measuring end-to-end turn time, you can accidentally optimize the prettiest part of a system users experience as slow.

Notice why developers asked about gateways

The obvious Hacker News question was comparison. People asked how Speko differs from voice infrastructure such as LiveKit Gateway or managed voice-agent platforms such as Vapi.

That is the right objection. A gateway usually makes it easier to connect to providers and route traffic. A managed platform may give you more of the application surface. Speko’s interesting claim is narrower: it helps find and explain an optimal combination from benchmarked options given constraints.

That matters because “switching vendors” is often the hidden tax in AI systems. The first stack decision is fun. Rechecking it every month is not. New STT, LLM, and TTS models arrive often enough that the original choice can go stale while nobody is looking.

The same pattern shows up in agentic coding. A repo might start with one coding agent, one review prompt, and one MCP server. Six weeks later, the codebase, model behavior, and team expectations have changed, but the workflow is still running on the first lucky guess. That is how developer productivity tooling quietly drifts.

Bring the lesson back to coding agents

The Speko story is not secretly about coding agents. It is about voice AI. But the engineering lesson travels well.

Agentic coding is also a pipeline. A coding agent reads repo context, plans a change, calls tools, edits files, runs checks, and hands back a diff. Each stage has its own failure mode.

For a Codex workflow, the equivalent of Speko’s “best stack” is not “which model writes the most code?” It is “which agent setup produces the smallest safe diff that passes verification for this repo?” That is where the related training topic becomes practical rather than bureaucratic.

A small repo rule can make this concrete:

# AGENTS.md

## Verification boundary
- Before opening a PR, run the narrowest relevant check first.
- For frontend changes, run: npm test -- --runInBand path/to/changed.test.ts
- For API changes, run: npm run test:api -- path/to/changed.test.ts
- If a full suite is needed, say why before running it.
- Do not change provider, model, or MCP permissions in the same diff as product code.

## Handoff receipt
Every agent handoff must include:
- files changed
- tests run
- tests not run, with reason
- assumptions about external services
- one suggested reviewer focus

That is not a grand program. It is a measurement boundary. The agent has to show what it touched, what it checked, and where the risk remains.

The trap is turning every model-routing insight into a platform project. Most teams do not need a full benchmark harness on day one. They need one repeatable comparison they can run again next month.

Try Speko when the stack decision keeps moving

Speko is worth a look when you are choosing or revisiting a voice AI stack and the constraints are real. Think call-center latency, multilingual transcription, noisy input, price ceilings, brand-sensitive voices, or a product where a half-second delay changes user behavior.

It may be overkill if you are building a prototype, using one provider’s hosted voice stack end to end, or still proving that users want the feature at all. In that stage, the fastest path is often one vendor, one happy path, and a clear note about what you did not evaluate.

For coding-agent work, borrow the shape of the decision. Keep provider choice separate from repo rules. Keep MCP access separate from model selection. Keep code review guardrails separate from model enthusiasm.

A useful comparison is our write-up on Epho Runs Claude Code with Curl, because it shows the same instinct from another angle: shrink the workflow until the verification loop is visible.

Copy this safe evaluation checklist

Use this when trying Speko for voice AI, or when borrowing the same evaluation pattern for Codex and other coding agents.

Copyable experiment plan:

## Voice stack evaluation receipt

Scenario:
- User goal:
- Audio conditions:
- Language or accent requirements:
- Latency target:
- Cost ceiling:
- Quality bar:

Stacks compared:
- Stack A: STT / LLM / TTS
- Stack B: STT / LLM / TTS
- Stack C: STT / LLM / TTS

Result:
- Best fit:
- Why:
- Tradeoff accepted:
- Tradeoff rejected:
- Recheck date:

Safety boundary:
- No production traffic until replay tests pass.
- No provider credential changes in the same PR as app logic.
- MCP servers used for evaluation must be read-only unless a maintainer approves write access.

The important line is “tradeoff accepted.” Real evals rarely produce a perfect winner. They produce a decision you can explain later.

Common questions

• Is Speko just OpenRouter for voice AI?

  Speko describes itself in that neighborhood, but the voice stack makes the problem different. A production voice agent usually combines STT, an LLM, and TTS, so the comparison is about combinations rather than one model endpoint. The useful part is the explanation of why a stack fits given constraints.

• How is this different from a voice AI gateway?

  A gateway usually focuses on connecting and routing across providers, while Speko’s launch pitch centers on benchmarking combinations and recommending an optimal stack. The distinction matters because a gateway can make switching possible, but an eval layer helps decide whether switching is worth it.

• Why should Codex users care about a voice AI launch?

  Codex users should care because the same failure pattern appears in coding-agent workflows. Teams pick one model, one tool boundary, and one review habit, then stop measuring. A lightweight eval receipt for diffs, tests, MCP access, and reviewer focus keeps the workflow honest without turning it into process theater.

• When is this kind of evaluation too much?

  It is too much when the product question is still “should this exist?” rather than “which stack should carry production traffic?” For a prototype, use one simple stack and write down the known gaps. Bring in comparison once latency, cost, quality, or reliability affects real users.

• What should we measure first for agentic coding?

  Measure the handoff before measuring everything else. For each Codex run, capture files changed, tests run, tests skipped, assumptions, and reviewer focus. That small artifact gives you a repeatable baseline for ai code review without pretending you can score every part of software engineering.

Best ways to use this research

• Best for: Developers choosing a voice AI stack, and engineering leads who want a concrete example of eval-driven model routing without a giant platform story.
• Best first artifact: A one-page evaluation receipt that records constraints, compared stacks, accepted tradeoffs, and the date you plan to recheck the decision.
• Best comparison angle: Speko is most interesting when compared with gateways and managed voice-agent platforms on decision support, not just provider access.
• Best coding-agent takeaway: Treat Codex and MCP workflows as pipelines with measurable boundaries: context, tool access, edit quality, verification, and handoff.

Further reading

• Speko (YC S26) — source
• Model Context Protocol — specification
• Codex — Agent
• OpenAI Codex

Next step

If Speko sounds relevant, replay three real voice-agent scenarios through your candidate stacks and write down the tradeoff you are accepting. If you are here for coding agents, add the AGENTS.md handoff receipt first; it is the cheapest eval you can run this week.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.