Grok 4.7 Is Public. Test the State Contract, Not the 500K Window

xAI released Grok 4.7 on its public API on September 21, with a new checkpoint aimed at coding, agentic work, and knowledge tasks. The obvious reading is that xAI made Grok bigger, posted stronger benchmark numbers, and left the price alone. That is true as far as it goes. It is also the least useful way for a builder to read this launch.

The 500,000-token context window, image input, four reasoning-effort levels, and standard $2 input / $0.50 cached-input / $6 output rates below 200,000 prompt tokens all existed in Grok 4.6. Grok 4.7 does not create a new capacity class. It puts a new model inside an existing economic envelope, then changes how long-running work carries reasoning state through the Responses API.

That distinction also separates this story from the September 18 Google Cloud release. That event made an existing Grok 4.6 route generally available on Google’s managed platform. This one is a newer checkpoint on xAI’s direct public API. Google’s catalog still showed 4.6 at research time, so “Grok is on Google” and “Grok 4.7 is public” are different deployment facts.

My read: Grok 4.7 earns a production slot only if its extra persistence survives a matched-effort test and your gateway preserves the state, cache, and route semantics that make long runs viable. The benchmark headline is a reason to run that test—not the result of it.

The upgrade is not a larger memory box. It is a new worker operating inside the same box, with a more consequential contract for carrying unfinished work forward.

What is actually new in Grok 4.7

xAI says Grok 4.7 uses a larger base model, longer reinforcement-learning runs on harder multi-hour tasks, and training tailored to the Grok Bot harness. Those are vendor descriptions, not disclosed parameter counts or an independent reliability audit. The cleanest way to understand the product delta is to separate the checkpoint from the specifications it inherited.

The model page documents Responses and Chat Completions, function calling, structured outputs, and reasoning, while explicitly marking Batch API as unsupported. The overview lists a May 2026 knowledge cutoff and no separate text-output limit. That does not mean unbounded generation: the context window, timeouts, budgets, and rate limits still exist.

Read the benchmarks as four-part configurations

xAI’s launch table reports Grok 4.7 at 46.3% on CursorBench 4.0 and 38.0% on Terminal-Bench 4.0. But the headline Cursor comparison puts 4.7 at xhigh effort against 4.6 at high. It therefore mixes a checkpoint change with a compute-policy change.

Cursor’s live evaluator provides the more useful matched-high view, along with tokens, steps, and tariff-derived average task cost. Cursor is both benchmark owner and launch partner, so this is corroborating partner data—not a disinterested replication.

At matched high effort, 4.7 gains 3.5 percentage points while using roughly 15,000 more tokens and 23 more steps. Yet Cursor’s calculated average cost falls by $0.51. The honest interpretation is not “4.7 is more token-efficient.” It is that a longer trajectory may have been productive, and that the missing cache and token-type breakdown prevents us from explaining the cost movement from total tokens alone.

The Terminal-Bench comparison needs another restraint. The contributor leaderboard covers 66 tasks and lists Sol Max with Codex at 37.3% ±3.8; it did not yet include a 4.7 row when checked. A launch-only 38.0% does not establish a meaningful lead over 37.3%, especially across different harnesses.

DeepSWE deserves even more care. Epoch AI’s manual review rated version 1.1 “Flawed” and found false negatives in at least 23 of 113 tasks, including 18 involving test edits and verifier interactions. That audit does not erase every score or produce a corrected ranking. It does show why a model trained to inspect and repair its own work can collide with a brittle verifier.

benchmark result = model checkpoint
                 + reasoning effort
                 + agent harness and tools
                 + token/time budget
                 + verifier behavior

That is the first non-obvious takeaway: self-verification can increase steps without reducing useful efficiency, and can even look worse under a verifier that mishandles legitimate test changes. Review failure traces, not only pass-rate deltas.

The Responses API turns memory into an integration responsibility

For Grok 4.7, Responses automatically return reasoning.encrypted_content and encrypted server-tool outputs. xAI says client-managed histories should replay those reasoning items unchanged. A gateway that serializes only visible user and assistant text can therefore preserve the conversation humans saw while deleting part of the continuity the model needs.

Encrypted return is not plaintext chain-of-thought, cross-provider portability, or a retention setting. It also does not disable xAI’s server-side trace rehydration. store separately controls stored Responses behavior; Chat Completions does not expose the ciphertext field. Keep these concepts separate in your privacy review and SDK abstraction.

