A million-token context window does not mean a million-token invoice. I would audit Gemini 4 Argon by keeping three records separate: the material present in one response, the input processed across its continuation hops, and the usage counters used to calculate charges.
This guide follows one large evidence packet through those records. You will learn why a job can fit its context while reporting more than a million processed input tokens, how a cache assumption changes its estimated price, and how to reconcile the final usage without counting progress snapshots twice.
Why one token total cannot answer every question
A token is a unit of material processed by the model, rather than a fixed number of words. The context window limits what the model can work with at once. A hop is a segment of continued generation. A billing record counts processing, including material processed again during later hops.
Imagine reading a large evidence packet, drafting part of a report, then reviewing the packet and the draft before continuing. The packet did not become two different packets, but it was processed more than once. This analogy explains the accounting distinction; it does not describe Google’s internal memory implementation.
The Argon model specification specifies one shared 1,048,576-token window. Our Argon preflight guide explains how to reserve capacity before a run. Here the question is what to do when the resulting usage and estimated charge look inconsistent with that capacity.
| Record | Question it answers | What it cannot establish |
|---|---|---|
| Live footprint | Does the prepared input plus this response’s generated material fit? | The cumulative input-processing charge. |
| Processed input | How much input did all hops process? | How much distinct material occupies the final context. |
| Usage and rates | Which counted categories receive which prices? | Whether the report is accurate or the final invoice includes other fees. |
First reconcile the capacity ledger
Use one worked scenario throughout: 900,000 prepared input tokens, 70,000 thinking tokens and 50,000 visible output tokens, with no added tool results. Thinking tokens represent internal reasoning work; visible output is the answer text returned to the application. All token allocations are assumptions for the calculation. Google’s thinking and token-limit guide says thinking and output share the response cap and the context window; an effort setting does not reserve a particular visible answer length.
The remaining space after the input is 1,048,576 − 900,000 = 148,576 tokens. The assumed response uses 120,000 of them. Its final footprint is therefore 1,020,000 tokens, leaving 28,576 unused. That spare space is not an accuracy guarantee, and a character count is not a substitute for a token count.
Read Figure 1: Read the shared boundary first, then subtract the original input. Thinking and visible output consume the remaining space together.
The token-counting guide documents counting input before a request and reading usage afterward. Keep the fully prepared input count with a manifest of the supplied files, messages and tool definitions. A file inventory alone can miss instructions inserted by an application. If tools add material or the conversation continues, update the workload model instead of reusing this simple one-response calculation.
Then reconcile the work repeated across hops
An application programming interface (API) lets software send requests to a service. An interaction is the service’s record for a run. Google’s Interactions route manages long decode on the server when background execution is enabled and the response cap is raised above 65,536; background execution requires storage. The long-decode guide describes 65,536-token hops that continue the same response.
Assume the first hop uses its whole allocation on thinking. It has processed 900,000 input tokens but produced no visible answer. The second hop processes the original 900,000 plus the prior 65,536 generated tokens: 965,536 input tokens. It then uses 4,464 more thinking tokens and emits 50,000 visible tokens.
Read Figure 2: Add the generation along the forward path to obtain 120,000. Add the two input passes separately to obtain 1,865,536 processed input tokens.
The two input passes sum to 1,865,536, exceeding the model’s context capacity without contradicting it. The live footprint remains 1,020,000. Using cumulative processed input as a compaction trigger would discard context for the wrong reason. Compaction means reducing retained history; it should respond to the live-context requirement, not a repeated-work counter.
The zero-character first segment also needs context. Inspect the documented status and continuation state. An active continuation and a terminal incomplete response are different conditions. Increasing a cap may help a response cut off while thinking, but it does not fix a misunderstood task or enlarge the shared window.
The cache partition explains a surprisingly different estimate
A cache allows qualifying previously processed input to be reused at a lower input price. Argon supports implicit caching, managed by the service, rather than an application-created explicit cache. Cached material still occupies context. Reusing it at a discount changes the price of processing, not the capacity calculation.
The documented long-decode billing rule discounts repeated hop input by 95%. In the worked scenario, the second input includes both the original prompt and the first hop’s generated state. Applying the repeated-input discount to 965,536 tokens yields a different estimate from discounting only the original 900,000.
Read Figure 3: Follow the original input and prior generation into the repeated-input bucket. Do not quietly price the prior generated state at the uncached rate while calling the result the full-discount case.
That distinction is useful when a calculator produces about $3.22 instead of $3.10. The larger figure can be a valid partial-cache scenario, but it needs that assumption stated. It is not the same scenario with a harmless rounding difference. Keep the observed cached count, or mark it unknown, before choosing a number for an audit.
Calculate three conditional prices for the same job
The Gemini Developer API Standard rate card, checked October 31, lists Standard prices in U.S. dollars per million tokens: $2 uncached input, $0.10 cached input and $10 generated output including thinking through November 30, 2026. The scheduled December 1 rates are $4, $0.20 and $20. Keep the applicable service tier and usage date with the calculation.
For the full repeated-input discount case, the arithmetic is $1.80 for the first 900,000 input tokens, $0.0965536 for 965,536 discounted repeated tokens, and $1.20 for 120,000 generated tokens. The token-only estimate is $3.0965536, or about $3.0966.
| Assumed cached input across this job | Current Standard estimate | Same usage at scheduled December rates |
|---|---|---|
| 965,536: full repeated-input discount | $3.0965536 | $6.1931072 |
| 900,000: only the original prompt cached on hop 2 | $3.221072 | $6.442144 |
| 0: no repeated-input discount | $4.931072 | $9.862144 |
Read Figure 4: Compare prices on the same scale. The final footprint and generated result are fixed; the assumed cached-input count changes.
The difference between the first two cases is 65,536 × ($2 − $0.10) / 1,000,000 = $0.1245184. This isolates one cause of a discrepancy. A much larger difference needs another explanation: additional attempts, a different tier, tools, rate timing or missing records. These estimates exclude tool charges, retries, taxes, credits and invoice adjustments; they are not measured invoices.
A progress update is not another billable copy of the job
Now consider three hypothetical observations within the same interaction. One reports 65,536 generated tokens, the next 90,000, and the final one 120,000. Those are cumulative snapshots. Summing them would report 275,536 generated tokens even though the final observation says 120,000.
Read Figure 5: Keep the latest cumulative snapshot for this interaction. Preserve earlier observations for diagnosis, without adding each observation as a new charge.
Google documents cumulative usage on Interactions progress events. Read its latest usage once. If an application instead manages separate requests with per-request counters, deduplicate those request records and sum each actual request once. A software development kit (SDK) can hide continuation calls; establish whether its returned metadata is already aggregated before adding a manual loop around it.
Keep separate attempts separate. Reconnecting to an existing interaction is different from submitting a new generation. Polling the same interaction should not create a new ledger row for generation, while an independently retried attempt can incur additional work. Record identifiers and attempt relationships so a reviewer can distinguish those paths. Our long-decode recovery guide covers response reconstruction; the accounting question here is which records describe the same work.
Map the final usage into explicit cost categories
For this Interactions example, use the final usage fields below. The token-counting guide lists input, cached, output, thought and tool-use counters. The simple formula applies to the stated no-tool workload and the matching Standard token prices. Preserve the raw response and API version alongside any normalized fields.
| Final field | Worked value | Use in this calculation |
|---|---|---|
total_input_tokens | 1,865,536 | All hop input; includes the cached portion. |
total_cached_tokens | 965,536 | Input receiving the cached price. |
total_output_tokens | 50,000 | Output, distinct from thinking in this field contract. |
total_thought_tokens | 70,000 | Add to output for the generated-token charge. |
Compute uncached input as total input minus cached input: 900,000 here. Compute generated tokens as output plus thought: 120,000. Multiply each category by its own per-million rate, then add. Do not subtract cached tokens from thinking or add thinking twice to a counter that already includes it under another API’s contract.
The following original Python worksheet performs only that offline arithmetic. It makes no network requests and does not predict a cache hit. Missing counts raise an error instead of becoming zero; invalid negative counts and impossible cache partitions are rejected. Supply one final cumulative Interactions snapshot for the stated no-tool case.
from decimal import Decimal
FIELDS = ("total_input_tokens", "total_cached_tokens",
"total_output_tokens", "total_thought_tokens")
def token_charge(latest_usage, rates):
# One cumulative Interactions snapshot; no tool charges.
counts = {}
for key in FIELDS:
value = latest_usage[key] # Missing evidence raises KeyError.
if type(value) is not int or value < 0:
raise ValueError(f"Invalid count: {key}")
counts[key] = value
if counts["total_cached_tokens"] > counts["total_input_tokens"]:
raise ValueError("Cached input cannot exceed total input")
for key in ("input", "cached", "generated"):
rate = rates[key]
if not isinstance(rate, Decimal) or not rate.is_finite() or rate < 0:
raise ValueError(f"Invalid rate: {key}")
cached = counts["total_cached_tokens"]
uncached = counts["total_input_tokens"] - cached
generated = counts["total_output_tokens"] + counts["total_thought_tokens"]
return (uncached * rates["input"] + cached * rates["cached"]
+ generated * rates["generated"]) / Decimal(1_000_000)
usage = dict(total_input_tokens=1_865_536, total_cached_tokens=965_536,
total_output_tokens=50_000, total_thought_tokens=70_000)
rates = dict(input=Decimal("2"), cached=Decimal("0.10"),
generated=Decimal("10"))
print(token_charge(usage, rates)) # 3.0965536 USD
The example prints 3.0965536. Decimal arithmetic preserves the calculation before presentation rounding. The function deliberately does not declare a request approved, a task successful or an invoice reconciled. For a different interface, first map its documented field semantics; renaming a cumulative total to “hop usage” does not make it incremental.
Investigate the remaining difference with a reconciliation record
Reconciliation means showing why two records agree or differ. Save a compact record containing the interaction and attempt IDs, endpoint, model, processing tier, timestamps, original input count, final usage snapshot, rate-card date and estimate. Link it to the billing export when that export is available. Separate gross usage charges from credits or tax adjustments.
Read Figure 6: Identify the work, normalize its counters, and apply matching rates. A missing cached count is an unresolved evidence gap, not proof that caching failed or that the charge was zero.
If the difference is small, check rounding precision and whether amounts were rounded per row or only after summation. If it resembles the full-versus-partial cache difference above, inspect the partition. If it resembles an entire additional generation, inspect attempt IDs and retries. These are diagnostic leads; the trace must establish which explanation actually applies.
Do not put secrets or whole private evidence packets into a cost dashboard merely to identify a job. Keep a manifest, appropriate identifiers and access-controlled references. A content hash can help distinguish versions, but it does not prove the service saw every file; retain the submitted-request record under the relevant data policy.
Finally, keep task acceptance separate. A correctly reconciled $3.10 generation can still omit a crucial document or produce an incorrect migration report. Check the requested artifact, source coverage and unresolved questions before someone relies on it. The accounting result tells you what processing was charged, not what engineering conclusion is safe.
My practical rule is to ask three questions in order: what occupied the shared window, what work was processed repeatedly, and what evidence assigns that work a price? Keeping those answers separate makes an unusually large usage counter explainable without inventing a larger context window or trusting an unsupported cache assumption.
Sources and scope: Official Google documentation and rates checked October 31, 2026. Google’s Gemini API release notes records Argon’s October 13 general availability. Diagrams, token allocations, diagnostic scenarios and the Python worksheet are original explanatory material. Calculations were checked locally; no paid inference run or customer invoice was used.