---
title: "What a context window actually costs"
canonical: "https://router.xark.io/blog/choosing-a-context-window"
description: "K means 1,024 here, so 200K is 204,800 tokens. What filling each window costs once, what it costs every turn, and where retrieval wins."
section: "blog"
updated: "2026-09-08"
source: "https://router.xark.io/blog/choosing-a-context-window.md"
---

# What a context window actually costs

*Published 2026-09-08. Topics: pricing, tokens, cost-control, open-weights.*

K means 1,024 here, so 200K is 204,800 tokens. What filling each window costs once, what it costs every turn, and where retrieval wins.

Filling a context once costs the input rate times the window, and the windows are binary rather than decimal: our 200K is 204,800 tokens and our 1M is 1,048,576. That makes one full GLM-5.2 context $0.168, one full Kimi K3 context $0.970, and one full DeepSeek V4 Flash context $0.0147. The largest window in the catalogue -- Llama 4 Maverick's 1,048,576 tokens -- is not callable here today; the largest one that is, Kimi K3 at 524,288, is also the most expensive per token.

## K here means 1,024, and the difference is real

Every context window on this site is printed by dividing the exact token count by 1,024. That is a formatting rule with a consequence: 200K means 204,800 tokens, not 200,000, and 1M means 1,048,576, not a million. The labels are 2.4% and 4.9% larger than they read.

In one direction that is free headroom. In the other it is a trap, because a prompt sized against the decimal number and then run against a model whose real ceiling is the binary one behaves fine right up until it does not -- and the request that finally exceeds it fails at the gateway rather than at your own guard.

Here is the whole distribution, exactly. The models endpoint returns context_window as the raw integer, so a build step can check a prompt budget against the real number rather than against a label.

| Printed as | Exact tokens | Models | Callable today |
| --- | --- | --- | --- |
| 1M | 1,048,576 | Llama 4 Maverick | No |
| 512K | 524,288 | Kimi K3 | Yes |
| 256K | 262,144 | Kimi K2.6, Qwen3 Max Instruct, Mistral Large 3 | Kimi K2.6 only |
| 200K | 204,800 | GLM-5.2, MiniMax M2 | GLM-5.2 only |
| 160K | 163,840 | DeepSeek V4 Pro, DeepSeek V4 Flash | Both |
| 128K | 131,072 | GLM-5.2 Air, Qwen3 235B A22B, GPT-OSS 120B | None |

## What one full context costs, once

Context is billed as input, so the cost of filling a window is the window times the input rate and nothing else. That single multiplication is the number most people never do, and it reframes the choice: a bigger window is not a feature you enable, it is a per-request price you agree to.

The two constraints point the same way and it is worth noticing. Among the models callable today, the one with the largest window also has the highest input rate, so the most context available here is also the most expensive context available here by a factor of about twenty against the cheapest.

| Model | Window | Input / 1M | One full context | Callable today |
| --- | --- | --- | --- | --- |
| Kimi K3 | 524,288 | $1.85 | $0.970 | Yes |
| Kimi K2.6 | 262,144 | $0.55 | $0.144 | Yes |
| GLM-5.2 | 204,800 | $0.82 | $0.168 | Yes |
| DeepSeek V4 Pro | 163,840 | $0.28 | $0.0459 | Yes |
| DeepSeek V4 Flash | 163,840 | $0.09 | $0.0147 | Yes |
| Llama 4 Maverick | 1,048,576 | $0.14 | $0.147 | No -- no upstream configured |
| Mistral Large 3 | 262,144 | $1.20 | $0.315 | No -- no upstream configured |

## Filling it every turn is the actual bill

A single full-context request is rarely what anyone actually does. The workload is a conversation or an agent loop that resends the same enormous prefix on every turn, and that is where a window choice turns into a monthly figure.

Cached input here is a fifth of the uncached rate on every text model, so the first turn pays full price and every subsequent turn pays a fifth for the unchanged prefix. Twenty turns at a full context is therefore roughly a quarter of what twenty uncached reads would be -- a 76% reduction on the input side across all five callable models, because the ratio is the same on all of them.

That is the workload behind the 65–68% figure this site quotes for agents, computed on 400M input tokens a month with a 60% repeated prefix, and 8M output. It is also the reason a large window is more affordable than the single-request price suggests, provided the prefix is genuinely stable.

