Grok 4.7: Same Price, Longer Runs, One 402

What xAI says changed

Grok 4.7 is described as "our most capable model for coding and knowledge work. It works longer on difficult tasks, checks its own work more carefully, and comes with our best-calibrated safeguards to date." The technical claims behind that sentence, from the announcement and the model card: a "new, larger base model"; a "longer reinforcement learning run on a harder mix of tasks, weighted toward problems that take many hours to complete"; better "at verifying its own work and managing longer context"; and it "natively understands the Grok Bot harness".

The model card adds the recipe in the amount of detail xAI is willing to publish. Supplemental training "ran longer than for Grok 4.6", with "an improved optimizer and recipe". Grok 4.6 models generated the supervised fine-tuning trajectories "across reasoning efforts, agent harnesses, and domains spanning STEM, software engineering, and knowledge work". Agentic reinforcement learning covered "knowledge work, general coding, and purpose-built environments for kernel optimization, web development, and computer-aided design". A footnote says the model "received supplemental training on anonymized Cursor workflow data". No parameter count appears in any primary source, so none appears here.

One sentence in the card is written for people like me: "We never silently downgrade intelligence or fall back to other models." That is the same rule my harness enforces on every vendor, so I read it as a promise I will hold them to rather than a feature.

The numbers, with the harness named

xAI's tables are the only source for these, and several are run by third parties in specific harnesses, which matters for terminal and long-horizon benchmarks. Competitor figures are xAI's, not mine.

Three readings of that table. First, the within-family gains are large where the task is long: Terminal-Bench nearly doubles on a mixed-effort pair, SWE-Marathon gains fourteen points, and 4.7 beats 4.6 on every row above. Second, the cross-vendor picture has not flipped: on CursorBench, Terminal-Bench, FrontierSWE and HealthBench, xAI's own numbers put Fable 5.1 ahead, sometimes by a lot; GPT-5.6 Sol leads DeepSWE, Opus 5 leads SWE-Marathon, GPT-6 Astra leads EEBench. Among the printed competitors, Grok 4.7 leads only the legal benchmark. Third, the card's stated design goal is "reaching results with fewer steps and fewer output tokens than other frontier models", and its CursorBench chart is drawn as score against average output tokens per task and score against average cost per task. That is the product: a cheaper way to get a long run finished, not a claim to the highest bar.

Two cautions before quoting any row. Effort is not uniform: some 4.7 figures are at xhigh, some at high, and the Terminal-Bench row pairs 4.7 at xhigh against 4.6 at high. And the card's footnote says 4.7 "received supplemental training on anonymized Cursor workflow data" while CursorBench is Cursor's own benchmark. A reason to weight that row differently.

The safety section is short and specific. xAI calls 4.7 "the strongest model we've tested on refusals and jailbreak resistance", scores 62.4% on the LatchBio biosafety benchmark and lets "only 3.3% of risky dual-use prompts through" on HackerBench v0.3. Those are the vendor's tests; I have not run them.

Specs and price

"Served at the same price and speed as Grok 4.6" is the announcement's own wording, and the pricing page bears out the price; speed is a claim I have not measured. Where 4.7 is available today: the API, Grok Build, Cursor on every plan tier, the Office add-ins, and gateways including OpenRouter, Vercel and Cloudflare. The consumer surfaces come "at a later date".

Two cutoffs and two EEBench figures

Same vendor, same day, two answers twice. The docs page puts the knowledge cutoff at May 2026; the model card says pretraining data runs to June 2026 with supplemental data as late as August 2026. EEBench is printed as 66.0% against 60.0% in the card and as 64.0% against 53.0% on the announcement page, so the 4.6-to-4.7 gap is six points in one document and eleven in the other. The 4.6 halves differ by labelled effort, which explains part of it; the two 4.7 figures sit at the same effort and stay unexplained. Documentation inconsistencies, not model defects. They are also the kind that end up in someone's slides as fact, so cite the document and its revision whenever you quote a Grok 4.7 number.

The switch

My setup, described in Grok Joins the Party and I Love Trios, pins each vendor's strongest model at its maximum reasoning setting, in one policy file, and generates the native adapters for Claude Code, Codex and Grok Build from it. The model name is a literal in a manifest, and a check command fails when any generated file, launcher or role definition drifts from it. That makes a model release a mechanical job with a defined finish line.

Probe first. Grok Build was at 1.0.40 and the updater reported nothing newer. grok models answered with a new default:

Default model: grok-4.7

Available models:
  * grok-4.7 (default)
  - grok-4.7-build-fast
  - grok-4.5
  - grok-4.6

The server-provided model metadata behind that list carries the effort menu for 4.7, with xhigh labelled "Extra High — Maximum reasoning for the hardest tasks" and high as the default. That is new plumbing: the 1.0.39 changelog from the day before says "Effort levels for models now come from the API instead of hard-coded lists", which is why a CLI built before the model shipped already knew its efforts.

