GPT-6.1 Sol: Cheap, Thorough at Code Review, but Uneven at Long Builds

Anthropic released Opus 5.5, and soon afterward OpenAI released GPT-6 Sol and Luna. Neither of those impressed me enough to make a video. But I also had early access to GPT-6.1 Sol, and I found it surprisingly capable and cheap. OpenAI asked me to wait for release before discussing it; I was not paid, and the company did not control my views.

My first warning is about the charts: I made mistakes in the first two Terminal-Bench runs, a medium run was missing, and the max run was incomplete. For unfinished or previously failed tasks, I was temporarily backfilling from x-high. The numbers are still changing, and running benchmarks myself has made me more skeptical of neat rankings.

In my DeepSWE comparison, Sol on low cost about $0.21 per task, Astra on low about $1.46, and Opus 5.5 on max about $14.65 for the same displayed score as Sol. That roughly 70-fold difference is striking, but DeepSWE is not a perfect measure of everyday coding and this is one particular configuration.

The quick succession of releases makes me suspect that Sol 6.1 is more than a small update. It seems smarter than Sol 6 and generates tokens more slowly, which I speculate could indicate a larger model. I cannot establish its architecture or OpenAI’s release plans from those observations.

I also discuss a post about changes to the $200 Pro subscription and estimate that the same plan may yield a lower API-equivalent dollar value than before. These are my calculations, not a guaranteed allowance; limits vary, and a subscription is not a cash balance.

At the prices I cite for launch, the model costs $2 per million input tokens and $10 per million output tokens. Cached input costs $0.10 per million, a 95% discount relative to ordinary input. For an agent repeatedly reading the same context, the cached rate can matter more than the headline rate.

I speculate that these prices and subscription adjustments reflect pressure on provider margins, and mention rumors of very high margins. Those numbers and the reasons for pricing are not verified financial facts. The actual cost of a workload depends on its mix of cached input, uncached input and output.

The Terminal-Bench chart updates as runs finish. I ran it on machines on my own network and removed three tasks that required an H100, so this is not the complete benchmark suite. Even strong results here should be considered alongside real work.

In my runs, the most expensive Sol 6.1 configuration cost around $1.38 per task, versus $5.12 for the cheapest Opus 5.5 configuration I tested. That cost gap makes it worth asking whether the model can handle the actual work for which I have been using Opus.

My frustration with Astra was inconsistency: it could be exceptionally capable, then suddenly make a surprisingly basic mistake. I had shifted much of my daily work to Claude models. In my experience, Sol 6.1 is less erratic, although it does not entirely eliminate the problem.

Its best moments are not quite as strong as Astra’s, and I would still put it below Opus 5.5 on some demanding tasks. For computer use it is not quite Astra, but it has been good enough for much of my daily work. That is my experience, not a guarantee of reliability.

For example, I had it find unpaid invoices and prepare browser tabs with investment-wire details for me to review and send. I report that it caught details I might have missed. Financial actions remain consequential, so my successful example does not remove the need to check recipients, amounts and authorization.

Other early testers described it as either incredible or boring, and I think boring can be a compliment when a model behaves consistently. At the edge of its abilities it can still act strangely, and I continue reaching for Opus on some work.

A strong use case for Sol is deep code review. In my Orchestrator V2 audit, its score was close to Astra’s at $2.97 versus $5.84. Sonnet and Opus cost less in that particular test, but I judged their analyses less thorough. The score is from my own audit setup, not a general guarantee.

I also asked models to find improvements in the T3 Code codebase. In that exercise I report a score of 87.4 for Sol, versus 83.8 for Astra and 80.7 for Grok 4.7. Sol cost about $2.15 for the run; my displayed comparisons for Opus and Sonnet were about $5 and $9. These are individual task results.

I asked Opus 5.5 to review the work without revealing the model’s identity. Its assessment called Sol strong at scoped investigation and finding problems, but weaker on long unattended builds. Its first code draft had real bugs, which review tools caught. This is a model’s assessment of my examples, not an independent evaluation.

My TypeScript-to-Rust port illustrates the difference. Sol 6.1 spent a long time and many tokens without improving the compiler, while I say Opus restarted the work and got it moving in about a day. Different attempts and starting conditions make this a useful case study rather than a controlled benchmark.

On managing my machine fleet, Sol made some mistakes; Opus also made mistakes, while Astra had made fewer of the particular mistakes I noticed. I nevertheless expect to use Sol much more, because of its combination of cost and investigation capability.

I asked Opus what it thought the model should cost before revealing the actual rates. It guessed higher prices and then described the launch pricing as aggressive. The exercise is illustrative of my sessions and a model-generated judgment, not evidence that prices will remain fixed or rise.

In the analyzed sessions, the agent estimated that repeated cached reads accounted for around 96% of input. It calculated roughly $1,550 at the cited rates instead of $5,700 at its initial guessed rates. That percentage and saving describe my workload; other traffic patterns may look very different.

Another comparison showed Sol making several rounds of progress with less context growth and fewer input tokens than the Sonnet run I compared. Context management and output length can affect total expense just as much as the price per token.

I also tested OpenRouter’s Jev Router on DeepSWE. In my run, it sent roughly 60% of requests to DeepSeek V4.1 Flash, took about 20 minutes per task and averaged 104 steps, versus 4.6 minutes and 19 steps for Astra low. I was disappointed, but the result concerns this benchmark and configuration.

Sol low reached the same displayed DeepSWE score as the router at about an eighth of the price in my test. It also matched the displayed Opus max score much faster and cheaper. I would still choose based on the kind of work: a small benchmark score does not capture every failure mode.

I expect to use Opus for longer implementation work and bring in Sol for investigation, root-cause analysis and reviewing what Opus produces. A combination can exploit different strengths, though it still needs verification and human decisions.

Then there is my fish game test. Sol produced attractive 3D fish, plants and a submarine, but surrounded them with interface text I found excessive. Compared with my Claude versions, the movement felt worse and the frame rate was lower, even though the visual detail was better.

I would not choose this output as a finished front end or game mechanic. Yet I was impressed by the model’s ability to make 3D assets using Blender, and I estimate the game cost about $5 to generate. I would be interested in asking another model to improve the gameplay while keeping the graphics.

During the early-access window I could not put its generated code into T3 Code or my other open-source projects, so I used it on internal projects and for audits. One real T3 Code pull request involved a worktree setup window that disappeared when switching away and back.

Sol found two problems I say other reviews had missed: follow-up messages could remain blocked after the agent started, and recovered setup progress could disappear too early. It used code analysis and computer use. I passed the findings to Claude, repeated the review cycle and ultimately merged after addressing the issues.

This is why I like the models together. Sol digs into details and reviews; Opus is, for me, a more pleasant collaborator and better at continuing an implementation without becoming stuck. Neither model’s output should be treated as correct just because another model reviewed it.

In the TypeScript-to-Rust project, I say Opus moved the result from 83.7% to 100% on the measure I was using in less than a day. When Sol audited that work, it noticed that roughly 1.3 million of 1.8 million lines were no longer used: Opus had rewritten the implementation in another crate while leaving the old material behind.

My conclusion is that Sol can be a strong default for scoped work and review, even if I still prefer Opus as a collaborator on larger implementations. I expect to use Sol to investigate code and review Opus’s work, while continuing my Claude subscriptions. My speculation that this release could signal the end of subscription subsidies is just that: speculation.