Claude voice mode moves to Opus and Sonnet: a voice that can actually reason
Anthropic upgraded Claude's voice mode on July 23, and for the first time it runs on Opus and Sonnet instead of only Haiku. You can also switch the model in the middle of a call. TechCrunch and 9to5Mac both framed it as a response to OpenAI's new conversational models, which is probably right, but the framing I care about is different: until now, voice was the interface that got the smallest model by design, because speed beat depth. That trade just became a choice instead of a default.
What shipped
The facts are short. Voice mode previously ran on Haiku, the tier that favors response speed. It now runs on Opus and Sonnet as well. The model can be changed during the conversation rather than picked once up front. Anthropic did not publish latency figures for the new configuration alongside the announcement, and I am not going to make any up; what follows is about workflow, not milliseconds.
Why the model behind the voice matters
A voice interface has always had two kinds of latency: how fast the audio pipeline responds, and how long the model thinks. Haiku minimized both, which made voice great for dictation, quick questions, and anything where the answer is retrieval rather than reasoning. It also made voice useless for the tasks I actually want to do hands-free, because those tasks need the model to hold a plan.
Consider what changes when the model on the other end is the same one I use in Claude Code. Walking through a pull request out loud and asking what breaks if a function's contract changes is a reasoning task. Asking an agent to sketch a migration plan and read it back is a reasoning task. Reviewing a design with someone who can push back is a reasoning task. None of those worked well with a model tuned for instant answers.
Voice was never the problem. The problem was that voice always got the model least able to think.
Where the reasoning latency pays for itself
- Hands-free code review. Reading a diff aloud and asking pointed questions works if the model can actually track the diff. A pause of a few seconds is fine here; a shallow answer is not.
- Agent tasks with a human on the loop. Kicking off a multi-step task by voice, then checking in, is a natural fit for a slower, stronger model. You are not waiting on the answer in real time.
- Thinking out loud. Design discussions where I want an interlocutor, not a transcriber. This is where switching mid-call matters: start with the fast model to set context, switch up when the question gets hard.
Where it breaks flow
- Dictation and capture. If I am transcribing notes or issuing short commands, any thinking pause is a cost with no benefit. Stay on the fast model.
- Back-and-forth conversation. Natural dialogue is rhythm-sensitive. A model that takes visibly longer on simple turns makes the conversation feel like a support line on hold.
- Anything where the answer is a lookup. More reasoning does not make a fact more correct. It just makes it slower.
The mid-call switch is the feature that makes this usable. The right model for a voice session is not one model; it is the fast one for most turns and the deep one for the three turns that matter. That is the same routing logic I apply to agent pipelines in text, now exposed as a UI control.
The honest gap
I have no numbers. Anthropic did not publish response-time figures for Opus or Sonnet in voice mode, the coverage did not measure them, and the announcement does not say which Opus and Sonnet versions sit behind the toggle or which plans get it. Everything above about where reasoning latency helps is a workflow judgment, not a benchmark. If you want a number, run your own: a fixed set of ten voice prompts, time to first spoken word on each model, and a note on where the slower answer was actually better. That last column is the only one that matters.