Build local voice agents with open-source models
5.8k
Stars
725
Forks
94
Open issues
26
Contributors
AI Analysis
Speech-to-Speech is a modular, low-latency voice-agent pipeline that chains VAD → STT → LLM → TTS components, exposing them via an OpenAI Realtime-compatible WebSocket API with fully swappable backends. It is purpose-built for developers and roboticists building local voice agents with open-source models, particularly those running conversational AI on edge devices or self-hosted infrastructure—not a general-purpose speech library, but a production-grade orchestration layer proven in thousand...
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
HuggingFace's modular VAD→STT→LLM→TTS pipeline exposes an OpenAI Realtime-compatible WebSocket API for fully local voice agents
speech-to-speech is a low-latency, four-stage voice agent pipeline (VAD, STT, LLM, TTS) built by HuggingFace. It targets developers who want to run voice assistants locally or in hybrid setups using open-source models, without depending on proprietary APIs. Each stage is independently swappable. Notably, it ships an OpenAI Realtime-compatible WebSocket interface, meaning any existing Realtime API client can point at a self-hosted instance. It is confirmed in production powering conversation backends for Reachy Mini robots, giving it at least one verified real-world deployment at meaningful scale.
Created in August 2024, originally as a research/demo project from HuggingFace. It has since matured into a pip-installable library with a production claim, growing from a demo to a proper server with a standardized API interface by mid-2026.
Initial traction came from HuggingFace's brand and the growing interest in local LLM voice interfaces. The shift to an OpenAI Realtime-compatible API in later development significantly broadened its appeal by enabling drop-in replacement scenarios. The Reachy Mini production mention and a recent 362-star week (as of 2026-07-05) suggest a new publicity event or feature release recently re-energized interest.
Explicitly stated in the README: the pipeline runs in production as the conversation backend for 'thousands of Reachy Mini robots' (HuggingFace's consumer robot). This is a verifiable, named deployment at non-trivial scale. Additional adoption beyond this is not documented in the README.
Appears to use a multi-threaded pipeline where each stage (VAD, STT, LLM, TTS) runs in its own thread connected via queues. The server exposes a WebSocket endpoint implementing the OpenAI Realtime API protocol. Backends are pluggable via CLI flags. Likely uses Transformers/HF Hub for model loading, with optional GGML and MLX backends for edge performance. Platform-aware dependency resolution (macOS vs non-macOS) is handled in pyproject.toml.
Not documented in README.
Last push was 2026-07-04, less than 48 hours before the evaluation date — indicating very active maintenance. The README documents active deprecation (MeloTTS archived), addition of new backends, and compatibility notes, all suggesting ongoing development rather than passive upkeep.
ADOPT IF: you need a self-hosted, modular voice agent backend with OpenAI Realtime API compatibility, especially for edge deployments, robotics, or privacy-sensitive applications where cloud dependency is unacceptable. AVOID IF: you need a production-grade, battle-tested multi-tenant server with SLA guarantees, mature observability, or broad language support out of the box — the project's operational maturity outside of HuggingFace's own use cases is unverified. MONITOR IF: you are building voice-enabled products and want to evaluate whether the OpenAI Realtime-compatible self-hosting path matures enough to replace a hosted dependency in the next 6–12 months.
Independent dimensions
Mainstream potential
6/10
Technical importance
8/10
Adoption evidence
4/10
- Dependency complexity is high: CUDA version-specific wheels, platform-conditional extras, and numpy version conflicts (DeepFilterNet vs Pocket TTS) may cause significant environment management pain in production.
- Production evidence is limited to a single first-party deployment (Reachy Mini by HuggingFace itself); third-party production hardening is largely unverified.
- OpenAI Realtime API compatibility is a feature claim that may drift as OpenAI evolves its protocol; maintaining parity could become a maintenance burden.
- As a HuggingFace project, its roadmap and maintenance depend on internal prioritization; if focus shifts, maintenance could slow without external community ownership.
- Latency characteristics for fully local inference depend heavily on hardware; the README does not document benchmark numbers, making it difficult to set expectations for resource-constrained deployments.
Likely to become a reference implementation for self-hosted OpenAI Realtime-compatible voice agents, especially in robotics and edge AI. Growth will be tied to the broader local LLM adoption curve and HuggingFace's continued investment.
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Language
- Python
- License
- Apache-2.0
- Last updated
- 21h ago
- Created
- 23mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
LLM responses containing Markdown are read literally by TTS (asterisks, headings, bullets, etc.)
Add Qwen3-ASR support as an STT backend
Add missing faster-qwen3-tts features for the ggml backend
Idea: add short sentences when LLM responses are taking too long
Proposal: split text and vision inference (vision resolver)
Top contributors
Recent releases
Similar repos
lenML/Speech-AI-Forge
Speech-AI-Forge is a specialized text-to-speech (TTS) platform that integrates...
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
|
5.8k | +849 | Python | 8/10 | 21h ago |
|
|
1.4k | — | Python | 7/10 | 2mo ago |
|
|
11.3k | — | Python | 8/10 | 14h ago |
|
|
2.2k | — | Python | 8/10 | 1d ago |
|
|
39.6k | — | Python | 7/10 | 3mo ago |
|
|
12.4k | — | Python | 7/10 | 2mo ago |
LiveKit Agents is a more comprehensive, infrastructure-first framework with built-in room/session management, plugins for many providers, and strong cloud deployment support. speech-to-speech is lighter, more focused on the inference pipeline itself, and easier to run fully locally without cloud dependencies. OpenAI Realtime compatibility partially overlaps their feature sets.
Open-LLM-VTuber targets the VTuber/avatar use case with a visual layer on top of voice. speech-to-speech is narrowly focused on the audio pipeline and exposes an API rather than a UI, making it more suitable as infrastructure than as an end-user application.
ChatTTS is a TTS-only project with very high star count driven by TTS quality interest. speech-to-speech is a full pipeline and can optionally use ChatTTS as its TTS backend, so these are more complementary than competing.
Speech-AI-Forge focuses on TTS model management and inference, including a studio UI. speech-to-speech is a complete conversational pipeline with bidirectional audio, a different problem scope.
The hosted OpenAI Realtime API is the reference implementation. speech-to-speech explicitly targets compatibility with it as a self-hosted, open-source alternative. It trades the convenience and latency optimization of the hosted service for model choice, privacy, and cost control.