Stateful Responses can continue with previous_response_id for 30 days. Longer workflows need locally preserved history and opaque state. That creates a useful architecture boundary: store portable, human-readable decisions, artifact references, approvals, and tool evidence in your own ledger; treat provider reasoning state as a performance aid rather than your only project memory.

portable project ledger
  decisions + constraints + artifacts + approvals
                 │
                 ├── visible conversation
                 ├── provider-native encrypted state
                 ├── warm prefix / cache affinity
                 └── compacted checkpoint when economics justify it

Prompt caching adds another continuity layer. A stable prompt_cache_key for Responses—or x-grok-conv-id for Chat Completions—improves affinity to a cache server. It does not guarantee a hit. Caching reuses identical prefixes, so editing, deleting, or reordering earlier messages can invalidate the warm path.

xAI’s compaction endpoint returns an opaque state item that must be replayed unchanged. Compaction consumes tokens and the source conversation must still fit inside context when you invoke it. This makes caching and compaction complementary but competing controls: preserving a prefix protects cache reuse; compacting changes that prefix and buys future headroom.

The second non-obvious takeaway: changing models or routes mid-session is not just inference routing. It is a state migration involving warm prefixes, opaque items, retention policy, hosted-tool availability, and a portable recovery record. An OpenAI-compatible request shape does not make long-running agents portable.

The important price number is 200,000, not 500,000

On xAI’s direct global route, standard Grok 4.7 costs $2 per million fresh input tokens, $0.50 per million cached input tokens, and $6 per million output tokens below 200,000 prompt tokens. At 200,000 or more, the rates become $4, $1, and $12—and the higher tariff applies to the entire request, not only the excess. Reasoning tokens are billed at the output rate, and cached tokens still count toward the prompt-length threshold.

These are list-rate ingredients, not a total-cost ranking. Sol applies higher rates to the whole request above 272,000 input tokens; Fable has separate cache-write prices; Grok charges extra for hosted tools. The mix of fresh input, cache reads, cache writes, reasoning output, tools, retries, and human review decides the bill.

Illustration A — one-token tariff edge
199,999 fresh input + 10,000 output = $0.459998
200,000 fresh input + 10,000 output = $0.92

Illustration B — cache works, tariff still changes
190K prompt (180K cached) + 10K output = $0.17
190K cache-cold prompt + 10K output       = $0.44
210K prompt (200K cached) + 10K output   = $0.36

Those are arithmetic examples using published standard rates. They exclude tools, regional or priority premiums, taxes, and discounts. The point is structural: one extra prompt token at the boundary can nearly double an otherwise identical cold request, while a heavily cached request can remain cheaper after crossing the line. A dashboard must show both cache-hit ratio and tariff tier.

The third non-obvious takeaway: compaction should be triggered by expected future savings and quality risk, not by panic near the 500K ceiling. Compact with margin before 200K when the projected avoided tariff and future turns exceed compaction plus cache-rewarming cost. Preserve the full prefix when reuse is likely and requirements are fragile. This is an optimization policy, not a universal token-count rule.

There is no single Grok 4.7 route

Provider names now carry product semantics. Put the route beside the model ID in every eval result, incident report, and cost record.

The US endpoint is a scoped processing commitment, not an end-to-end “US-only agent” switch. xAI says request handling, inference, moderation, and retained request data are covered; hosted tools, files, collections, and the network path are not. Map the complete data flow and distinguish client-executed functions from vendor-hosted tools.

The default API policy states 30-day request and response retention and no training on API content without explicit permission. Zero Data Retention, where available, is team-wide and disables stateful Responses, Files, Collections, Batch, and deferred completions. Ciphertext return, store:false, US routing, and ZDR are four different controls.

The model’s published Tier 0 ceiling is 150 requests per second and 50 million tokens per minute. At 500,000 counted tokens per job, TPM permits only about 100 such requests per minute before other demand; cached and reasoning tokens still consume quota. Admission control for long agents should budget tokens, not only concurrency. And because 4.7 does not support Batch, do not quietly apply generic batch discounts or scheduling assumptions.

A practical evaluation plan for the next seven days

Do not begin with a fleet-wide model swap. Give 4.7 an evaluated lane for work that can benefit from persistence: multi-file code changes, screenshot-grounded debugging, long-document synthesis, and sessions that must recover after a failed tool call.

1. Build two controlled comparisons. First run Grok 4.6 high against Grok 4.7 high to isolate the checkpoint. Then run Grok 4.7 high against xhigh to price the extra effort. Keep tasks, harness, tools, wall-clock cap, token cap, and acceptance rubric fixed.

