On 9 June 2026, Google released Gemini 3.5 Live Translate, an audio model that delivers near real-time speech-to-speech translation across more than 70 languages. It detects the spoken language automatically and returns translated speech that keeps the speaker's intonation, pacing and pitch, running continuously and staying only a few seconds behind rather than waiting turn by turn. For any Australian business running voice or translation workflows, this is a strong piece of technology, and pretending otherwise would not help anyone. The more useful question is where a single-purpose model like this fits inside a Claude-first stack, and what it actually changes for teams already building on Claude.
The news hook: what Live Translate actually does
The model is narrow by design, and that is the point. It takes audio in, identifies the language, and returns spoken translation that sounds natural to the listener, preserving the prosody most translation systems flatten. Because it generates speech continuously instead of waiting for a full sentence, a conversation feels closer to simultaneous interpretation than to the stop-start cadence of older tools. Google is shipping it across its own products, and giving developers public-preview access through the Gemini Live API and Google AI Studio, with a separate enterprise track. On its own terms, it does one job well.
None of that makes it a platform. It is a capability. And the difference between a capability and a platform is the whole question for a business deciding how to build.
Where a specialised translation model earns its place
There are real situations where a dedicated real-time translation model is the right call. If your work involves spoken conversation across languages and a few seconds of latency is acceptable, a model built for exactly that will usually beat a general assistant on quality and speed. A mid-size Sydney services firm that currently spends around $45,000 a year on human interpreters for multilingual client onboarding has an obvious reason to look closely.
The clearest fits look like this:
Live multilingual customer support, where a caller and an agent speak different languages and the conversation cannot wait for a transcript.
Site inductions and safety briefings for multilingual workforces on construction or manufacturing sites, where comprehension is a compliance issue, not a nicety.
In-person events, tours and field operations where staff need to understand and respond in the moment.
In each case the value comes from speed and natural delivery in a narrow task. That is genuinely where Gemini's strength sits, and an honest assessment should say so.
Why Claude stays the orchestration core
Translation is rarely the whole job. The whole job is usually to understand what the customer wants, check it against a policy or a record, draft a response, take an action in another system, and keep a defensible trail of what happened. That work is reasoning, tool use and judgement, and it is what Claude is built for. A translation model does not read your contracts, reconcile your invoices, run an agentic loop across your tools, or apply your governance rules. It converts speech.
This is why we keep Claude as the orchestration layer and treat any specialised model as something Claude calls when the task needs it. In a Claude-first build, the assistant decides whether translation is even required, routes the audio to the best model for that language pair, and then carries on with the actual work once the words come back. The translation step becomes one tool among many, not the centre of the design.
A Claude-first build for a voice-heavy workflow tends to look like this:
Claude sits at the centre as the agent that interprets intent, makes decisions and calls tools through MCP connectors.
A specialised model handles real-time speech translation when, and only when, the language pair and latency call for it.
Claude takes the translated text, does the reasoning and the system actions, and writes the record.
Governance, logging and access control live at the Claude layer, so the rules do not change depending on which model answered.
The Australian angle you cannot skip
Voice workflows carry data questions that a feature comparison will not surface. Customer audio is personal information under the Privacy Act, and sending it to an offshore model for translation is a decision your privacy obligations should drive, not your shortlist of features. For firms in regulated sectors, APRA's expectations on outsourcing and data handling apply to AI vendors the same way they apply to any other third party. Choosing a model is partly a technical question and largely a governance one, and the governance is easier to hold together when one layer, Claude, owns the orchestration and the audit trail.
Spending here adds up quickly too. A team that wires three separate AI products together, each with its own admin console and billing, often pays more in integration and oversight than a business running a single Claude-centred stack that calls specialised models as needed. We have seen the difference between those two shapes run to tens of thousands of dollars a year once you count the engineering time, not just the licences.
How we think about choosing
The Automata AI view is straightforward. Pick the best model for each specific job, and keep Claude as the core that ties the jobs together. Gemini 3.5 Live Translate may well be the right choice for the translation step in a workflow. That does not make it the right choice for the workflow. The model that orchestrates the work, holds the context, applies your rules and takes the actions is the one that defines your build, and for the Australian businesses we work with, that is Claude.
If you are weighing a voice or translation project and want a clear-eyed read on where a specialised model fits versus what stays on Claude, have a brainstorm with us. We will give you the honest version, including the cases where Claude is not the answer.