Then the real test. A single-turn headless call with --model grok-4.7 --reasoning-effort xhigh came back with HTTP 402: "Grok Build usage balance exhausted". The same call with grok-4.6 came back with the same 402. So the CLI accepted the model and effort flags, and the only error returned was the balance; availability rests on the model list and the API metadata, not on the 402. My policy says to surface an unavailable model rather than quietly pick a weaker one. A balance wall is a different state, and the harness already classifies it separately: the second-opinion runner treats credits as an availability failure and moves to the next vendor rather than downgrading. I switched on the evidence of the model list and the API metadata, and I am saying plainly that no successful 4.7 run has happened on this machine yet.

Then the pins, in order. The policy text and the Grok adapter. The second-opinion runner's Grok entry, grok-4.7 at xhigh, and its validator, which now accepts a 4.7 identity in the response and rejects anything else. The tracked Grok configuration, which names the model in nine places:

[models]
default = "grok-4.7"
web_search = "grok-4.7"
session_summary = "grok-4.7"
image_description = "grok-4.7"
prompt_suggestion = "grok-4.7"
default_reasoning_effort = "xhigh"

[ui]
fork_secondary_model = "grok-4.7"

[subagents.models]
explore = "grok-4.7"
plan = "grok-4.7"
general-purpose = "grok-4.7"

That file is installed into the live configuration through a managed merge that keeps the CLI's own acknowledgements and any local additions; the previous version is kept as a backup. Nine role definitions and six persona overrides carry their own model and reasoning_effort keys and were updated one by one. The PATH wrapper that injects -m grok-4.7 --effort xhigh --always-approve into interactive, headless and agent launches. The global drift check, which asserts every one of those keys. The manifest invariants, which now require the grok-4.7 literal in fifteen role and persona files and forbid grok-4.6. The documentation. Then the tests: 312 passed after the fixtures that expected the old name were updated. Then the three global instruction files were regenerated from the policy, and the decision graph's Grok claim was rewritten and every source hash it cites refreshed, because a graph that says "4.6" next to a file that says "4.7" is worse than no graph.

Then the two other repositories. The private cockpit that runs headless loops carries the model name in its loop templates, runtime notes and command adapters; those changed, its manifest now forbids the old literal, and its tests (38) passed once the reviewed portable packet of the dotfiles was regenerated at the exact new revision. The second personal repository got a dated default paragraph, its own manifest invariant, its loop pin and documentation, 52 passing tests, a memory entry and refreshed graph hashes. Live loop batches, stop markers and working checkouts were not touched; templates change, running controllers do not.

Seven commits across three repositories, and about an hour, most of it spent on the graph hashes and the portable packet rather than on the model name. That is the intended shape: the name is trivial, the proof that nothing else drifted is the work. And the cost of the switch at the API is nothing, because the price rows are identical; the real constraint is a subscription balance that is currently zero. A free upgrade with no measured effect is still an upgrade with no measured effect.

Hot takes

A model release is a config diff with a test suite, or it is a rumor. If you cannot list every file that names the model, you do not know what your agents are running.

The effort menu coming from the API is the quiet win. A CLI that hard-codes effort names lies the day a model adds one. 4.7 kept xhigh, so nothing broke; next time it may not.

"Same price" is the headline, and it is honest. Identical pricing rows and a card drawn in score-per-token and score-per-dollar tell you what xAI is selling: finished long runs for less, not the top of the table.

Check the harness column before quoting a terminal benchmark. Terminal-Bench 4.0 was run with the Grok Build harness; the card itself says "absolute scores remain sensitive to the agent harness".

A 402 is not a downgrade signal. It is a balance. Subscription balances fail differently from metered APIs, and a drift check has to know the difference or it files a credits problem as a model problem. The right reaction is to fall over to another vendor's maximum model and keep the pin, not to reach for a cheaper Grok.

A forbidden literal is the only pin that stays pinned. A migration that leaves the old model string in a fixture, a persona or a subagent default has not migrated.

Publishing a table where a competitor leads most coding rows is unusual. It also leaves price-performance as the only frame in which this release wins, which is the frame xAI chose.

What this does not show

Any measured change in my own work. No 4.7 completion has run here yet; the balance has to be topped up first, and the first real comparison will be on accepted results, not on vendor charts.

Any independent benchmark. Every number above is xAI's, run by xAI or by the evaluator it names.

The fast variant. It exists in Cursor and Grok Build at twice the token rate; I have not enabled it and have no plan to, because speed was not the constraint.

Whether the "fewer output tokens" claim holds in an agent loop. That is the claim I care about most, and it is the one that needs a month of receipts.

Green checks mean every reference to the model agrees with the manifest. They say nothing about what the model does once the balance is not zero.