Grok 4.7 gives existing Grok users a practical reason to revisit their model choice: improved performance on difficult work at unchanged starting token prices. Released September 21, 2026, it targets coding and knowledge work, with a larger base model and more training on extended tasks, according to the official launch announcement.
For SeeAPI readers building applications, the useful question is whether those improvements solve an existing bottleneck. Does your assistant lose track of requirements? Does a coding workflow produce plausible changes that fail verification? Does a document task need repeated corrections? Those are better starting points for an upgrade decision than the version number alone.
Grok 4.7 vs 4.6: What Is Actually New?
The previous release already emphasized sustained work. The Grok 4.6 announcement described an agent that could research, implement, and refine projects across many steps, with more self-testing during extended runs.
That history matters. Long-running work is not a capability that suddenly appeared in 4.7. The new release continues that direction, with the developer reporting better self-verification and context management. Think of the change as an attempt to improve how consistently the model finishes difficult assignments.
Consider a feature request involving several files. A useful assistant must understand the request, find the relevant code, implement the change, and check that existing behavior still works. An attractive first draft solves only part of that problem. When evaluating an upgrade, inspect the whole sequence and the final result.
The same principle applies outside coding. For a research brief, assess whether the final recommendations follow from the supplied evidence. For a presentation, check whether the numbers remain consistent across slides. These are proposed evaluation tasks, not claims that this article has tested either model.
Grok 4.7 Benchmarks: Gains With an Important Caveat
The release table reports the following results:
Benchmark | Grok 4.6 High | Grok 4.7 xHigh | Change |
|---|---|---|---|
CursorBench 4.0 | 40.4% | 46.3% | +5.9 percentage points |
Terminal-Bench 4.0 | 20.3% | 38.0% | +17.7 percentage points |
EEBench | 53.0% | 64.0% | +11.0 percentage points |
These are vendor-published results, not SeeAPI measurements. They compare different reasoning settings: 4.6 High and 4.7 xHigh. Consequently, they do not isolate the model upgrade at an identical reasoning budget.
For a buyer, the distinction is straightforward. The table shows what the published configurations achieved. It does not establish that replacing a model name in your application will reproduce the same improvement at the same total cost or latency.
Also keep benchmark versions consistent. The earlier 4.6 launch used CursorBench 3.2 and Terminal-Bench 3.0. Comparing those older scores directly with the newer benchmark versions would confuse changes in the evaluation with changes in the model. The table above uses the paired results in the 4.7 release.
Grok 4.7 Pricing: Same Starting Rates, Different Possible Bills
As of September 22, 2026, standard Grok 4.7 pricing in the official API release notes is:
Prompt size | Input / 1M tokens | Cached input / 1M tokens | Output / 1M tokens |
|---|---|---|---|
Below 200K prompt tokens | $2 | $0.50 | $6 |
Above 200K prompt tokens | $4 | $1 | $12 |
A token is a unit of text processed by the model. Cached input refers to eligible reused input billed at a reduced rate. Confirm the boundary treatment in current billing documentation when planning requests around exactly 200K tokens.
For illustration, 100,000 uncached input tokens plus 10,000 billed output tokens cost $0.26 at the lower rates, excluding tools and other charges. That is arithmetic, not an estimate of how many tokens your workflow will consume.
Grok 4.6 also launched at $2 input and $6 output per million tokens. Equal starting rates do not guarantee equal invoices: longer reasoning, extra calls, retries, and crossing a prompt-size threshold can alter the total.
These figures are the developer's direct API prices. For deployment through SeeAPI, check the platform's current model listing, billing rules, and supported parameters before budgeting.
API Details That Affect an Upgrade
The API identifier is grok-4.7. Its documented context window is 500K tokens, with text and image input and text output. Reasoning levels include low, medium, high, and xhigh; high is the default. The 4.6 release notes list the same context size, modalities, and reasoning levels, so these specifications are continuity rather than new features. The release notes also specify that the Responses API returns encrypted reasoning content even without an explicit include request.
For an integration, review how conversation state and response objects pass through your application. Test parsers, logging, and tool handling using actual responses before moving production traffic. Do not assume that changing the model identifier is the only relevant change.
Fast deserves separate consideration. The release notes describe it as the same model at double the token rates, available through Cursor and Grok Build rather than the public xAI API. Treat that access distinction separately from the standard model's API availability.
Should You Switch From Grok 4.6?
Start with a small set of assignments your current application finds difficult. Include successful examples as well as failures, so the evaluation can catch regressions instead of measuring only improvements.
Use the same source material, tools, and acceptance criteria. Compare matched reasoning settings first, then evaluate whether a higher setting earns its additional time or token usage. Record completion quality, total spend, elapsed time, and the amount of human correction needed.
For a coding workflow, require relevant tests to pass and review the diff. For document work, use a checklist of required facts and deliverables. Define success before seeing either answer.
Grok 4.7 is worth testing when incomplete verification or loss of context makes Grok 4.6 expensive to supervise. Keep the existing model where it already meets your requirements until the replacement demonstrates a useful gain. The strongest upgrade case is a better completed task at an acceptable total cost.






