On OrcaRouter the grok models table reads top to bottom in descending price, which is also, as it happens, descending version number after the first row — and the context column does not descend with it. It falls off a ledge. `grok/grok-4.3` holds a one-million-token window. Grok 4.5, Grok 4.6 and Grok 4.7 each hold half that. Three consecutive releases of the same family, each newer than the row above, each fitted with a window the previous model already had and doubled. It is the clearest example on the site of a number that does not move the way buyers assume it moves.
The assumption is worth naming because it is nearly universal: newer means bigger, and a version number is a capability ladder you climb. The Grok catalogue is the counterexample. If you chose by name you would expect 4.7 to be the roomiest row on the page. It has the smallest window of any token-priced model on it.
The cliff, row by row
| Model | Input / 1M | Output / 1M | Context | Max output | Quality (ours) |
| `grok/grok-4.3` | $1.25 | $2.50 | 1M | — | 10 |
| Grok 4.5 | $2.00 | $6.00 | 500K | — | 9 |
| Grok 4.6 | $2.00 | $6.00 | 500K | — | 9 |
| Grok 4.7 | $2.00 | $6.00 | 500K | 450K | 9 |
The context column is the one to read twice. It is 1M for the row the page names as its cheapest input, then 500K for everything below it, and it never comes back. That is not a gradual taper — it is a single step, taken between 4.3 and 4.5 and never reversed across the two releases that follow. The max-output column adds a second wrinkle: only Grok 4.7 publishes a figure, 450K, and it is a curious one, because a 450K output ceiling inside a 500K window leaves just 50K of the window for everything else — the system prompt, the retrieved documents, the conversation so far, and the model’s own reasoning. For a long-running agent loop that accumulates turns, that arithmetic runs out faster than the window size suggests.
The quality column is our own 0-to-10 composite, built by grading each model across our own quality dimensions; it is not a third-party benchmark and it is not xAI’s own claim. By that measure the four rows cluster tightly — a 10 on the flagship and a 9 on each of the three 500K rows — so quality is doing almost none of the work of separating them. Context does the separating, and it separates in the direction nobody expects.
Why a shrinking window is not automatically a regression
A smaller context window in a newer model is usually a deliberate trade, not an oversight, and it is worth being precise about what is being traded. Window size is bought with memory: attention over a longer sequence costs more at inference, and serving a 1M-token window at production latency across a fleet is a materially different engineering problem from serving 500K. A vendor that ships a newer model with a smaller window is, in effect, saying that this row is built for a different workload shape than the row before it — one where requests are shorter and the value comes from somewhere other than holding a million tokens at once.
That reading is consistent with the rest of the page. The three 500K rows also sit at $2.00 input and $6.00 output — a higher price and a lower composite score than `grok/grok-4.3` at $1.25 and $2.50 with a 10. So the newest rows on the page are simultaneously dearer, narrower and (by our composite) a shade weaker than the row above them. Whatever xAI is optimising in 4.5 through 4.7, it is not the three columns a buyer is most likely to sort by, which is exactly why the name is the worst of the four signals to sort by here.
For a buyer the takeaway is not that the newer models are bad. It is that “4.7 is newer than 4.3” and “4.7 is better for my job than 4.3” are unrelated statements in this catalogue, and the page gives you the columns to tell them apart if you read them.
What 500K actually costs you in practice
The gap between 1M and 500K is not a marketing difference; it is the difference between one class of workload and another. A few concrete shapes:
• Whole-repository code review in a single pass. A mid-sized repository’s source, its dependencies and its history can approach or exceed a million tokens when passed as raw context. At 500K you are back to retrieval — chunking, ranking, stitching — and every chunk you leave out is a bug the reviewer cannot be blamed for missing.
• Long-document analysis without a retrieval layer. Contract review, financial filings, regulatory dumps and technical manuals routinely land in the 300K to 900K band. A 500K window handles the bottom of that band and truncates the top; a 1M window takes the band and leaves room for the question.
• Multi-hour agent transcripts. An agent that runs for hours and keeps its own history in context spends tokens on every turn. Halving the window halves the time before you must summarise, evict or restart, and every summary you insert is information you chose to lose.
• Few-shot prompting with large exemplars. If your few-shot set is itself a document, the shot budget competes directly with the task budget. A truncated window means fewer shots or smaller ones.
None of those are exotic. They are the workloads that made long context a feature people pay for, and they are precisely the ones the three newest rows on this page cannot take whole.
How to choose between the rows
The decision reduces to a single question, and the columns above answer it directly. Does your workload ever need to hold more than 500K tokens in one request?
If yes, the answer is `grok/grok-4.3`, and it is not a hard call: it is the only row on the page that can take the request, it is the cheapest input row on the page at $1.25, and it carries the top composite score. That combination — widest window, lowest price, highest score — is unusual enough that it is worth checking the table twice before believing it, which is what the screenshot above is for.
If no, the three 500K rows are the ones you are actually choosing between, and the differences between them are thin: same price, same window, same composite score. Grok 4.7 is the only one that publishes a maximum output figure, which makes it the one to look at if your completions are long relative to your prompts. Otherwise the rows are close enough that a swap between them should cost you nothing measurable, and the honest counsel is to pick one and spend your evaluation budget on the window question instead.
The larger lesson outlives this catalogue. Version numbers are release order, not capability order, and a context window is a per-model engineering decision that a vendor can and does change in either direction between adjacent releases. Sort by the column, not the label.
The takeaway
A 1M-to-500K step between adjacent versions of the same family is the kind of detail that only shows up if you read the table rather than the name. `grok/grok-4.3` holds the million tokens; the three rows released after it hold half that; one of them caps its output at 450K inside a 500K window, which leaves the rest of the request just 50K. The newer rows are not broken — they are shaped differently, and if you are choosing by capability you have to say out loud which capability you mean. If long context is the one you mean, the answer is the oldest row on the page, and it is also the cheapest.
Sourcing note: the model rows, the 1M and 500K context figures, the 450K maximum output, the median p50 and the capability census are from the OrcaRouter Grok provider page and the linked model page, read 2026-10-14. The quality column is our own 0-to-10 composite, built by grading each model across our own quality dimensions — it is not a third-party benchmark, and we label it as our own wherever it appears. Prices are the vendor’s published rates with $0 markup [VENDOR]. The interpretation of why a window would shrink is ours [OURS] and is not a vendor statement. All figures read 2026-10-14.
