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

> Pin gpt-6-sol vs gpt-6-luna in agent config with reasoning.effort and Responses tools. Cost matrix and failover next to each pin — not a chat-picker default.
> By Dave · 2026-09-23
> Source: https://otf-kit.dev/blog/gpt-6-sol-luna-pin-builders

![Pin GPT-6 Sol and Luna in owned agent config](https://cdn.otf-kit.dev/blog/gpt-6-sol-luna-pin-builders/hero-20260923a.png)

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](https://openai.com/index/introducing-gpt-6-sol-and-luna/)). The model docs are live: [gpt-6-sol](https://developers.openai.com/api/docs/models/gpt-6-sol) and [gpt-6-luna](https://developers.openai.com/api/docs/models/gpt-6-luna). The announcement thread is [Announcing GPT-6 Sol and GPT-6 Luna in the API, Codex, and ChatGPT](https://community.openai.com/t/announcing-gpt-6-sol-and-gpt-6-luna-in-the-api-codex-and-chatgpt/1399925).

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](https://otf-kit.dev/blog/gpt-astra-computer-use-production) and [gpt-live-1-delegation-ai-gateway](https://otf-kit.dev/blog/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.

![Sol for agentic loops vs Luna for high-volume focused calls](https://cdn.otf-kit.dev/blog/gpt-6-sol-luna-pin-builders/inbody1-20260923a.png)

## 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.

![reasoning.effort dials and explicit failover next to each pin](https://cdn.otf-kit.dev/blog/gpt-6-sol-luna-pin-builders/inbody2-20260923a.png)

## Effort and failover

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

| Route | Model | Effort (starting point) | Failover |
| --- | --- | --- | --- |
| Agentic coding loop | `gpt-6-sol` | `high` or `max` | Retry Sol, then fail closed if the task cannot degrade |
| Focused extract / classify | `gpt-6-luna` | `none` or low | Retry Luna |
| Mixed: plan on Sol, fan-out on Luna | both | Sol high, Luna low | Luna must not silently replace Sol for the plan step |

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](https://otf-kit.dev/blog/gpt-astra-computer-use-production) is a computer-use production ID and a different control surface.
- [GPT Live-1 delegation on the AI gateway](https://otf-kit.dev/blog/gpt-live-1-delegation-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](https://openai.com/index/introducing-gpt-6-sol-and-luna/) — OpenAI (2026-09-22)
- [GPT-6 Sol model docs](https://developers.openai.com/api/docs/models/gpt-6-sol)
- [GPT-6 Luna model docs](https://developers.openai.com/api/docs/models/gpt-6-luna)