GPT-6 Sol and Luna make model choice an operating decision. OpenAI released both on September 22, 2026, with Sol aimed at complex coding and agent workflows and Luna at focused work performed at high volume. For a software business, the useful question is which tasks need the extra capability and which can run economically on the smaller model.
What the release changes
Both models accept text and images and produce text. OpenAI's launch pricing for standard API requests with up to 272,000 input tokens is $2 input and $10 output per million tokens for Sol, compared with $0.10 input and $0.50 output for Luna. Cached input is priced separately. Those are token rates, rather than the total cost of running an application.
OpenAI also reported an image-encoding fix on September 25. Applications processing screenshots or documents should include fresh visual examples in their evaluations. A successful text-only test would miss that part of the workload.
A cost example worth doing before launch
Consider a hypothetical feature that receives 100,000 requests per month. Each request uses 2,000 uncached input tokens and produces 300 billed output tokens. That adds up to 200 million input tokens and 30 million output tokens.
- Sol: 200 × $2 plus 30 × $10 equals $700 per month.
- Luna: 200 × $0.10 plus 30 × $0.50 equals $35 per month.
This illustration assumes standard short-context pricing. It excludes tool charges, retries, hosting, and additional tokens consumed by reasoning. Actual billing will also depend on caching, processing tier, region, and request size. A useful budget records those items separately and uses the provider's returned usage data.
The comparison changes if the cheaper model creates more corrections. Measure cost per accepted result: model and tool spend, failed attempts, and the human effort needed to produce a usable answer. A low token bill can still hide an expensive workflow.
Match the model to the job
For a travel app, extracting a booking reference into a defined schema is a sensible candidate for a Luna trial. Resolving conflicting itinerary details or planning a difficult integration deserves a separate Sol comparison. These are proposed evaluation tasks, not claims that either model will achieve a particular accuracy.
Start with 50 representative examples from the feature, including missing fields, ambiguous dates, contradictory instructions, and malformed input. Define an accepted answer before running either model. Record schema validity, factual accuracy, latency, billed tokens, retries, and reviewer corrections.
A routing rule should use evidence the application can inspect. For example, a failed schema check or unresolved required field can trigger another attempt or human review. An answer sounding confident is not enough to justify accepting it. Keep the route simple enough that failures can be reproduced.
Customer-facing messaging can then describe a measured outcome: faster booking import, fewer manual corrections, or clearer trip details under stated test conditions. The model name belongs behind that result. A release announcement alone does not establish that the product improved.
Source context
This article covers the September release. The workload examples, evaluation method, and monthly calculation are AyNcode analysis. Confirm current rates before estimating a new deployment.