GPT-6 Sol and Luna make routing a cost test

OpenAI released GPT-6 Sol and GPT-6 Luna on 22 September 2026, describing the pair as GPT-6 models with different balances of capability and cost. The launch was reported independently by TechCrunch, AWS Machine Learning and Simon Willison; AWS says the models are generally available on Amazon Bedrock. For the person responsible for a production model route, the immediate change is a pair of new candidates, not an established performance ranking.

The accounts agree on the event but supply different kinds of evidence. TechCrunch reports that OpenAI is positioning Sol and Luna as related to GPT-6 Astra while boasting lower cost and fewer mistakes. AWS focuses on availability and says the models offer more options for matching intelligence and efficiency to a workload. Simon Willison writes that Sol and Luna are half the price of their GPT-5.6 equivalents.

Those statements should not be collapsed into a single conclusion. TechCrunch is reporting OpenAI's positioning; AWS is describing the models on its own service; and Willison is offering a comparative price observation. OpenAI says the models differ in their capability-cost balance, but the supplied material does not tell a team which model belongs on which task.

A lower model price needs a task-level test

A lower model price changes an input to a routing decision, not the decision itself. The useful question is whether the cost of a completed workflow changes: a request that needs repeated attempts, produces an unusable draft, or requires substantial human correction can alter the total even when the listed model price is lower.

That is the measurement job for the engineer or product owner maintaining a route. Record the model selected, the task class, input and output token use, cache status, retries, completion outcome and any human correction. Then compare the candidates on work that resembles the production workflow, rather than on an attractive prompt chosen after the result is known.

Willison's half-price observation makes that exercise worth doing for teams using GPT-5.6 equivalents. It does not make either new model an automatic default. A route owner needs to know whether the output meets the acceptance condition for a specific task, and whether that result holds when the task includes the actual context, tools and constraints used in production.

The practical consequence is modest but concrete. Add Sol and Luna to the evaluation set, retain an approved fallback, and make the rule for selecting a model explicit. That gives a manager a decision they can inspect later instead of a quiet configuration change justified by a launch headline.

The Astra connection is not a benchmark

TechCrunch reports that OpenAI presents Sol and Luna as cut from the same cloth as GPT-6 Astra. That describes product lineage, not a test result. The other comparison supplied here is Willison's reference to GPT-5.6 equivalents, which establishes a price comparison in his account but does not establish a capability ranking.

No benchmark suite, scoring method or common price card appears in the material. Nothing here supports ranking Sol, Luna, GPT-5.6 or Astra for coding, research, document work or an agent loop. That absence matters because different capability-cost balances are precisely the sort of language readers can mistakenly turn into an unearned assumption that a model is suited to a particular job.

The timing invites a second overreach. Simon Willison writes that Anthropic released Claude Opus 5.5 around an hour before OpenAI released Sol and Luna. TechCrunch reports that Anthropic called Opus 5.5 its strongest-performing model it had tested, while ZDNET reports that it delivers Fable 5.1 performance for most work and costs about 40% less to run. Those are separate companies' product claims, with no common task suite or common pricing basis in the supplied accounts.

Willison's headline calls the releases a new price war. That is a reasonable frame to investigate, but it is his framing, not a conclusion that follows from a pair of launches. Comparable prices, workloads and outcomes would be needed before a buyer could treat the releases as a like-for-like contest.

The tool update is narrow but useful

Willison's LLM 0.36 release supplies a small, concrete integration signal: it adds the model identifiers gpt-6-sol and gpt-6-luna for GPT-6 Sol and GPT-6 Luna. For users of that tool, that creates an immediate way to address the new models in an evaluation setup.

It does not establish broader compatibility. The LLM 0.36 release also lets model plugins declare that they do not support conversations, but the supplied summary does not say that Sol or Luna use that setting. It would be a mistake to infer their conversation behaviour, tool support or interface compatibility from the existence of the flag.

AWS's announcement has a similarly bounded implication. Bedrock users have an announced place to evaluate the models; the announcement does not settle availability or implementation details elsewhere. The relevant engineer should therefore test the integration they actually operate, including request formats and any workflow state the application sends with a prompt.

Treat launch claims as controlled-routing inputs

A sensible response is to turn the announcements into a controlled evaluation rather than a broad migration. Start with a catalogue entry for each model, a defined task class and an acceptance condition. Track the direct model bill alongside retries, cache behaviour and the work needed to correct or reject outputs. Keep the existing approved route available until the new route has evidence behind it.

This is what the reports change. They corroborate that GPT-6 Sol and GPT-6 Luna have launched and that AWS says they are generally available through Bedrock. They do not independently establish that either model makes fewer mistakes, offers the right balance for a particular workflow, or should replace GPT-5.6, Astra or Claude Opus 5.5.

The cost-control page covers budgets, allowed models, model right-sizing, token caps and batching offline work.