Claude Meetings Beta Drops into Google Meet — Your Local Audio Path Still Decides Language Latency

On 12 November 2026 Anthropic rolled out Claude Meetings in beta. Claude now joins Google Meet calls as a visible participant, follows the conversation, answers questions out loud or in chat (replies in writing by default), and can draft documents, whiteboards or other artifacts while people are still talking. Notes, transcripts and most in-call answers stay free during the beta; created artifacts are free through 10 February 2027. Support starts on Google Meet for Team and Enterprise plans, with other platforms promised later. It keeps a transcript and screen descriptions, not the raw audio.

That is useful for teams that already live in Meet and want an extra participant that can look things up or start a doc. It does not solve the problem of a developer or candidate sitting in a call conducted in a language they do not speak fluently. For that use case the interesting path is still the local Windows client that captures both sides of the call, runs STT, and paints a translation or suggestion overlay with as little added latency as possible.

Why the audio engine still owns the budget

A meeting bot that joins the call receives mixed audio after the conferencing platform has already done its own mixing, jitter buffering and processing. A local overlay that needs speaker-separated, low-latency text has to start earlier:

1. Capture endpoint (USB headset, Bluetooth HFP/A2DP, built-in, or exclusive-mode WASAPI).
2. Separate render-loopback track so the remote party's audio stays distinct from the local microphone.
3. Windows Audio Engine (audiodg.exe + audioeng.dll) in shared mode. Mixing, communications enhancements and vendor APOs routinely add 10–40+ ms and become non-deterministic under load or Bluetooth.
4. Consumer thread: lock-free SPSC ring copy, format conversion, resampling, VAD.
5. Streaming STT (local GGUF or remote) plus optional local model polish for translation or short replies.
6. Overlay paint on a dedicated thread that never blocks the audio callback.

Even if Claude (or any other meeting participant) can produce text quickly once it has the audio, the local path that feeds a personal language overlay still pays the full capture tax. Bluetooth HFP alone can inject another 50–150 ms of buffering that no model improvement recovers.

A minimal shared-mode capture callback that stays under 1 ms and does no allocation looks like this:

// WASAPI shared-mode capture — callback must be allocation-free
static HRESULT STDMETHODCALLTYPE CaptureCallback(IAudioCaptureClient *pCapture) {
    UINT32 packetLength = 0;
    BYTE *pData = NULL;
    DWORD flags = 0;
    HRESULT hr = pCapture->GetBuffer(&pData, &packetLength, &flags, NULL, NULL);
    if (FAILED(hr) || !packetLength) return hr;

    // Writer side of a pre-allocated power-of-two SPSC ring (float32 frames)
    ring_push_float32(capture_ring, (const float *)pData, packetLength);
    pCapture->ReleaseBuffer(packetLength);
    return S_OK;
}

The consumer owns resampling (libsamplerate or a fixed polyphase), VAD, and the write to the model or WebSocket. Keep the audio thread pure; any lock or malloc here shows up as glitches or higher DPC latency.

Dual-track still matters more than the bot

Meeting platforms mix everything into one stream for the bot. A local tool that wants accurate speaker labels (especially when the remote party has a different accent or language) must keep the tracks separate until after STT. Mixing early destroys identity and forces the recognizer to handle two voices in one beam.

Practical controls that still move the needle:

• Request the smallest period the driver will honor (often 10 ms shared-mode; exclusive can go lower when the device allows it).
• Prefer exclusive mode on the capture side when compatibility allows; shared mode is easier but inherits every APO the OEM enabled.
• Keep thinking/budget low for any online suggestion path; reserve higher compute for offline prep (job-description summary, question bank).
• Dual independent rings so mic and loopback never mix early.

Local models (faster-whisper, Whisper.cpp, or smaller speech checkpoints) avoid the network hop entirely once the audio has left the engine. Hybrid is common: local for the hot path, cloud for higher accuracy on finalized turns.

Trade-offs that remain

Claude Meetings is a server-side participant that sees the already-mixed call. A local Windows overlay sees the raw endpoints and can decide what to send where. The first approach is convenient for teams that already pay for the platform and want shared artifacts. The second is what keeps latency predictable when the goal is personal real-time help during a high-stakes call conducted in another language.

The 1.0.0-era local inference stacks (llama.cpp, ggml, and the various speech GGUFs) make the model side more stable. They do not move the first millisecond. That millisecond is still spent inside the audio engine.

I'm building Talkaside, a Windows app for job interviews and calls in another language.
Drafted with AI assistance from this project's code and logs.