Grok 4.7 vs 4.6: What Changed, Benchmarks, Should You Upgrade?
grok-4.6 and grok-4.7.This guide covers what changed, the benchmark numbers from xAI and from Artificial Analysis side by side, what the token difference does to a bill that has the same unit price, and how to test the upgrade on your own workload before moving traffic.
What changed in Grok 4.7
xAI describes three changes. First, a larger base model: Grok 4.7 is trained from a bigger base than 4.6. Second, a longer reinforcement-learning run on a harder mix of tasks, weighted toward problems that take many hours to complete. Third, the behavioural result xAI highlights: the model is "better at verifying its own work and managing longer context."
What did not change: the 500,000-token context, text and image input, function calling and structured outputs, the four reasoning effort levels, the rate limits, and the price.
Grok 4.7 vs 4.6 benchmarks: xAI-reported and third-party
xhigh and Grok 4.6 at high.| Benchmark | Grok 4.6 (xAI) | Grok 4.7 (xAI) | Grok 4.6 (AA) | Grok 4.7 (AA) |
|---|---|---|---|---|
| Terminal-Bench 4.0 | 20.3% | 38.0% | — | +4.5 pts over 4.6 |
| Artificial Analysis Intelligence Index v4.3.2 | — | — | 44 | 46 |
| CursorBench 4.0 | 40.4% | 46.3% | — | — |
| DeepSWE v1.1 | 65.2% | 71.0% | — | — |
| EEBench | 53.0% | 64.0% | — | — |
| AA-Briefcase v1.1 (Elo) | 1,546 | 1,657 | 1,546 | 1,657 |
| GDPval (Elo) | 1,605 | 1,695 | 1,605 | 1,695 |
| Harvey legal agent | 15.8% | 19.6% | — | — |
| HealthBench Professional | 48.5% | 56.7% | — | — |
| Output tokens per index task | — | — | ≈36k | ≈81k |
xhigh, Grok 4.7 writes about 81,000 output tokens per task where Grok 4.6 at high wrote 36,000.Specifications side by side
| Dimension | Grok 4.6 | Grok 4.7 |
|---|---|---|
| API model ID | grok-4.6 | grok-4.7 |
| Release | August 12, 2026 | September 21, 2026 |
| Context window | 500,000 tokens | 500,000 tokens |
| Modalities | Text and image input; text output | Text and image input; text output |
| Reasoning effort | low, medium, high (default), xhigh | low, medium, high (default), xhigh |
| Function calling and structured outputs | Yes | Yes |
| Standard rate per 1M tokens (xAI direct) | $2 input, $0.50 cached, $6 output | $2 input, $0.50 cached, $6 output |
| Long-context tier | Prompt ≥ 200,000 tokens: every token billed at 2× | Same rule, same threshold |
| Fast variant | — | Grok 4.7 Fast: 2× speed, 2× price ($4 / $1 / $12); Cursor and Grok Build only, not on the public API |
| Published rate limits | 150 requests/s, 50M tokens/min | 150 requests/s, 50M tokens/min |
| EvoLink route | Live | Live since September 22, 2026 (standard model) |
Same price per token, not the same bill
Both models bill $2 per million input tokens and $6 per million output tokens on xAI's direct rates. The unit price is settled. What changed is how many units the new model spends to finish a task.
xhigh versus 36,000 for 4.6 at high. At $6 per million output tokens that is roughly $0.49 against $0.22 of output per task before any input, cache or tool charges. The higher-effort setting is part of that difference, which is why the first thing to do is run both models at the same effort on your own tasks.cost per accepted task = total billed cost of all attempts / accepted tasksCount failures and retries in the numerator. If no task is accepted, report that outcome; do not display a zero cost. Keep human review cost separate from API charges.
Three billing rules apply equally to both models and should be checked with real traces:
- The 200,000-token threshold. When a prompt reaches 200,000 tokens, xAI bills every token in that request at the long-context rate. A conversation that grows past the threshold mid-session doubles its cost from that point.
- Cached input. Stable system prompts and tool schemas can be served at the cached rate. Check the cached-token field in usage to confirm the cache is hit under your request pattern.
- Tool charges. Since September 21, 2026, xAI bills X Search per fetched post ($5 per 1,000) and per fetched user profile ($10 per 1,000) rather than per call, for Grok 4.5, 4.6 and 4.7 alike. Other server tools remain per call.
How to run a fair upgrade test
Start from a problem 4.6 actually has. If 4.6 meets your acceptance rules and deadline, there is no cost penalty for staying. Reserve the test for workloads with a named failure: a code assistant that explains a fix instead of making it, an extraction job that returns valid JSON with missing fields, an agent that finishes but blows the latency budget with repeated tool calls.
| Your situation | What to do | What would justify moving |
|---|---|---|
| Correct results, acceptable cost and latency | Save a small regression set; test 4.7 without urgency | A clear gain without losing required behaviour |
| Unfinished repository tasks | Collect representative failures and independent tests | More accepted fixes within the same budget |
| Tool loops or expensive retries | Preserve traces and controlled error cases | Better recovery and lower cost per accepted task |
| Long-context tasks that drop earlier constraints | Build cases at real context sizes, including near 200K | Retained constraints at the same or lower token use |
| Hard delivery deadline | Keep the verified 4.6 configuration | Validation completed before the deadline |
high, and record the reasoning and output tokens each one consumed. A second pass may tune each model separately; report the two passes apart.For a repository task, an accepted run must produce a working patch, pass the relevant tests and stay within the permitted scope. A plausible explanation with no patch fails. If the agent says it ran tests, keep the tool output so a reviewer can check the claim. This is the "verifying its own work" claim made observable.
Score completed work, not the response:
| Metric | How to measure it | Mistake it prevents |
|---|---|---|
| Accepted-task rate | Tasks meeting the frozen rubric divided by attempted tasks | Counting plausible answers as completed work |
| Scope compliance | Check permitted edits, actions and constraints | Rewarding an effective but unacceptable workaround |
| Completion time | Task start to accepted artifact, including retries | Reporting first-token speed as end-to-end latency |
| Reasoning and output tokens per task | Usage fields on each attempt, by effort setting | Assuming equal rates mean equal spend |
| Billed cost per acceptance | All attempt charges divided by accepted tasks | Hiding failed-request and retry spend |
| Review burden | Corrections and reviewer time, recorded separately | Shifting work from the model to a human invisibly |
Keep raw counts beside percentages, and re-run hard cases to expose variability. Do not let a coding benchmark replace your task mix: keep translation, extraction and screenshot cases in the regression set.
Compatibility checks and rollout
Same provider, same protocol, same effort values: on paper a one-line change. In practice, version changes surface in output shape, tool behaviour and edge cases.
| Surface | What to preserve | What to retest |
|---|---|---|
| Model ID | Explicit configuration and rollback value | Send grok-4.7; confirm the model ID in the response |
| Structured output | Your schema and validator | Missing fields, invalid values and truncation |
| Tools | Tool definitions and authorization boundaries | Arguments, repeated calls and error recovery |
| Streaming | Handling of partial output | Event shape, interrupted responses and terminal state |
| Conversation state | Original messages and test data | Context limits, compaction and retained constraints |
| Usage and billing | Logs linking a task to its attempts | Cache, reasoning, output and tool accounting per model |
Do not change the model, prompt, tool adapter and retry policy at the same time. Start with offline replay, then shadow read-only work while 4.6 remains responsible for what users see, then move a limited workload. Define a stop condition in operational terms: a critical schema failure, unauthorized tool behaviour, a drop in accepted outcomes, or cost and latency outside budget. When switching back, check which side effects already completed before retrying on 4.6.
Promotion does not need to be all-or-nothing. A candidate could earn difficult repository tasks while 4.6 keeps predictable extraction work. Because the rates are identical, a split costs nothing extra in unit price; it costs monitoring and configuration.
The practical decision on EvoLink
FAQ
Is Grok 4.7 better than Grok 4.6?
On xAI's numbers, clearly: Terminal-Bench 4.0 nearly doubles and every listed benchmark improves. On Artificial Analysis's independent run the gain is smaller, two index points and 4.5 points on Terminal-Bench, at more than twice the output tokens per task. Whether it is better for you is what the paired test measures.
What is the Grok 4.7 vs 4.6 benchmark difference?
xAI reports Terminal-Bench 4.0 at 38.0% versus 20.3%, CursorBench 46.3% versus 40.4%, and GDPval 1,695 versus 1,605 Elo. Artificial Analysis measures the Intelligence Index at 46 versus 44. See the table above for the full set with sources.
Does Grok 4.7 cost more than Grok 4.6?
xhigh used about 81,000 output tokens in Artificial Analysis's test against 36,000 for 4.6 at high, so the same work can cost more.Should I upgrade from Grok 4.6 to 4.7?
Upgrade the workloads where 4.6 has a named failure and 4.7 passes the paired test at an acceptable cost per accepted task. Keep 4.6 as the rollback target. A release is not a retirement notice.
Can I reuse the same prompt and effort setting?
low, medium, high and xhigh. Tune separately afterwards and report the passes apart.Do tool calls and structured outputs need another test?
Yes. Retest schemas, arguments, recovery and output validation, and recheck tool costs: X Search is now billed per fetched post and user profile.
What is Grok 4.7 Fast?
The same model on faster infrastructure at twice the output speed and twice the token price. xAI offers it only in Cursor and Grok Build, not on the public API, and EvoLink's Grok 4.7 route serves the standard model.
When should I roll back?
When a critical behaviour fails or your predefined quality, cost or latency limits are exceeded. Inspect completed side effects before retrying a task on the other model.
