Pin GPT-6 Sol and Luna in your agent config, not your chat window

OpenAI announced GPT-6 Sol and GPT-6 Luna in the API, Codex, and ChatGPT on 2026-09-22 (Introducing GPT-6 Sol and Luna). The model docs are live: gpt-6-sol and gpt-6-luna. The announcement thread is Announcing GPT-6 Sol and GPT-6 Luna in the API, Codex, and ChatGPT.

This post is the builder cut. Pin the two IDs in owned-repo agent config, set reasoning.effort, and decide failover before the first production call. The question is not “which model is smarter.” It is which calls stay on Sol and which belong on Luna.

This is distinct from gpt-astra-computer-use-production and gpt-live-1-delegation-ai-gateway. Computer-use and live delegation are other surfaces. Sol and Luna are coding and volume IDs you put in config.

The two IDs

gpt-6-sol is priced at $2 input / $10 output per 1M tokens. OpenAI positions it for complex coding and agentic workflows.

gpt-6-luna is priced at $0.10 input / $0.50 output per 1M tokens. It is the focused, high-volume ID.

The promo line is 50% lower versus GPT-5.6. Treat that as a pricing claim on the announcement, not a quality ranking. You still pick the ID by failure mode of the call, not by the discount.

Both support reasoning.effort from none through max. Tools go through the Responses API. If your stack still talks Completions-only for tool loops, that is a migration item, not a model feature.

Pin in owned-repo config

Chat defaults are not a contract. An owned repo should name the model, effort, and failover in files that review like any other change.

A useful shape:

• model.sol: gpt-6-sol
• model.luna: gpt-6-luna
• effort.sol: typically high or max for the calls you actually keep on Sol
• effort.luna: typically none or low for classification, extract, and short codegen
• failover: Luna on Sol timeout/rate-limit, or a hard fail if the call is not allowed to degrade

Do not hide the IDs in a dashboard-only default. The PR that changes Sol to Luna should be as visible as a dependency bump. Operators should be able to grep the repo and know which path is expensive.

If you already route through an internal gateway, keep Sol and Luna as named backends. Do not collapse them into one “gpt-6” alias. The prices and the jobs are different. An alias that silently swaps IDs will burn either money or quality without a diff.

Which calls stay on Sol

Keep Sol when the call is an agentic loop, not a single completion:

• Multi-step coding: plan, edit, test, repair, with tools in the loop
• Repo-scale refactors where missing a constraint is expensive
• Tool-using agents that must hold a long context of prior tool results
• High-stakes reviews: security-sensitive diffs, migration plans, protocol changes

Sol’s job is to reduce the number of loops, not to win a cheap-token race. If you drop effort to none on those paths, you are not “optimizing Sol.” You are paying Sol rates for Luna-shaped work.

Use reasoning.effort as a first-class field next to the model ID. A Sol call at max and a Sol call at none are not the same product. Log both.

Which calls belong on Luna

Luna is for focused, high-volume work:

• Classification, routing, and ticket triage
• Extract-to-schema on short documents
• Single-file or single-function codegen with a tight spec
• Eval harnesses, synthetic labels, and bulk rewrite where you already have a checker
• The inner “summarize this tool result” step inside a larger agent, if that step does not need Sol’s loop quality

If a Luna call starts growing a tool graph and a long plan, promote that route to Sol in config. Do not “just raise Luna effort to max” as a permanent substitute. Effort is not a substitute for the ID OpenAI assigned to complex agentic workflows.

Effort and failover

reasoning.effort runs none through max. Pair it with the ID:

Failover that always falls Sol → Luna will look healthy in dashboards and quietly ship weaker plans. If the call is a coding agent, a Luna fallback should be explicit in the product (queue, human, or “degraded mode”), not a default.

Rate limits and timeouts are operational. Quality failover is a product decision. Encode it in the same config file as the model IDs.

Responses API for tools

Tool use is specified on the Responses API for these models. Keep tool definitions, call IDs, and follow-up turns in that protocol. Do not invent a parallel tool channel.

Practical checklist:

• One Responses conversation per agent episode, not a new completion per tool ping-pong unless you have a reason
• Persist tool results in the turn history you send back
• Bound the number of tool rounds; Sol is for complex loops, not unbounded loops
• Log model, reasoning.effort, tool count, and output tokens per episode

If Codex or ChatGPT is in the announcement, that is a product surface. Your owned agents should still pin IDs in repo config rather than inheriting ChatGPT’s picker.

Distinct from astra and live-1

Do not merge this rollout into computer-use or live-delegation work.

• GPT Astra computer-use production is a computer-use production ID and a different control surface.
• GPT Live-1 delegation on the AI gateway is live delegation routing.

Sol and Luna are coding/agentic versus focused volume. Mixing those posts’ runbooks with these IDs will produce the wrong pin and the wrong eval.

What to put in the PR

A minimum PR for this announcement:

1. Add gpt-6-sol and gpt-6-luna constants.
2. Map existing “complex agent” routes to Sol with an explicit effort.
3. Map high-volume focused routes to Luna.
4. Document failover: when Luna is allowed, when it is not.
5. Point reviewers at the three primary URLs, not a screenshot of a chat model picker.

Skip claims you cannot measure in your own traces. The public facts are the IDs, the two price pairs, the 50% versus GPT-5.6 promo line, effort range, Responses API for tools, and the 2026-09-22 announcement. Everything else is your routing policy.

Sources

• Introducing GPT-6 Sol and Luna — OpenAI (2026-09-22)
• GPT-6 Sol model docs
• GPT-6 Luna model docs