Long-Context Pricing Tiers: Up to 6.7x, and Gateways Never Show It

The price on a gateway's model page is not the price on its invoice once a prompt gets long. We sent requests through one large multi-provider aggregator on both sides of every documented length line for nine tiered models: five billed exactly 2x their page price past the first line, Alibaba's three climbed to 3x, 3x, and 6.7x by the top of their ladders, and one Azure-served model billed 1.25x its listed endpoint rate on both sides of its line and then doubled. None of this is on the page. The mechanism is documented by the vendors themselves: Google, OpenAI, xAI, Alibaba, ByteDance, and MiniMax all reprice the whole request, output included, past a line at 32K, 128K, 200k, 256K, 272K, or 512k input tokens. This post shows the invoices, then the tier tables behind them, then the settings that keep a request under the line.

TL;DR

• Nine tiered models billed 1.8x to 6.7x past the vendor's line through an aggregator whose pages show one price; GPT-5.6 Luna via Azure billed 1.25x its listing.
• qwen3.7-flash charged $0.03, then $0.10, then $0.20 per million input at 32K and 256K; qwen3-coder-plus stopped at 3x where the vendor lists 6x.
• Vendors reprice the whole request, output included, once the input crosses a line between 32K and 512k tokens.
• Cap the input, not the output: Claude Code /autocompact, Codex model_context_window, API compaction triggers.

Do gateways charge what their page says?

No, not once the prompt is long, and finding out by how much takes two things per intermediary: the pricing metadata the gateway publishes, and the cost it actually reports for a request on each side of the line.

One large multi-provider aggregator publishes its catalog with a pricing.overrides array: a base price plus conditional rules such as min_prompt_tokens: 200000 with the higher rates, and, for DeepSeek and Tencent models, utc_start / utc_end windows for off-peak pricing. In the catalog we fetched on 2026-09-01, 60 entries carried overrides, including the Gemini Pro models, Grok 4.x, qwen3.7-plus, qwen3.7-flash, qwen3-coder-plus, the Seed 2.0 models, and the entire GPT-5.6 family at 272,000. The model pages show the base price only; the tier lives in the metadata. And the metadata is not the vendor's ladder: qwen3-coder-plus carries rules at 32,000 and 128,000 but nothing at the vendor's fourth tier, 256K.

So we sent requests on both sides of every documented line through that aggregator, with usage accounting enabled (the aggregator returns the amount it charged inside the response) and the serving endpoint recorded (one model id on the aggregator fronts several upstream hosts, each with its own price; it calls them endpoints), two runs per point, on 2026-09-02 and 2026-09-03:

The pages themselves, captured the same day as the invoices: one headline price, a per-endpoint table, and no length tier on either. Every charge above followed the metadata to the token. All nine models stepped at the vendor's first line by the vendor's factor, and on the three Alibaba models the invoice climbed a ladder the page never mentions: qwen3.7-flash from $0.03 to $0.10 at 32K and to $0.20 at 256K, 6.7x the page price, on a page that prints $0.03. GPT-5.6 Luna stepped too, and added a second gap: every Azure-served run was billed 1.25x the listed Azure endpoint price, below and above the line alike ($0.275 against $0.22, $0.50 and $0.55 against $0.40 and $0.44), a surcharge that appears neither on the page nor in the endpoint metadata.

The ladder can also stop short of the vendor's. On qwen3-coder-plus the charge rose 1.8x at 32K and 3x at 128K, then stayed at $1.95 per million through 276k tokens, where Alibaba's own list moves to $6 on input and $60 on output, six and twelve times the base. The aggregator's metadata has no rule at 256K, so the charge did not move. Whether the aggregator absorbs that difference or buys under a different contract is not visible from outside. What is visible is that the invoice follows the metadata, and the metadata and the page are two different documents.

The transparency gap, then, is not between metadata and invoice; it is between the page and both of them. The page's headline number is the cheapest endpoint's rate in the table below it, not the rate of the endpoint that will serve you, and neither number carries the length condition. A model card with one price does not tell you about the tier, or which endpoint will serve the next request, or whether the endpoint whose price you are looking at is reachable for your account at all.

The rule that follows is simple. Read the machine-readable pricing for the model you use, at the endpoint level, and check for a length condition; then send one request on each side of the line with usage accounting on and compare the reported cost. A gateway whose charge steps where its page does not is passing a vendor rule through without telling you. A gateway whose charge stays flat where the vendor's does not is either serving the model from a host with different prices or absorbing the difference, and only the first of those is a stable state.

Where are the lines, and how does a tier apply?

Six vendors publish a length line, and every model that states the rule applies the higher rate to all tokens of the request, output included. The step is 2x at most first lines, but the ladders climb: 3x at qwen3.7-plus's only line, 6.7x on input by qwen3.7-flash's third tier, and 6x on input and 12x on output by qwen3-coder-plus's fourth. Prices are per million tokens, fetched from the vendors' pricing pages on 2026-09-01.

Two boundary details worth copying into billing code. Google's two pages disagree by one token: the Vertex footnote says "longer than or equal to 200K", the Gemini API pricing table says "prompts > 200k tokens". And Alibaba defines its K precisely: 128K equals 128,000 tokens, 256K equals 256,000, not powers of two.

The tier applies to the whole request, decided by the input length alone, on every token including the output. The marginal cost of the token that crosses the line is therefore the entire premium on everything before it. For Gemini 2.5 Pro: a 199,999-token prompt bills $0.25 of input; at 200,001 tokens it bills $0.50, and a 4,000-token answer moves from $0.04 to $0.06. One token, plus $0.27.

