{"slug": "mistral-voice-agents-tools-calls-and-running-costs", "title": "Mistral Voice Agents: Tools, Calls and Running Costs", "summary": "Mistral released Voice Agents on October 20, 2026, a managed real-time voice pipeline that runs transcription, a text model and speech-to-text in sequence and charges by the minute of conversation: $0.04 with Mistral Small 4 as the text model and $0.08 with larger models, per the pricing page as of October 26, 2026. The runtime is a cascade rather than a single full-duplex model, exposed through an SDK with telephony, browser and custom-audio interfaces, and built on LiveKit transport. SIP telephony is enterprise-only and inbound-only at launch, and client-side tools fail on surfaces that cannot register a handler, including phone calls and dashboard tests.", "body_md": "A cascaded voice agent combines three model stages and supporting application code: something that hears, something that thinks and something that speaks, wired together so that a person can interrupt mid-sentence and the agent can look things up without the line going dead. Mistral's managed offering takes responsibility for much of that integration. On October 20, 2026 Mistral released Voice Agents, a managed runtime that owns the whole chain and charges by the minute of conversation: $0.04 with Mistral Small 4 as the text model and $0.08 with larger models, as listed on October 26.\n\nThis post is deliberately not about the speech models. The Voxtral 3 transcription and text-to-speech components, their prices and their Public Preview status are covered in our [Voxtral 3 component guide](https://www.digitalapplied.com/blog/voxtral-3-transcription-tts-models-price-preview). Here the question is the runtime: whether to let Mistral run the pipeline, which deployment surfaces exist, how tools and interruptions behave, what your application still has to do, and what the minute price actually buys.\n\nOne definition before anything else. Mistral's Voice Agents is a cascade: a realtime transcription model produces text, a text model produces an answer, a speech model produces audio, with streaming that can overlap work across the stages. It is not a single model that listens and speaks natively, the class we compared in our [full-duplex voice model comparison](https://www.digitalapplied.com/blog/full-duplex-voice-models-compared-2026). That distinction governs latency, cost and what can be swapped, and Mistral's documentation explains that each stage contributes to the user's wait, so measure end-to-end response time rather than adding isolated model timings.\n\n1. 01It is a managed cascade with a per-minute price.Transcription, a text model and speech run at Mistral in sequence; your application captures and plays audio. The pricing page lists $0.04 a minute of conversation with Mistral Small 4 and $0.08 with larger models as of October 26, 2026.\n2. 02Where a tool runs decides where it works.Server-side tools (web search, document libraries, connectors) run at Mistral and work everywhere. Client-side tools run your own code and fail on any surface that cannot register a handler, which the docs say includes phone calls and dashboard tests.\n3. 03Phone lines are enterprise-only and inbound-only at launch.SIP telephony is enabled through an account team, not self-serve; the agent answers calls and cannot place them, cannot transfer to a person, and runs none of your code during the call. The launch post's broader SIP wording should be read against the telephony page.\n4. 04Interruptions are on by default and the trade-off is yours.Users can cut the agent off unless you turn that off per agent. End-of-turn detection is a dial between answering late and cutting people off, and the docs offer presets rather than a setting that removes the trade-off.\n5. 05The minute price is the pipeline, not the whole system.The pricing table states only the per-minute rate by model class. Carrier charges for SIP, your own tool backends and any external services behind client-side tools are outside it, and the page does not itemise what the minute includes.\n\n## 01 — The RuntimeWhat the managed runtime *is*, stage by stage\n\nMistral's changelog for October 20 lists two things: the Voxtral 3 audio family, four models all in Public Preview, and Voice Agents, described as a managed real-time bidirectional voice pipeline exposed through an SDK with telephony, browser and custom-audio interfaces. The overview page lays out one turn. Your application reads the microphone. At Mistral, transcription turns the speech into text and detects when the person has finished; the text model reads the conversation and writes the answer, calling tools if it needs to; the speech model speaks it. Your application plays the result.\n\nThe transport underneath is LiveKit, which the docs say you do not need to know about; the SDK adds Python and TypeScript bindings and the bridge to Mistral's models. Each stage's model is chosen per agent or per session, with Mistral Small as the default text model in the configuration reference, and the transcription stage needs a Voxtral 3 realtime model for language hints, context biasing and turn-detection settings. Mistral advertises response latency below one second and describes overlapping stages. The latency guide also notes that each stage depends on earlier output. A streamed cascade can have both properties: work can overlap once an earlier stage starts producing data. Neither statement establishes the response time of your deployment; measure first sound and useful answer separately.\n\nA failure case in reading the launch material: the post says the agent answers and places calls over SIP and connects to the contact-centre software you already use. The telephony documentation, read the same day, says telephony is available to enterprise customers through an account team, that calls are inbound only, and that the agent cannot place them. Where a launch post and a reference page disagree, the reference page is what you can build against.\n\n- Releasedchangelog\n- October 20, 2026same entry as Voxtral 3; four speech models in Public Preview\n- Pipelineone turn\n- STT → text model → TTSmodels at Mistral; capture and playback in your app\n- Pricepricing page, Oct 26\n- $0.04 · $0.08 / minMistral Small 4 · larger models; per minute of conversation\n- Transportoverview\n- LiveKitPython, Node.js and browser TypeScript SDKs\n- TelephonySIP page\n- enterprise, inboundvia account team; not self-serve; no outbound calls\n\n## 02 — Two ObjectsAgent versus *session*: what each one holds\n\nThe runtime separates what you configure from what runs. An agent is a saved, versioned configuration: instructions, the model for each stage, the voice, tool declarations, a welcome message and whether the user can interrupt. A session is one live conversation started from an agent or from an inline configuration, and it holds what is specific to that conversation: the audio interface, the handlers for your client-side tools and any option you override for this session only. The agent lasts until you delete it; the session lasts from connection until your application closes it or a fatal error ends it.\n\nWhy save an agent rather than pass configuration each time: the docs give three reasons. Sessions from the SDK, a browser and a phone line can share a baseline configuration, while each surface still needs testing for its supported tools and audio path. Each change creates a new version, sessions start from the latest by default, and a session can pin a version to keep a known configuration in production while you try the next. And phone numbers and webhooks attach to a saved agent, not to a script. The saved interruption settings apply to phone calls bound to the agent too.\n\nThe failure case is the handler gap. A saved agent can declare a client-side tool, but only the declaration is stored; the handler is code in your application and is never uploaded. When you start a session from that agent you pass the tool again to attach the handler, matched by name. Start a session without doing so and the model can still call the tool; the SDK then emits an unhandled-tool event and reports the call as failed so the conversation does not hang. That exposes a production feature failure through an event your application needs to monitor.\n\n### Saved, versioned configuration\n\nInstructions, per-stage models, voice, tool declarations, welcome message, interruption setting. One per use, such as a support line. Change it by creating a new version; pin a version in production.\n\n### One live conversation\n\nAudio interface, your client-tool handlers, per-session overrides. Created on the backend, connected on demand, closed by your code. Events for transcripts, state changes, tool calls and errors arrive while it runs.\n\n## 03 — SurfacesSDK, browser or *phone line*: four ways to deploy\n\nThe overview lists four paths. The SDK in Python or Node.js runs the pipeline on a machine with a microphone and speakers, which is the quickstart and the testing surface. The browser path is TypeScript only and is organised around one security rule: the API key must never reach the page, so your server creates the session and returns the session ID and connection credentials, the page connects and streams audio directly, and when the conversation ends the page asks your server to close the session. The browser records and plays audio itself, so there is no audio tool to install.\n\nThe third path is telephony. You bring the number and the SIP system that carries your calls, such as a carrier, an IP PBX or a contact-centre platform; it forwards each call to your Mistral SIP endpoint; Mistral starts a session from the saved agent bound to that number and the agent answers. There is no configuration step on your side in the console or the API; the number and SIP setup are arranged with the Mistral team. The docs advise creating and saving the agent before requesting access, and testing it in a browser or SDK session with every client-side tool removed first.\n\nThe fourth path is not the managed runtime at all: your own pipeline from realtime transcription, a chat model and streamed speech, where you own the transport, the latency and turn handling. The docs frame the choice plainly. Use the SDK when you want capture, transcription, the model, speech and playback handled end to end; build your own when you need to control each stage, for example to change how turns are detected or where audio is processed. Our [voice-agent infrastructure reference](https://www.digitalapplied.com/blog/voice-agent-infrastructure-stack-2026-reference) lays out what that own-pipeline route involves.\n\n##### Python or Node.js on a machine\n\nThe quickstart and the test bench. Needs PortAudio for Python or SoX and FFmpeg for Node.js; the docs list missing audio tools as the common first failure.\n\n##### Server-assisted session in a web page\n\nYour server creates and closes the session with the API key; the page connects with returned credentials and streams audio over the real-time transport.\n\n##### SIP telephony bound to a saved agent\n\nArranged with Mistral's team. No code of yours runs during the call, so only server-side tools work and the agent cannot transfer or dial out.\n\n##### Realtime STT, chat model, streamed TTS\n\nThe components without the runtime. Full control over each stage, and full responsibility for latency, interruptions and playback.\n\n## 04 — Tool PlacementWhere a tool runs decides *where it works*\n\nTools come in two kinds and the kind is the whole decision. Server-side tools run at Mistral: built-in web search, document libraries you have uploaded, and workspace connectors that must already be authenticated in your workspace, which the agent then uses on your behalf. Client-side tools are your own functions. The SDK sends their declaration, name, description and parameters, so the model knows they exist; when the model calls one, the SDK runs your handler in your code and returns the result. The docs suggest client tools for things only your application has: the state of the interface, the user's location, an authenticated call to your own backend.\n\nThe rule that follows is stated as a warning in the docs: client tools only work where your code runs. Launch the same agent from a surface that cannot register handlers, such as a phone call or a test in the dashboard, and its client tools fail when called. So the worked example for a support line is to use an authenticated server-accessible connector for live order lookup, reserving a document library for suitable reference information, and keep client tools for the web widget where a browser is present. The telephony page's own advice is to give a phone agent server-side tools for anything it needs during a call.\n\nTwo further details change how tools feel. A tool call can take a moment, and silence is awkward, so any tool, server or client, can carry a filler: a short text spoken in the agent's voice when the call starts and stopped when the result arrives, prepared at connection time so the first call is not delayed; a tool without one stays silent. And client handlers run on the same event loop that streams the audio, so the docs insist that any handler doing input or output be asynchronous, or the conversation stalls while your database query runs.\n\n| Tool kinds and surface behaviour from Mistral's Voice Agents tools and telephony pages, read October 26, 2026. |  |  |  | \n|---|---|---|---|\n| Tool kind | Runs where | Works on | Watch for | \n|---|---|---|---|\n| Web search | Mistral | SDK, browser, phone, dashboard | Add a filler; searches are often the longest wait | \n| Document library | Mistral | All surfaces | Libraries referenced by ID in the agent | \n| Workspace connector | Mistral | All surfaces | Must be authenticated in the workspace beforehand; the agent acts on your behalf | \n| Client-side function | Your application | SDK and browser only | Fails on phone and dashboard; handler must be re-attached per session and be asynchronous for I/O | \n\n## 05 — Turn-TakingInterruptions, end of turn and the *dial* you cannot remove\n\nTwo behaviours make a voice agent feel like a conversation rather than a kiosk, and Mistral documents both as settings with trade-offs rather than solved problems. Interruptions are on by default: when the user starts speaking while the agent talks, the agent stops and listens. You can turn that off per agent, and the docs give the cases for doing so, such as a legal notice or a confirmation read back in full, with the warning that a user who cannot stop a long or wrong answer gets frustrated.\n\nEnd-of-turn detection is the harder one. People pause to breathe, to find a word or to read a reference number digit by digit, and a rule based on silence alone either cuts them off or answers late. Mistral's realtime transcription model scores whether the person is still mid-thought and turns that into events; the Voice Agents SDK handles this internally and does not expose the early signals to your application. What you control is the lean: end turns sooner for voice menus and fast back-and-forth, later for collecting addresses and order numbers or for users who think aloud. The docs offer a default and an aggressive preset and say plainly that no setting removes the trade-off.\n\nThe failure case is tuning for the demo. Short, clear test sentences hide the pauses that real callers produce, so an aggressive setting that feels snappy in testing cuts off the first customer reading out a postcode. Mistral's latency page recommends replaying recordings of real users, with their accents, microphones and background noise, and changing one setting at a time. It also recommends timing the first sound the user hears separately from the useful answer, because a filler makes the agent sound responsive without making the tool any faster.\n\n##### User can take the floor\n\nAgent stops speaking and listens. Turn off per agent for messages that must be heard in full.\n\n##### Default and aggressive\n\nCopy a preset's values into the session, then adjust. Sooner means faster replies and more cut-offs; later means the reverse.\n\n##### Inactivity reminders\n\nAfter silence the agent speaks a reminder, by default twice, then the session ends. Timeout, count and text are configurable.\n\n##### First sound and useful answer\n\nRecord both per turn. One hides slow tools behind fillers; the other hides what fillers do for the conversation.\n\n## 06 — ResponsibilitiesWhat your application *still owns*\n\nManaged does not mean absent. Reading the sessions, webhooks and browser pages together, the list of things your code is responsible for is longer than the launch post implies. For SDK and browser sessions, your application creates the session and is responsible for closing it; the docs say closing leaves the real-time room and deletes the server-side session, and the browser page asks your server to do it. Your application subscribes to session events and acts on them: partial and final transcripts, agent state changes between listening, thinking and speaking, tool calls starting and ending, unhandled tools and errors, including a fatal flag that means the session is closing.\n\nYour backend receives the record of each call. Webhooks deliver signed JSON when a call starts, ends or fails, configured per agent, with an HMAC-SHA256 signature over the raw body that you verify with a secret generated at endpoint creation that cannot be rotated in place; if it leaks, you delete the endpoint and create a new one. The docs position webhooks as the server-side record for storing transcripts, updating a customer record or tracking call duration for billing, and session events as the in-conversation channel for updating an interface.\n\nAnd on a phone line your application owns everything the agent cannot do. The telephony page's current limitations are inbound calls only, no transfer to a person, and no client-side tools. Its advice is to tell the agent in its instructions what to say when a request is out of scope, such as that a colleague will call back, and to handle that follow-up in your own systems. A voice agent that promises a transfer it cannot make is the failure case; the instructions, not the runtime, prevent it.\n\n## 07 — Running CostsThe per-minute price, *unpacked*\n\nThe pricing page has one section for the Voice Agents API, billed per minute of conversation, with two rows: $0.04 a minute with Mistral Small 4 and $0.08 a minute with larger models. It does not say which models count as larger, does not itemise what the minute includes, and does not mention telephony. That is the entire published price as of October 26, so everything else here is inference, labelled as such.\n\nOur arithmetic, hypothetical workloads on the listed rates. A support widget handling 10,000 conversation minutes a month costs $400 with Mistral Small 4 or $800 with a larger model. A contact-centre pilot at 100,000 minutes costs $4,000 or $8,000. Compared with assembling the components yourself, the realtime transcription model alone lists at $0.008 a minute and the speech model at $13 per million characters, but those separate component rates cannot establish the managed offer's billing inclusions. The published table does not itemise them, so confirm the commercial terms and measure billable duration before treating the minute-rate calculation as a complete budget. Our [guide to voice pricing by characters, tokens and minutes](https://www.digitalapplied.com/blog/voice-ai-pricing-characters-tokens-minutes) explains why those units do not convert cleanly.\n\nBudget separately for the external services your deployment uses, and confirm any bundled terms in the agreement. Carrier and SIP trunk charges for phone calls are yours, arranged with your own telephony provider. Anything a client-side tool calls, such as your own backend or a third-party API, is billed by whoever runs it. The page does not state whether built-in web search or document library calls inside a voice session carry their own charge, and we do not assume either way. For a phone deployment the enterprise arrangement may carry its own terms, which are not on the public page.\n\n| Published Voice Agents rates from Mistral's pricing page on October 26, 2026, and our hypothetical monthly arithmetic on them. Excludes carrier charges, your own tool backends and any cost the page does not state. |  |  |  | \n|---|---|---|---|\n| Workload (hypothetical) | Minutes / month | Mistral Small 4 | Larger models | \n|---|---|---|---|\n| Listed rate | 1 | $0.04 | $0.08 | \n| Website support widget | 10,000 | $400 | $800 | \n| Contact-centre pilot | 100,000 | $4,000 | $8,000 | \n| After-hours line, 20 calls a night at 4 minutes | ≈ 2,400 | ≈ $96 | ≈ $192 | \n\n## 08 — FitManaged runtime or *your own pipeline*\n\nThe managed runtime fits a team whose product is the conversation, not the audio engineering: a web support widget, an internal assistant on a laptop, an appointment line for an enterprise with an account team. Its value is the list of things section 06 did not include: no turn detection to build, no audio transport to run, interruptions handled, fillers built in, versions and webhooks provided. The per-minute price is simple enough to put in a forecast.\n\nIt does not fit a team that needs to change how turns are detected beyond the exposed settings, process audio somewhere specific, mix in a different transcription or speech vendor at one stage, or place outbound calls. Those are the cases the docs themselves route to building your own pipeline. It also does not fit, as of October 26, a small company that wants a phone agent without an enterprise relationship, because self-serve telephony does not exist.\n\nFor a marketing or operations team deciding whether an inbound-call or web-widget agent is worth piloting, the sequencing matters more than the vendor: prove the agent in a browser session with server-side tools only, measure first-sound and useful-answer times on real recordings, write the hand-off behaviour, then ask about a number. Our [automation practice](https://www.digitalapplied.com/services/crm-automation) can help design that evaluation. Testing each surface before a live pilot gives the team a chance to identify tool-placement and turn-detection failures.\n\n**Our reading** Mistral's Voice Agents is a well-documented managed cascade with a clear price and clear limits. The documentation is unusually honest about the trade-offs it cannot remove, the tools that fail on a phone and the things your application must still do. Adopt it for browser and SDK agents and for inbound lines where an enterprise relationship exists; treat the per-minute rate as the pipeline cost only; and build your own stack where you need outbound calls, transfers or control of a stage.\n\n## 09 — ConclusionThe runtime handles the turn; you still *own the call*\n\n### Pilot in a browser session with server-side tools, measure real recordings, write the hand-off script, and only then attach a number through an enterprise agreement.\n\nMistral's Voice Agents, released October 20, 2026, runs transcription, a text model and speech as one managed pipeline with interruptions, fillers, versions and signed webhooks, for $0.04 or $0.08 per minute of conversation as listed on October 26. It deploys through a local SDK, a server-assisted browser session or an enterprise-only inbound SIP line, and it is a cascade, not a native speech-to-speech model.\n\nThe decisions it leaves you are the ones this guide covered. Place every tool a phone agent needs on Mistral's side, because client tools fail where your code does not run. Choose where to sit on the end-of-turn dial from real recordings, not demo sentences. Manage the SDK or browser session lifecycle, monitor SIP call events, verify webhook signatures, and script what the agent says when it cannot help, since it cannot transfer the call. Then budget the minutes, and budget the carrier and your own backends on top of them.", "url": "https://wpnews.pro/news/mistral-voice-agents-tools-calls-and-running-costs", "canonical_source": "https://www.digitalapplied.com/blog/mistral-voice-agents-managed-pipeline-tools", "published_at": "2026-10-26 00:00:00+00:00", "updated_at": "2026-10-26 21:11:22.134400+00:00", "lang": "en", "topics": ["ai-products", "ai-agents", "large-language-models", "ai-tools"], "entities": ["Mistral", "Voice Agents", "Mistral Small 4", "Voxtral 3", "LiveKit"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/mistral-voice-agents-tools-calls-and-running-costs", "markdown": "https://wpnews.pro/news/mistral-voice-agents-tools-calls-and-running-costs.md", "text": "https://wpnews.pro/news/mistral-voice-agents-tools-calls-and-running-costs.txt", "jsonld": "https://wpnews.pro/news/mistral-voice-agents-tools-calls-and-running-costs.jsonld"}}