| Model | Window | 20 full-context turns, uncached | With the prefix cached | Reduction |
| --- | --- | --- | --- | --- |
| Kimi K3 | 524,288 | $19.399 | $4.656 | 76% |
| Kimi K2.6 | 262,144 | $2.884 | $0.692 | 76% |
| GLM-5.2 | 204,800 | $3.359 | $0.791 | 76% |
| DeepSeek V4 Pro | 163,840 | $0.918 | $0.217 | 76% |
| DeepSeek V4 Flash | 163,840 | $0.295 | $0.071 | 76% |

## The condition attached to that reduction

A prefix cache matches from the first token forward and stops at the first divergence. Everything after a changed token is a miss even if it is byte-identical to the previous request, which makes prompt ordering a cost decision rather than a style preference at this scale.

At a 204,800-token prefix the arithmetic is unforgiving. A timestamp injected into the first line of a system prompt voids the entire prefix on every single request, which turns the $0.791 column above back into the $3.359 one and does it silently. Nothing errors; the bill is simply four times larger.

Put everything stable at the front -- tool definitions, instructions, retrieved documents -- and everything volatile at the end. Serialise structured content once and reuse the string, because re-serialising JSON with different key ordering produces different tokens and therefore a miss.

## Stuffing against retrieval, priced

The alternative to a large window is retrieval, and the comparison is usually made on quality when it should first be made on arithmetic. Embedding a 100-million-token corpus once on Qwen3 Embedding 8B is $3.00 at our rate. Reading 200,000 tokens of that corpus into a GLM-5.2 prompt costs $0.164 per request, so the corpus pays for its own index in about eighteen requests.

That comparison is unfair in both directions and worth stating honestly. Retrieval adds a vector store, a chunking strategy and a set of thresholds you have to tune, and none of those appear on a rate card. Stuffing adds nothing but a bigger number in a prompt.

The rule that survives both is about repetition. A corpus read once is cheaper to stuff. A corpus read thousands of times is cheaper to index, and the crossover arrives faster than most teams assume -- particularly on the models with the largest windows, which are also the ones with the highest input rates.

## Do not size a prompt from a character count

Our own rough estimator treats four characters as one token, and it is documented as rough for a reason: it is a placeholder for a real tokenizer, not a model of one. Code, JSON, non-Latin scripts and long identifiers all break that ratio in different directions, and a prompt budget built on it will be wrong by more than the headroom a binary window gives you.

The reliable number is on the response. usage.prompt_tokens is what was actually counted and what was actually billed, so a hundred real requests tell you your true tokens-per-character ratio for your own content in about a minute.

The consequence of getting it wrong is not a truncation you can ignore. A request over the window is refused upstream, and the failure lands in production on the longest document rather than in testing on the average one.

```python
# The window as an integer, not as a label. 200K is 204800.
window = requests.get(f"{BASE}/models/z-ai/glm-5.2").json()["context_window"]

r = client.chat.completions.create(model="z-ai/glm-5.2", messages=msgs)

# The real ratio for YOUR content, measured rather than assumed.
chars = sum(len(m["content"]) for m in msgs)
print(chars / r.usage.prompt_tokens, "chars per token")
print(r.usage.prompt_tokens / window, "of the window used")
```

## Where we are not the answer

If you need a million tokens in one call, we cannot serve it today. Llama 4 Maverick carries the largest window in this catalogue at 1,048,576 tokens and has no configured upstream, so it is priced here and not callable here. DeepInfra publishes the same model at $0.17 input and $0.60 output per million and actually serves it; that is the honest answer for anyone whose requirement is the window itself.

Two of the three 256K models are in the same position. Qwen3 Max Instruct and Mistral Large 3 are catalogued at published rates and are not servable, which leaves Kimi K2.6 as the only 256K model callable here.

Check the models endpoint before you build against a window. It is unauthenticated, CORS-open and returns the current lineup, which makes it the honest answer rather than a page somebody updates when they remember.

## A short checklist for choosing a window

Multiply before you choose. Window times input rate is the price of one full request, and it is the number that decides whether the workload is viable at all.

Use the integer, not the label. 200K is 204,800 and 1M is 1,048,576; the models endpoint returns the exact figure.

Ask whether the prefix repeats. If it does, the cached rate governs most of the bill and a large window is far cheaper than its headline. If it does not, you pay the full read every time.

Keep the volatile part last. One timestamp at the top of a 200,000-token prompt costs four times the input bill and reports nothing.

Price retrieval against stuffing on repetition rather than on quality first. A hundred-million-token corpus embeds once for $3.00; reading a slice of it into a prompt is $0.164 a request on GLM-5.2.

Measure prompt_tokens on real content. A character-count estimate is not a token budget, and the request that proves it will be your longest one.