GPT-6.1 Sol Deep Dive: OpenAI Strikes Back at Opus 5.5 with Extreme Cost Efficiency

OpenAI's Lightning Counterpunch: From 6.0 to 6.1 in Just One Week

After Anthropic dropped the formidable Opus 5.5, the competition in AI coding models reached a boiling point. According to a deep-dive review by prominent tech YouTuber Theo (t3.gg), OpenAI launched GPT-6 Sol and GPT-6 Luna in rapid succession within a single week — but the release that truly shook the industry is GPT-6.1 Sol, now available to everyone.

Theo disclosed upfront that he received early access but no payment, and that OpenAI could only influence the timing of his video, not its content. That transparency matters, because the conclusions he reached are bold: the jump from 6.0 Sol to 6.1 Sol happened in just one week, yet the model is noticeably smarter and generates tokens more slowly (which typically signals a larger model). He suspects 6.1 Sol was never originally intended to ship as a minor version bump — there may be fundamental architectural differences under the hood.

In other words, this isn't a simple fine-tuning update. It's OpenAI going head-to-head against Opus 5.5.

Pricing That Defies Belief: A Signal That the Subsidy Era Is Ending

The most striking thing about 6.1 Sol isn't its intelligence — it's the price. It's listed at $2 per million input tokens and $10 per million output tokens, matching GPT-6 Sol but coming in at one-fifth the cost of Astra.

Even more significant is the cache read pricing. According to Theo, OpenAI had never touched its cache read price before — it had always been fixed at 10% of the standard read price (a 90% discount). This time, cache reads drop to $0.10 per million input tokens, a 95% discount, effectively cutting the cost of cached reads in half.

Why does that matter? Because in real agentic workloads, roughly 96% of requests are cache reads. Theo found in testing that 6.1 Sol averages about 110,000 tokens per request, compared to Sonic 5's 360,000. That combination of high token efficiency and rock-bottom cache pricing delivers absurd cost-effectiveness.

Theo also noticed that OpenAI's $200/month Pro subscription has returned, but the way usage is calculated has changed — the effective API credit value works out to about half of the old plan. He takes this as a signal that a thinner-margin model era may be arriving, with subsidy capacity declining. In his words: "This may genuinely mark the beginning of the end of the subsidy era."

---

The cache read mechanism is a key concept in LLM API billing. When users repeatedly pass the same prefix content across multiple requests — such as system prompts, codebase context, or lengthy documents — providers can store the KV cache (Key-Value Cache) for those tokens in VRAM or fast storage. Subsequent requests that hit the cache don't need to recompute attention, drastically reducing cost compared to a "cold" read. In agentic workflows, every tool call requires the full history context to be passed back into the model, meaning the vast majority of requests read the same prefix — which is exactly why Theo says "roughly 96% of requests are cache reads." Cache pricing therefore directly determines the real-world bill in production agent scenarios, far more than the nominal input token price. OpenAI dropping cache reads from 10% to 5% of standard price (a 95% discount) effectively halves costs again for high-frequency production agents — its practical impact far exceeds any adjustment to the base input price.

---

Benchmarks: Matching Opus at a Fraction of the Cost

Theo personally ran Terminal Bench 4 and Deep SWE on his own virtual machine, repeatedly cautioning that the testing environment was far from ideal (he even had to exclude tasks requiring an H100). The numbers were still striking:

• On Deep SWE, 6.1 Sol's scores on the Low and High tiers matched what Astra achieves on High, but at $0.21 per run on Low versus $1.46 for Astra;
• Opus 5.5 reaching the same score on the Max tier costs $14.65 — meaning 6.1 Sol is roughly 73x cheaper;
• On Terminal Bench, 6.1 Sol matched Opus 5.5's Max-mode performance at one-tenth the time and roughly one-seventh the cost.

Theo remained skeptical of benchmarks throughout, openly acknowledging that Deep SWE is far from a perfect measure of day-to-day coding ability. But the fact that you get "the same score for tens of times less money" is something the entire industry should pay attention to.

---

Terminal Bench and Deep SWE are two of the leading benchmarks for evaluating AI coding capability. Deep SWE is derived from SWE-bench and requires models to locate and fix bugs corresponding to real GitHub Issues in actual repositories — covering everything from understanding codebase structure to generating patches that pass unit tests. It's considered closer to real engineering practice than simple code completion tasks. "Low/High/Max tiers" typically correspond to the number of reasoning steps or tool-call budget the model is allowed during inference; higher tiers let the model spend more compute exploring solutions, yielding higher scores at proportionally higher cost. Terminal Bench focuses on executing multi-step tasks in a real terminal environment — file operations, code compilation, environment setup via the command line. Both benchmarks share a key limitation: they measure success rates on discrete, bounded tasks, and don't fully capture conversational collaboration, code review, or long iterative cycles in daily development — which is exactly why Theo repeatedly emphasizes they're "not a perfect standard."

