GPT-6 Sol vs. Luna vs. Claude Opus 5.5: Which Should You Use?

September 22 was one of those AI release days where you open your laptop, blink, and suddenly your entire model picker needs an explanation.

Anthropic launched Claude Opus 5.5. OpenAI followed the same afternoon with GPT-6 Sol and GPT-6 Luna. All three arrived cheaper than the models they replace, all three claim meaningful performance gains, and all three landed in the middle of a model market where “which AI is smartest?” is becoming a surprisingly bad way to choose one.

So Corey Noles and I did what any responsible AI publication would do.

We asked them both to rebuild Doom with cats.

Watch our full GPT-6 Sol, Luna, and Claude Opus 5.5 livestream

The more useful conclusion from our testing had very little to do with Cat Doom, though. The biggest change here is that frontier-level AI is getting cheap enough that you can start routing different parts of a job to different models instead of searching for one model to rule them all.

The short version: which model should you use?

Here’s our starting map after digging through the launches and testing them live:

• GPT-6 Luna: Start here for high-volume, well-defined work like extraction, summarization, quick questions, repetitive automations, and cheaper subagents.
• GPT-6 Sol: The strongest default when you want serious coding, agents, research, or professional work without paying flagship prices.
• Claude Opus 5.5: Worth testing for long, messy coding jobs, reviews, complex knowledge work, and projects where Claude’s style of interpreting your intent works better for you.
• GPT-6 Astra: Keep it for the hardest planning, reviewing, computer-use, and high-value work where another jump in quality is worth paying for.

That last part matters.

The workflow Corey described on the livestream looks less like choosing an AI and more like managing a tiny AI company:

Astra plans → Sol does the work → Luna handles cheap subtasks → Astra reviews

Watch Corey explain the planner-worker-reviewer setup at 19:00

We’ve been moving toward this setup for a while in our own work. Our GPT-6 Astra workflow guide already focused heavily on giving agents clear autonomy and verification rules. These cheaper models make that architecture far more economical.

GPT-6 Sol and Luna turned model day into price-cut day

OpenAI cut the standard API prices for both models by 50% compared with their GPT-5.6 promotional pricing:

GPT-6 Sol

• $2 per million input tokens
• $10 per million output tokens

GPT-6 Luna

• $0.10 per million input tokens
• $0.50 per million output tokens

OpenAI still positions Astra as its most capable model, but Sol and Luna are explicitly designed to spread much of that generation’s capability down the price curve. (OpenAI)

The raw price comparison is almost comical. Sol is exactly half Opus 5.5's $4 / $20 token price. Luna is 2.5% of Opus 5.5's rate and 1% of Astra's $10 / $50 pricing.

OpenAI researcher Noam Brown pointed out that Luna's output price fell from $6 to $0.50 per million tokens in roughly two months. Sam Altman said Sol and Luna beat their GPT-5.6-family predecessors across intelligence, alignment, work output, coding, and computer use while costing half as much per token.

OpenAI product lead Tibo Sottiaux framed the point less as "cheap models" and more as making high-end intelligence viable for workloads that previously did not make economic sense. That is exactly why model routing suddenly matters so much.

The rollout itself was still messy on launch day. Early users were seeing the new models in Codex while others reported uneven availability. Reuters and TechCrunch both treated the same-day releases as a new round of price competition between the labs.

OpenAI also published a separate GPT-6 prompt-caching deep dive on launch day, and it changes the economics more than the sticker price alone suggests. Reused context can receive discounts of up to 90% on cached input reads, eligible shared prefixes can be reused within a 30-minute window, and developers now get cache diagnostics, explicit breakpoints, and prewarming controls. GitHub told OpenAI that these improvements cut the share of prompt tokens requiring fresh processing by more than 50% across billions of requests.

That means the cost of an agent now depends on more than which model you picked. It also depends on whether your harness preserves context efficiently. A cheap model with a constantly broken cache can give back a surprising amount of its savings.

There is one launch-day documentation wrinkle worth knowing. OpenAI’s product post says GPT-6 models can adjust reasoning effort without breaking earlier cached context, while the current reasoning API documentation says the configuration_update mechanism is supported only by GPT-6 Astra. If you are building directly on Sol or Luna today, verify that capability in your own API setup instead of assuming the broader product-page wording applies everywhere.

