What breaks

Every Gemini Live turn that produces two or more usageMetadata messages reports inflated token usage. The Live API documents that "the server will periodically send messages that include usageMetadata" during a session, and each of those messages carries the cumulative token totals (input tokens grow monotonically across turns in real traces). The Google realtime session emitted a metrics_collected event for every usageMetadata message, so a single generation that produced two or more of them was reported — and summed again by the usage collectors (ModelUsageCollector / UsageCollector do += per event) — once per message. A turn with a mid-turn report plus a final report on the turnComplete message was counted twice; long turns with several periodic reports were counted several times, each carrying the full running total.

Root cause

_handle_usage_metadata in livekit/plugins/google/realtime/realtime_api.py built and emitted a full RealtimeModelMetrics event on every usageMetadata message the receive loop forwarded to it:

if response.usage_metadata:
    self._handle_usage_metadata(response.usage_metadata)  # emits "metrics_collected" every time

There is no per-generation deduplication and no distinction between the periodic intermediate reports and the final one, so each cumulative report became a separate usage event attributed to the current generation.

For comparison, the built-in OpenAI realtime path reports usage exactly once per response (_handle_response_done in livekit/agents/llm/_realtime/openai.py), and #7231 addresses the same cumulative-usage semantics for the GPT-Live plugin.

The fix

Report usage once per generation, with the final cumulative value seen for it:

• _ResponseGeneration records the latest usage_metadata it received.
• While the generation is active, incoming usageMetadata messages only update that record (latest wins, nothing emitted).
• When the generation completes (_mark_current_generation_done), the recorded usage is emitted as a single metrics_collected event. If the final usageMetadata arrives on the same message that ends the turn, it is emitted immediately instead; usage messages arriving after the generation is done are ignored with a debug log, so a mid-turn snapshot stands only in the rare case where the API splits the true final into a separate post-turn message (traces show it is normally bundled on turnComplete, which is handled correctly).
• In _recv_task, usageMetadata is now recorded before the serverContent/toolCall handlers, which can end the generation. Without this reorder, a final usage value bundled on the turnComplete (or toolCall) message would be processed after the generation is already done and reported, and the stale mid-turn value would win.

Usage arriving while no generation exists keeps the previous warning behavior, and the emitted metrics payload (token counts, token details, duration, timestamps) is unchanged — only the emission frequency and the value's freshness change.

Tests

Added livekit-plugins/livekit-plugins-google/tests/test_realtime_usage_metrics.py (pure unit tests driving the real _recv_task with a scripted fake AsyncSession, no network):

• test_usage_emitted_once_per_generation — one turn with an incremental and a final usageMetadata: asserts exactly one emission with the final value. Fails before the fix with two emissions.
• test_final_usage_bundled_with_turn_complete_is_reported — the final usageMetadata arrives on the turnComplete message itself: asserts one emission carrying that final value (guards the handler ordering). Fails before the fix with two emissions.
• test_usage_reported_once_per_turn_across_multiple_turns — two consecutive turns with several usageMetadata messages each: asserts one emission per turn, each with that turn's final value. Fails before the fix with four emissions.

Four existing parametrized unit tests in tests/test_plugin_google_realtime.py were updated to the new emission contract: test_ttft_is_unavailable_without_a_response_start_event[...] called _handle_usage_metadata directly on an active generation and pinned the old emit-on-call timing; they now complete the generation (session._mark_current_generation_done()) before asserting, and still verify exactly one usage event with ttft == -1 and the expected token counts. The full file (66 tests) passes with the fix.

The full livekit-plugins-google test suite (7 tests, including the existing STT timing tests) passes with the fix.