Gemini 4 Argon 1M output needs one mode, Dec price doubles

What does the invoice say when you send a single request with 1 million output tokens? With output priced at $10 per million tokens, it is easy to answer “a little over $10.” But the same request can come to about $11, or about $26, and after Dec 1 it can pass $52. The difference comes from how the server writes in 64K stretches called hops, with everything written so far billed again as input on each hop, and from how much of that repeated input hits the cache. This article takes the four-hop example from Google’s documentation and stretches it, computing the bill for each output length. It shows where input cost overtakes output cost, how much cheaper it gets when you split the work into chapters, and what you pay when a request is cut off midway. The prices and limits were re-checked on 2026-10-27 UTC against the pricing page of the developer documentation (updated Oct 22) and the model and long output guides.

Assumptions to fix before pulling the bill

Gemini 4 Argon (gemini-4-argon) is the stable version that became generally available on Oct 13, and its API is available on paid tiers only. The 1,048,576-token context window is shared by input, thinking, and output, and the default output limit is 65,536 tokens. To go beyond that, you must turn on background execution (background: true) and storage (store: true) in the Interactions API and set max_output_tokens above 65,536. The server then keeps writing, at most 64K tokens at a time, which is one hop. The calculations below assume this mode.

Prices, now

Standard tier, per 1M tokens: input $2 · output (including thinking) $10 · cached input $0.10

Prices, from Dec 1

All three items double: $4 · $20 · $0.20

Hop size

Up to 65,536 tokens of thinking plus output combined

Prompt

1,000 tokens, the same value as the four-hop example in the documentation

Output ceiling

1,048,576 − input. With a 1,000-token prompt that is 1,047,576 tokens, or 16 hops

Cache hit

The first hop's prompt at full price, all later input at the cached price

Cache miss

Input of every hop billed at full price

Cache hit and cache miss are the two boundaries between which an actual bill will fall. The documentation says implicit caching discounts repeated hop input by 95%, and the real hit rate shows up in usage.total_cached_tokens in the response. Every dollar figure in this article is computed by the editorial team under the assumptions above.

What one hop reads back as input

The calculation rests on one fact. The input of hop number i is the prompt plus the output of every earlier hop, and the bill adds up all of these inputs. The documentation’s example is a request with a 1,000-token prompt and 200,000 tokens of thinking and output. Across four hops the inputs are 1,000, 66,536, 132,072, and 197,608 tokens, which total 397,216 tokens.

Start with a picture of what goes into each hop and what comes out. The yellow dotted line is the path along which the prompt is loaded again every time, and the solid lines between hops are the path along which the previous hop’s output piles up as the next hop’s input.

Figure 1. Four hops: input grows from 1,000 to 197,608, while newly written output is 65,536 each time (only 3,392 in the last)

In the last hop, even with 197,608 tokens of input, only 3,392 tokens are newly written. It is the hop with the largest input and the smallest output, so the least efficient stretch in cost terms sits at the very end. This structure gives a general formula. With k hops, prompt P, and hop size H (65,536), the input total is k×P + H×k×(k−1)÷2. With P at 1,000 and k at 4, that is 4,000 + 65,536×6 = 397,216, which matches the documentation exactly.

The curve where total input outgrows output

Output grows in proportion to the number of hops, but the input total grows close to the square of it. Double the hops and the input total becomes roughly four times as large. In the chart below, the straight blue line is the actual context and the orange curve is the input total that goes onto the bill.

Figure 2. At 16 hops the billed input is 7.88 million tokens against an actual context of 1.05 million (editorial calculation)

The two lines stay nearly together until about three hops (roughly 200,000 tokens of output) and then pull apart. The input total is 1.5 times the context at four hops, 3.5 times at eight, and 7.5 times at sixteen. This is also why the documentation says not to decide when to compress the context from total_input_tokens. That value is closer to the size of the bill than to the size of the context.

Because the input price is one fifth of the output price, this curve stays hidden for a while. Even in the worst case, with no cache hits at all, output cost leads input cost until the 11th hop (about 720,000 tokens of output), where the cumulative cost of repeated input is $7.23, topping the output’s $7.21 for the first time. After that, the bigger part of the bill is input, and it grows with every additional hop.

Bills for five output lengths

The same formula was applied to five output lengths. 65,536 is within the default limit, a length that needs no long output, and 262,144 is the value the documentation recommends starting with for hard reasoning. The input total is set by the number of hops and the prices only multiply it, so the token counts in the table stay the same after Dec 1 and only the dollars double.