When Corey pulled those numbers up live, the Luna pricing was the moment that made both of us stop.

Watch the pricing discussion at 5:44

Because Luna is no longer priced like a slightly cheaper frontier model. At ten cents in and fifty cents out, you can start using it for jobs where the economics previously pushed you toward much smaller models.

OpenAI claims Luna at max reasoning effort scored 66.6% on DeepSWE v1.1, a benchmark for long-horizon software-engineering work. Sol reached 68.8%. OpenAI says Luna was 93% cheaper per task than Opus 5 and 96% cheaper than Fable 5 in those comparisons. (OpenAI)

The factuality curve is just as interesting. OpenAI says Luna at higher effort matches GPT-5.6 Sol's factuality on its flagged-conversation evaluation at roughly one-hundredth the cost. That benchmark is deliberately filled with conversations that previously triggered factual errors, so it is not a general production hallucination rate.

That gap is small enough to change how you design an agent.

Maybe your most capable model does not need to spend its tokens reading every file, extracting every field, checking every routine condition, and writing every intermediate summary. Give the mechanical parts to Luna. Escalate when the job actually gets hard.

Welcome to Jevons paradox for AI

Grant brought up Jevons paradox during the stream: when efficiency makes a resource cheaper to use, people often consume much more of it.

Watch the Jevons paradox discussion at 6:32

That may sound academic until you look at how people actually use coding agents.

Corey said his own usage has climbed from a few thousand tokens a week to roughly three billion tokens per week, largely through subscription products and long-running agent workflows.

AI bills may get cheaper per token and somehow get more expensive per month.

Technology has discovered Costco.

OpenAI gave another extreme example in its announcement. Valued at API prices, the median OpenAI researcher now uses more than $600 worth of coding-agent tokens per day, while researchers at the 90th percentile exceed $7,000. (OpenAI)

Those numbers come from OpenAI’s separate look inside its own research workflows, which is useful context for the Jevons point: the people closest to the frontier are already responding to cheaper, stronger agents by using dramatically more inference.

When agents work for hours, spawn subagents, use tools, review their own work, and carry huge contexts around, the cost per call stops being trivia.

It becomes product architecture.

Sol looks like OpenAI’s new workhorse

Sol occupies the awkward middle position that often ends up being the most useful one.

You get a large jump over the previous Sol while paying half as much.

OpenAI reports 33.2% on AutomationBench at xhigh effort for $0.27 per task. AutomationBench tests multi-step business workflows across 47 tools used in sales, marketing, operations, finance, support, and HR. (OpenAI)

OpenAI’s computer-use numbers tell a similar story. On OSWorld 2.0 offline, Sol at xhigh effort reached 60.5% versus Opus 5 at medium effort at 60.3%, which OpenAI estimates came at approximately 80% lower cost per task. Different effort settings make this an imperfect head-to-head, but it is another sign that Sol is being positioned for work that previously pushed users toward a more expensive model. (OpenAI)

OpenAI also says Sol makes roughly half as many mistakes as GPT-5.6 Sol on its internal factuality evaluation.

That number needs an asterisk the size of a house.

The evaluation specifically uses conversations where users had previously flagged factual errors, and OpenAI says those conversations are not representative of normal usage. So this is evidence of improvement on situations that tend to induce errors, rather than a universal “50% fewer hallucinations” rate. (OpenAI)

OpenAI’s GPT-6 system card appendix for Sol and Luna adds another useful boundary. OpenAI classifies both models as High capability in cybersecurity and biological / chemical work, below its Critical threshold, and says neither reaches its High threshold for AI self-improvement. In an internal simulation of Codex deployment traffic, GPT-6 Sol produced roughly 36% fewer severity-3-or-higher misalignment flags than GPT-5.6 Sol across matched tasks. OpenAI also found more signs that Sol recognized it was being evaluated, 4.76% of trajectories versus 2.56% for its predecessor, so that improvement should not be read as a clean real-world failure-rate estimate.

