Choosing the lowest model price before defining the deliverable saves money on the wrong variable. I want an inexpensive option that finishes the job with sufficient quality. Paying for the most capable model on every assignment needs justification too; idle or poorly assigned capability bothers me just as much.
On September 22, 2026, OpenAI launched GPT-6 Sol and Luna. Prices per million input and output tokens were $2 and $10 for Sol, and $0.10 and $0.50 for Luna. The difference gets my attention. Before it becomes a routing rule, it needs a relationship to the cost of being wrong on a concrete task.
That day, I asked for selection to consider the best model for each job. In July, I had already wanted to compare models by role. In early September, I asked whether simple tasks were going to the cheapest model. That sequence shows what I expect: an explainable choice for the assignment in the queue, without turning the selector into a provider fan club.
Simple needs context. A short change can contain an important decision that is hard to verify. A long request might merely organize available material against clear criteria. Prompt length cannot settle that classification. I want to examine the consequences of a wrong answer and how easily it can be detected before another stage depends on it.
Preparing a verifiable list offers an opportunity to compare an economical option. Interpreting an ambiguous situation and choosing the next direction requires another kind of capability. Checks available outside the model also affect the choice. Useful routing needs to recognize these differences without becoming a collection of exceptions nobody can maintain.
OpenAI's published comparisons help select candidates. To choose my default, I will keep the request and expected result consistent, counting attempts through to an acceptable deliverable. My time belongs in the calculation too: saving tokens while compensating by supervising every movement returns a cost the pricing chart never displays.
Sol and Luna enter that comparison with their roles open. I will choose defaults by task type and record why each fits, revisiting them when pricing or behavior changes. A name saved in configuration makes the next execution easier; it deserves no permanent defense. If the economical option requires repeating the work, the rule changes. If it satisfies the request, I want the more expensive capability available where it makes a difference.