Route GPT-6 Sol and Luna by Accepted Patch Cost

OpenAI released GPT-6 Sol and GPT-6 Luna on September 22, 2026. The model pages make the intended split clear: Sol is built for complex coding and agentic workflows, while Luna is the efficient choice for focused, high-volume work. That is a useful starting point, but it is not a production router.

A coding team needs to know which task classes each model can complete inside its own repository contract. The deciding unit is an accepted patch after tests, review and required rework. Token rates are inputs to that decision, not the result.

The verdict: Luna by default, Sol by evidence

Start Luna on tightly scoped work with a deterministic acceptance path. Route a task class to Sol only after matched evals show that Sol's reasoning improves the accepted-task rate or reduces review and rework enough to justify its higher observed cost.

Good Luna candidates include a bounded dependency update, a fixture-backed test addition, a mechanical API migration with an explicit file boundary, or a small issue whose expected behavior is already encoded in tests. Good Sol candidates include ambiguous failures that require repository navigation, coordinated changes across several subsystems, and tasks where the agent must reconcile incomplete requirements before it can produce a valid patch.

Do not route one prompt at a time through intuition. Define the class before dispatch, retain the model and reasoning effort with the task record, and compare one observation window against the same acceptance rule.

OpenAI's current model guidance recommends Sol for strong reasoning on demanding tasks and Luna for efficient, repeatable work at scale. It also says model choice should reflect reasoning needs, latency and cost. That supports a task-class split, not a blanket replacement of one model with the other. OpenAI GPT-6 model guidance.

The shared surface does not choose the model

Sol and Luna have matching published context and output ceilings and the same broad tool inventory. The material difference for a coding-agent router is the capability-cost tradeoff on the buyer's tasks.

Both models accept text and images and produce text. Their Responses tool lists include web search, file search, code interpreter, hosted shell, apply patch, skills, computer use, MCP and tool search. Neither supports fine-tuning on the current model page. GPT-6 Sol model page and GPT-6 Luna model page.

Use Responses when the coding agent needs tools. The model pages say Chat Completions supports function calling only when reasoning effort is none; Responses supports the built-in tools and function calling across the intended reasoning workflow. Keep the endpoint, tool schemas, sandbox, instructions and reasoning effort fixed while comparing models.

The short-context prices do not apply unchanged to every request. On both model pages, prompts above 272K input tokens are billed at twice the input and cache rates and one and a half times the output rate for the full request. A large repository context can therefore cross a billing boundary before anyone notices a quality problem.

Token price is the first cost, not the final cost

For the same short-context task with 200,000 uncached input tokens and 20,000 output tokens, the listed Standard rates produce $0.60 of Sol token cost and $0.03 of Luna token cost. The arithmetic is illustrative: (0.2 × input rate) + (0.02 × output rate). It excludes cache writes, tools, sandbox execution, retries, evaluation, review and rework.

That 20-fold token-rate difference matters, but it does not set the production winner. If Luna creates more rejected patches or consumes materially more human review on one hard task class, the cheaper call can create the more expensive accepted outcome. The inverse is also true: paying Sol rates for mechanical work wastes budget when Luna passes the same gate.

Use the same joined ledger described in coding-agent task economics:

cost_per_accepted_patch =
  (model + tools + sandbox + evaluation + review + rework)
  / reconciled_accepted_patches

Keep observed provider and infrastructure spend separate from modelled human cost. A reviewer-hour estimate is not an invoice, and released capacity is not a cash saving unless spending actually changes.

When accepted patches are zero, unit cost is unavailable. Do not remove rejected tasks from the numerator or convert an empty denominator into zero.

Build a task-class router

The first router should be a small policy table backed by a replayable task set, not another model call.

The release gate still belongs outside the model. Protected branches, required checks, code ownership and a rollback path should remain identical whichever model handles the task. A repository readiness score is not release evidence; representative tasks, denied actions and retained merge control are.

Store the routing decision with a version and an expiry. Model behavior, prices, instruction files and repository shape all move. A class that belonged on Sol last month may move to Luna after tests improve or the task becomes more constrained. A Luna class may move the other way after a dependency migration changes its failure modes.

Keep public benchmarks in their lane

OpenAI reports 68.8% for GPT-6 Sol at max effort and 66.6% for GPT-6 Luna at max effort on DeepSWE v1.1. OpenAI describes DeepSWE as original, long-horizon software-engineering tasks in real codebases. Those results establish that both models deserve evaluation for coding work. They do not establish which one accepts more of your tasks or costs less after your review process. OpenAI's GPT-6 Sol and Luna launch.

The comparison also mixes more than model identity. Reasoning effort, harness, tools, task set, evaluator and pricing method are part of the benchmark record. Preserve that tuple when using a public result to shortlist a candidate.

For production routing, replay representative local tasks and measure cost per accepted patch. Use the public benchmark to decide what deserves a canary, then let retained repository evidence decide what gets traffic.