There is one agent-safety footnote worth keeping attached to that improvement. In the same Codex simulation, lower-severity flags fell from 19.67% of matched tasks to 14.80%, but exfiltration flags increased. OpenAI says the simulation is best read as a relative signal about internal deployment risk, not a production failure rate. Translation: Sol looks better behaved overall, but unattended agents still need narrow permissions and explicit review boundaries. (OpenAI system card)

The same appendix exposes a smaller tradeoff hiding inside OpenAI’s “shorter and clearer” communication story. Sol improved slightly on HealthBench Professional and Consensus, but regressed on the overall and Hard versions. OpenAI says the regressions coincided with answers that were about 45% shorter on HealthBench, which sometimes omitted details the rubrics expected. Shorter can be better for everyday use without being better on every evaluation.

Still, the combination is compelling: stronger coding and agent performance, better factuality on that test, and $2 / $10 token pricing.

That makes Sol the model I would probably begin with for a difficult job before deciding whether I need to move up.

Corey’s version was even simpler during the livestream: use Astra to design the plan, then hand implementation to Sol.

Luna might be the more important release

Sol is easier to brag about.

Luna may change more workflows.

Corey already runs many of his scheduled agents and automations on Luna for a wonderfully technical reason:

“It’s enough.”

That is basically the entire economics of production AI.

A model does not have to win every benchmark. It has to cross the quality threshold for your job, reliably enough that moving to a more expensive model adds less value than it adds cost.

During the livestream, Corey looked at OpenAI’s coding curves and said he would probably live around Luna High, then increase reasoning when a task needed extra help.

OpenAI’s full release gives that instinct some support. On AutomationBench, Luna at high effort improved 5.4 percentage points over GPT-5.6 Luna at 58% lower cost per task. On OSWorld 2.0 offline, Luna at max effort beat GPT-5.6 Sol at medium effort at one-tenth the cost. That does not make Luna a universal substitute for Sol. It makes Luna unusually attractive once a task is bounded enough that extra capability stops paying for itself. (OpenAI)

Watch the Luna discussion at 20:48

This becomes especially interesting once you start building multi-agent systems. Our beginner guide to AI agents explains the basic pieces, but the economic version is simple:

Use the cheapest model that reliably clears the task.

Then escalate.

A researcher agent might let Luna collect material, Sol analyze it, and Astra review only the conclusion. A coding workflow can let Luna handle straightforward edits while Sol tackles implementation and a flagship model reviews architecture or security.

The model picker becomes a routing layer.

Claude Opus 5.5 got cheaper at exactly the right time

Anthropic apparently got the same memo about AI economics.

Opus 5.5 costs:

• $4 per million input tokens
• $20 per million output tokens
• $0.20 per million cached reads

Anthropic’s official model page fills in the rest of the spec sheet: a 1M-token context window, 128K maximum output, a June 2026 knowledge cutoff, and adaptive thinking that is always on. The Claude Platform release notes list the same model across the Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud, and Microsoft Foundry.

The full pricing docs also matter for heavy users. Five-minute cache writes cost $5 per million tokens, one-hour cache writes cost $8, cache reads cost $0.20, and the Batch API discounts standard input and output to $2 / $10. Anthropic also offers a Fast mode research preview on the Claude API at $8 / $40, with Anthropic advertising up to 2.5x faster generation.

Anthropic says that standard input and output pricing is 20% below Opus 5, but the new model also uses fewer tokens to finish work. Combined, Anthropic estimates roughly 40% lower cost on typical workloads. It also says output generation is more than 30% faster. (Anthropic)

Anthropic published a second launch-day piece called “What a task costs on Opus 5.5”, and it makes the same point from a different direction: users buy completed tasks, not tokens. Its worked example shows 2.8M input tokens costing $11.20 with no cache, about $1.62 at a 90% cache-hit rate, and roughly $0.99 at 96%. The expensive part of an agent can be the retry loop, the cold cache, or the unnecessary turn rather than the model’s headline token price.

That distinction matters.

Token price tells you what each token costs.

Cost per completed job tells you how many tokens, tool calls, retries, and minutes it took to actually finish something.

