GPT-5.6 gives you three choices in Codex: Sol, Terra, and Luna. The official descriptions explain what each is for. Sitting in front of actual work, you still have to ask: which one do I pick for this?
When they launched I used a crude rule: Sol if it looks hard, Terra or Luna if it looks light. After running article production, web development, research, WordPress updates, and pre-publication QA through them, task size turned out to be the wrong axis.
So I froze the dataset at 66 schema-validated production runs recorded through July 22, 2026 and reconsidered how I route work.
The conclusion: Luna for clearly defined repetitive work, Terra for normal operations, Sol when the task is ambiguous and failure is expensive.
This is not a ranking. It is a routing record from one environment, based on four properties of the work: ambiguity, blast radius on failure, repetitiveness, and whether it can be rolled back.
Originally published in Japanese on July 23, 2026. This English version was written in September 2026.
Note for readers arriving later: OpenAI has since added GPT-6 Astra to Codex, and the model picker now covers Astra alongside Sol, Terra, and Luna. The routing record below covers only the three GPT-5.6 options, observed through July 22, 2026. The reasoning — route by ambiguity and blast radius rather than by a capability ranking — is what I would still apply to a four-model picker.
The routing rule
Before reaching for a model name, I ask four questions:
- How bad is it if this fails?
- Is the request, or the correct answer, ambiguous?
- Does this repeat the same shape every time?
- Can I roll it back easily?
| Character of the work | First choice | Escalate when |
|---|---|---|
| Clear, repetitive, reversible | Luna / low-to-mid effort | Judgment or publication impact enters → Terra |
| Normal implementation, research, article diffs, daily operations | Terra / low-to-mid effort | Multiple domains, ambiguous spec, or serious impact → Sol |
| Complex, ambiguous, high-value, long-running, final judgment | Sol / start at low effort | Security, migration, complex design → raise effort |
OpenAI’s guidance positions Sol for complex or ambiguous work, Terra for everyday work, and Luna for clear, repeatable work.
OpenAI’s own guidance already points the same way: Terra is described as a natural starting point for work you previously gave GPT-5.5, and the docs say to use the lowest reasoning effort that produces the result you need. What my records add is the escalation trigger. I move to Sol when ambiguity or blast radius becomes visible, and drop to Luna once the output format is fixed — which is only affordable because independent QA and rollback are already in the pipeline, lowering the cost of starting one tier too low.
What the 66 runs actually are
66 schema-validated production runs through July 22, 2026. 62 completed: Sol 41, Terra 19, Luna 2. From completion summaries and artifact metadata I recorded completion state, whether the first output was usable as-is, revision count, human intervention, and issues found by independent QA.
| Model | Runs | Complete | First output usable | Revisions | Human intervention | QA issues |
|---|---|---|---|---|---|---|
| Sol | 43 | 41 | 30 | 22 | 7 | 47 |
| Terra | 21 | 19 | 13 | 22 | 4 | 24 |
| Luna | 2 | 2 | 1 | 2 | 0 | 2 |
Revisions counts total revision events, not runs that needed a revision, which is why Terra shows 22 revisions across 21 runs.
Read these numbers carefully, because they are not a benchmark. This was not an A/B test with tasks randomly assigned across three models. Sol received most of the complex development, long-running work, and publication decisions. Terra received daily operations, research, and routine articles. Luna has only two runs and generalizes to nothing.
QA issue counts are not failure counts either. Harder work with more checkpoints produces more findings. Browser connection, network, and external tool failures were tracked separately from model quality.
So you cannot derive “Sol’s success rate is X%” from this. What you can derive is which characteristics of work produced revisions and interventions, and where independent QA closed things out most reliably.
Sol: choose it for blast radius, not for length
In my records Sol fit work that integrates multiple outputs, changes spanning several repositories, database and migration work, final pre-publication judgment, and long-horizon goals.
The decisive property is how hard it is to undo. A long piece of writing is fine on Terra. A short change that touches public URLs, data, permissions, or an external service is worth Sol.
Choosing Sol did not remove the need for QA. Design inconsistencies, final screen states, the meaning of a measurement window, and post-publication rendering were all caught and corrected by a human or an independent reviewer.
I also start Sol at low reasoning effort, raising it only for security, architecture, or serious incidents where exploration breadth and failure cost are both high. Isolating the decisions that genuinely need Sol works better than running everything at maximum.
Terra: the default, with a check at the end
Terra is my first choice for normal operations: researching official documentation, scoped updates, article diffs, daily processing, ordinary implementation.
I initially suspected lighter models would skip required documentation. That hypothesis did not reproduce in the production runs.
Where weakness did appear was in reconciling technical specifications across multiple locations, closing final completion conditions, and finishing post-publication verification. That is not “Terra is sloppy.” The work was correct partway through; getting other files, published HTML, metadata, and rollback all aligned required a verification design.
Hand normal work to Terra, put a checklist or independent QA at the end, and escalate to Sol when ambiguity or high impact surfaces there. That flow keeps quality without making Sol the default.
Luna: narrow work, and only two runs
Luna handles extraction, classification, format conversion, and table shaping — work where the correct output form is decided in advance, the input/output contract is explicit, failure means re-running, and QA follows downstream.
Two production runs supports no generalization at all. I would not extend it to new design, publication decisions, product identification, or ambiguous prose quality on this evidence.
What Luna suits is not “work that needs no thought” but “work whose decision space was narrowed beforehand.” Use it with something after it: Terra or Sol making the judgment, or a human reviewing the diff. Luna is the result of decomposing a process, not a way to offload one.
Do not raise reasoning effort before you need it
After picking a model, I still start at the lowest effort that meets the quality bar, raising it only when ambiguity or failure cost justifies it. Because model and effort vary together, I cannot say “Sol always consumes N times more.”
One caution on cost: OpenAI’s published API token prices and a Codex subscription’s usage allowance are different things. API pricing applies to API usage. You cannot convert a weekly Codex allowance into those figures, or treat them as a fixed per-model consumption rate.
Why routing matters more than ranking right now
Part of the reason I wrote this up is that access conditions elsewhere shifted. Anthropic announced on June 30, 2026 that Claude Fable 5 would return from July 1, counted within up to 50% of the weekly allowance on eligible plans through July 7, and available via usage credits after that — a mechanism for continuing at standard API rates once a plan’s included allowance is exhausted.
Community discussion at the time included people weighing a move toward Codex, but I am not treating forum reaction as a market conclusion, and comparing Claude against Codex is not the point here. The relevant shift is this: when access conditions change, “which model is most capable” matters less than “which model should this particular task go to.” That is exactly why the three GPT-5.6 options should not sit on one ranking table.
How I route today
| Task | Model / effort |
|---|---|
| Extraction, classification, table shaping, fixed diffs | Luna / low-to-mid |
| Normal implementation, official research, article diffs, daily operations | Terra / low-to-mid |
| Complex design, multi-repo, publication incidents, final judgment | Sol / low, raised when needed |
Rather than routing everything to Sol, decompose the work and escalate only the decisions that need it. Keep independent QA and rollback regardless of model.
Unsure? Terra. Expensive to get wrong? Sol. Output format already fixed? Luna.
At 66 observed runs, that is the routing that closes most reliably in my environment. I will revisit it when the models or allowances change, or when I have comparable records for the same task types.
References
- Codex models (OpenAI Developers)
- Redeploying Claude Fable 5 | Anthropic — the announcement covering the June 30 dates and access conditions
- Manage usage credits for paid Claude plans | Claude Help Center — how the usage credits mechanism itself works