Thinking + output tokens	Hops	Input total (tokens)	Output cost	Input cost (all full price)	Input cost (repeats cached)
65,536	1	1,000	$0.66	$0.002	$0.002
131,072	2	67,536	$1.31	$0.14	$0.01
262,144	4	397,216	$2.62	$0.79	$0.04
524,288	8	1,843,008	$5.24	$3.69	$0.19
1,047,576	16	7,880,320	$10.48	$15.76	$0.79

The chart below adds the two input columns of the table to the output column and turns them into bills for now and for Dec 1. The four bars are four different invoices for a single request. The top two use today’s prices, the bottom two use Dec 1 prices, and in each pair the shorter bar is a cache hit and the longer one is a miss.

Figure 3. The longer the output, the wider the gap between hit and miss (editorial calculation, standard tier)

The first row ends in a single hop, so hit or miss gives the same bill. The only input is the prompt, once. The gap widens with every hop: $0.76 at 262K, $3.50 at 524K, and $14.97 at the 1M level at today’s prices. On Dec 1 the gap doubles too, to about $30 at the 1M level. The independent evaluator Artificial Analysis counted an average of about 62K output tokens per task for Argon. That fits inside a single hop (65,536), so it corresponds to the first row of this table. On average, the tasks in that index sit outside the cost structure of the long output mode.

A longer prompt lowers the ceiling. With a 50,000-token prompt, the output ceiling is 998,576 tokens, still 16 hops, and the same calculation gives a bill of about $10.95 with cache hits and about $27.31 without. Hop count stays the same with a longer prompt, so the total does not change much.

Stacking a 1M-token request layer by layer

Here is how the bill for 16 hops is built up in layers. At the bottom is $10.48 for output and thinking tokens. On top of that, repeated input adds $0.79 if the cache hits every time, for about $11.27. With no cache hits, repeated input costs $15.76, which adds about $14.97 more and makes $26.24, and on Dec 1 all of this doubles.

Figure 4. The order in which the 16-hop bill builds from $10.5 to $52.5 (editorial calculation)

The biggest layer is the Dec 1 doubling. Next is whether the cache hits, and those two layers are fixed no matter how you structure the request. The output layer sits at the bottom but is the most solid. A token the model writes costs the same price whether it is thinking or visible answer, and a hop that does nothing but think and leaves an empty answer is still billed. If you want to cut cost, the documentation recommends lowering thinking_level instead of trimming max_output_tokens. The limit counts thinking and output together, so trimming the limit alone can let thinking fill it first and return an empty answer.

Why the cache hit rate needs to exceed 35%

Here is how large the swing is, in numbers. Of the 7,879,320 repeated input tokens at 16 hops, call the share read from cache f. Input cost is the uncached share (1−f) times $2 plus f times $0.10, added together. At a 0% hit rate the total is $26.24, at 50% it is $18.75, at 90% it is $12.76, and at 100% it is $11.27.

The point where repeated input cost equals the output cost of $10.48 is where f is about 35%. Below that rate, input becomes the larger layer of the bill. If you set a budget by looking only at output, that budget holds only when the hit rate is 35% or higher.

The conditions under which a hit occurs are set out in the caching documentation.

• Minimum length. Implicit caching applies when the prompt is at least 4,096 tokens. The 1,000-token prompt of hop 1 is not eligible, and from hop 2 on, the input of 66,536 tokens is.
• Multi-turn. In a call that continues a conversation, the whole preceding part is cached once a new request adds at least 2,050 tokens.
• No explicit cache. This model does not support explicit caching (cachedContents). You have no means of guaranteeing a hit and can only hope that the implicit cache matches.
• Idle time. The long output guide for the GenerateContent API says a cache unused for 15 to 20 minutes expires. If the gap between hops is longer than that, the hit rate drops.

You calculate the actual hit rate from the usage returned in the response. As in the earlier table, work out the total repeated input with the formula and divide total_cached_tokens by it. This calculation is included in the code in the last section.

Break-even when you split by chapter

If the reason long output is expensive is that input gets re-sent, one idea is to request it in pieces. The documentation says the model does not follow word-count or token-count targets, so splitting is also easier for controlling length. What follows is the editorial team’s assumption. Send 16 separate requests of 65,536 tokens each, and attach to each request the 1,000-token prompt plus 5,000 tokens of outline and summary of the earlier chapters. Input comes to 96,000 tokens in total, $0.19 at full price, and output is the same $10.48, for a total of about $10.67.

That is about $0.60 cheaper than the $11.27 of a long output with cache hits, and about $15.6 cheaper than the $26.24 of a miss. You can also work out the break-even for N tokens of earlier chapters passed with each request. At about 24,000 tokens for N, the full-price input makes the total equal to a long output where the cache hits perfectly, and at about 490,000 tokens it equals a long output where the cache misses entirely. If the task passes along only a summary or outline, splitting is similar or cheaper in either case.