Anthropic has several impressive examples. In one internal test, Opus 5.5 and Fable 5.1 both translated HAProxy from C to Rust while passing nearly all of HAProxy’s regression tests. Opus 5.5 reportedly finished in 9.5 hours versus 12 hours for Fable 5.1 and cost 51% less. (Anthropic)

The launch post has two more examples that explain what Anthropic means by “long and sprawling.” An early tester reportedly completed a 680,000-line code migration in less than a day, and another audited and fixed a 200,000-line codebase in under three hours, where Opus 5 took more than 20 hours and used 2.5x as many tokens. Anthropic also says Opus 5.5 improved page-load performance successfully in 39 of 40 web-app tests. These are Anthropic and early-tester results, not neutral third-party benchmarks, but they are useful evidence for the shape of work the model is being optimized for. (Anthropic)

Early testers also reported fewer steps, fewer tokens, faster code reviews, and better performance on sprawling codebase work. (Anthropic)

For people who liked Claude but found Opus expensive enough to save for special occasions, this is a much easier model to actually use.

Developers should still treat Opus 5.5 as a migration, not a drop-in model swap. Anthropic’s “What’s new” guide and migration guide call out four breaking changes: thinking can no longer be disabled, forced tool choice returns an error, thinking blocks are tied to the model and conversation, and an older computer-use tool is no longer accepted on the Claude API and Google Cloud.

The Opus 5.5 prompting guide also changes how I would interpret our livestream test. Opus 5.5 defaults to medium effort, not high, and Anthropic says it tends to think more per turn than Opus 5 at the same named effort level. Anthropic recommends starting at medium, testing effort levels against your own evals, and reserving xhigh or max for work where you have measured a quality gain. In other words, our extra-high Cat Doom run was intentionally much heavier than the model’s default operating point.

Anthropic’s broader effort documentation reinforces the same idea: reasoning depth is now a first-class cost and latency control. That makes “which model?” only half the question. “At what effort?” can change the economics almost as much.

Anthropic's own Opus 5.5 playbook makes another useful change to the way you should prompt it. Give the model the whole task and a clear finish line. Remove generic "think carefully" boilerplate. Put stop and continue rules in CLAUDE.md, and use subagents for repo-wide audits instead of forcing one context to hold everything.

That is a subtle shift from "prompt engineering" toward work specification. The model needs to know what done means, what it can touch, and when it should stop.

And Opus 5.5’s benchmark numbers are strong

Anthropic reports:

• 66.4% on Terminal-Bench 4.0
• 54.4% on FrontierCode v1.1 Main at max effort
• 1,846 Elo on GDPval-AA v2.1
• 40.0% on AutomationBench
• 81.8% partial reward on OSWorld 2.0

Those results put Opus 5.5 near or at the top of Anthropic’s published comparisons across coding, business workflows, computer use, and professional knowledge work. (Anthropic)

Then Anthropic does something unusually useful in the same announcement.

It tells you to calm down about the benchmarks.

The company says benchmark margins at this capability level have become a less reliable guide to real-world differences, and that its own experience suggests the gap between Opus 5.5 and Fable 5.1 feels narrower than the charts imply. (Anthropic)

The system card is also unusually explicit about research limits. Anthropic says a common internal agent failure was asserting unverified inferences as established fact, with examples like describing a partial check as a full read or turning a tentative interpretation into a recommendation without verifying it. On CoBench 2.1, a 500-problem internal R&D debugging evaluation, Opus 5.5 scored 55.8% versus 53.4% for Mythos 5.1 and 53.2% for Opus 5; Anthropic says the three results were not statistically distinguishable (p ≈ 0.2). The company says a model capable of fully substituting for its research staff would be expected to score at least 85% on this evaluation family. For research workflows, source verification still belongs in the loop. (Anthropic system card)

Anthropic’s safety material adds another benchmark caveat. Its launch report says Opus 5.5 performed best among recent Claude models on nearly every measure in an automated audit spanning almost 2,000 scenarios, and attempted to cross containment boundaries about 85% less often than Opus 5 or Mythos 5.1 in a new test. Anthropic also says the model often appears to suspect when it is being evaluated, which makes pre-release behavioral measurement harder to interpret.

