Evidence checked September 22, 2026. Prices are direct API rates in US dollars. This is an analysis of published evidence; Kingy ran no paid benchmark tests.
GPT-6 Sol and Grok 4.7 both start at $2 per million ordinary input tokens. That looks like a straightforward price comparison until you look at the rest of the bill. Grok charges less for output. Sol charges less for cached input. Long prompts trigger different pricing thresholds. And the effort setting can change how many tokens an agent spends before it finishes.
My starting recommendation is Sol high for an existing OpenAI coding workflow, with Grok high worth considering when output costs dominate and your tools already support it. For sessions that repeatedly read a large cached prefix, Sol’s lower cache-read rate deserves particular attention. Neither choice is a demonstrated overall winner over the other in the published evidence reviewed here.
There is a reason for that qualification: the current CursorBench table includes GPT-5.6 Sol, not GPT-6 Sol. A Grok result against the older model cannot be relabeled as a win against the new one. This comparison keeps that distinction visible while working through the decisions we can support. Cursor’s live evaluation table.
Specs and prices that affect the decision
| Detail | GPT-6 Sol | Grok 4.7 |
|---|---|---|
| API model ID | gpt-6-sol |
grok-4.7 |
| Context window | 1,050,000 tokens | 500,000 tokens |
| Input and output | Text/images in; text out | Text/images in; text out |
| Ordinary input, per 1M tokens | $2 | $2 |
| Cached input, per 1M tokens | $0.20 | $0.50 |
| Output, per 1M tokens | $10 | $6 |
| Reasoning settings | none, low, medium, high, xhigh, max | low, medium, high, xhigh |
| Default effort | medium | high |
Sources: OpenAI’s Sol reference, Grok’s model reference.
These are standard short-context rates. Sol also lists cache writes at $2.50 per million tokens. Its input and cache rates double, and output rates rise by 50%, when a request exceeds 272,000 input tokens. Grok’s pricing table places requests at or above 200,000 prompt tokens in a $4 input, $1 cached-input and $12 output tier. In both cases, the higher tier applies to the whole request. Sol pricing conditions, xAI pricing.
The larger Sol context window gives it room for requests that cannot fit in Grok’s advertised window. It does not establish better understanding of a long document. Capacity, retrieval accuracy and the ability to finish a useful task are separate questions.
What the published effort curves show
Effort names are not a common unit of compute. Sol medium and Grok medium can spend very different amounts of time and tokens. Grok also has no max setting in its current API reference, while Sol exposes both max and none. Use the supported setting names and compare the resulting work and bill.
Grok 4.7 on CursorBench 4.0
Cursor evaluates ambiguous, multi-file coding tasks. Its current Grok rows show:
| Grok effort | Score | Average cost per task | Reported tokens per task | Steps per task |
|---|---|---|---|---|
| Low | 33.1% | $1.58 | 15,677 | 40 |
| Medium | 41.6% | $3.49 | 36,683 | 60 |
| High | 43.9% | $4.69 | 56,382 | 71 |
| Xhigh | 46.3% | $6.01 | 70,141 | 88 |
Source: CursorBench 4.0. Cursor calculates cost from the tokens used and published rates. Its displayed token column should not be treated as a complete invoice breakdown or multiplied by one rate to reproduce the total.
Moving from medium to high adds 43.9 − 41.6 = 2.3 percentage points while cost rises by ($4.69 − $3.49) ÷ $3.49 = 34.4%. High to xhigh adds 2.4 points and ($6.01 − $4.69) ÷ $4.69 = 28.1% more cost. The highest setting buys a higher observed score here, but the extra spend still needs to earn its place in your workflow.
Cursor develops and distributes Grok products, so this is a useful platform-published evaluation with a commercial relationship to the model. It is not an entirely unaffiliated test. Cursor also warns that small score differences may not be statistically meaningful. CursorBench methodology, Grok’s launch and distribution details.
GPT-6 Sol on DeepSWE v1.1
OpenAI publishes a five-setting curve for repository coding on DeepSWE v1.1:
| Sol effort | Score | Published cost per task |
|---|---|---|
| Low | 37.2% | $0.16 |
| Medium | 56.6% | $0.38 |
| High | 65.3% | $0.64 |
| Xhigh | 66.6% | $1.00 |
| Max | 68.8% | $2.74 |
Source: OpenAI’s September 22 coding charts. These rows are a separate evaluation from the Cursor table above. Their scores and dollar amounts cannot be compared across the two tables as though they describe the same tasks.
Sol’s medium-to-high step adds 8.7 points for ($0.64 − $0.38) ÷ $0.38 = 68.4% more cost. Xhigh to max adds 2.2 points, while cost rises by ($2.74 − $1.00) ÷ $1.00 = 174%. That makes high and xhigh sensible starting candidates for coding whose output you can check. Max needs a harder task or a demonstrated gain to justify its bill.
Our Sol vs Astra effort comparison covers the same Sol curve alongside a more expensive OpenAI option.
Where the two models still lack a matched comparison
xAI’s launch table reports Grok 4.7 at 71.0% on DeepSWE v1.1, explicitly marked as high effort. OpenAI reports Sol max at 68.8%. Those are two vendor-published results with the same benchmark name, but the reviewed sources do not establish an identical agent setup, task execution or accounting method. The numerical difference is 71.0 − 68.8 = 2.2 points; it is not enough to award a controlled head-to-head win. xAI’s table and high-effort footnote, OpenAI’s coding results.
Artificial Analysis supplies another useful perspective. It reports 73% DeepSWE for Grok 4.7 xhigh in Grok Build, with 33% Terminal-Bench 4.0 in that agent setup. Its article distinguishes those native-agent results from its standardized Intelligence Index. That distinction matters: changing the surrounding agent can change the outcome. Those results are additional Grok evidence, not a substitute for a matched GPT-6 Sol run. Artificial Analysis’s Grok evaluation.
Worked costs: when each model is cheaper
The following examples use fixed, hypothetical token counts to isolate pricing. They include billed reasoning in the stipulated output totals and exclude separately billed tools, taxes, regional premiums and discounts. Equal token counts do not predict equal token usage on a real job. OpenAI’s reasoning billing, xAI’s reasoning documentation.
1. One uncached request
Assume 100,000 ordinary input tokens and 10,000 output tokens, below both long-context thresholds:
- Sol: 0.100 × $2 + 0.010 × $10 = $0.20 + $0.10 = $0.30.
- Grok: 0.100 × $2 + 0.010 × $6 = $0.20 + $0.06 = $0.26.
- Grok’s saving: ($0.30 − $0.26) ÷ $0.30 = 13.3%.
Grok’s output rate is 40% lower, but this whole request is only 13.3% cheaper because the shared input charge makes up much of the bill.
2. A follow-up against an already warm cache
Assume 100,000 cache-read tokens, 10,000 ordinary new input tokens and 2,000 output tokens:
- Sol: 0.100 × $0.20 + 0.010 × $2 + 0.002 × $10 = $0.02 + $0.02 + $0.02 = $0.060.
- Grok: 0.100 × $0.50 + 0.010 × $2 + 0.002 × $6 = $0.05 + $0.02 + $0.012 = $0.082.
- Sol’s saving: ($0.082 − $0.060) ÷ $0.082 = 26.8%.
These are subsequent-request costs. They deliberately exclude the earlier cache fill and assume the cache hit succeeds. For a complete session, add that startup bill and any cache refreshes. For example, a separately billed 100,000-token Sol cache write costs 0.100 × $2.50 = $0.25, replacing the ordinary-input charge for those write tokens rather than being added on top of it. OpenAI prompt caching.
3. A request between the two long-context thresholds
Take 250,000 ordinary input tokens and 10,000 output tokens. Sol remains in its standard tier. Grok is in its long-context tier:
- Sol: 0.250 × $2 + 0.010 × $10 = $0.50 + $0.10 = $0.60.
- Grok: 0.250 × $4 + 0.010 × $12 = $1.00 + $0.12 = $1.12.
- Grok ÷ Sol: $1.12 ÷ $0.60 = 1.87 times the cost.
Now increase the request to 300,000 input tokens and 20,000 output tokens, putting both models in their higher tiers:
- Sol: 0.300 × $4 + 0.020 × $15 = $1.20 + $0.30 = $1.50.
- Grok: 0.300 × $4 + 0.020 × $12 = $1.20 + $0.24 = $1.44.
The cost order changes again. A model-selection rule based only on the ordinary input price misses this entirely. Sol rate conditions, Grok rate conditions.
A useful break-even rule for cached work
For a short-context request with equal ordinary-input counts, no new cache writes and the same output length, those ordinary-input costs cancel. Let R be cache-read tokens in millions and O be billed output tokens in millions:
Grok cost − Sol cost = ($0.50 − $0.20)R + ($6 − $10)O = $0.30R − $4O.
The prices break even when R ÷ O = 4 ÷ 0.30 = 13.33. Under these assumptions, more than about 13.3 cached tokens for each output token favors Sol. Fewer favors Grok.
This is a billing rule, not a quality rule. Different tokenization, reasoning volume, cache hit rates, tool calls and retries can overturn the equal-count assumption. Its practical use is to explain why a writing-heavy job and a repeated repository-context job can favor different providers.
Recommendations by workload
| Your workload | Starting choice | Reason and limit |
|---|---|---|
| Existing OpenAI coding workflow | Sol high; examine xhigh when needed | Its own coding curve supports those candidates, and staying with working tools avoids a migration based on an unmatched score. |
| Output-heavy work with modest prompts | Grok high | The $6 output rate creates a clear fixed-token advantage. Confirm that extra reasoning does not consume it. |
| Many follow-ups reading the same cached context | Sol medium/high | Its cache-read rate is lower; include the initial fill and actual cache-hit rate. |
| Requests around 250K input tokens | Sol on token pricing | Grok has crossed its long-context threshold while Sol has not. |
| Requests exceeding Grok’s context capacity | Sol, if the complete request fits its limits | More capacity is useful, but it does not guarantee reliable retrieval. |
| Hard coding where completion matters more than token rates | Keep both on the shortlist | The reviewed evidence does not establish an equal-setup GPT-6 Sol–Grok winner. |
For Grok, I would start with high and move to xhigh only when the added work is useful. For Sol, I would start with high for coding and compare medium for simpler jobs. Those are editorial starting points from published evidence, not Kingy test results.
Choose using the complete cost of accepted work: tokens, tools, failures and review time. A few cents saved on an attempt can disappear if it needs a second run. Our cost-per-successful-job guide explains that denominator, while the Grok 4.7 overview covers its wider launch evidence.
Evidence notes
All tables preserve the model version, publisher, benchmark and effort label. Cursor’s four Grok settings and OpenAI’s five Sol settings are presented separately because they describe different evaluations. Missing paired results remain missing. Calculations use displayed, rounded prices and scores; small score differences are not treated as statistically proven advantages.
Direct API prices also differ from the effective cost of using a subscription app or a third-party platform. Sol’s reference lists Batch and Flex at half Standard rates; Grok’s model page currently says Batch API is unsupported. Those choices require their own availability and latency comparison. Check the provider rate cards before applying these examples to a different route.