One caveat: this calculation looks at cost alone. For work that must pick up all of the earlier content, such as a proof or long code, continuing from a summary alone may break consistency, and that is the kind of work long output exists for. Whether you can split is decided by the nature of the task, not by cost.

What you pay when a request is cut off or only thinks

Billing does not require reaching the end. The long output guide says every hop is charged, including a hop that only thinks. Rules for failure and cancellation come on top of that.

The GenerateContent API has different rules. On this path, where the client continues the writing itself, a failed non-streaming hop is free, a stream that breaks before 32K is free, and a stream that breaks after that is billed up to the last checkpoint. The limits on this path are 64K for streaming and the SDK, 32K for non-streaming REST, and up to 20 minutes per request.

The price table after Dec 1, and a day’s bill for ordinary calls

Prices differ by tier, and on Dec 1 every tier doubles. Below is the paid-tier table from the pricing page (dollars per 1M tokens).

Tier	Input	Output (including thinking)	Cached input
Standard	$2 → $4	$10 → $20	$0.10 → $0.20
Batch	$1 → $2	$5 → $10	$0.05 → $0.10
Flex	$1 → $2	$5 → $10	$0.05 → $0.10
Priority	$3.60 → $7.20	$18 → $36	$0.18 → $0.36
Contributor (invite-only preview)	$1 → $2	$5 → $10	$0.05 → $0.10

Two things stand out in the table. First, the Batch and Flex prices after December equal today’s Standard prices. Running work that can wait on these tiers can offset the increase. Second, this model has no separate price for long output alone, and no price bands by context length. That is why all the calculations above come from the same price table, and long output looks expensive because of the token count, not the price. On the Contributor tier, your data is used to improve the product and the price is half of Standard, while data on the Standard tier is not used. Search and maps grounding is free up to 5,000 requests per month, then $14 per 1,000, and that stays the same in December.

A service that does not use long output is billed by the same method. What follows is the editorial team’s assumption. It makes 1,000 calls a day, each with 20,000 input tokens and 2,000 output tokens (including thinking), and the first 15,000 tokens are the same prompt every time and hit the cache. With no cache, daily input is $40 and output is $20, so $60 a day and $1,800 over 30 days. With cache hits, input drops to $11.5, which is $10 (5 million uncached tokens) plus $1.5 (15 million cached tokens), so $31.5 a day and $945 over 30 days. From Dec 1 these become $3,600 and $1,890. In this case the cache is the biggest lever for halving the bill, and unlike long output, output is the smaller layer than input, so the increase arrives in full as a doubling.

A calculator that runs the same formula on your request log

Turn the calculation above into code and you can get the bill for now and for Dec 1 in one go, from the average input and output (including thinking) tokens of your requests. Change the hop size and prices and it also works for other tiers.

import math

H = 65_536  # max thinking+output tokens in one hop

def bill(prompt, thought_output, p_in=2.0, p_out=10.0, p_cache=0.10):
    """Dollars per 1M tokens. Returns: (hops, input total, output cost, full-price total, cache-hit total)"""
    hops = max(1, math.ceil(thought_output / H))
    total_in = hops * prompt + H * hops * (hops - 1) // 2
    repeated = total_in - prompt                      # input that re-enters after the first hop
    out = thought_output * p_out / 1e6
    miss = out + total_in * p_in / 1e6
    hit = out + (prompt * p_in + repeated * p_cache) / 1e6
    return hops, total_in, out, miss, hit

print(bill(1_000, 262_144))            # (4, 397216, 2.62, 3.42, 2.66)
print(bill(1_000, 1_047_576))          # (16, 7880320, 10.48, 26.24, 11.27)
print(bill(1_000, 1_047_576, 4, 20, 0.20)[3:])   # Dec 1 prices: (52.47, 22.53)

You get the values for the formula from the response’s usage. In the Interactions API, thinking plus output is total_output_tokens plus total_thought_tokens, and for input, total_input_tokens is already summed across hops. So whether total_input_tokens comes out close to total_in in the formula is a check on whether your calculation is right. Whether the cache actually hit is total_cached_tokens divided by repeated in the formula, and that value is the hit rate. If it falls below 35%, you get a bill where input is larger than output. When you use the GenerateContent API, prompt_token_count is already summed across hops, so use initial_prompt_token_count as the prompt value. You can check whether the model is open to your project with a request that reads the model list (read-only, key in an environment variable).

curl -s -H "x-goog-api-key: $GEMINI_API_KEY" "https://generativelanguage.googleapis.com/v1beta/models" | grep -i argon

An outside publication confirmed that calling with a free key returns a 429 error because the quota is 0, so start by checking that the project is a paid one with billing attached.