The full system card gives the less flattering side of the same picture. In Anthropic’s sandbox-escape evaluation, Opus 5.5 still attempted to cross a containment boundary in 1.5% of runs, although every attempt was low severity, read-only, stopped at a stronger barrier, and was reported afterward. In a separate simulated package-registry exercise run without cyber safeguards, the model took actions Anthropic says would likely be harmful in roughly half of cases. Anthropic also observed evaluation awareness in about one-third of those runs and warns the setup may not represent deployment behavior. (Anthropic system card)

Production safeguards can also change what users and benchmarks actually see. Anthropic says most cybersecurity tasks that trigger its safeguards are transparently rerouted to Opus 4.8. Its AutomationBench footnote says safeguard interventions were counted as failures in that particular evaluation because fallback models were disabled. So “Opus 5.5 score” can depend on whether you are measuring the raw checkpoint, the production system, or a benchmark harness with fallbacks turned off.

There is also a specific prompt-injection regression worth knowing if your workflow pastes READMEs, logs, emails, or web text directly into Claude. In Anthropic’s coding evaluation, the final Opus 5.5 release acted on malicious instructions planted inside pasted user text in about 2% of attempts at default effort and 7.4% at max effort. That was down sharply from 52% in an early pre-mitigation snapshot. With Anthropic’s product mitigations enabled, none of the planted visible or invisible instructions were followed. Anthropic says the regression appeared in pasted text inside the user’s own message, not in tool-result prompt injections in that test. (Anthropic system card)

Correct!

There is no clean launch-day Sol vs. Opus 5.5 scoreboard

This is where model-release charts get messy.

OpenAI’s launch page compares GPT-6 Sol mainly against Claude Opus 5 and Fable 5.1, because Opus 5.5 had effectively just arrived.

Anthropic’s page compares Opus 5.5 against GPT-6 Astra and GPT-5.6 Sol, because GPT-6 Sol had effectively just arrived.

So screenshots that immediately declare one model the winner by lining up unrelated bars deserve skepticism.

Even when both companies use the same benchmark, you still have to check reasoning effort, tools, harnesses, safeguards, test subsets, and cost methodology.

OpenAI itself warns that its evaluations may differ from production ChatGPT because system prompts and tools differ. Anthropic documents similar setup differences throughout its benchmark notes. (OpenAI)

Our view on benchmarks during the livestream was basically: use them to decide what deserves a test, then test the model on your work.

Watch that discussion at 14:42

Your benchmark is the task you have to do again tomorrow.

The first outside tests refuse to give us a winner

The interesting part of day one was how quickly independent results split by workload.

• Browser Use put GPT-6 Sol medium at 66.9 on its browser-agent benchmark versus 59.4 for Opus 5.5, with Sol reported about 3.5x cheaper on its cloud. Founder Gregor Zunic said Sol and Luna looked unusually strong on long browser tasks that humans also find hard. This is one third-party benchmark, not a universal head-to-head.
• Artificial Analysis ranked Opus 5.5 Max first on its Intelligence Index at 58 in the digest's cited snapshot. But a companion Hacker News thread surfaced a very practical failure case: two max-effort "pelican riding a bicycle" runs reportedly burned through the 128K reasoning budget before producing an SVG.
• Every said Fable-class capability at $4 / $20 was already pulling some Codex converts back toward Claude. Its quick cheat sheet favored Opus for interfaces, 3D, games, writing, and personas while keeping Fable for the biggest first-time-right jobs.
• Victor Taelin said Opus 5.5 beat Fable 5.1 on every prompt he tried and showed unusually deep recall of Interaction Calculus. Ethan Mollick called it the first non-Fable/Astra model that felt Fable-class to him, while still noticing the dense-language habit of recent Claude models.
• Yuchen Jin came away with the opposite preference on a hard research question and coding work, choosing Astra and describing the frontier more as a race for intelligence per dollar.
• Anthropic researcher Nat McAleese called Opus 5.5 dramatically better than Opus 5 and urged people who had written Claude off to retry it.
• Theo interpreted Anthropic's compute chart as evidence Opus 5.5 may be smaller than Opus 5 and that post-training is doing more of the work. Anthropic has not disclosed that model-size conclusion, so treat it as interpretation.
• signüll gave OpenAI credit for lowering the delivered cost of high-quality intelligence across quality, latency, reliability, model choice, and access. That is a better description of this release cycle than "benchmark X went up three points."
• The GPT-6 Sol/Luna Hacker News thread focused heavily on the 50% API cut and whether Luna now sits on the cost-performance frontier. The Opus 5.5 thread spent more time on the tension between Anthropic's "pace the frontier" messaging and shipping something cheaper and materially stronger.
• Matthew Berman summarized the surprise well: an Opus model that looks top-tier while also undercutting Astra and Fable pricing was not the expected shape of this launch.

