Grok 4.7: Same Token Price, Higher Cost per Task
Grok 4.7 is a disappointment. It is not a bad model, and on coding agents it is a genuinely better one, but as a general upgrade over Grok 4.6 it is hard to justify: in the current independent measurements it costs more per finished task, scores two points higher on the aggregate index, and decodes slower. That is the finding, and the rest of this post is the evidence behind it.
xAI released Grok 4.7 on September 21, 2026, and kept the headline API rates identical to Grok 4.6: $2 per million uncached input tokens, $0.50 for cached input, and $6 for output. The model has a 500,000-token context window, accepts text and images, and offers low, medium, high, and xhigh reasoning with high as the default. Once a prompt reaches 200,000 tokens, the rate card switches to $4 input, $1 cached input, and $12 output for the whole request. [1] [2]
The rate card staying flat is the easy part. The number that matters is what it costs to finish a piece of work, and there 4.7 loses to its own predecessor. In the current Artificial Analysis comparison, Grok 4.7 high and xhigh both round to an Intelligence Index score of 46, against 44 for Grok 4.6 at the same effort levels. high uses about 66,000 output tokens per task and costs $2.73, where 4.6 high costs $1.86. xhigh uses 81,000 output tokens and costs $3.74, where 4.6 xhigh costs $2.32. On output speed, 4.7 runs at 52 tok/s at high and 40 at xhigh, against 64 and 65 tok/s for 4.6. So the new model burns roughly half again as much, gives back two index points, and generates more slowly. That is a worse deal in every dimension except the one the launch was built around.
That one exception is coding. Grok Build with Grok 4.7 xhigh moves from 47 to 56 on the Coding Agent Index when compared with Grok 4.6 xhigh. DeepSWE rises from 65% to 73%, Terminal-Bench from 18% to 33%, and SWE-Atlas-QnA from 58% to 63%. Average token use jumps from 5.5 million to 14.3 million per task, cost from $3.57 to $8.82, and time from 19.5 to 39.2 minutes. The extra inference bought real gains, and the bill went with it. If coding agents are all you need, 4.7 earns its price. For everything else, the upgrade is thin.
The price of a token stayed flat. The amount of inference used to finish difficult work did not.
The rate card did not move
The short-context rate card is the same as Grok 4.6’s, and the long-context threshold applies to every token in the request once the prompt hits 200k, not just the tokens past the threshold. [2]
| Model | Input / 1M | Cached input / 1M | Output / 1M | Long context (>= 200k prompt) |
|---|---|---|---|---|
| Grok 4.7 | $2.00 | $0.50 | $6.00 | $4 input, $1 cached, $12 output |
| GPT-6 Luna | $0.10 | $0.01 | $0.50 | $0.20 input, $0.02 cached, $0.75 output |
| GPT-6 Sol | $2.00 | $0.20 | $10.00 | $4 input, $0.40 cached, $15 output |
| GPT-6 Astra | $10.00 | $1.00 | $50.00 | $20 input, $2 cached, $75 output |
| Claude Opus 5.5 | $4.00 | $0.20 | $20.00 | No surcharge at 1M context |
| Claude Fable 5.1 | $10.00 | $0.25 | $50.00 | No surcharge at 1M context |
The comparison rows are standard base rates, not statements about total task cost. OpenAI’s GPT-6 family changes rates past 272k input tokens, Anthropic charges for cache writes, and xAI’s own tools are billed separately. xAI’s pricing page lists server-side web search at $5 per 1,000 calls, X search at $5 per 1,000 posts and $10 per 1,000 profiles, code execution at $5 per 1,000 calls, and file attachment search at $10 per 1,000 calls. Every tool call also carries the model’s own token cost.
A few more xAI-specific details matter for a bill. The US regional endpoint runs inference in the United States at a 10% premium. Grok 4.7 Fast is the same model on faster infrastructure at twice the token rates, available only in Cursor and Grok Build rather than the public API. Priority processing is another 2x multiplier. None of that is a reason to avoid the model. It is a reason to know which endpoint and tier the request is landing on. [1] [2]
Reasoning effort is a second price dial
Grok 4.7 cannot disable reasoning. The reasoning_effort setting controls how much thinking the model does before it answers, and the reasoning tokens are billed as output. xAI describes low as latency-sensitive agentic use, high as the default for challenging problems, and xhigh as maximum reasoning depth for the hardest work. [3]
Artificial Analysis ran both settings through the same Intelligence Index v4.3.2:
| Grok 4.7 setting | Intelligence Index | Output tokens / task | Reasoning tokens / task | Output speed | Cost / index task |
|---|---|---|---|---|---|
high | 46 | 66k | 47k | 52 tok/s | $2.73 |
xhigh | 46 | 81k | 59k | 40 tok/s | $3.74 |
The cost-per-task figure is a weighted average across the ten evaluations in the index, calculated from input, cache hit, cache write, reasoning, and answer token prices. Moving from high to xhigh adds 15,000 reasoning tokens, 15,000 answer tokens, and 20% more wall time per task. [10]
The same comparison puts Grok 4.6 high at 44 with 36,000 output tokens per task and $1.86, and Grok 4.6 xhigh at 44 with 38,000 output tokens and $2.32. So the generation-to-generation story is not that 4.7 is a cheaper model. It is that 4.7 xhigh more than doubles the output volume of 4.6 xhigh while the per-token rate stays flat, for two extra index points and a slower decoder. [10]
Here is the same comparison as cost per Intelligence Index task, reconstructed from the release page. It is a dated snapshot of a live comparison, not a forecast. [10]
%%{init: {"xyChart": {"showDataLabel": true, "showDataLabelOutsideBar": true}}}%%
xychart-beta
title "Artificial Analysis cost per Intelligence Index task (USD)"
x-axis ["4.6 low", "4.6 medium", "4.6 high", "4.6 xhigh", "4.7 high", "4.7 xhigh"]
y-axis "USD / task" 0 --> 4
bar [0.48, 1.50, 1.86, 2.32, 2.73, 3.74] The two Grok 4.7 bars are the headline. The four Grok 4.6 bars show that the 4.6 model is still available at a lower cost, with a lower score, and 4.6 low at $0.48 is only worth it for work where an index score of 35 is enough.
The speed numbers need a footnote. The same Artificial Analysis page reports 52 tok/s for high and 40 tok/s for xhigh on its standard workload. Its launch article separately reports about 188 tokens per second for Grok 4.7 xhigh on long prompts. Different prompt shapes, different measurement. xAI’s own announcement says 4.7 is served at the same speed as 4.6 and that the Fast variant is twice as fast. [5] [8]
Cost per completed task
None of the public evaluations I found provides the metric a buyer actually wants: how often a developer has to step in, how long they spend fixing the result, and how many retries happened before acceptance. I am not going to turn a benchmark percentage into a “human intervention rate.” A 73% DeepSWE score says the agent passed 73% of that suite under that harness. It does not say how often a real repository needed a rescue.
The metric I would log is cost per accepted task:
model_cost =
uncached_input_tokens * input_rate
+ cached_input_tokens * cached_input_rate
+ output_tokens * output_rate
+ cache_write_cost
+ tool_cost
task_cost =
sum(model_cost for every attempt)
+ fallback_model_cost
+ human_minutes * loaded_human_cost_per_minute
cost_per_completed_task =
sum(task_cost) / number_of_accepted_tasks A failed attempt is not free, and neither is a refusal. If the model declines, falls back, or leaves the repository half-changed, those events belong in the denominator and the numerator, not in a footnote. Human minutes are the hardest number to collect and the one most likely to be ignored, which is why I would start logging them by hand before automating anything.
Artificial Analysis’s Coding Agent cost metric is a useful middle ground. It prices the agent’s own API calls, including cache reads, cache writes, and output, and it explicitly excludes infrastructure, engineering, and supervision costs. [12] The Grok Build numbers below are that metric, not my estimate of a production bill.
Coding agents
Grok Build with Grok 4.7 xhigh is a clear improvement on the Coding Agent Index:
| Grok Build model | Coding Agent Index | DeepSWE v1.1 | Terminal-Bench 4.0 | SWE-Atlas-QnA | Tokens / task | Cost / task | Time / task |
|---|---|---|---|---|---|---|---|
Grok 4.6 xhigh | 47 | 65% | 18% | 58% | 5.5M | $3.57 | 19.5m |
Grok 4.7 xhigh | 56 | 73% | 33% | 63% | 14.3M | $8.82 | 39.2m |
Grok Build used a 94% cache hit rate on the 4.7 run, so the bill is not the result of a cold cache. It is the result of 2.6 times the tokens. [12]
xAI’s own launch table reports DeepSWE v1.1 at 71% for 4.7 xhigh and 65.2% for 4.6 high, with Terminal-Bench 4.0 at 37.6% versus 20.3% and AA Briefcase at 1,657 versus 1,546. Those are first-party numbers from xAI’s harness. The Coding Agent Index numbers come from Artificial Analysis using Grok Build as the harness. The two are not interchangeable, and the gap between them is exactly why I would not treat any single table as the answer. [8] [9]
The wider system-level comparison is more useful for choosing what to test first. These are agent-plus-model results from the same Coding Agent Index, so the harness, tool policy, retries, and context management all contribute:
| Coding-agent system | Index | Tokens / task | Cost / task | Time / task |
|---|---|---|---|---|
Codex + GPT-6 Astra max | 62 | 3.3M | $7.47 | 29.4m |
Codex + GPT-6 Sol max | 57 | 9.8M | $2.99 | 22.3m |
Grok Build + Grok 4.7 xhigh | 56 | 14.3M | $8.82 | 39.2m |
Codex + GPT-6 Luna max | 41 | 10.2M | $0.18 | 21.4m |
Codex with Sol is one index point above Grok Build with Grok 4.7 at roughly a third of the API cost and half the wall time. Astra buys five points over Sol for 2.5 times the API cost, which only makes sense if a failed task is expensive. Luna is cheap enough to run in volume, but the 41 shows where the capability floor sits. [13] [12]
For model-only context, Artificial Analysis’s Intelligence Index comparison puts Claude Opus 5.5 at xhigh with fallback on 56 at $3.46 per task, against Grok 4.7 xhigh at 46 and $3.74. That run includes Anthropic’s default server-side fallback, which served about 4% of output tokens in the Fable 5.1 evaluation and a similar share here. [11] [14] I covered the full Opus and Fable comparison in an earlier post, and the GPT-6 family in another. The short version is unchanged: a lower token rate does not make a model cheaper per task, and a higher token rate does not make it more expensive per accepted result.
How to run the comparison
The vendor tables tell you which configurations deserve a test. Your own harness tells you which one ships. I would use three fixed workloads:
- A small code edit with a test that passes or fails. This is the most common production task and the easiest one to accept or reject automatically.
- A multi-file repository change with a clear spec and a hidden set of checks. This is where the agent harness, context management, and retry policy start to matter.
- A document-analysis task with a rubric: extract the right numbers, cite the right passages, and produce a deliverable a human would send. This is closer to the knowledge-work benchmarks that drove 4.7’s AA-Briefcase gain.
The starting protocol is 30 runs per task. That is not a statistically rigorous sample size. It is a starting point that catches the large differences before you spend a week measuring small ones. Hold the harness fixed, change one thing at a time, and run each configuration at high and xhigh so the effort dial is part of the experiment rather than a default you inherited.
For every run, record:
- first-attempt success
- retry count and fallback rate
- safeguard and refusal events
- human intervention: did a person have to finish, correct, or revert the result, and how many minutes did that take
- uncached input, cached input, cache writes, reasoning tokens, answer tokens, and tool calls
- final cost per accepted task
The result is a table you can actually route on:
flowchart TD
start[Choose a fixed workload] --> run[Run 30 attempts at high and xhigh]
run --> check{Accepted without human edits?}
check -->|Yes| accepted[Count one accepted task]
check -->|No| inspect[Record retries, refusals, and correction time]
inspect --> retry{Fallback or retry helped?}
retry -->|Yes| retry
retry -->|No| abandon[Count the spent cost against zero accepted tasks]
accepted --> total[Sum model, tool, and human cost]
abandon --> total
total --> next[Compare cost per accepted task]
next --> route[Promote xhigh only where acceptance improves enough] Log the usage fields the API returns rather than inferring them. xAI’s docs say reasoning tokens are billed as output and that cache hits are reported separately. If a cached_tokens field is consistently zero, something is wrong with the conversation routing, not with the model. [3] [4]
Caching, latency, and safeguards
Prompt caching is the cheapest lever in a Grok deployment. xAI caches matching prefixes automatically and recommends a stable prompt_cache_key on the Responses API or the x-grok-conv-id header on Chat Completions. Earlier messages should stay unchanged, system prompts and reference documents belong at the front of the conversation, and cache hits are not guaranteed because entries can be evicted at any time. The docs are explicit about logging cached_tokens and designing the application to work when the cache is cold. [4] [5]
Long-running agents accumulate history. xAI’s context compaction replaces a large conversation with a single opaque item that preserves the salient state and drops verbose tool output. You pass that item back verbatim on the next request. The compaction call itself costs tokens, so a once-every-N-turns policy based on your own token count makes more sense than compacting on every turn. [6]
For sequential agent loops, xAI’s WebSocket mode keeps the prior response state on an open socket so each turn sends only the new items. xAI reports up to about 20% lower end-to-end latency in its own internal benchmarks against repeated HTTP requests with the same chaining. That is a vendor number on a vendor workload, not a guarantee for your rollout, but the mechanism is real and the connection limit of 25 minutes is worth designing around. [7]
On safeguards, xAI says 4.7 uses a new safeguard stack and reports that it allows 3.3% of risky dual-use prompts through on HackerBench v0.3 while rarely blocking legitimate security work. It also describes a much lower refusal rate on benign cyber tasks than earlier models. These are first-party numbers on a first-party benchmark, and the appropriate response is to test refusal behavior on your own traffic rather than to treat the 3.3% as your expected rate. [8]
The reviewed xAI API material does not document an Anthropic-style automatic model fallback. Treat a refusal or a failed attempt as an application-level event and decide yourself whether to retry, route to another model, or ask a person. Anthropic’s default server-side fallback is a useful counterexample: in Artificial Analysis’s Fable 5.1 run it served about 4% of output tokens, which is part of why the published cost per task is what it is. [14] xAI’s Responses API does return encrypted reasoning on every 4.7 response whether or not you ask for it, and passing those reasoning items back unchanged preserves the model’s thinking across turns. That is conversation state, not fallback, and it is worth handling correctly. [3]
Where I would start
For Grok itself, high is the sensible starting point. In the current independent measurement it reaches the same rounded Intelligence Index score as xhigh at about 27% lower cost, with fewer tokens and faster decoding. Promote to xhigh only where a workload-specific evaluation shows that the extra inference materially improves acceptance. The benchmark component scores that justify the promotion are on the table: AA-Briefcase, GDPval-AA, and the coding-agent components. If your tasks do not look like those, the index is not the evidence you need. [9] [10]
For coding agents, I would test Codex with Sol first. In the current system-level benchmark it sits one point above Grok Build with 4.7 at roughly a third of the API cost, and the routing post lays out the effort settings and three scenarios in more detail. Luna belongs in high-volume work where the capability floor is acceptable. Astra earns its rate when a failed task costs more than the tokens. [13]
Claude Opus 5.5 is worth testing when Grok’s low token rate is eaten by retries or long rollouts. Artificial Analysis gives its xhigh configuration a higher Intelligence Index score than Grok 4.7 xhigh, and Anthropic’s cache reads are cheap. Fable 5.1 remains considerably more expensive per token and, in the same independent run, more expensive per task. The full comparison is here. [11]
The pattern across every model on this page is the same. Price per token tells you what one million tokens cost. It does not tell you what a finished task cost, how long it took, or how often a person had to step in. Grok 4.7 makes the gap unusually visible because the rate card stayed flat while the token count moved. Measure the whole thing before you route a dollar.
Sources
Sources checked September 25, 2026. I did not run new paid xAI, OpenAI, or Anthropic calls. Where a public source did not disclose a value, such as a real-world human intervention rate, it is left unspecified rather than estimated.
xAI primary
- xAI API: Grok 4.7 model page
- xAI API: Pricing
- xAI API: Reasoning
- xAI API: Prompt caching
- xAI API: Prompt caching best practices and FAQ
- xAI API: Context compaction
- xAI API: WebSocket mode
- xAI: Introducing Grok 4.7
Artificial Analysis
- Artificial Analysis: Benchmarking Grok 4.7
- Artificial Analysis: Grok 4.7 vs Grok 4.6 release comparison
- Artificial Analysis: Claude Opus 5.5 vs Grok 4.7 release comparison
- Artificial Analysis: Grok Build vs Muse Code
- Artificial Analysis: Claude Code vs Codex
- Artificial Analysis: Claude Fable 5.1 tops the Intelligence Index