A token estimate of the latest user message is not a complete-request estimate. For a Gemini integration using CometAPI’s native generateContent endpoint, my recommendation is to retain the system instruction, conversation history and declared tools in the estimation workflow—and keep the resulting estimate separate from the endpoint’s returned usage.
The distinction matters before treating a difference as a routing cost problem. You may be comparing different request components, or counters from different protocols, rather than observing a price difference.
Two documentation surfaces, not one counter contract
Google’s token guide describes pre-request count_tokens as counting input only. Its system-instruction example uses Interactions and explicitly includes the instruction in total_input_tokens. Its tool example reads both total_input_tokens and total_tool_use_tokens. That does not establish that the latter is simply the size of the declared function schema.
CometAPI’s native Gemini documentation instead documents a generateContent request with contents, systemInstruction and tools. For multi-turn requests, it says to send preceding user and model content in contents. Its response example exposes usageMetadata.promptTokenCount, alongside candidatesTokenCount, thoughtsTokenCount and totalTokenCount.
Both pages use gemini-3.8-flash in the relevant examples. They support this protocol-specific workflow, not a claim that every Gemini model has identical accounting. In particular, do not rename Google’s Interactions total_input_tokens to CometAPI promptTokenCount and assume you have reconciled usage.
Keep the estimate auditable
For the CometAPI native route, I would use this checklist:
| Request component | What to retain for the comparison |
|---|---|
| System instruction | The actual systemInstruction, not just the user-facing prompt |
| Conversation | The contents sent on this turn, including preceding user/model turns and their parts |
| Declared tools | The actual tools definitions, not just a note that tools were enabled |
| Counting context | Exact model, protocol, estimator and which components it can represent |
Construct the comparison from the request you intend to send, rather than maintaining a second, shorter prompt just for estimation. If the counting method cannot represent a component, mark its result partial. Do not silently omit the component or invent a token adjustment.
After the CometAPI request, record the native usageMetadata fields under their original names. Keep an external estimate in a separate field, with its model and protocol attached. Missing usage should remain missing, not become zero. This is a proposed instrumentation design, not a report of a measured run.
When numbers disagree, first check whether the system instruction, history and tools were included on both sides. Then check the counter definitions and protocol. Only after those checks would I use the observations as inputs to a cost investigation; neither page establishes billing equivalence between the two surfaces.
The boundary is deliberate: Google’s counting examples do not prove that CometAPI exposes a native countTokens endpoint, and the CometAPI response example is not a tariff or invoice. This workflow helps identify incomplete estimates without promising an exact preflight total or savings.