The caller hears **a confident wrong reply**, and the logs show every stage "working". The nesting below shows where transcription sits inside the whole agent, and why a clean transcript only clears the first stage. ### Checking current ElevenLabs realtime speech-to-text details Because ElevenLabs added the realtime speech-to-text API recently, behavior and options may still be shifting. I'm not quoting a release date here. Read the date the maker's own pages give, on the [ElevenLabs documentation](https://elevenlabs.io/docs), and compare it with the 2026-10-25 check date above. If the page's changed since then, trust the page over this article. ## How one live call moves through the system Count the stages of a live call and you get **six, in a fixed order**. ElevenLabs' realtime speech-to-text documentation covers only the first four-ish: the connection, the audio going in and the transcripts coming back. 1. Your server opens a WebSocket (a connection that stays open so data can flow both ways) to the realtime endpoint. 2. Audio from the caller streams in over that connection. 3. Partial transcripts come back while the caller is still talking. 4. A final transcript comes back once the speech settles. 5. A language model drafts the reply from that final text. 6. A speech synthesiser voices the reply and plays it back to the caller. Read the list and you see that stages 1 to 4 sit inside one service and stages 5 and 6 sit outside it. **You can't blame the transcriber for a slow or wrong answer on the phone until you've checked which stage produced it.**  On its documentation page, ElevenLabs describes the [realtime endpoint](https://elevenlabs.io/docs/de/api-reference/speech-to-text/v-1-speech-to-text-realtime) as a "realtime speech-to-text transcription service" whose WebSocket API "enables streaming audio input and receiving transcription results." That's the whole of its stated job: audio in, text out. Nothing in that description says it decides what to reply, so any logic you attach starts after the final transcript. ### After the transcript: reply and voice If the reply is wrong while the transcript is right, the fault is in stage 5, and re-tuning the listening side will change nothing. That stage belongs to whichever language model you choose. The transcriber hands over text; the model drafts the answer. When stage 6 stalls, a caller hears silence, even when every earlier stage finished cleanly. It is a separate text-to-speech step, with its own latency and its own failure modes. That's why each stage needs its own test before the call goes live. ## Where realtime voice agents are used Look at where realtime voice agents show up, mainly live transcription, call handling and voice interfaces, and the listening stage does a different job in each. Mixing those jobs up is how a captioning-grade transcript gets blamed for a booking that failed. Nothing replies in captioning or note-taking, so the only failure is a wrong or late word on screen. Those uses need the listening stage alone. You can test it in isolation: play recorded audio in and read what comes out. If a call goes wrong on a phone agent, check the transcript first, then the decision, then the voice. The agent chains listening, a language model that decides what to do, and speech output. The transcript is the first link, so a misheard date or name flows into the booking unchanged. Testing only the finished call hides which link broke. ### Other vendors and non-voice options - Live captioning needs only transcription, so GPT-Live-Transcribe or Voxtral Mini Transcribe Realtime 3 can fill that role. - Call handling needs listening plus reasoning and speech, which Gemini 3.8 Live or GPT-Realtime-2.1 cover in one model, so you test one component instead of three. - Voice interfaces for apps, such as spoken commands, can use the Grok Voice API, which bundles speech-to-text and text-to-speech. - Multilingual conversations can use Gemini 3.5 Live Translate, which treats translation as part of the listening step. If callers mostly need a form filled in, a voice agent adds a failure point without adding much. Typed chat, buttons and forms remain the non-voice option. Whichever route you pick, the same rule holds: write down which stage each vendor's covering, then test that stage alone. ## Using ElevenLabs realtime in Activepieces After the call is where [Activepieces](https://www.activepieces.com/pieces/elevenlabs), the open-source AI automation platform, belongs. Its ElevenLabs integration, updated on 30 September 2026, handles what happens once the audio path's finished, not the audio path itself.  That integration is one of the 744 integrations in the [community pieces directory](https://github.com/activepieces/activepieces/tree/main/packages/pieces/community) of the open source repo under packages/integrations. The Integrations Framework and MCP Server documentation describe the mechanism, and packages/integrations holds it: a integration action defined once is the same code that runs as a step in a flow and that an agent calls as an MCP tool. ### What has shipped, and when Every [Activepieces](https://www.activepieces.com) integration is available to an AI as a tool, so a team can connect voice-agent transcripts to the apps it already uses. It works with the existing API-key connection, so no new credential setup is needed. That count means an AI agent calling the integration sees a very wide menu, so you should decide which actions a workflow exposes rather than accept all of them. Nothing in the pull request says the integration streams audio or wraps the realtime speech-to-text endpoint, and nothing here claims it does. To confirm what your own instance is running, open the admin settings page under Integrations, which lists every installed integration with its package name and version. Check that version against the pull request date before you build on any of this, because an integration installed before 30 September won't carry these actions. ### Using workflow automation around voice agent calls For work that can wait a few seconds, workflow automation fits: saving a finished transcript, tagging the call outcome, creating a follow-up task, notifying a human. A failed step there can be retried without anyone hearing a gap.  It doesn't fit the live audio path. A caller waiting through a pause can't be helped by a workflow that retries on its own schedule, and nothing in the shipped changes puts Activepieces between the microphone and the transcript. So test the listening stage separately, and treat the integration as a downstream consumer of its output. ## What realtime access costs and requires Before you compare prices, compare billing units. Realtime access takes an ElevenLabs account and an API key, and the cost depends on which stage you buy and in what unit. ### Account and API key Create an account, generate a key in the dashboard, and keep it server-side. A key in browser code is a key anyone can copy. Check the plan first, because it decides your headroom: the [ElevenLabs Help Center](https://help.elevenlabs.io/hc/en-us/articles/14312733311761) lists concurrent requests per plan, with Flash and Turbo voices getting double.  According to the ElevenLabs [Help](https://help.elevenlabs.io/hc/en-us/articles/14312733311761) Center, **Free allows 4 against 2**, Starter 6 against 3, Creator 10 against 5, Pro 20 against 10, and Scale and Business 30 against 15. Free therefore stalls at the third simultaneous standard-voice call, so a test with three testers can fail on the plan, not the code. Checked 2026-10-25, the options differ more in billing unit than in setup: | Option | Setup effort | Billing unit | Published price | What the page leaves unstated | |---|---|---|---|---| | ElevenLabs Free | Key only | Plan credits | Free tier | Whether concurrency figures cover realtime transcription | | Starter | Key only | Plan credits | Monthly plan | Same | | Creator | Key only | Plan credits | Monthly plan | Same | | Scribe v2 Realtime API | Streaming client | Audio time | Check pricing page | Latency under your load | | Vapi | Platform config | Call minutes | Check pricing page | Which speech-to-text vendor's cost is included | | Retell | Platform config | Call minutes | Check pricing page | Same | _Prices and plan limits checked against [elevenlabs.io](https://elevenlabs.io/docs/de/api-reference/speech-to-text/v-1-speech-to-text-realtime) and [github.com](https://github.com/activepieces/activepieces/pull/15981) on October 25, 2026._ As the table shows, setup is the same across the plans, and they differ only by ceiling. Treat any price not on a page you opened today as stale. Whether those limits apply to realtime transcription sessions, the concurrency page doesn't say. So open as many parallel streams as your busiest hour needs, and watch for the first rejected connection before launch. ## Common mistakes with realtime speech to text Unlike the first rejected connection, which is a capacity failure you can see, the mistakes below stay invisible until a caller complains. Each fails quietly, and each has a check that takes a day or less. ### Judging the agent by the transcript alone Read perfectly in a quiet office, a transcript tells you only that the listening stage works in a quiet office. The failure chain usually runs like this: the team tests with studio-clean recordings, the transcript looks right, and the agent ships. Then a caller on a motorway says a postcode, the transcript drops half of it, and the language model answers a question nobody asked. The speech output carries the error to the caller in a confident voice. On its own, each stage looks fast. Latency fails the same way, though, because the caller waits for the sum of transcription, reasoning, tool calls and speech synthesis, so a stage-by-stage pass proves nothing about the pause they hear. ### Skipping handoff and fallback Callers repeat themselves, the agent repeats its error, and **the only exit is hanging up**. That is what a voice agent with no route to a person does with every misheard word: it turns it into a dead end. Something observable has to trigger the handoff, such as repeated low-confidence turns or an explicit request for a human, and you have to test it as a path of its own. ### Monitoring realtime transcription usage and limits You will learn about a stuck session or a looping client from the invoice, or from rejected connections at peak. **Streaming transcription is billed and limited by use**, so either one quietly spends your allowance. Claims about limits, pricing or language support belong here too: if you haven't confirmed one on the maker's current page, treat it as unverified. | Mistake | Monday check | |---|---| | Clean-audio-only testing | Replay recordings with noise, accents, crosstalk and spoken numbers, and compare transcripts to what was said | | Whole-chain latency ignored | Time one call from the end of the caller's speech to the first audible reply, across every stage together | | No human handoff | Trigger the handoff on purpose and confirm a person actually receives the call | | Unmonitored usage | Set an alert on concurrent streams and daily usage, and read the dashboard once before launch | | Unconfirmed claims trusted | Check each limit or capability against the maker's page and note the date you checked | ## Frequently asked questions Is ElevenLabs realtime the same as ElevenLabs Agents? No. Maker states: realtime speech-to-text is the listening stage, and Agents is the product that wraps listening, a language model and spoken replies into one conversation. A call can fail in the reasoning or speaking stage while transcription is flawless, so test the transcript on its own before blaming the whole agent. Does it work in languages other than English? Maker states that its speech-to-text family covers many languages, and its pages carry the list. The pages don't say whether realtime accuracy matches batch transcription in every one of them. Feed the realtime endpoint recordings in your callers' language and accent, then read the transcripts. Treat the language list as a claim to verify, not a guarantee. ### Can I use it without writing code? Maker states that Agents can be configured through its dashboard. **Maker silent on a no-code path** for the realtime transcription stream on its own. That stream is an API you connect to and feed audio, so expect a developer or an integration layer to open the connection and handle what comes back. If someone tells you it's point-and-click, ask which product they mean. ### How do I know what a call will cost? Maker states pricing on its pricing page, and it's set per product. Maker silent on any single all-in figure for a live call, because a call's cost depends on how long it runs, how much the caller talks, and which language model and voice you attach. Read the rate for each stage on the date you're building, since pricing pages change. Then run a few realistic test calls and total the usage the dashboard reports. A cost you measured beats one you inferred from a rate card. ## Related reading - [ElevenLabs Realtime: Scribe v2 Pricing and Features](https://www.activepieces.com/blog/elevenlabs-realtime-scribe-v2-pricing-and-features) - [Mistral Voxtral 3: Speech Models, Pricing & Benchmarks](https://www.activepieces.com/blog/mistral-voxtral-3-speech-models-pricing-benchmarks) - [AI Launch Week Day 2: Universal Text AI](https://www.activepieces.com/blog/text-ai) ## References - [ElevenLabs Help Center](https://help.elevenlabs.io/hc/en-us/articles/14312733311761)When a word is mistranscribed, it reaches the model as fact, the model answers the wrong question, and the synthesized voice delivers that answer fluently.