Route GPT-6.1 Sol and Luna by Accepted Patch Cost

OpenAI released GPT-6.1 Sol on September 29, 2026. It keeps GPT-6 Sol's $2 input and $10 output rates per million short-context tokens, cuts cached input from $0.20 to $0.10, and reports stronger results across coding, computer use and professional work. The new model is available through the OpenAI API as gpt-6.1-sol, is rolling out in GitHub Copilot, and is generally available on Amazon Bedrock.

That makes GPT-6.1 Sol the better hard-task candidate. It does not make a model-picker selection a production routing decision. A coding team still needs to define the task class, hold the runtime constant and measure an accepted patch after tests, review and required rework.

The verdict: Luna by default, GPT-6.1 Sol by evidence

Start Luna on tightly scoped work with a deterministic acceptance path. Canary GPT-6.1 Sol on harder classes where repository navigation, coordinated changes or incomplete requirements make reasoning quality materially affect the outcome. Keep GPT-6 Sol as a frozen comparison baseline while the canary runs, not as the automatic middle choice.

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 GPT-6.1 Sol candidates include ambiguous failures, coordinated changes across several subsystems, and tasks where the agent must reconcile incomplete requirements before it can produce a valid patch.

GitHub's rollout adds a governance wrinkle. Copilot Business and Enterprise administrators can manage GPT-6.1 Sol through model policy, but default model enablement can automatically enable a new model unless the global default is off or the model is explicitly disabled. Availability is not repository approval. Let the platform expose the candidate, then let a versioned task-class gate decide whether it receives work. GitHub's GPT-6.1 Sol rollout.

The three-model surface changes one routing decision

GPT-6.1 Sol, GPT-6 Sol and GPT-6 Luna publish the same 1,050,000-token context window and 128,000-token maximum output. Their prices and reasoning controls differ enough that a router should treat them as three distinct runtime candidates.

GPT-6.1 Sol supports web search, file search, image generation, code interpreter, hosted shell, apply patch, skills, computer use, MCP and tool search through Responses. Use Responses when the agent needs tools. Its model page says Chat Completions is supported without tool calling. GPT-6.1 Sol model page.

The missing none reasoning effort matters for a matched test. Do not compare GPT-6.1 Sol at medium against GPT-6 Sol at none and attribute the result only to model identity. Pin reasoning effort, agent client, instructions, tool schemas, sandbox, network, credentials and repository commit. If a task needs the none setting for latency or cost, keep that as a separate runtime class rather than hiding it in the average.

The long-context price boundary still applies. Above 272,000 input tokens, all three model pages price the full request at twice the input and cache rates and one and a half times the output rate. Repository-context growth can therefore change cost before it changes acceptance.

The cache discount is useful, but it does not choose the model

For 200,000 uncached input tokens and 20,000 output tokens, current Standard rates produce $0.60 of token cost for either Sol version and $0.03 for Luna. The arithmetic is illustrative: (0.2 × input rate) + (0.02 × output rate). It excludes cache writes, tools, sandbox execution, retries, evaluation, review and rework.

With 180,000 cached input tokens, 20,000 uncached input tokens and 20,000 output tokens, GPT-6.1 Sol costs $0.258 and GPT-6 Sol costs $0.276 at the published rates. The cached-input improvement saves 1.8 cents in that example. It helps repeated-context workloads, but the production decision still turns on accepted patches and human burden.

Use the 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.

Amazon Bedrock exposes another provider path and supports explicit prompt caching for GPT-6.1 Sol. GitHub Copilot wraps model usage in its own product and billing controls. Treat provider and harness as part of the runtime tuple. A Copilot result, a direct OpenAI API result and a Bedrock result should not share one row merely because the model family name matches.

Public evaluations qualify the canary, not the rollout

OpenAI reports that GPT-6.1 Sol exceeds GPT-6 Sol's best DeepSWE v1.1 score by 6.4 percentage points at lower reasoning effort and cost. On the OSWorld 2.0 offline set, OpenAI reports a seven-point improvement at maximum effort and less than half the cost. Those results are strong enough to move GPT-6.1 Sol to the front of the hard-task evaluation queue. OpenAI's GPT-6.1 Sol launch.

They do not establish which model accepts more of your patches. OpenAI also states that its evaluations ran in a research environment or through the API and may differ from production ChatGPT because system prompts, tools and efforts can differ. GitHub describes fewer tokens and steps in early testing, but publishes no magnitude in the announcement. Preserve both claims as vendor evidence, not as a local production result.

The right benchmark record includes the task set, repository revision, harness, model, reasoning effort, tool inventory, evaluator, scoring rule, token accounting, pricing date and missingness policy. A percentage without that tuple cannot safely move a production route.

Build the promotion gate around a task class

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, human merge control and rollback 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 expiry. Model behavior, prices, instruction files and repository shape move. A class that belongs on GPT-6.1 Sol today may move to Luna after tests improve or the task becomes more constrained. A class can move the other way when a dependency migration changes its failure modes.