*Fact-checked July 12, 2026. Availability, limits, and rate cards can change.*
## Executive summary — TL;DR / BLUF
GPT-5.6 is easier to use when you stop treating Sol, Terra, and Luna as a quality ladder and give each one a different job:
- **Sol investigates.** Start with **Sol High** when the problem is hard, unclear, or spread across systems.
- **Terra executes.** Use **Terra Medium** when the plan, boundaries, and acceptance checks are already defined.
- **Luna processes.** Use Luna for narrow, repeatable, high-volume work with an automatic or inexpensive review path.
- **Max is an escalation, not a badge.** Pay for it after High fails because the model did not explore deeply enough.
- **Ultra is a team, not a reasoning level.** Use it only when the work can be split into genuinely independent branches.
Our week of real use reinforced one rule: **the best configuration is the cheapest one that can reliably produce a verified result.** Sol needed stopping conditions. Terra was strongest against explicit gates. Luna was reliable when the output contract was exact.
One current usage note matters: **as of July 12, the five-hour restriction for Codex and ChatGPT Work temporarily does not apply to Plus, Business, or Pro, although weekly limits still apply.** OpenAI also says its experiments with internal reasoning budgets—“juice values”—were reverted. Do not treat hidden values circulating in screenshots as stable product settings.
## The picker is asking the wrong question
“Which GPT-5.6 model is best?” sounds reasonable, but it collapses three decisions into one:
1. What kind of job is this?
2. How much exploration does it need?
3. How will I know the result is good enough?
The first decision chooses Sol, Terra, or Luna. The second chooses reasoning effort. The third determines whether the cheaper route is actually cheaper after retries and review.
OpenAI’s broad guidance is clear: Sol is for complex reasoning and coding, Terra balances capability and cost, and Luna is for cost-sensitive volume. The missing piece is an operating policy for actual work.
This is ours.
## One week with all three changed the way we route work
This was field use, not a controlled benchmark. The models handled different tasks, contexts, and settings across websites, evaluation work, research, and tooling. That means the observations are useful, but they are not universal rankings.
### Sol found the path—and sometimes kept walking
Sol handled the longest investigations. It was good when the first task was discovering what the task really was. During the fact-check for this article, a Sol review surfaced two material errors: Fast had been treated as a current GPT-5.6 control, and Codex credit consumption had been described too loosely.
The same persistence created the main failure mode. Once Sol had found the useful answer, it could keep exploring. A hard problem needs room; it also needs an exit condition.
A reliable Sol brief includes:
- the boundary of what it may inspect or change;
- the evidence required for completion;
- the protected areas it must not touch; and
- the condition under which it should stop or ask.
### Terra was strongest when the decision was already made
Terra performed well in bounded reviews and execution. When the task named its acceptance criteria, Terra found concrete enforcement and evaluation failures and returned clear approve-or-hold judgments.
That is different from asking it to own an open-ended investigation. Terra became more useful after the uncertainty had been converted into a specification.
A reliable Terra brief is simpler:
- named files or deliverables;
- explicit acceptance gates;
- a bounded definition of done; and
- no architecture expansion unless a gate proves it is necessary.
### Luna was dependable when the shape of the answer was exact
We used Luna for repeated blinded judging and structured JSON outputs. It stayed inside requested output boundaries and produced machine-checkable results. A few runs still benefited from an explicit completion reminder, which is one reason we would not make Luna the default project orchestrator.
Luna worked because validation was part of the job. The output had a schema, a fixed directory, a known count, or another deterministic check.
The practical distinction is not strong versus weak. It is:
- discovery;
- execution; and
- processing.
## Sol: use it to figure out what is true
Sol is the flagship model in the family. OpenAI positions it for complex reasoning, coding, research, science, cybersecurity, computer use, and design.
Use Sol when the path is still part of the problem:
- diagnosing a failure that crosses subsystems;
- planning a consequential migration or refactor;
- researching a question with conflicting evidence;
- coordinating work whose dependencies are not understood yet;
- recovering a project with incomplete state; or
- deciding whether the premise is even correct.
Do not use Sol merely because the work matters. A five-line known change can matter and still belong to Terra. Sol earns its cost when exploration is necessary.
The default I would test first is **Sol High**. High gives the model enough room for difficult work without automatically paying the latency and usage of Max.
## Terra: use it when the path is known
Terra is not “Sol but worse.” It is the balanced execution model.
Use Terra when the work is already decision-complete:
- implementing an approved plan;
- reviewing a diff against explicit requirements;
- writing tests for known behavior;
- carrying out a bounded migration;
- updating documentation from settled source material; or
- producing a defined deliverable with a visible finish line.
Terra’s API token price is half of Sol’s: $2.50 per million input tokens and $15 per million output tokens, compared with Sol at $5 and $30. OpenAI’s published evaluations often show a smaller capability gap than that pricing difference might imply.
My working default is **Terra Medium** for bounded execution. Increase effort when the job itself is more demanding, not because the model name feels less prestigious.
## Luna: put it inside the workflow
Luna is the fastest and lowest-cost GPT-5.6 model. Its best role is often invisible: a focused worker called by a larger system.
Use Luna for:
- classification and routing;
- extraction into a schema;
- metadata, titles, and branch names;
- record normalization;
- repeated summaries;
- simple transformations; and
- bulk outputs that can be sampled or validated automatically.
Luna’s API pricing is $1 per million input tokens and $6 per million output tokens.
The test is not “Is this task easy?” The test is:
> Is the task narrow, repeatable, and cheap to verify?
If one silent mistake can contaminate hundreds of records, add a validator, a stronger review model, or both. Cheap generation without cheap verification is not a cheap workflow.
## Reasoning effort matters as much as the model
All three GPT-5.6 API models support `none`, `low`, `medium`, `high`, `xhigh`, and `max` reasoning effort. Higher effort gives a model more room to explore, use tools, compare approaches, and revise. It does not guarantee that the improvement will justify the added latency or usage.
| Sol effort | DeepSWE score | Estimated cost per task |
| --- | ---: | ---: |
| High | 69.4% | $3.47 |
| Extra High | 70.7% | $4.70 |
| Max | 72.7% | $8.39 |
High to Max produced about 3.3 additional observed benchmark points at roughly 2.4 times the estimated task cost. The published 95% intervals overlap slightly, so the table does not prove Max will improve your next repository.
The escalation rule is more useful than the ranking:
- If High failed because it did not explore enough, try Max.
- If High failed because the brief was vague, fix the brief.
- If the environment was broken, fix the environment.
- If permissions were missing, fix the access path.
- If the premise was wrong, more reasoning will make the wrong work more expensive.
## A routing policy you can actually use
| Work state | Model and starting effort | Required verification |
| --- | --- | --- |
| Problem is unclear or crosses systems | Sol High | Evidence record, reproduction, decision, or tested plan |
| Plan and boundaries are explicit | Terra Medium | Named acceptance gates, bounded diff, or checklist |
| Task is narrow and repeatable | Luna at the lowest sufficient effort | Schema, deterministic check, sample audit, or stronger-model review |
| High failed from shallow exploration | Sol Max | Compare against the failed attempt and verify the new evidence |
| Work has independent branches | Ultra with deliberately different assignments | One synthesis owner and collision-free outputs |
If you cannot explain how the output will be checked, you have not finished routing the task.
## Check the product surface before copying a picker screenshot
The available choices differ by product:
- **Standard ChatGPT:** GPT-5.6 Sol powers Medium, High, and Extra High. Terra and Luna are not selectable there.
- **ChatGPT Work and Codex:** eligible plans can expose Sol, Terra, and Luna. Max and Ultra depend on product and plan.
- **API:** all three models are available with the published effort controls.
That is why preview screenshots age badly. A launch-day option is not a durable architecture.
## Max, Fast, and Ultra are three different things
**Max** increases reasoning effort for one model.
**Ultra** is a separate multi-agent setting that coordinates four agents by default. It is not another single-agent reasoning level above Max.
Use Ultra when the branches are genuinely independent: separate subsystems, competing approaches, or parallel research questions. Avoid it when every worker needs the same mutable files or will rediscover the same context.
Parallelism without decomposition is just duplicated spending.
## Do not mix three different cost systems
**API price** is the published token rate:
- Sol: $5 input / $30 output per million tokens;
- Terra: $2.50 / $15; and
- Luna: $1 / $6.
**Benchmark cost** is an estimate produced by one evaluation harness. DataCurve’s $3.47 or $8.39 is not the fixed price of a real coding task.
**Codex credits** use a separate rate card. For most plans, the current card maps one million input/output tokens to:
- Sol: 125 / 750 credits;
- Terra: 62.5 / 375; and
- Luna: 25 / 150.
Cached-input rates are lower. Real consumption also changes with context length, tool output, retries, and the number of agents.
Compare like with like. The lowest token price can still lose if it creates more retries or review work.
## P.S. The current five-hour limit and “juice value” situation
So the accurate statement is not “GPT-5.6 is unlimited.” It is: **there is currently no five-hour window for those plans in Codex and ChatGPT Work, the exception is temporary, and weekly limits remain.**
That means exact reduced values circulating online should not be treated as current specifications. Route against the controls OpenAI actually publishes, then measure the verified result in your own work.
## The mental model I would keep
- **Sol investigates.** Give it uncertainty, evidence requirements, and a stopping condition.
- **Terra executes.** Give it a decided plan, explicit gates, and a bounded finish line.
- **Luna processes.** Give it a narrow contract and cheap validation.
- **High is the starting point for hard work.**
- **Max must answer a diagnosed need.**
- **Ultra is a team design problem.**
The best GPT-5.6 setup is not the strongest combination in the picker. It is the least expensive combination that can reliably finish the real job and leave behind evidence you trust.
---
## Sources and attribution
This guide combines OpenAI’s current product documentation, DataCurve’s independent benchmark artifact, one week of our own non-controlled field use, and Theo Browne’s preview-era review as one secondary source. Field observations are not controlled evaluation results.