Voice AI deployments typically lock you into a single vendor’s STT/LLM/TTS stack. You pick Deepgram or AssemblyAI or OpenAI based on an English leaderboard, then discover your users speak Hindi or Norwegian and your chosen model ranks seventh for those languages. Speko (YC S26) positions itself as “OpenRouter for Voice AI,” a routing layer that benchmarks speech models across providers and languages, then selects the optimal combination given your latency and cost constraints.
The platform measures 23 speech-to-text models, multiple LLMs, and text-to-speech engines across nine languages. It exposes a single API that decides which provider stack to call per request, using published benchmarks instead of vendor marketing claims.
Orchestration Flow
Speko’s routing decision happens before the first audio frame hits a provider. Based on the platform’s public demo and documentation, the flow works like this:
- Constraint ingestion: You specify latency ceiling, cost cap, and target language via API parameters.
- Candidate filtering: The router queries its benchmark database for STT/LLM/TTS combinations that satisfy hard constraints.
- Scoring: Remaining candidates are ranked by a composite score balancing accuracy against cost.
- Selection: The top-ranked combination is chosen and logged.
- Execution: The request is proxied to the selected providers.
The platform’s demo video shows the router displaying candidate combinations with their benchmark scores before making a selection. The interface exposes why each model was chosen or rejected based on the constraint set.
Benchmarking Pipeline
Speko runs continuous benchmarks across providers using a fixed test corpus per language. According to the platform’s public model comparison table:
- Audio corpus: Standardized recordings in nine languages (English, Arabic, French, German, Hindi, Norwegian, Spanish, Tamil, Telugu).
- Metrics collected: Word Error Rate (WER) for STT, cost per minute from provider pricing APIs.
- Coverage: 23 STT models benchmarked, with 11 measured only in English. The platform explicitly notes that “their rank in any other language is unknown, including the model that sits at the top of the English table.”
- Language-specific winners: The benchmark table shows four different models winning across the nine languages, confirming that no single model is optimal everywhere.
The platform publishes these benchmarks publicly, allowing you to verify the data before routing production traffic. For example, AssemblyAI’s Universal-3.5 Pro shows 2.0% WER at $0.0075/min in English, while OpenAI’s GPT-4o Transcribe shows 2.3% WER at $0.0060/min.
Constraint Enforcement
When multiple combinations satisfy your constraints, Speko uses a weighted scoring approach. The exact implementation is not publicly documented, but the typical pattern for multi-objective optimization in routing systems follows this structure:
[pseudocode]
function score_combination(stt_model, llm_model, tts_model, user_weights):
accuracy_score := (1 - stt_model.word_error_rate) * user_weights.accuracy
cost_score := (1 / total_cost(stt_model, llm_model, tts_model)) * user_weights.cost
latency_score := (1 / estimated_latency(stt_model, llm_model, tts_model)) * user_weights.latency
return accuracy_score + cost_score + latency_scoreThe platform does not predict LLM token counts before generation, so cost enforcement is approximate. If a call exceeds the cost cap due to unexpectedly long LLM output, you pay the overage. This is a common constraint in voice AI routing: pre-call token estimation adds latency and is often inaccurate for conversational workloads.
Provider API Failures and Fallback
The Hacker News discussion includes questions about mid-call failure handling, but Speko’s public documentation does not specify whether the platform implements automatic fallback to secondary models. Common patterns in voice AI routing include:
- Abort on failure: Predictable error modes, simpler state management, but no resilience.
- Fallback to secondary stack: Better uptime, but switching STT models mid-conversation breaks context and introduces latency spikes.
Most production deployments prefer the first approach because silent model swaps can degrade quality in ways that are hard to debug. Without explicit documentation from Speko, assume standard timeout and retry behavior similar to other API gateways.
Observability
The platform’s demo video shows a request-level view of routing decisions, including which models were evaluated and why the selected combination won. While the exact log format is not publicly documented, the interface displays:
- Language detected
- Constraints applied
- Candidate models evaluated
- Selected STT/LLM/TTS combination
- Benchmark scores for each component
This visibility helps debug why a specific combination was chosen for a given request. You can track model selection distribution over time to spot when a provider’s latency degrades and triggers a shift to a competitor.
Deployment Shape
Based on the demo video and platform documentation, Speko appears to run as a stateless HTTP proxy. You point your voice AI client at api.speko.ai instead of api.openai.com or api.assemblyai.com. The likely architecture:
- Authenticates your request using a Speko API key.
- Translates your request into the selected provider’s API format.
- Proxies the call to the provider.
- Streams the response back to your client.
This design means Speko sits in the critical path for every request. If the platform goes down, your voice AI stops working. You are adding a dependency and a network hop in exchange for automated model selection.
Tradeoffs and Failure Modes
| Dimension | Speko Approach | Direct Provider Integration | Tradeoff |
|---|---|---|---|
| Model selection | Constraint-based routing | Manual provider choice per language | Automates optimization but adds routing latency and platform dependency |
| Cost enforcement | Post-call variance logging | Pre-call budget checks | Simpler logic but occasional overages when LLM output is verbose |
| Observability | Unified routing logs | Per-provider dashboards | Single pane of glass but requires trusting Speko’s metrics |
| Vendor lock-in | Single API for all providers | Direct provider SDKs | Easier switching but dependency on Speko’s uptime |
| Benchmark coverage | Nine languages, 23 STT models | Provider-specific testing | Broad comparison but gaps in less common languages |
Likely failure modes:
- Benchmark staleness: If a provider updates a model and Speko’s benchmarks lag, you might route to a now-inferior option. The platform’s update frequency is not publicly documented.
- Language coverage gaps: Only nine languages are benchmarked. If your users speak Swahili or Mandarin, the router must fall back to heuristics or default to English benchmarks.
- Provider API changes: If a provider deprecates an endpoint, Speko must update its translation layer or that provider becomes unavailable to all customers.
- Routing overhead: Adding a proxy layer introduces latency. Typical API gateway overhead ranges from 50ms to 150ms depending on network conditions and routing complexity. This overhead is not published in Speko’s documentation but should be measured in your production environment before committing to the platform.
Technical Verdict
Use Speko when:
- You serve users across multiple languages and need per-language model optimization without manual configuration.
- Your cost or latency constraints are strict enough that manual provider selection is risky.
- You want to avoid vendor lock-in and test new providers without rewriting integration code.
- You can tolerate an additional network hop and platform dependency in your critical path.
Avoid Speko when:
- You need guaranteed sub-200ms end-to-end latency and cannot afford any routing overhead.
- Your application operates in languages outside the nine benchmarked options.
- You need to run voice AI in an air-gapped or on-premises environment (Speko is SaaS-only).
- You require contractual SLAs for uptime and latency that a third-party proxy cannot provide.
The platform solves a real problem: voice AI model selection is currently guesswork dressed up as vendor leaderboards. Speko turns it into a data-driven routing decision. The cost is an extra dependency and the risk that benchmarks do not perfectly predict your production workload. For applications where per-call cost variance and multi-language support directly impact operational efficiency, the routing layer may be worth the added complexity.