Four Buckets, One Column: How the Qwen models Context Window Sorts a 27-Row Catalogue

The context column on the OrcaRouter Qwen models page has twenty-seven cells and only four distinct values: 1M on fifteen rows, 262K on four, 131K on three, 32K on four, and one blank [OURS page data, read 2026-10-21].

Four values across twenty-seven rows is the widest spread in the provider set. The Anthropic catalogue uses two values across thirteen; Grok uses two across five; Kimi two across four; Z.ai three across ten. Only Google, with twelve blanks among thirty rows, comes close to this kind of dispersion — and Google’s is dispersion into absence rather than into four distinct buckets.

That matters because a context window is not a quality indicator and it is not a price. It is a hard constraint, and a catalogue that mixes 32K and 1M in one table is one where the wrong row is not slow or expensive — it simply cannot hold the request.

The four buckets, with the rows in them

(The two 397B entries are different models: Qwen3.5 397B A17B sits at 32K, while the 1M bucket holds fifteen rows spanning the 3.5 through 3.8 generations.)

Two patterns jump out, and neither is about capability.

The vision models are not in the biggest bucket. All three VL rows with a stated window sit at 131K, and the fourth has no window at all [OURS]. The multimodal rows are the ones with the smallest usable context outside the 32K group — a fact that matters a great deal for image-heavy work, where a handful of images can consume a large share of a window.

The 32K group is the open-weight size variants. 3.5-27B, 3.5-35B-A3B, 3.5-122B-A10B and 3.5 397B A17B. Four rows, four sizes, one window. These are the rows priced lowest ($0.057 to $0.172 input) and they are the rows with the least room.

What a 32K row can and cannot do

Thirty-two thousand tokens is roughly 24,000 words of English, or a medium codebase’s worth of source, or about a dozen long documents. It is not small; it is simply an order of magnitude smaller than the 1M rows sitting at the top of the same table.

The concrete consequences:

• A 40,000-token document does not fit. It has to be chunked, and the chunks cannot share a cached prefix because they are different text.

• A conversational agent with a long tool-schema block and a few turns of history will approach the ceiling faster than expected, because schemas are verbose.

• RAG with a top-k of twenty passages, each 1,500 tokens, is thirty thousand tokens of context before the question — right at the edge.

None of that makes the 32K rows bad. They are the cheapest rows on the catalogue by input rate ($0.057 on 3.5-35B-A3B, $0.086 on 3.5-27B), and for classification, extraction and short-form generation they are entirely adequate. What it does mean is that a pipeline designed against one bucket will not port to another without a chunking strategy.

There is one more oddity in the 32K rows worth naming: every one of them carries a 65K max-output value, twice its own context window [OURS]. That combination cannot describe a real request. The two figures must come from different sources, and a planner that sizes against the larger one will send requests these rows cannot serve.

The price gradient does not follow the bucket

The intuitive model — bigger window, bigger price — does not survive contact with this table.

Qwen3.7 Flash is $0.030 input and $0.130 output, with a 1M window [VENDOR]. That is the cheapest input rate on the page among chat models, and it sits in the largest window bucket.

Qwen3.5-27B is $0.086 input and $0.688 output, with a 32K window. Nearly three times the input price of 3.7 Flash, more than five times the output price, and one thirty-second the window.

So on this catalogue the widest window is also the cheapest row, and the narrowest window is more than twice as expensive on input. Whatever the axis is, it is not “context costs money”.

The explanation is generation. 3.7 Flash is a newer, smaller, faster model; 3.5-27B is an older size variant. The window widened and the price fell at the same time, which is the direction the market has been moving and is the opposite of what a per-token mental model would predict.

What that means for a shortlist

The practical workflow is to filter by bucket before comparing price, because a row that cannot hold the request is not a cheaper option — it is not an option.

Step one: how big is the largest single request? Under 32K, all twenty-seven rows are candidates. Between 32K and 131K, twenty-three. Between 131K and 262K, nineteen. Above 262K, fifteen.

Step two: within the surviving set, sort by the rate that dominates your workload. For generation-heavy work that is the output column, where the spread runs from $0.130 (3.7 Flash) to $6.00 (3.8 Max) — a factor of 46 across the catalogue [OURS].

Step three: check the cache column. Seven rows carry a cached price and twenty do not, so a prefix-heavy workload is effectively choosing from seven rows regardless of window [OURS].

Those three filters applied in that order will usually leave two or three rows, and the choice among them is a genuine trade rather than a price comparison.

The blank cell and what it hides

The single blank context cell belongs to `Qwen3 VL 235B A22B Instruct`, whose max-output and quality cells are blank as well. Its rates are filled: $0.400 input, $1.600 output [VENDOR].

That is the least usable row on the page and, at $0.400 input, not the cheapest. A row that states a price and nothing else is a row you cannot size a request for, and the honest treatment is to exclude it from any shortlist until the envelope is known.

There is a broader lesson in the four buckets: a context column with four values is telling you that the catalogue spans four product classes, and the price column is not going to tell you which class a row belongs to. Reading the two columns together — bucket first, price second — is the only order that produces a shortlist you can actually deploy.

The column is a filter, not a score

It is tempting to read a context column as a quality signal: wider is better, and therefore more expensive. On this catalogue that reading fails twice over — the widest window belongs to one of the cheapest rows, and the narrowest belongs to a row that costs more than twice as much on input.

What the column actually does is partition the catalogue into four sets that cannot substitute for one another without a change to the application. That is a more useful thing for a table to do than to imply a ranking, and it is the reason the context value deserves to be read before the price rather than after it.

Sourcing note: every context window, max-output value, rate and capability count in this article is read from the OrcaRouter Qwen provider page on 2026-10-21. The rates are the provider’s published prices passed through with $0 markup [VENDOR]; the row structure, the four-bucket counts, the cache coverage and the cross-row arithmetic are ours [OURS]. The 0-to-10 quality scores, where mentioned, are our own composite, not a third-party benchmark. No third-party evaluation figures are used. Rates and limits change; all values checked 2026-10-21.