When Max Output Equals Context: The Kimi models Row That Spends Its Whole Window on One Answer

On the OrcaRouter Kimi models page, two rows sit next to each other at the same price and the same context window, and their output ceilings are as far apart as two numbers on a four-row table can get.

Model Context Max output Input / output per 1M Cached
Kimi K3 1M — $3.00 / $15.00 $0.300
`kimi/kimi-k2.6` 262K 32K $0.950 / $4.00 $0.160
Kimi K2.7 Code 262K 262K $0.950 / $4.00 $0.190
`kimi/kimi-k2.5` 262K 32K $0.600 / $3.00 $0.100

 

Kimi K2.7 Code’s maximum output is 262,000 tokens, which is exactly its context window [OURS page data; the rates are the provider’s published prices passed through with $0 markup]. kimi/k2.6’s is 32,000 inside the same 262K window. Two rows, one rate card, an eight-fold difference in how much of the window a single answer may consume.

That equality is the most easily misread cell on the page, in both directions.

What “max output equals context” would mean if taken literally

A context window is a budget shared between what you send and what comes back. If the ceiling on the reply is the same number as the ceiling on the whole exchange, then a request that used the full context could not receive a reply at all — there would be nothing left to put it in.

No model works that way; the equality is a statement that the output cap is not the binding constraint on this row. It says the row is willing to let a single completion run to the full window, and the practical limit is the sum of prompt plus answer against 262K. It does not mean a 262K prompt can be followed by a 262K answer.

The useful way to read the pair is as two different bets by the vendor about how the row will be used.

32K (k2.6, k2.5) is a coding-and-chat number. Most completions are under a few thousand tokens, and capping at 32K protects the serving path from a runaway generation. It also means the row is designed to carry a long input and a short answer — retrieval, review, extraction, summarisation of a document you have already loaded.

262K (K2.7 Code) is a “write the whole file” number. A model that will emit a quarter of a million tokens in one response is betting that its users ask it to produce something enormous in a single pass: an entire repository’s worth of scaffolding, a full test suite, a long generated document. You cannot prompt it with a large document and ask for a large document back in the same call, because the two budgets share one window.

The name is the tell. The row with the full-window output ceiling is the one called Code, and code generation is the use case where a single answer legitimately runs to tens of thousands of tokens.

The price of that ceiling, in arithmetic

Both rows bill at $0.950 input and $4.00 output per million tokens. The output ceiling does not change the rate. What it changes is the maximum possible bill per call.

At the ceiling:

  • k2.6 with a 230,000-token prompt and a 32,000-token answer: 230,000 × $0.950 ÷ 1,000,000 = $0.2185 in, 32,000 × $4.00 ÷ 1,000,000 = $0.128 out. Total $0.3465.
  • K2.7 Code with a 0-token prompt and a 262,000-token answer: 262,000 × $4.00 ÷ 1,000,000 = $1.048 out. Total $1.048.

So the full-window row can produce a call three times as expensive as the capped row’s worst case, at the same advertised rates [OURS arithmetic on VENDOR rates]. The difference is entirely in the answer length, and answer length is what the max-output column controls.

This is the sort of figure that belongs in a budget guard rather than in a planning deck. A per-call ceiling of about a dollar on one row and about thirty-five cents on the other is the difference between a spend cap that catches a runaway job and one that does not.

The cached price moves too, and not in the same direction

One column in that table does not follow the price: cached input. k2.6 caches at $0.160 per million and K2.7 Code at $0.190, even though both list $0.950 input [VENDOR].

As a share of the input rate that is 16.8 percent against 20.0 percent. The row with the larger output ceiling charges more for a cache hit — the only place on this page where the two same-priced rows diverge on a per-token rate.

Whether that matters depends on which way your workload leans. A prompt-heavy job that repeats a 200,000-token context will see the cache line dominate its input cost, and 3.2 percentage points of difference compounds across every call. A generation-heavy job that uses almost no prompt will never notice. The page cannot tell you which you are; the two columns together can.

There is a third row worth folding in here. `kimi/kimi-k2.5` is $0.600 in, $3.00 out, $0.100 cached, with the same 262K context and the same 32K output ceiling as k2.6, at roughly two thirds of the price. On a per-token basis it is the cheapest row on the page by a wide margin. What it does not carry is a measured p50 — its latency record shows no value — so any comparison that ranks the catalogue by speed will sort an unmeasured row against three measured ones.

Where a 1M row enters the same question

Kimi K3’s row is the outlier in the other direction: 1M context, no max-output value at all, $3.00 in and $15.00 out [VENDOR].

A dash in the max-output column is not a zero and it is not an unlimited ceiling. On this page it means the figure is not stated, which is what the catalogue does for any model whose cap it does not publish. That puts K3 in the same category as several rows on other catalogues — the OpenAI page leaves the column blank on fourteen of its seventy-six rows — and the practical reading is the same: if your workload depends on a specific output ceiling, a blank cell is a question to take to the provider’s own documentation, not a number to assume.

The 1M context does have a cost consequence worth naming. At $15.00 per million output tokens, a full-window answer on K3 would bill $15.00 if the ceiling were the full million, which is fifteen times what the same answer costs on K2.7 Code. Nobody generates a million tokens in one call today, but the rate difference per generated token is real whatever the ceiling: $15.00 against $4.00 is 3.75× for the same unit of work.

How to choose between them without guessing

Three questions, in the order that resolves fastest.

How long is your longest single answer? If it is under 32K — and for most interactive products it is under 4K — the full-window row buys you nothing you will ever spend. If it is a generated file, a migration or a long document, 32K will truncate it and the capped row is disqualified regardless of price.

How much prompt do you send? The two budgets share a window. A 200,000-token prompt leaves 62,000 for the answer on K2.7 Code, which is still generous, but a 250,000-token prompt leaves almost nothing. The ceiling on the reply is a ceiling on the pair, not a promise about the answer.

Is the answer cached-relevant? Cache discounts apply to input, so a generation-heavy job mostly pays $4.00 per million output whatever the cached column says. The 16.8-versus-20.0 percent difference only matters if you are repeating a big prefix.

A max-output column is the least examined column on any price table and, on this page, the one that separates two otherwise identical rows by an eight-fold factor. The rate card says they cost the same; the envelope says they are for different jobs.See More