benchr
xAI launched Grok 4.6 on August 12, 2026 and added it to GitHub Copilot on August 14. benchr checked the launch post, developer guide, pricing table, partner notice, and model card. Those sources establish the product contract. They don't establish that the model will finish your repository tasks safely or cheaply.
Start with a workload gate, not the launch table
The useful question isn't whether Grok 4.6 posts a higher provider score than Grok 4.5. It is whether your workload benefits from longer agent runs enough to justify a new failure profile and the long-context price step. Use this gate before sending production traffic.
| Workload | Choose a pilot when | Pause or avoid when | Acceptance evidence |
|---|---|---|---|
| Multi-file coding agent | The task needs repository search, edits, tests, and recovery across many turns. | Your harness has no turn, cost, or permission ceiling. | Build success, regression count, reviewer acceptance, and total billed cost per accepted change. |
| Interactive or visual build | Text and image input plus tool calls belong in one trace. | A deterministic template or smaller bounded model already handles the work. | Requirement coverage, visual review, accessibility checks, and rework needed after the first pass. |
| Research with current data | You can enable and audit the documented web or X search tools. | Your process cannot retain citations or separate retrieved evidence from model prose. | Source coverage, unsupported-claim rate, and a human check of every decision-critical citation. |
| Predictable short transformation | Only if the same evaluation shows a clear quality or workflow gain. | Latency, spend, and deterministic output matter more than long-horizon agency. | Schema pass rate, retry rate, and cost against the current production baseline. |
The 200K boundary can change the winner
The headline $2/$6 rate is the short-context tier, not a flat price for the full 500K window. Once the prompt reaches 200K tokens, xAI lists $4 input, $1 cached input, and $12 output per million. The threshold applies to the request's prompt, and the higher rates apply to the billed tokens in that long-context request. A migration that looks cheap on small samples can cross into a different budget during a long repository session.
Before comparing models, split your logs into requests below and at or above 200K prompt tokens. Price both buckets in the production cost calculator, then add server-side tool charges and retries. Don't assume a large advertised window is free capacity.
“No text output limit” still needs hard controls
The official guide says Grok 4.6 has no text-output limit, but it does not publish a numeric maximum-output value. That is a documented gap, not permission to let an agent run without bounds. Set a maximum turn count, wall-clock deadline, spend ceiling, tool allowlist, artifact-size limit, and stop rule for repeated failures. Put approval before destructive actions and before any external side effect.
Keep the model ID pinned during evaluation, preserve prompts and tool schemas, and record reasoning effort. A result from high should not be silently compared with a baseline using a different effort or tool set. The Labs workspace can hold a fixed prompt set and rubric without pretending that benchr ran the model for you.
Read the benchmarks as provider evidence
xAI reports 69.9% on CursorBench v3.2 and 65.9% on DeepSWE v1.1 for the named Grok 4.6 variant. They are launch-table results, not independent benchr measurements. They justify testing long coding work. They do not predict your language stack, repository permissions, CI setup, or review standard.
Build a replay set from work your team already understands: a small bug fix, a multi-file change, a tool failure that requires recovery, a visual task, and a long-context request that crosses the price threshold. Score completion, correctness, regressions, tool discipline, citations where relevant, reviewer time, and billed cost. Publish no “win rate” unless the prompts, settings, raw outputs, rubric, and calculation are available.
Use a reversible migration plan
- Freeze the baseline. Pin the current model, prompts, tool definitions, repository snapshot, and acceptance tests.
- Replay before routing. Run the same representative cases through Grok 4.6 with explicit reasoning effort and limits.
- Review failures, not just averages. Inspect unsafe tool calls, incomplete changes, citation gaps, and expensive loops.
- Canary a narrow queue. Route low-risk tasks first, retain a fallback, and stop automatically when an acceptance gate fails.
- Expand only on measured value. Compare accepted work and reviewer time against total token, tool, and retry cost.
If you are moving from the previous release, keep the Grok 4.5 review beside the replay report. That prevents a launch-day scorecard from replacing the behavior your team already knows.
| Field | Verified record | What you must decide |
|---|---|---|
| API model ID | grok-4.6 | Alias or pinned-version policy for reproducible runs |
| Base pricing | $2 input / $0.50 cached / $6 output per 1M below 200K prompt tokens | Cache routing and a per-task spend ceiling |
| Long-context pricing | $4 input / $1 cached / $12 output per 1M at or above 200K prompt tokens | Whether a long trace still beats retrieval or compaction |
| Context and output | 500,000-token context; no numeric text-output cap published | Turn, time, output, and artifact limits |
| Interfaces | Responses and Chat Completions; functions, structured output, web/X search, code execution | Tool permissions, audit logging, and approval gates |