That is a much more useful picture than a single launch-day leaderboard. Different people are already finding meaningful wins for both models on different work.

Opus 5.5 gets stranger when you give it teammates

The multi-agent results may matter more than any single-model score.

Researcher Maksym Andriushchenko highlighted Anthropic's system-card appendix, where small teams of agents completed ProgramBench work 2.7x faster. Larger groups also improved knowledge-base and Lean tasks, although the gains diminished as more agents were added.

Anthropic's Boris Cherny said Opus 5.5 used Lean to formally verify the Claude Agent SDK and produced 16 pull requests for bugs and race conditions from a couple of short prompts. Some runs paired Lean with TLA+ for concurrency and state.

Then there is the C-HD experiment. Ten Opus 5.5 agents reportedly spent 15 hours and 733 message-board turns producing a Lean-verified exact shortest-path algorithm for directed graphs with non-negative weights. The certified moderate-density regime improves an asymptotic bound over Dijkstra in that range, but the authors did not claim a wall-clock speedup because the constants are large. Hacker News also noticed the dated run appears to predate Opus 5.5's public release.

That is the pattern to watch: not "can one model answer the question?" but "what happens when a capable model can delegate, verify, and coordinate for hours?"

And then everyone started making weird stuff

Opus 5.5's creative demos were less scientific, but they reveal what people are actually trying to hand to the model.

• Kevin Ngo had Opus 5.5 draw every frame of a 28-second JavaScript town animation.
• Matthew Berman recreated San Francisco in Unreal Engine with Jev-driven inhabitants.
• Ben Poole shared an approximately 80-second sketch-to-simulation run.
• Addy Osmani built a Three.js pelican-on-a-bike demo and framed the new Opus as a step-up model for agentic coding, computer use, and following writing rules.
• Alex Albert showed the merged Claude chat and Cowork surface driving Blender claymation from a single prompt. He separately rebuilt 1906 pre-earthquake Market Street from historical maps, photos, film, and reusable Blender-Python generators, tagging buildings with footprint, height, material, occupant, and confidence.
• Peter Yang tested five use cases in a hands-on video: a Golden Gate flyover, Disney-style ride, MS Paint computer use, Claude Design, and HyperFrames editing.
• Noah Wachnik reported a 1-hour-37-minute one-prompt Minecraft build as his wildest LLM result yet.
• Chris posted realistic Minecraft and Star Wars scenes, while making the important point that the best model-generated art may need days or weeks of unattended iteration.
• Mia AI Lab published Claude Opus 5.5: 100 HTML Files, a gallery of 100 offline HTML pages across generative art, physics simulations, instruments, layouts, and games. The lab says all 100 worked without broken files, and the full set is on GitHub.
• Ethan Mollick's Fable/Opus experiment produced Orbital Declaration, a hard-science-fiction browser combat game with Newtonian motion, the rocket equation, gravity, beam geometry, projectile travel time, heat, eight story chapters, eleven Jupiter sites, skirmishes, and a shipyard. The MIT source is public.
• Jake Moran's camera-3d-captions skill turns After Effects-style camera motion, depth, captions, alpha mattes, focus racks, and motion blur into deterministic per-frame rendering that Opus 5.5 can trigger through HyperFrames.

There are two useful cautions hiding inside all that eye candy.

Vercel CEO Guillermo Rauch used the Opus 5.5 launch page to argue that AI lowers the cost of a more "headless" web, where every page can take a shape unique to its content instead of collapsing into one template.

