# Why Sol and Luna changed the economics of task allocation

The Sol and Luna release widened model choices; compare completed workflows, escalations and acceptance quality before assigning work by token price.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-22
Original announcement: https://developers.openai.com/api/docs/changelog
Canonical URL: https://retrivium.ai/retrospectives/sol-luna-two-model-economics/

Sol and Luna made task allocation a more interesting question than choosing the strongest available model. Their September release expanded the available operating points, but an organization still had to decide which work could move between them without changing what counted as an acceptable result.

## The sequence introduced a portfolio decision

The [September 22, 2025 Responses explanation](https://developers.openai.com/blog/responses-api) established an earlier execution interface. Astra appeared in the [September 3, 2026 changelog](https://developers.openai.com/api/docs/changelog), followed by Sol and Luna on September 22, 2026. The [family announcement](https://openai.com/index/introducing-gpt-6-sol-and-luna/) positioned these additions around different scales and budgets. This chronology supports a portfolio question; it does not specify a ready-made routing policy.

## Average request cost hides task differences

Suppose a support workflow contains extracting an order identifier, explaining a documented exception and investigating an inconsistent account history. These jobs can have similar prompt lengths while requiring different evidence and recovery behavior. Assigning them all by token count confuses input size with difficulty.

Conversely, sending every request to the highest tier can spend capacity on tasks whose answer space is already narrow. The opportunity is to separate task types before optimizing their model assignment. The release created options, not evidence that every task should use the cheapest option.

## Model cost is only one term

A lower-cost first attempt can become expensive when it triggers repeated clarifications, manual review or a second model call. A more capable first attempt can also be wasteful when a deterministic lookup would have answered the question. Count the completed workflow rather than only its initial inference.

An illustrative decision ledger should therefore retain the task type, evidence available, first result, escalation and accepted outcome. These records reveal whether savings came from genuine substitution or from leaving more work unfinished outside the model bill.

## Test the boundary between neighboring tasks

Start with a pair of superficially similar requests: one answer explicitly appears in an approved document; the other requires reconciling conflicting revisions. Keep the output contract comparable, then inspect whether the cheaper path recognizes the second request's uncertainty.

The discriminating result is not merely a longer answer from the larger model. It is correct evidence selection, an explicit unresolved conflict or a justified escalation. A routing rule that cannot represent uncertainty may conceal failures by forcing every case into a confident answer.

## The release changed the decision surface

A useful policy assigns a model together with an acceptance condition and fallback. Revisit that combination after the task mix or source quality changes. A workload dominated by repeated extraction is different from one dominated by investigations, even with the same monthly request count.

The retrospective lesson is that model portfolios require task accounting. Sol and Luna widened the available choices, while the application retained responsibility for identifying which choice actually completed the work.

## Related reading

- [Components of inference economics](/journal/inference-economics/)
- [Tool decisions and execution](/journal/openrouter-tool-calling/)