On qwen3.7-plus the step is 3x: the official rate for a 255,029-token prompt is $0.102, for a 257,332-token prompt $0.309. On qwen3-coder-plus the same mechanism compounds across four tiers, so a 260k-token prompt bills six times the per-token rate of a 30k one and its output twelve times.

The rule is visible on a real invoice, not only in the vendor's table. On qwen3.5-plus, whose official tiers are $0.40 then $0.50 per million input tokens at 256K, our gateway bill per input token differed by exactly 1.25x between ten runs below the line (243k tokens) and 24 runs above it (256k to 321k), with the output price unchanged. The 259k request did not pay 1.25x on its last 3k tokens; it paid 1.25x on all of them.

For an agent that accumulates history, the crossing happens mid-session and silently: the turn that tips over pays the premium for every earlier turn it carries, and every later turn keeps paying it until something shrinks the context.

Does capability step at the same line?

No. We measured this because the tier is easy to mistake for a capability edge, and it is not one. On two tiered Qwen models with the line at 256K, a salted needle (a one-line fact carrying a per-run random code) planted at five depths was recalled 30 of 30 times on each model at 243k, 269k, and 320k tokens, with thinking off, and latency grew with length on a line rather than a step (15.2 s, 17.0 s, 20.5 s median on qwen3.7-plus). A harder task, counting K planted rare sightings across the whole log, did degrade with length: on qwen3.7-plus the share found slid from 74% at 128k to 60% at 192k, 58% at 243k, and 45% at 320k. The decline starts well below the price line and the cells on either side of it sit on the same slope.

Anthropic's own documentation names the gradual effect: as token count grows, accuracy and recall degrade, "a phenomenon known as context rot". It is real, it is continuous, and it does not know where the price tier is.

How do you keep a request under the line?

Cap the input, not the output. The tier keys on the request's input length, so max_tokens (an output cap) does nothing for it; the levers are the settings that bound what the client sends. They exist at four layers.

Here are the settings that bound the prompt, by layer. "Under a tier" marks the ones that take an absolute token count and can therefore be set just below a price line; the window-relative ones only keep you inside the model's context window, which is a different number.

Two things the table implies. On a coding agent pointed at a tiered model, the compaction window is the one knob that turns the cliff into a summary, and it has to be set in absolute tokens just under the line, not as a fraction of a 1M window. And the two most common "safety" settings, Responses truncation: "auto" and the aggregator's middle-out, are window guards: they act at the model's window, 1M on the tiered Gemini and GPT-5.6 models, not at the 200,000 or 272,000 tokens where the price moves, so they will keep a request from failing and still let it cross the line.

Do not count on caching to keep you under. Prompt caching cuts the bill but not the tier on Google's models, where cache reads are priced by the same length tier: a cached 150k prefix plus 60k of fresh context is a 210k prompt and bills as one. Provisioned capacity sidesteps the question entirely, since provisioned throughput units (PTUs) bill per hour regardless of tokens. And when crossing is worth it, cross deliberately: the measurement above says the model does not get worse at the line, so the decision is purely whether the marginal context is worth a 2x, 3x, or at the top tiers 6.7x multiplier on the whole request.

How Synthorai handles it

A length tier is a rate condition, so the gateway treats it as one: a model's price card can carry a list of tiers keyed by input-token boundary, and each request is rated against the tier its own prompt length selects, on all of its tokens, the same way the vendor rates it. That is the mechanism the qwen3.5-plus invoice above exercised. The usage record keeps the prompt token count and the price version alongside the rated cost, so a bill can be decomposed back to "this request crossed the line". The tier a request was rated under can be read back from the usage record, not only from a price table.

FAQ

Is the higher long-context rate charged only on tokens beyond the threshold?

No. Every vendor that documents the rule reprices the whole request: Google ("all tokens (input and output) are charged at long context rates"), OpenAI ("for the full request"), xAI ("for all tokens in the request"), Alibaba ("all tokens in the request are billed at the unit price of the corresponding tier"). A prompt one token over the line pays the premium on every token before it.

Do API gateways pass long-context pricing tiers through?

Yes, in our measurement: through one large aggregator, nine tiered models were billed the vendor's higher rate past the vendor's line, on model pages that show a single price. The tier is in the gateway's pricing metadata, not on the page, and the metadata can also omit a vendor tier, as it did for qwen3-coder-plus above 256K.

Does max_tokens keep a request under a pricing tier?

No. max_tokens caps the output; the tier is decided by the input length. The settings that help are the ones that bound the prompt: a compaction window or token limit in the agent (Claude Code /autocompact, Codex model_context_window), a compaction trigger in the API, or client-side truncation before the request is sent.

Does model quality drop at the pricing threshold?

Not in our measurement. On two tiered Qwen models, needle recall was perfect on both sides of the 256K line and a counting task degraded gradually with length with no step at the boundary. The tier is a business rule; capability loss with length is real but continuous.

Prices and semantics quoted from vendor pricing pages fetched 2026-09-01; agent and API settings from the linked documentation on 2026-09-02; invoice measurements run 2026-09-01 to 2026-09-03 with thinking disabled and salted prompts, two runs per aggregator point. Prices drift; check the linked source before wiring a threshold into billing code.

Related: billing units field guide (the modifier layer this post zooms into), token usage anatomy, prompt caching explained, cache minimums measured.