OpenAI released GPT-6 Sol and GPT-6 Luna on September 22, extending the GPT-6 family with two models aimed at lower-cost reasoning, coding and agentic workloads. The practical significance is not just another model choice. The price gap between Sol and Luna is large enough to make workload-specific routing an economic design decision rather than a minor optimization.
For standard requests with up to 272,000 input tokens, GPT-6 Sol costs $2 per million input tokens, $0.20 per million cached input tokens and $10 per million output tokens. GPT-6 Luna costs $0.10, $0.01 and $0.50 respectively. Both models support text and image input and text output through the Responses API and Chat Completions.
Luna changes the economics of routine agent steps
Luna's standard input and output prices are one twentieth of Sol's. That creates an unusually large spread inside the same model family. For an agent system that performs many classifications, extraction steps, planning passes or lightweight code transformations, sending every step to the stronger model becomes harder to justify.
Aipolix's analysis is that model routing should now be tested at the workflow level. A team can use Luna for routine steps and escalate difficult work to Sol, but only if the cheaper model does not create enough retries, bad intermediate decisions or human review to erase the savings. The useful metric is therefore cost per accepted task, not price per token.
This is especially important for agents because one user request can trigger dozens of model calls. A small difference in the cost of each step compounds across planning, tool selection, code edits, verification and retry loops.
Sol keeps a large context window for harder work
OpenAI's model documentation positions GPT-6 Sol for complex coding and agentic workflows. Sol exposes a 1.05-million-token context window and up to 128,000 output tokens. It supports reasoning effort settings from none through max, giving developers another control over latency, cost and depth.
The large context window can reduce the need to aggressively trim repositories, long documents or session history. But using more context is not free. OpenAI's pricing documentation charges higher rates once prompts exceed 272,000 input tokens: input and cache rates double and output pricing rises by 50% for the full request.
That threshold is therefore an architectural boundary as much as a pricing detail. Teams should measure whether the additional context actually reduces retrieval complexity, retries or missing-information failures enough to justify the higher long-context rate.
Existing API architectures can evaluate the models directly
Both Sol and Luna are available through the Responses API and Chat Completions. OpenAI recommends the Responses API for built-in tools and function calling with Sol. The models accept image input as well as text, making them usable in agents that inspect screenshots, documents or visual context.
For teams already using the Responses API, the release does not require a new agent protocol. Sol and Luna can be introduced as alternative model targets in existing routing and evaluation infrastructure. That makes A/B testing relatively straightforward: keep prompts, tools, permissions and acceptance criteria fixed, then compare task success, tool-call count, elapsed time, retries and total token cost.
Data residency adds another deployment constraint
OpenAI's current pricing documentation says EU data residency is available for GPT-6 Sol and Luna only with Standard processing. Regional processing adds a 10% premium where applicable.
For European organizations, including teams in Portugal, this means model selection cannot be separated from processing mode. A deployment that needs EU residency may not be able to use the cheapest alternative processing tier even if the model itself is eligible. Cost comparisons should therefore include the processing and residency configuration actually required in production.
Lower token prices do not remove orchestration costs
A cheaper model call can make experimentation easier, but it does not solve agent reliability. Tool permissions, state management, evaluation, checkpointing and failure recovery still determine whether a workflow is safe and useful.
The biggest opportunity with Luna is volume: many more reasoning calls can fit inside the same budget. The biggest risk is assuming that this automatically improves the economics of a complete task. If a weaker step causes a bad plan that triggers several downstream calls, the initial savings can disappear.
Sol and Luna therefore make multi-model architecture more attractive, but also make evaluation discipline more important. Teams should track the route taken by each step and calculate the total cost of the final accepted outcome.
What to benchmark before changing production
A practical evaluation should compare the current production model with at least two configurations: Sol-only and a Luna-to-Sol escalation path. Keep tools and policy identical. Measure accepted-task rate, escalations, retries, tool calls, long-context usage, latency and human review.
The release matters because OpenAI has widened the price spectrum inside a single reasoning-model family while preserving large context and tool support. The strongest architecture will not necessarily be the one using the strongest model everywhere; it will be the one that spends model capability where it changes the final result.