—
real blended monthly cost—naive flat-rate estimate
—hidden surcharge exposure
—savings if long requests trimmed
Cost breakdown at your workload
Short requests price normally at the base rate; long requests price their ENTIRE call — input and output — at the higher cliff rate. The naive row shows what a flat-rate estimate would assume, and the trimmed row shows the scenario where long requests are compressed to just under the threshold.
| Row | Requests | Cost/request | Subtotal |
|---|
Blended cost by share of long requests
Everything else held at the values above, swept across the share of requests that land over the threshold. The highlighted row is closest to your current setting.
| Over-threshold share | Actual cost | Naive estimate | Surcharge |
|---|
How this connects to other tools
This calculator prices one specific mechanic: a hard length threshold where crossing it reprices an entire request, not just the tokens over the line. That's different from our context window cost calculator, which models a smooth, flat per-token cost by context size and has no cliff or threshold logic at all — use that tool if the model you're pricing charges the same rate regardless of request length. It's also different from the LLM tier pricing calculator and LLM service tier calculator, which price latency-based Batch/Flex/Priority service tiers — a choice you make per request about how fast you need a response, not a consequence of how long your prompt is. If you want general Gemini pricing across model sizes without the cliff mechanic isolated out, see the Gemini API cost calculator. This page exists because a flat per-token view of Gemini 2.5 Pro's headline $1.25 rate misses the real cost entirely once any share of a workload crosses 200K input tokens.
How this calculator works
The Long-Context Tiered Pricing ("Cliff") Calculator splits your monthly request volume into two groups using the share of requests over the threshold: short requests, priced normally at the base rate for their input and output tokens, and long requests, whose input exceeds the context threshold and which therefore price their ENTIRE call — every input and output token — at the higher long rate. At the defaults (10,000 requests/month, 20% over the 200,000-token threshold, short = 60,000 in / 2,000 out, long = 350,000 in / 5,000 out, base $1.25/$10, long $2.50/$15), that's 8,000 short requests at $0.095 each ($760 subtotal) and 2,000 long requests at $0.95 each ($1,900 subtotal), for a real blended monthly cost of $2,660.
To show what a normal flat-rate calculator would miss, the tool also computes a naive estimate that applies the base rate to every request regardless of size — at the defaults that comes to $1,735, meaning the real cost carries a hidden surcharge exposure of $925, about 53.3% more than the naive number would suggest. Finally, the tool models a trim scenario: what the long requests would cost if compressed to just under the threshold (1,000 tokens under it) while keeping the same output size — at the defaults that drops the long-request cost enough to save $1,302.50 a month, which is the real payoff of keeping prompts under a pricing cliff rather than just shrinking them a little.
Frequently asked questions
What is a long-context pricing "cliff"?
A pricing cliff is different from ordinary marginal or tiered pricing, where only the tokens above a threshold cost more while everything below stays at the base rate. With a cliff, crossing the threshold reprices the ENTIRE request — every input and output token in that call — not just the tokens over the line. That means a request at 200,001 input tokens can cost meaningfully more than one at exactly 200,000 tokens, not just a fraction of a cent more for that single extra token. This calculator models that specific mechanic, since a normal flat per-token estimate misses it entirely.
Does Gemini 2.5 Pro really reprice the whole request?
Yes. Any single API call to Gemini 2.5 Pro whose input exceeds 200,000 tokens bills at the higher $2.50 per 1M input / $15 per 1M output rate on the WHOLE call — both the input and the output tokens — not a blended or marginal rate applied only to the excess. This is documented in Gemini's published pricing, but it is easy to miss when you're estimating costs from the headline "$1.25 per 1M input tokens" figure, which only applies to requests at or under the 200K-token threshold.
Why is my actual bill higher than a simple token-count estimate?
This calculator computes what it calls "surcharge exposure" — the gap between your real blended cost and a naive estimate that applies the base rate uniformly to every request regardless of size. That naive estimate understates real cost whenever any real share of your requests cross the length threshold, because it has no way to know those long requests get repriced entirely at the higher tier rather than just the tokens over the line. The more of your workload sits over the threshold, the bigger that hidden gap gets.
How can I reduce cliff-pricing costs?
Trim your prompts to stay just under the threshold. Better context management — retrieval instead of stuffing full documents into the prompt, summarizing conversation history, dropping stale context — can keep a request under the cliff and avoid the whole-request repricing entirely. Because the cliff reprices the full request rather than just the excess tokens, a fairly small reduction in prompt size can produce a much bigger saving than the token count alone would suggest, precisely because it avoids crossing the line rather than just shrinking what's on one side of it.