xAI Ships Grok 4.7 With Longer Agent Runs at Unchanged Prices
xAI ships Grok 4.7 with longer deliberation, better self-checking, and stronger safety guardrails, matching Grok 4.6 on price and latency.
- xAI released Grok 4.7, a reinforcement-learning refinement of Grok 4.6 at identical price and speed
- Model works longer on hard tasks, verifies its own outputs, and ships with xAI's strongest safeguards yet
- Available immediately in Cursor, Grok Build, and the xAI API
- Pricing holds at $2 per million input tokens and $6 per million output tokens
- Release fixes RL bugs where earlier builds finished difficult tasks too quickly without checking work
- Ships ahead of expected Meta and OpenAI model launches, extending xAI's aggressive two-month cadence
Grok 4.7 targets longer agent runs at Grok 4.6 prices
xAI has released Grok 4.7 after several public schedule slips. The company presents the model as a low-friction successor to Grok 4.6, with longer reasoning on difficult tasks, more self-verification, and stronger safeguards. xAI says the standard model retains Grok 4.6 pricing and serving speed.
For production teams, the release offers a relatively inexpensive upgrade test because existing API integrations should require limited application changes. Workload testing remains necessary: longer reasoning can increase output volume, latency, and total cost even when per-token rates stay fixed.
The release in one screen
| Item | Grok 4.7 details |
|---|---|
| Launch access | xAI API, Cursor, and Grok Build |
| Standard price | $2 per million input tokens and $6 per million output tokens |
| Faster service | $4 per million input tokens and $12 per million output tokens |
| Main changes | Longer reasoning, stronger self-checking, and revised task management |
| Published evidence | An xAI side-by-side game-building demo; no independent results yet |
| Architecture | Parameter count and base-model changes remain undisclosed |
Reinforcement learning shaped the release
xAI attributes the delay to reinforcement-learning work performed after the model’s main training run. This stage adjusts behavior using reward signals, including how long the model works, when it uses tools, and when it decides a task is complete.
During the delay, Elon Musk said internal builds sometimes ended difficult tasks too early and failed to verify their results. He also cited problems with response-length penalties and task management. xAI says the released model allocates more thinking tokens, meaning internal computation before the final answer, when a prompt requires extended reasoning.
Architecture details remain unresolved because xAI has not published Grok 4.7’s parameter count, training-compute figures, or base-model design. Reports describing a 2.1-trillion-parameter model remain unconfirmed and should not guide infrastructure or capacity decisions.
Access starts with xAI, Cursor, and Grok Build
At launch, developers can use Grok 4.7 through the xAI API, Cursor, and Grok Build. Existing Grok 4.6 applications may need only a model-selector change, although teams should confirm the exact model identifier, endpoint compatibility, and alias behavior in xAI’s current API documentation.
OpenRouter, Vercel, and Cloudflare distributed Grok 4.6 through partner channels. Their Grok 4.7 support remains pending until each provider lists the model, pricing, context limits, and regional availability.
Evidence begins with a game demo
xAI published a side-by-side demonstration in which Grok 4.7 and Grok 4.6 build an open-world city game within the same wall-clock window. The newer model produces a more complete scene, according to the company’s presentation. Independent measurements are still needed to establish reliability across repositories, frameworks, and tool configurations.
xAI’s recent evaluations have emphasized DeepSWE, CursorBench, Terminal-Bench, APEX, and AA-Briefcase. These suites focus on agentic work, where a model plans multiple steps, edits files, runs tools, and responds to failures. The release materials summarized here provide no comparable Grok 4.7 scores or detailed evaluation methodology.
Workloads aligned with the announced changes include:
- Long repository-level coding tasks that require repeated edits and tests
- Multi-step tool use where the model must inspect results before continuing
- Generative user-interface work spanning several coordinated files
- Game and 3D-scene generation with many dependent assets and components
- Agent loops that previously ended before all acceptance criteria were met
Short classification, extraction, routing, and chat requests may see smaller gains because they offer little scope for extended reasoning or iterative tool use.
Longer answers can change the bill
Total cost may rise when Grok 4.7 generates more output or performs longer reasoning on prompts that Grok 4.6 handled briefly. Teams should measure cost per completed task, including retries and failed tool calls, instead of comparing token rates alone.
Request latency also requires local testing. xAI’s claim of unchanged speed may describe serving throughput or a broad latency target, while individual hard prompts can still take longer when the model performs additional reasoning. Median latency, tail latency, time to first token, and total completion time provide a more useful production view.
Safeguard claims need documentation
xAI describes Grok 4.7 as its most strongly safeguarded model to date, but the release summary does not provide a full system card. A system card typically documents safety evaluations, known failure modes, mitigations, and deployment limits, giving security and governance teams evidence they can review.
Enterprise evaluations should examine prompt-injection resistance, sensitive-data handling, tool permissions, refusal behavior, code-execution boundaries, and logging controls. External testing will also be needed to compare the model’s safeguards with earlier Grok releases.
Key API details remain open
The release summary leaves several implementation questions for xAI and its distribution partners:
| Open question | Why developers need it |
|---|---|
| Model IDs and alias behavior | Version pinning, reproducibility, and rollback |
| Context and output limits | Chunking, truncation handling, and memory design |
| Tool and schema compatibility | Agent reliability and structured-output validation |
| Thinking-token accounting | Accurate latency and cost estimates |
| Caching and batch rates | Economics for repeated prompts and offline jobs |
| Rate limits and regions | Capacity planning and deployment compliance |
| Grok 4.6 deprecation schedule | Fallback planning and migration timing |
Fast releases raise versioning stakes
Grok 4.7 follows Grok 4.5 and Grok 4.6 within roughly two months. That cadence allows xAI to ship post-training improvements quickly, while giving developers less time to evaluate each version before another arrives.
Rapid updates and slipped public timelines increase the value of pinned model versions, regression suites, and maintained fallbacks. The unchanged token rates preserve xAI’s price position, but production value will depend on successful tasks per dollar and the operational stability of each release.
Canary metrics for migration
A controlled canary deployment can establish whether Grok 4.7 improves a specific workload before it receives general traffic. The comparison should use representative production prompts and fixed acceptance criteria.
- Confirm model identifiers, context limits, tool support, rate limits, and data-retention terms.
- Replay a production evaluation set against Grok 4.6 and Grok 4.7.
- Measure task completion, output tokens, retries, tool-call accuracy, schema compliance, and latency percentiles.
- Review longer responses for unnecessary output, truncation, and increased spend.
- Test safety policies and permission boundaries for every connected tool.
- Keep Grok 4.6 available as a rollback target until the canary meets its thresholds.
Teams already using Grok 4.6 have the clearest migration path. Promotion should follow measurable gains in completion quality or cost per successful task, backed by stable API behavior and a tested rollback route.