GPT-5.6 Model Selection: From Sol-Only to a Three-Model Workflow

YunLab · Model-use retrospective

Spending less while assigning work more sensibly.

After GPT-5.6 launched, I did not immediately start a new project. Most of my time still went into closing out several earlier projects and handling routine work.

My first approach to the three models was simple: Sol was the strongest, so I used Sol whenever possible. I occasionally used Terra. I hardly used Luna at all.

During one stretch near the end of July, the allowance I saw seemed to reset almost every day, so I stopped paying much attention to quota. If the allowance was there, why choose a less capable model?

After using them for a while, I began to think I had made the wrong choice.

The problem was not that Sol was inadequate. The problem was that I had treated “the most capable model” and “the right model for every part of the job” as the same thing.

Three models, not three simple quality tiers

OpenAI positions the three GPT-5.6 models differently:

Sol is the flagship model for the hardest, highest-value work that needs deep reasoning.
Terra is the balanced everyday model, combining capability, speed, and cost.
Luna emphasizes speed and affordability for frequent, high-volume, and cost-sensitive work.

Read as a product list, they can look like high, medium, and low tiers.

In my current workflow, I treat them as three different roles:

Sol handles uncertainty.
Terra organizes and advances execution.
Luna completes large amounts of work once the task is clearly specified.

This is my own orchestration, not a fixed workflow prescribed by OpenAI. The roles are not simple substitutes for one another.

What the official benchmark numbers show

OpenAI published the following results for several representative tasks on July 9:

Benchmark	Sol	Terra	Luna
SWE-Bench Pro	64.6	63.4	62.7
DeepSWE v1.1	72.7	69.6	67.2
Terminal-Bench 2.1	88.8	87.4	84.7
OSWorld 2.0	62.6	50.2	45.6
BrowseComp	90.4	87.5	83.3
OpenAI MRCR v2 8-needle (256K–512K)	91.5	89.6	41.3

The gap between the models is not constant.

On code modification and terminal tasks, Terra and Luna stay closer to Sol than I once expected. The gap widens substantially on the OSWorld computer-use benchmark, while it remains more moderate on BrowseComp. On the MRCR long-context result, Luna falls far behind, while Terra remains close to Sol.

The useful question is therefore not:

Which model is best?

It is:

Which part of this task is difficult or uncertain, and which parts are already defined well enough to give to a cheaper model?

That question became the starting point for changing my workflow.

Independent agent tests show a much larger cost gap

As of August 5, 2026, Artificial Analysis Coding Agent Index v1.3 covered 321 tasks, with three attempts per task. The results below use the Codex agent harness and the maximum reasoning setting for each model; they are not model-only scores detached from an execution environment.

Model	Coding Agent Index	Average API cost per task attempt	Average time per task attempt
Sol	67	$7.08	10.2 minutes
Terra	62	$2.21	8.4 minutes
Luna	59	$0.31	8.0 minutes

These costs are API-based estimates. They should not be converted directly into Codex subscription usage. The comparison still reveals something useful: Sol scores highest overall, but the extra capability it brings to a clearly specified execution task may not always justify the extra cost.

Luna’s score is not so low that it cannot do real work, yet its estimated cost is dramatically lower. What Luna needs is not exclusion from the workflow. It needs a clearer task description, a smaller execution boundary, and an explicit acceptance standard.

There is another detail worth keeping in mind: cheaper does not mean fewer tokens. In the same Artificial Analysis results, Luna Max used more tokens per task attempt on average than Sol Max. Model routing is not only about reducing token count. It is about applying expensive capability where that capability matters.

OpenAI’s individual benchmark results and the Artificial Analysis v1.3 composite use different tasks and scoring methods. Their numbers should not be compared directly.

The price change made model routing more valuable

On July 30, OpenAI lowered the prices of Terra and Luna while leaving Sol unchanged. For requests with no more than 272K input tokens, the resulting standard uncached API prices were:

Model	Input per million tokens	Output per million tokens
Sol	$5.00	$30.00
Terra	$2.00	$12.00
Luna	$0.20	$1.20

For requests exceeding 272K input tokens, long-context rates are higher: Sol costs $10 / $45 per million input / output tokens, Terra $4 / $18, and Luna $0.40 / $1.80. A workload using roughly 512K tokens of context therefore cannot use the table above as its cost estimate.

OpenAI also said that ChatGPT and Codex subscription prices and quota budgets had not changed; Terra and Luna would consume fewer credits in Codex and ChatGPT Work.

More important than the price table was the workflow example in OpenAI’s price-performance update: let Sol resolve uncertainty and define the plan, then let Luna implement clearly specified changes, write and run tests, and evaluate the results.

That example does not prove that my full routing method is optimal. It does support the underlying direction: using the strongest model for planning, then handing well-defined execution to a cheaper model, is not merely a cost-cutting trick.

How I choose models now

After a period of experimentation, I no longer begin with “which model is strongest?” I begin by looking at uncertainty, consequence, and execution volume.

Workflow one: relatively complex work

Sol sets the direction and refines the plan → Terra executes → Sol reviews and repairs.

I use this flow when the direction is still uncertain, the scope of impact is large, or a mistake would be difficult to reverse. Sol first takes responsibility for:

