Grok 4.6’s 500K Context Window Has a 200K Toll Booth
xAI launched Grok 4.6 with the sort of specification that makes an agent builder reach for the model selector: a 500,000-token context window, image input, function calling, structured outputs, server-side search and code execution, plus a new xhigh reasoning setting. It is already in the xAI API, Cursor, Grok Build, OpenRouter, Vercel, and Cloudflare’s AI Gateway.
The obvious reading is that xAI has shipped a bigger brain for longer coding jobs. That is true, but it misses the decision builders now have to make.
Grok 4.6 turns context management into part of model selection. At 200,000 prompt tokens, xAI doubles the input, cached-input, and output rates for the entire request. Its cache reads also cost 66.7% more than Grok 4.5. And on CursorBench, moving from High to Extra High adds just 0.9 percentage points while average task cost rises roughly 20%.
So the useful question is not whether Grok 4.6 can hold a large repository and think longer. It can. The question is whether your harness can keep the right state, preserve cacheable prefixes, compact before the price cliff, and escalate reasoning only when the task earns it.
That makes this release a model launch and a runtime-design test at the same time.
xAI describes Grok 4.6 as a successor to Grok 4.5 trained for long-running agents and ambitious interactive and visual work. The company says the supplemental training run was longer, used curated technical and model-generated reasoning data, regenerated supervised trajectories across reasoning settings and agent harnesses, and added reinforcement-learning environments for coding, knowledge work, kernel optimization, web development, and computer-aided design.
Those details matter because they point to co-design. xAI is not optimizing a chat model and hoping an agent shell can make it productive later. It is training the model around loops that plan, call tools, inspect artifacts, recover, and continue.
The API documentation exposes that intent directly. grok-4.6 works through Responses and Chat Completions, accepts text and images, emits text, supports function calls and structured outputs, and can use xAI-hosted web search, X search, and code execution. Its knowledge cutoff is February 1, 2026, so any current-events agent still needs retrieval rather than confidence.
There is also broad day-one distribution. Grok 4.6 is the default model in Grok Build, available across Cursor plans, listed by OpenRouter, and supported in Vercel AI SDK 4.0.37 with xhigh reasoning. Cloudflare availability should be described precisely: it is an AI Gateway integration that forwards requests using the customer’s xAI authorization, not a native Workers AI-hosted copy of the model.
xAI’s launch table places Grok 4.6 High at 61 on the Artificial Analysis Intelligence Index, tied after rounding with GPT-5.6 Sol Max and one point behind Fable 5 Max. The more revealing numbers are below the aggregate.
| Evaluation | Grok 4.6 High | GPT-5.6 Sol Max | Fable 5 Max | Useful reading |
|---|---|---|---|---|
| CursorBench 3.2 | 69.9% | 67.2% | 70.5% | Competitive on ambiguous, multi-file coding inside Cursor’s harness. |
| DeepSWE 1.1 | 65.9% | 73% | 70% | Not a universal software-engineering win; the public operator had not yet posted a 4.6 run. |
| FrontierCode 1.1 Extended | 61.3% | 60.6% | 63.6% | Frontier-level hard coding, with no decisive separation. |
| APEX-Agents | 57.5% | 56.7% | 59.2% | Strong professional cross-application work, still behind Fable in xAI’s table. |
| Terminal-Bench 3.0 | 26% | 34.6% | 34.1% | The clearest warning against calling 4.6 the best terminal agent. |
Source: xAI’s launch table. Competitor values are the best self-reported or public results, not an equal-cost controlled comparison.
That spread suggests a model optimized for project work more than command-line dominance. It performs well on ambiguous multi-file tasks, professional artifacts, and some knowledge-work evaluations, but it does not sweep software engineering. Buyers should resist collapsing that profile into “best coding model.”
The strongest live corroboration is CursorBench 3.2, which uses ambiguous multi-file tasks derived from real Cursor sessions. Grok 4.6 Extra High currently leads at 70.8%, while High scores 69.9%, Medium 67.1%, and Low 61.0%. Cursor also publishes cost, token, and step counts, which makes the leaderboard more useful than a percentage alone.
Cursor is both a training partner and a distribution surface, so this is not conflict-free independent evidence. Cursor also warns that small differences may not be statistically meaningful. Still, its cost curve reveals a production decision that xAI’s launch graphic does not.
The launch price sounds simple: $2 per million input tokens and $6 per million output tokens. The full xAI pricing table changes the architecture.
Below 200,000 prompt tokens, Grok 4.6 costs $2 input, $0.50 cached input, and $6 output per million tokens. At 200,000 prompt tokens or more, those rates become $4, $1, and $12. The higher rates apply to all tokens in the request, not only the tokens beyond 200K.
| Route | Context | Input / 1M | Cached input / 1M | Output / 1M |
|---|---|---|---|---|
| Grok 4.6 short | Below 200K prompt | $2.00 | $0.50 | $6.00 |
| Grok 4.6 long | 200K–500K prompt | $4.00 | $1.00 | $12.00 |
| Grok 4.5 short | Below 200K prompt | $2.00 | $0.30 | $6.00 |
| grok-build-0.1 short | Below 200K prompt | $1.00 | $0.20 | $2.00 |
| Grok 4.3 short | Below 200K prompt | $1.25 | $0.20 | $2.50 |
The first non-obvious consequence is a cliff. A simplified uncached request with 180K prompt tokens and 20K output costs about $0.48. If the prompt grows to 200K while output stays at 20K, the bill becomes about $1.04. Twenty thousand additional prompt tokens more than double the request cost because they reprice the entire trajectory.
The second consequence is a migration penalty hidden behind an unchanged headline. Grok 4.6’s $2/$6 base rates match 4.5, but short-context cache reads rise from $0.30 to $0.50 per million tokens, a 66.7% increase. Agent products with a stable system prompt, repository prefix, or long conversation history can pay more before generating one extra answer.
The operational target is not “use all 500K.” It is “retain enough state to finish correctly without drifting across the 200K whole-request rate switch.”
xAI explicitly recommends prompt_cache_key with the Responses API or x-grok-conv-id with Chat Completions so related calls reach the same server. Without affinity, a request can land on a cache-cold server and pay full input rates.
The multi-turn caching guide is stricter than many agent histories. The reusable prefix must remain exact. Editing, removing, or reordering an earlier message breaks the cache. Reasoning models must also preserve prior reasoning content or continue through previous_response_id; omitting that state is a leading cause of misses.
This means two products calling the same grok-4.6 model can have different effective prices and continuity. One app appends turns, preserves encrypted reasoning, pins conversation affinity, and measures cached tokens. Another rewrites its rolling summary on every turn and silently invalidates the prefix. The model ID is identical; the economic product is not.
Context compaction is the complementary control. It replaces verbose prior messages and tool output with an opaque item that preserves salient state. That can lower input cost, improve latency, and keep a long loop focused. But compaction cannot rescue a request that already exceeds the context limit, and a compacted state still needs evaluation: requirements, unresolved failures, file references, and user constraints can disappear even when the continuation sounds coherent.
xAI supports Low, Medium, High, and xhigh for Grok 4.6. High is the default, reasoning cannot be disabled, and reasoning tokens are billed. The API also rejects presencePenalty, frequencyPenalty, and stop on reasoning models, a small but concrete migration trap for OpenAI-compatible clients.
CursorBench gives a reasonable first routing policy, not a universal one.
Start here for analysis, ordinary multi-file changes, and tool use where latency and cost matter. CursorBench reports 67.1% at $1.28 per task, but your accepted-result rate is the deciding metric.
Use when repository breadth, ambiguity, or reviewer cost justifies more search. High reaches 69.9% at $2.34 in CursorBench and is xAI’s API default.
Reserve maximum effort for hard tasks, failed lower-effort attempts, or work whose correctness value dominates latency. The public score gain over High is small.
Classification, retrieval preparation, mechanical edits, and workflow branches should not inherit frontier spend merely because Grok 4.6 is available.
The deeper point is that an effort setting changes the shape of the trajectory: tokens, steps, latency, tool calls, and opportunities for side effects. A team should measure accepted results per dollar and reviewer-hour, not reward the agent for thinking longer.
Server-side tools add another budget. xAI currently charges $5 per 1,000 successful web-search, X-search, or code-execution calls, on top of tokens. An autonomous agent chooses call frequency unless the harness imposes limits. A cheap-looking prompt can become an expensive research loop through repeated search, reasoning, and retries.
Grok 4.6 arrived one day after Grok Bot and became the default inside Grok Build. That sequence makes xAI’s direction clear:
Grok 4.6 capability and reasoning effort
Grok Build coding harness, tools, checkpoints, sandbox
Grok Workflows fan-out, verification, synthesis
Grok Bot persistent computer, connectors, routines
RohitAI’s earlier Grok Build Workflows analysis argued that orchestration is the product because parallel agents multiply model, tool, and verification budgets. Grok 4.6 adds a fourth budget: context state. A workflow with dozens of branches can duplicate long prefixes, cross the 200K rate switch, and spend xhigh reasoning on branches that never affect the final answer.
The new model also updates the Grok Bot launch. Better long-horizon reasoning may improve what an always-on teammate can complete. It does not reduce the blast radius of a persistent cloud computer with browser sessions, connectors, memory, and external side effects. Model self-testing is evidence; it is not authorization to merge, deploy, publish, purchase, or message.
This stack strategy is probably xAI’s strongest move. The closed model can improve while the Apache-2.0 Grok Build harness exposes the loop, context assembly, tools, sandboxing, MCP support, skills, plugins, checkpoints, and subagent mechanics. Builders can inspect much of the runtime even though they cannot inspect the weights.
The tradeoff is transfer. A score earned inside Cursor does not prove the same result through direct xAI calls, Grok Build, or a gateway. Prompts, tool implementations, reasoning-state handling, permissions, timeouts, moderation, and cache semantics can all vary. “We tested Grok 4.6” is incomplete unless the record names the harness and route.
xAI positions Grok 4.6 for interactive and visual projects, and the model accepts image input. It produces text, not native images or video. That distinction points to a useful evaluation design.
Test screenshot diagnosis, screenshot-to-code, UI reconstruction, chart reading, CAD instructions, and render-review iterations. Let the harness render the artifact, show the result back to the model, and measure whether it repairs visual defects without breaking behavior. If the product needs media generation, xAI’s Imagine API remains a separate model and cost surface.
This is another example of the harness carrying the product claim. “Visual” is not a modality checkbox. It is the closed loop between an image, generated code or structure, a renderer, a new screenshot, and a verifier.
xAI says Grok 4.6 received its widest-ever suite of pre-deployment capability and safeguard-calibration tests, along with post-deployment and third-party testing. That is a meaningful company claim, especially for a model promoted for vulnerability patching, code execution, engineering design, and long-running autonomy.
The public evidence is asymmetric. At publication time, xAI’s safety index lists cards for Grok 4.5, Grok 4 Fast, Grok Code Fast 1, and Grok 4, but not a standalone Grok 4.6 card. The launch post does not supply quantitative safety tables, red-team methodology, architecture, training compute, or a reproducible package for the capability evaluations.
That absence is not proof that the model is unsafe. It means procurement teams cannot substitute the launch statement for local testing. A long-running coding agent should be evaluated for prompt injection, secret handling, destructive-command restraint, network overreach, dependency confusion, approval bypass, repeated side effects, and the ability to stop after uncertainty rather than rationalize continuation.
The fastest useful pilot is not a generic chat arena. Replay work your team can grade and keep the model-plus-runtime configuration fixed enough to explain differences.
The scorecard should end with one number that launch benchmarks cannot provide: accepted work per dollar after review. A model that closes more tasks with fewer human corrections can justify premium tokens. A model that produces impressive first drafts but increases review, retries, or incident exposure cannot.
Agent routers already consider task type, latency, model price, and failure history. Grok 4.6 adds current prompt size and cache state. A request at 195K with a cold prefix should not be routed like the same task at 60K with a warm cache. The router will need to decide whether to compact, retrieve, fork a fresh session, select a cheaper model, or accept the long-context rate.
If one harness preserves cache affinity and encrypted reasoning while another rewrites history, they do not offer the same continuity or cost. If Cursor exposes different tools and review loops than a direct API agent, its score describes a configuration, not a checkpoint. Serious eval reports will publish model, effort, provider, cache policy, context policy, tools, permissions, and harness revision together.
The public CursorBench curve makes permanent maximum effort hard to justify. The practical route is Medium or High first, then xhigh for failed, unusually difficult, or high-value tasks. That can deliver most of the quality gain without paying maximum reasoning cost and latency on every branch.
Grok 4.6 is xAI’s frontier text-output model for coding, agentic tasks, knowledge work, and interactive or visual projects. It accepts text and images, supports function calling and structured outputs, and can use xAI-hosted search and code-execution tools.
xAI documents a 500,000-token context window. Capacity does not prove reliable retrieval or coherent tool use at the limit, so teams should test a long-context quality curve on their own repositories and documents.
Below 200K prompt tokens, pricing is $2 per million input tokens, $0.50 per million cached-input tokens, and $6 per million output tokens. At 200K prompt tokens or more, all three rates double for every token in the request. Priority Processing is billed at twice standard rates when the response confirms the priority tier.
Probably not. High is already xAI’s default, and CursorBench shows only a 0.9-point gain from High to Extra High while average task cost rises about 20%. Test effort levels on accepted results from your own work and use xhigh as an escalation route.
The evidence supports “frontier contender,” not a universal winner. It leads the current CursorBench 3.2 table at Extra High and performs strongly in xAI’s professional-work evaluations, but trails GPT-5.6 Sol and Fable 5 on DeepSWE and Terminal-Bench in xAI’s own comparison.
No. It is the model layer and is now Grok Build’s default. Build supplies the coding harness, while Bot supplies a persistent cloud computer and connectors. Better model capability does not replace sandboxing, approvals, provenance, memory policy, or side-effect controls.
Grok 4.6 is a serious frontier release. It gives xAI a model that can compete for ambiguous multi-file coding, professional agent work, long-context analysis, and render-and-review projects. Shipping it across the API, Cursor, Build, Vercel, OpenRouter, and Cloudflare’s gateway on day one removes much of the integration excuse that previously limited Grok adoption.
But its most useful lesson is architectural. The 500K window is not a flat pool of cheap memory. It contains a 200K price cliff. The reasoning dial is not a quality badge. It is a trajectory budget. Prompt caching is not an automatic discount. It depends on exact state and affinity. And the model is not the agent. The harness still decides what the model sees, remembers, spends, calls, and is allowed to change.
Teams that treat those details as runtime policy can make Grok 4.6 an effective premium route. Teams that fill the window, inherit High everywhere, rewrite history, and trust the model to police its own side effects will discover that frontier capability does not simplify the system around it.
It makes that system more important.