gemini-3.5-live-translate-preview: usageMetadata from the WebSocket doesn't match actual billing shown in Cloud Console / AI Studio — how is per-turn cost really calculated?

Gemini API
1

Hi all,

We’re using gemini-3.5-live-translate-preview over the BidiGenerateContent
WebSocket for a real-time closed-captioning feature (mic audio in → translated
text out via outputTranscription). We’re trying to log accurate per-meeting
token usage and cost directly from the session, without depending on Cloud
Console after the fact.

What we’re doing:
On every server message we get a usageMetadata block like this:

"usageMetadata": {
  "promptTokenCount": 25,
  "responseTokenCount": 25,
  "totalTokenCount": 50,
  "promptTokensDetails": [
    { "modality": "TEXT", "tokenCount": 2407 },
    { "modality": "AUDIO", "tokenCount": 25 }
  ],
  "responseTokensDetails": [
    { "modality": "AUDIO", "tokenCount": 25 }
  ]
}

We accumulate the top-level promptTokenCount / responseTokenCount across
every message in the session and multiply by the published per-1M-token rate
(input $3.50, output $21.00) to get a “total cost for this meeting” figure.

The problem:
For the same session, our summed total does NOT match what Cloud Console and
AI Studio show for that day (Console and AI Studio agree with each other, but
our WebSocket-based sum is [lower/higher — fill in your actual numbers here,
e.g. “our sum was ~2,000 tokens, Console showed ~X tokens”]).

We noticed the top-level promptTokenCount stays roughly flat every turn
(~25, matching just the new audio chunk), while the nested
promptTokensDetails[TEXT].tokenCount keeps growing turn over turn (in one
session we saw it climb from 2407 up to 3700+ over ~30 seconds). This looks
like it lines up with the documented behavior that Live API sessions are
billed per-turn on the full Session Context Window (new tokens + all
accumulated history reprocessed), not just the incremental delta.

Questions:

  1. For gemini-3.5-live-translate-preview specifically, is the actual billed
    input per turn = the full promptTokensDetails context size (re-billed
    every turn), rather than the flat top-level promptTokenCount?
  2. Is there a reliable way to reconstruct the exact billed input/output
    totals for a session purely from the WebSocket usageMetadata stream, or
    is Cloud Console/AI Studio the only authoritative source?
  3. Does responseTokenCount include internal “thinking” tokens, given the
    pricing page lists output pricing as “including thinking tokens”? If not,
    where would those show up in the message stream?
  4. Is this pricing/token-reporting behavior specific to the translate-preview
    model, or the same across all Live API models (e.g.
    gemini-3.1-flash-live-preview)?

Any clarification on the exact billing formula for this model — or a pointer
to docs that spell it out precisely — would be hugely helpful for building
accurate real-time cost tracking.

Thanks!

2

Hello @Kashyap_Prajapati,

1 & 2. Input Billing & Real-Time Tracking: Billed input per turn corresponds to the full context size reported in promptTokensDetails (re-processed each turn), rather than the flat top-level ~25-token chunk delta. You can estimate total session input by summing the full context size (promptTokensDetails) across each turn. Cloud Console / AI Studio remains the final billing authority. We recommend to test this and let us know if you see any inconsistency.

3. Thinking Tokens: Output token pricing includes thinking tokens. In usageMetadata, reasoning tokens for thinking models appear under thoughtsTokenCount (and are included in totalTokenCount), while candidate output tokens appear under responseTokenCount. Both response tokens and thinking tokens are billed as output tokens.

4. Model Scope: This token-reporting behavior applies across Live API models.