2. Grade completed work, not eloquence. Record accepted outcome, reviewer minutes, test regressions, retries, steps, tool failures, latency, and whether the model knew when to stop. Manually inspect a sample of benchmark-style failures for verifier collisions.

3. Instrument the token mix. Capture fresh input, cached input, reasoning/output, prompt length, selected tariff tier, endpoint, hosted-tool usage, and the actual billed amount. xAI exposes cost_in_usd_ticks; divide by 10^10 for dollars and sum every turn in the task. See xAI’s cost-tracking guide.

4. Test four continuity paths: previous_response_id; locally replayed history with every encrypted item intact; the same history after your normal gateway serialization; and a compacted checkpoint. Verify required decisions survive, then measure cache rewarming and subsequent cost.

5. Run boundary cases at 190K, 199,999, 200K, 210K, and near your operational ceiling. Confirm how your SDK counts images, tool results, and reasoning state. Reserve room for the next tool result and final response rather than filling all 500K.

6. Exercise governance separately. Compare global and US routes with tools on and off, test store:false and approved retention settings, and verify what your partner route actually preserves. Keep the current production route as a declared fallback; quality improvement does not authorize moving data to an unapproved endpoint.

For research agents, add one more meter. xAI scheduled X Search to switch at 19:00 UTC on September 21 from $5 per 1,000 calls to $5 per 1,000 fetched posts and $10 per 1,000 fetched profiles. That is a platform billing change, not a 4.7 feature. It means unchanged model token prices can still produce a higher research-agent bill when one broad retrieval fetches many objects. Log retrieved posts, parents, quotes, and profiles—not just tool-call count.

What xAI has not established yet

xAI reports 62.4% on LatchBio’s refusal-and-utility biosafety benchmark and 3.3% risky dual-use acceptance on its own HackerBench v0.3. These are vendor-reported safeguard results, not broad biology or cyber capability scores. LatchBio’s public methodology combines routine requests with concealed-risk cases, but no independently posted 4.7 result was found. HackerBench’s denominator and grading details were not established.

The xAI safety index still listed older Grok model cards at research time, not a release-specific 4.7 card. There is also no disclosed parameter count, training-compute total, independent long-horizon reliability result, or public latency distribution. “Larger base model” and “same speed” remain vendor claims until measured in your workload.

Fast pricing is another unresolved detail. The pricing page says Fast costs twice standard rates, but its long-context row lists $6/$1.50/$18 versus standard $4/$1/$12—a 1.5× multiple. Fast is partner-only anyway, but teams buying through Cursor or Grok Build should get the exact threshold and rate in writing before making a TCO claim.

Quick answers for builders

Is the 500K context window new?

No. Grok 4.6 already had 500K context, image input, xhigh effort, and the same direct-API tariff. Grok 4.7 is a new checkpoint with new Responses state behavior and new performance claims.

Does the launch prove Grok 4.7 beats Sol or Fable?

No. Launch comparisons mix efforts and harnesses, while relevant leaderboards lack independent 4.7 rows or expose verifier problems. The evidence justifies a matched internal evaluation.

Is Grok 4.7 the cheapest long-running agent model?

Not categorically. It has lower fresh-input and output list rates than the two comparators shown here, but Sol and Fable list cheaper cache reads. Grok also has a whole-request step at 200K and separate tool charges. Measure your token and tool mix.

Can I call Grok 4.7 Fast on xAI’s public API?

No. xAI documents Fast as the same model on faster infrastructure available through Cursor and Grok Build, excluding Grok Build’s free tier. Do not invent a public Fast model ID.

Should an existing Google Cloud Grok integration switch model IDs?

No. Google’s managed catalog still listed 4.6 at the research check. Direct xAI availability does not establish Google availability, quota, state, or residency behavior for 4.7.

Grok 4.7 is interesting precisely because xAI did not reprice the standard model or enlarge its headline context. The experiment is cleaner: put a new checkpoint into the same broad capacity and tariff envelope, then see whether it finishes harder work more reliably.

But the checkpoint is only one layer of the result. Effort policy determines how far it thinks. The harness determines what it can do. Encrypted state and cache affinity determine whether it remembers the useful middle. Compaction policy determines when memory becomes economical. The route determines price, retention, tools, and regional scope.

Treat 4.7 as a candidate worker, not a leaderboard winner. Give it difficult, bounded jobs; preserve its state correctly; meter the full trajectory; and promote it only where matched evidence shows a better completed outcome. That is how this release becomes a product decision instead of another model-name update.