Grok 4.7: from token prices to completed-task cost

A coding assistant can charge less per token while spending more on the task. It may read a repository repeatedly, generate several patches, run tools, or retry after a failing test. Grok 4.7’s release puts price and longer-running work together. To evaluate that combination, separate the model’s published results from your application’s request budget and acceptance criteria.

The September 21 announcement is the primary source for the release claims and comparison below. Consult the API documentation for the current integration interface. The arithmetic here is a planning example, not a Qentrah benchmark or a bill from a completed run.

What a longer-running agent has to do

The publisher describes a larger base model and a longer reinforcement-learning run, with training tasks weighted toward work that takes hours. It also reports improved verification and context management. These are claims about training and behavior; the announcement does not give enough architectural detail to reconstruct the model or calculate its training cost.

In a repository task, the agent needs to connect several decisions. It locates the relevant module, forms a hypothesis about the failure, edits the implementation, and checks the result. A passing unit test answers a narrower question than whether the user’s problem was solved. The surrounding application may still have a regression, an inaccessible control, or an incorrect migration.

Consider an illustrative request to fix a filter that drops items with a zero price. A convincing patch preserves zero as a valid value, handles absent prices separately, and checks both cases. An assistant that merely changes the visible result count has not established the behavior. This example supplies an acceptance rule before any model comparison begins.

Read one benchmark at a time

The announcement’s table reports the following CursorBench 4.0 scores. These are publisher-reported results for different models and effort settings. They measure performance on that evaluation, rather than success on every repository or a probability that any particular request will work.

Grok’s two reported scores differ by 5.9 percentage points. Relative to the earlier 40.4 value, the increase is approximately 14.6%. These two descriptions use different denominators. Neither establishes statistical significance: the comparison table does not supply the trial-level results or uncertainty required for that calculation.

The chart retains the percentage scale and starts at zero. It does not combine coding scores with ratings from office-work evaluations. Those axes describe different quantities, so averaging them would produce a number without a clear task meaning.

Publisher-reported results

Coding results at the published effort settings

Y Model and effortX CursorBench 4.0 (%)

Focus the graph and use arrow keys, or tap a point, to inspect values. The complete data table is available below.

View data table

Graph data table

Category	CursorBench 4.0 (%)
Grok 4.7 · xHigh	46.3
Grok 4.6 · High	40.4
GPT-5.6 Sol · Max	41.7
Fable 5.1 · Max	51.8

Calculate the request budget

The release lists starting prices of $2 per million input tokens and $6 per million output tokens. Let I and O be billable input and output token counts, and C be the token charge in US dollars. For the quoted rates:

$$C = \frac{2I + 6O}{10^6}$$

For an illustrative request with 100,000 input tokens and 5,000 output tokens:

$$\begin{aligned} C &= \frac{2(100{,}000)+6(5{,}000)}{10^6} \\ &= 0.20 + 0.03 = \$0.23 \end{aligned}$$

This estimate assumes those counts are entirely billed at the quoted rates. It excludes caching discounts, additional tool charges, infrastructure, taxes, and any tokens not included in the assumed billable counts. Check the actual usage fields and current pricing before treating the estimate as a spending limit.

Three agent steps need not repeat identical token counts. A conversation may grow, a cache may be reused, and tool results may add input. The repeated-count rows isolate how a budget scales; they are not measurements of an actual agent trajectory.

Count accepted tasks, including failures

For application planning, divide total experiment spend by the number of accepted outcomes. Let S be total cost in dollars and A the accepted-task count. When A is positive:

$$C_{\mathrm{accepted}} = \frac{S}{A}$$

Suppose ten independent task attempts cost $0.23 each and four satisfy a prewritten acceptance rubric. The total is $2.30, so the calculated cost per accepted task is $0.575, or about $0.58. If no task is accepted, this ratio is undefined. Reporting zero would erase the failure.

This hypothetical four-out-of-ten result is unrelated to CursorBench. Do not insert a published benchmark percentage into this budget equation as though it measured your own workflow. Record retries and abandoned attempts in S; otherwise the successful tasks appear cheaper than the experiment was.

Compare speed without changing the task

The publisher also offers a faster variant at twice the price and claims twice the output speed. Output speed is only one part of elapsed task time. Repository discovery, model prefill, test execution and waiting for external tools can dominate a run. Doubling one component’s speed cannot be assumed to halve the entire task’s duration.

Use the same repository revision, instructions, tool permissions and stopping rule for each comparison. Record time to first answer, total elapsed time, billable usage, accepted outcomes and failure causes separately. Review patches without the model label where practical. A small experiment can identify failure modes even when it cannot establish a universal ranking.

For deployment, start with a constrained task set and a recorded budget. Keep a human review step for changes that affect access, payments or stored data. Expand the workload when the evidence shows that the assistant handles both the intended change and the surrounding invariants. Qentrah has reviewed the linked release material; it has not reproduced the publisher’s model evaluations.