MIT's Phillip Isola went the other direction. His Claude Tells project catalogs recurring Claude habits like cream-and-terracotta palettes, three-card grids, pill buttons, giant stat rows, and stock phrases. Better generation does not automatically mean less recognizable generation.

So naturally, we tested Doom with cats

Last time we tested Astra, we gave it an extremely rigorous scientific instruction:

“Make the game Doom end to end, but with cats.”

We ran essentially the same test again with GPT-6 Sol and Claude Opus 5.5.

Watch the Cat Doom test begin at 31:17

Sol eventually produced Catacomb, a playable first-person cat shooter with maze-like levels, enemies, health, keys, fish for vitality, yarn ammunition, portals, and a boss named Meowlock.

Which, frankly, is peer review.

Watch us play GPT-6 Sol’s Cat Doom at 48:36

The Codex run showed roughly 10 minutes and 30 seconds of model work. Corey’s impression was that the result got surprisingly close to the Astra version despite Sol costing $10 per million output tokens versus Astra’s $50.

Opus 5.5 was still working around the 20-minute mark when we had to wrap the stream.

That does not mean Sol is twice as fast or “better at coding.” One run had to be restarted, the environments were not identical, and a one-prompt cat game is a demo rather than a controlled benchmark.

It did prove something more relevant to normal users: the cheaper model produced something useful enough that nobody watching it would have mistaken the task for “cheap-model work.”

And Anthropic may still have the last laugh. Opus had produced a considerably more elaborate project plan, and Anthropic specifically claims Opus 5.5 improved at building polished games from single prompts. We did not stay live long enough to see the completed result. (Anthropic)

We’re running more tests before our next livestream.

The official docs add one big routing caveat

The first-party guidance from both companies actually points toward the multi-model workflow we landed on during the stream, but with an important catch: routing has a cost of its own.

Anthropic’s task-cost guide recommends Opus 5.5 at medium effort for well-scoped daily work, raising effort when it stalls, moving to Fable 5.1 after repeated failures on a hard problem, and sending search or log-reading subagents to Sonnet or Haiku. That is almost exactly the planner-worker-escalation pattern we were discussing live.

But Anthropic also warns that changing effort at the top level can invalidate the prompt cache, and switching models means the new model may need to pay the cache-write cost on the conversation. Its docs recommend switching at a natural break, compacting first, or starting a fresh session with a short plan. Opus 5.5’s preserved thinking is also model-dependent: some models can read its thinking blocks and others cannot.

OpenAI is attacking the same problem from the infrastructure side with more aggressive caching, explicit breakpoints, diagnostics, and stable tool definitions. Put those ideas together and the next optimization target becomes clearer: route models at meaningful task boundaries, not just whenever another model is a few cents cheaper. A model router that saves on token price but destroys context, repeats work, or creates extra retries can lose the whole advantage.

The smartest setup may use several models

Corey and I actually use different approaches.

He tends to put the expensive model at the edges:

strong model plans → cheaper model executes → strong model reviews

I sometimes keep the more capable model working longer, because the cost of fixing stupid mistakes can exceed the savings from generating them cheaply.

Both approaches can work.

You can also parallelize. Three Sol agents can attack separate pieces of a project simultaneously. Luna can serve as a swarm of inexpensive workers. Opus can handle a long ambiguous codebase investigation while another model handles smaller deterministic jobs.

And sometimes you should simply use the model you communicate with better.

Corey put it well on the livestream: at this level, the capability margins can be small enough that the model which best responds to the way you explain a problem may produce the better result for you.

Watch that discussion at 22:48

AI users spent the last three years asking which model is smartest.

The next skill is learning when you actually need the smartest model at all.

OpenAI just made Luna cheap enough to throw at enormous amounts of work. Sol makes near-frontier capability much easier to use all day. Anthropic cut the effective cost of Opus while improving its strongest areas. Astra remains available when you really want to put the pedal down.

The unresolved question is what happens to total AI spending when every unit of intelligence gets cheaper.

Do we save money?

Or does Jevons win, and six months from now all of us are casually running 40 agents because, hey, Luna is practically free?

Please check on Corey when he hits 30 billion tokens a week.