---

Behavioral Stability: No More Astra's Random Misfires

Theo's biggest frustration with the GPT-6 family had been Astra's "brilliant and dumb" behavior — peak performance was stunning, but it would randomly make embarrassingly basic mistakes, with stability so poor he largely stopped using it.

6.1 Sol shows a marked improvement here. He says the model has "mostly fixed" Astra's issues, with stability "so much better it's not even close." He even felt comfortable letting it comb through all his emails, identify overdue invoices, and pre-fill wire transfer information in Chrome for each investment — "didn't get a single thing wrong" — a task he would never have trusted Astra with.

Other testers corroborated this. Theo relays that Julius, who also had early access, called it "incredibly good," while Ben described it as "boringly impressive" — and for a model launch, "boring" is high praise for stability. The tradeoff is that peak performance isn't as revolutionary as Astra's best moments, and computer use capability is slightly weaker, but the gap is small enough that Theo chose it without hesitation for day-to-day work.

Where It Shines: Deep Code Review, Not Long Autonomous Builds

Theo used a vivid analogy: OpenAI models have a "Rottweiler quality" — they sink their teeth into a problem and refuse to let go, digging and tearing until every flaw is exposed. 6.1 Sol's code review capability is impressive.

In one experiment where Theo had Opus 5.5 evaluate the model blind (he later edited the conversation history to hide the model's identity), Opus quickly judged it as "a frontier-level model" and gave 6.1 Sol a score of 87.4, ranking it first in a 10-model blind code review benchmark. In real testing, 6.1 Sol also caught a genuine bug that both Fable and Opus had missed, successfully preventing a regression-introducing merge.

But 6.1 Sol has a clear weakness. On a long-horizon task rewriting TypeScript to Rust, it "burned a huge pile of tokens and made no progress" — rigidly following its process, getting stuck, and never asking for help. Opus 5.5, by contrast, could start from scratch and have things running within a day. According to Theo, Opus "leads by an absurd margin" on these kinds of heavy, unattended rewrites.

---

The "long agentic loop" rewrite task Theo describes represents a special challenge for AI coding assistants: the model must autonomously plan and execute dozens or even hundreds of steps without real-time human intervention — reading code, formulating a migration strategy, rewriting files one by one, fixing compilation errors, and ultimately validating results through a test suite. This demands extreme robustness — not just intelligence, but the ability to recognize when it's stuck in a dead end and adjust strategy (i.e., "self-recovery"), rather than rigidly following a predetermined process. A TypeScript-to-Rust migration is especially demanding because the two languages differ fundamentally in memory model, ownership system, and type system — mechanical translation is nearly impossible, and major architectural decisions must be remade throughout. 6.1 Sol's failure here — "burning tokens without asking for help" — suggests its metacognitive awareness in uncertain states (knowing when it's stuck) is still weaker than Opus 5.5's.

---

Weaknesses: Frontend and UI Are a Disaster

In Theo's "Fish Slap" fun test, 6.1 Sol's fish tank game exposed serious problems: visual fidelity was actually higher (plants, tank grime, and other details were impressive), but the UI was cluttered with unnecessary text, movement felt laggy with poor frame rates, and the game randomly triggered a game-over screen without warning.

Theo was blunt: "This model is terrible at frontend. It's bad at design. It has no aesthetic sense." If you need a model that can produce decent UI, don't spend your money here. That said, it performed reasonably well at Blender 3D modeling — given a screenshot, it produced a solid model through the CLI.

Verdict: A Strong Candidate for Default Coding Model, But Opus Remains the Better Collaborator

Theo's overall assessment is clear and measured: 6.1 Sol is a perfectly viable default coding model for many developers, performing at a frontier level for well-scoped tasks at an almost unbelievable price point.

His recommended setup is having Opus 5.5 actively call 6.1 Sol — Sol handles investigation, root-cause analysis, codebase exploration, and reviewing Opus's work, while Opus handles actual code implementation and long-horizon builds. He finds Sol stronger at deep review and excavation, while Opus is "a more pleasant collaborator" — noticeably better at implementation and less prone to getting stuck.

Amusingly, when Opus was asked what price this model should carry, it guessed something comparable to itself ($5 input / $30 output). Upon learning the actual price — $2 input / $10 output — Opus called the pricing "very aggressive" and predicted the price "will go up in the future."

For everyday developers, Theo's advice is practical: if your work falls within 6.1 Sol's capability range, hand everything to it; if not, stick with Opus and let Opus call Sol for triage and review. This is an excellent release — but it hasn't knocked Opus off the top spot. At least not yet.