understanding the real problem;
finding conflicts between the request, permissions, and current state;
setting the modification boundary;
adding execution detail and acceptance criteria;
deciding which areas should not be changed yet.

Once the plan is specific enough, Terra executes it.

Terra’s job is not to redesign the task. It follows the agreed direction, makes the changes, runs the checks, and organizes the evidence. The work then returns to Sol for final review.

This costs less than using Sol from beginning to end. It also avoids asking Terra to guess the direction while it is already changing things.

An unfinished case: revising my machine “constitution”

I am currently revising the “constitution” for my local machine.

This constitution is not an ordinary instruction document. It defines the basic rules governing how AI works on my computer: which actions it may take directly, which actions require confirmation, how it preserves evidence, how it recovers after failure, and how different AIs hand work to one another.

The project is still unfinished, but it already provides a useful example of model routing.

I did not let Terra begin by editing files. Sol Max first had to:

audit the existing rules;
identify the actual problem;
design the new structure;
define permission boundaries;
divide the work into controlled batches;
give each batch an exact scope and acceptance standard.

Terra Max may execute a batch only after it passes Sol’s design review. When execution finishes, the work returns to Sol, which checks whether the actual changes and verification evidence match the design.

Before live execution, an independent review had already raised several risks that needed to be resolved first: privacy boundaries, over-broad authorization, protection of existing edits, and the credibility of execution evidence.

These issues were not left for the executor to patch on the fly. They stopped an immature plan before it reached the files.

Since the project remains unfinished, it does not prove that the final constitution works. It also does not prove that Terra’s execution quality has passed acceptance.

What it has shown so far is narrower: separating design from execution can expose mistakes earlier. Sometimes “no edit was made” is evidence that the review gate did its job.

I did not add Luna to this project. It is a complex, high-impact task with strict boundaries. Adding Luna merely to include all three models would increase handoff cost without improving the work.

A three-model workflow does not mean every task must use all three models.

Workflow two: simple work at large volume

When the direction is clear and each unit of work is simple, but there are many files, records, or repeated steps to process, I use a longer chain:

Sol sets the direction and refines the plan → Terra breaks down and dispatches the work → Luna executes → Terra reviews → Sol performs the final audit and repairs.

The important step is not simply “send the task to Luna.” The task must first be processed into a form Luna can execute reliably.

Sol defines:

the final objective;
the boundaries that must not change;
the input and output formats;
the conditions for success and failure;
the sampling checks and stop conditions.

Terra converts that plan into small executable tasks, controls their scope and batch size, collects Luna’s results, and performs the first review.

Luna handles only work whose rules are already clear. It does not decide the direction, and it does not expand the task on its own.

After execution, Terra checks counts, formats, errors, and omissions. Sol then decides whether the combined result actually satisfies the original goal and repairs what remains.

This flow suits work such as:

organizing many similar files;
processing data under established rules;
generating large amounts of structurally consistent content;
making tightly scoped code changes;
running repeated tests and collecting results;
handling work that can be accepted through rules or sampling.

Luna’s advantage appears only after the task has been defined well. If the task is still vague, the model cost saved during execution may return as rework.

The real saving is not one model call—it is avoided rework

I used to define saving as “using less quota” or “choosing the cheaper model.” Now I care more about the total cost of the task:

How much did direction-setting cost?
How much did execution cost?
How much rework came from unclear requirements?
Did review uncover real problems?
Did the work end in a result that could actually be accepted?

Using Sol from beginning to end wastes expensive capability when Luna could have handled the execution.

Sending an ambiguous task to Luna too early is not a real saving either, especially if the task must then be done again.

My current rule is simple:

High uncertainty: start with Sol.
Reliable execution: use Terra.
Clear requirements and high volume: use Luna.
Large consequences: return to Sol at the end.

Saving money is one result. The larger gain is that capability, responsibility, and task stage now match.

From cross-tool review to role separation inside Codex

My previous workflow was to let Claude Code execute and then let Codex review the result.

The two tools created a natural separation. The executor and reviewer did not come from the same system, and their reasoning styles, context, and blind spots were not identical.

Later, I could no longer use Claude Code, and that execution-and-review chain broke. Once all the work moved into Codex, asking one task to design, execute, and review its own result too easily became self-confirmation.

Separating design, execution, and review inside one Codex system is more cumbersome, but the division among Sol, Terra, and Luna provides one workable substitute:

Sol owns design, key decisions, and final acceptance.
Terra owns execution management and the first review.
Luna owns clearly bounded, high-volume execution.
When necessary, Sol reviews the first Sol’s design in a separate context.

This does not fully replace cross-system review between Claude Code and Codex. Sol, Terra, and Luna still belong to the same model family and may share some of the same biases.

It does, however, separate design, execution, review, and final acceptance again. Each stage has a different responsibility, a clear handoff, and a defined stop condition.

The change may not make any single answer look more intelligent. It can still improve engineering completion: fewer omissions, earlier discovery of conflicts, better execution evidence, and a greater chance that the work reaches a verified finish.

My central idea for GPT-5.6 is no longer to keep choosing the strongest model.

I let Sol handle uncertainty, Terra manage execution, and Luna carry clear, high-volume work. Then I return the final judgment to Sol.

The model choices did not change. What changed was that I began treating them as a team that needs a division of labor.