Do Not Confuse Model Tier with Reasoning Depth

title: "Do Not Confuse Model Tier with Reasoning Depth: When Luna Max Can Catch Terra Medium—and Why Sol Medium May Be More Rational Than Terra X-High" subtitle: "The practical economics of GPT-5.6: quality, reasoning tokens, latency, model routing, and multi-agent systems" language: "en" date: "2026-07-10" keywords:

• GPT-5.6
• OpenAI
• Luna
• Terra
• Sol
• reasoning effort
• X-High
• Max
• Ultra
• reasoning tokens
• token cost
• model routing
• Codex
• multi-agent
• subagents
• evals
• latency

When Luna Max Can Catch Terra Medium—and Why Sol Medium May Be More Rational Than Terra X-High

Current as of: July 10, 2026.

> Core argument: a weaker model at a high reasoning effort can sometimes match a stronger model at Medium. But “can match” and “is the best choice” are different claims. Higher effort can sharply increase reasoning-token consumption, latency, and cost. The correct comparison is not the label in the model picker. It is the cost of an accepted result under explicit quality and latency requirements.

Every external fact, price, and benchmark result in this article has a source. Formulas and cross-configuration comparisons are identified as calculations derived from official pricing and published benchmark data. Recommendations are engineering conclusions, not verbatim OpenAI policy.

Executive conclusion

Yes, Luna Max can outperform Terra Medium on a particular class of tasks. On GeneBench-Pro, Luna Max posted a nominal pass rate of 16.5%, versus 13.6% for Terra Medium. But Luna Max used an average of 118.2K trace/response tokens, compared with 15.9K for Terra Medium. At current API rates, the output side alone would cost about $0.709 versus $0.239—almost three times as much.[^genebench][^models]

Yes, Terra X-High can be a candidate alternative to Sol Medium on some workloads. Yet the same benchmark produced the opposite result: Sol Medium scored 22.5%, versus 18.8% for Terra X-High, while using 14.4K tokens rather than 31.1K. Its calculated output-side cost was also slightly lower: $0.432 versus $0.467.[^genebench][^models]

Higher effort on a cheaper model is therefore not a free “tier upgrade.” Sometimes it closes the quality gap. Sometimes it does not. Sometimes it closes the gap but makes the request slower and more expensive than using a stronger model at a lower effort. OpenAI consequently recommends using the lowest reasoning effort that reliably produces the required result, reserving max for the hardest quality-first workloads, and comparing it against xhigh on representative tasks.[^guidance][^codex-models]

1. GPT-5.6 exposes two independent control axes

With GPT-5.6, the user chooses at least two things:

1. the model tier: Luna, Terra, or Sol;
2. the reasoning depth: none, low, medium, high, xhigh, or max.

OpenAI positions Luna for efficient, high-volume, well-defined tasks; Terra as the balanced everyday all-rounder; and Sol as the flagship for complex professional work, ambiguity, deeper analysis, and coding.[^models][^codex-models]

Table sources: OpenAI’s model catalog and Codex model guidance.[^models][^codex-models]

Crucially, reasoning effort is not a different model. It constrains how much reasoning the selected model applies to the task. OpenAI states that higher effort generally increases response time and reasoning-token usage, although it can improve quality on difficult work.[^reasoning][^subagents]

A useful engineering interpretation is:

• model tier defines the underlying capability, price, and speed envelope;
• effort determines how deeply the selected model explores the problem within that envelope.

This is not an official statement about architecture or parameter count. It is a practical selection model derived from OpenAI exposing model choice and reasoning effort as separate controls.[^guidance]

2. Why does Luna have X-High and Max at all?

At first, the product matrix may look redundant. If Luna is intended for clear, high-volume work, why give it xhigh and max? Why not simply move to Terra?

Because model tier and inference budget address different failure modes.

High effort can be useful when the task remains narrow and well specified but requires more checking, search, or careful execution across a long sequence. The desired output, acceptance criteria, and permitted actions may already be known; the difficulty may lie in not missing an exception or in validating many conditions. OpenAI explicitly recommends Luna for extraction, classification, transformation, and structured summaries, while advising users to increase effort when a task requires more planning, analysis, or checking.[^codex-models]

Luna is also 2.5 times cheaper than Terra for both input and output tokens. It can therefore spend materially more tokens and still remain cheaper—until token expansion crosses the break-even point.[^models]

But the existence of a setting does not mean it should be the default. Codex documentation says Max gives the selected model more time on a single task, is intended for the hardest problems, and that most tasks need neither Max nor Ultra. OpenAI’s API guidance similarly says to reserve max for the hardest quality-first workloads and compare it with xhigh using your own evals.[^codex-models][^guidance]

In other words, Luna Max exists not because it should universally replace Terra, but because some narrow workloads benefit more from extra reasoning on a cheap model than from changing model tier. That remains a hypothesis until measured.

3. X-High does not turn Luna into Terra, and Max does not turn Terra into Sol

A common mistake is to read the options as one continuous ladder:

> Luna Medium → Luna High → Luna X-High → Terra Medium → Terra High → Sol Medium.

OpenAI does not define such a ladder. Its documentation even warns that there is no exact mapping of reasoning levels across model generations and recommends testing familiar tasks at multiple settings.[^codex-models]

Why a direct conversion does not exist:

• a stronger model may identify the correct problem formulation earlier;
• a weaker model may spend a long time exploring the wrong branch;
• extra effort helps only when the failure is actually recoverable through more search, checking, or planning;
• if the bottleneck is broader judgment, ambiguity resolution, or robustness across a long dependent chain, extra tokens alone may not be enough.

Those four points are an engineering interpretation of observable behavior, not a disclosure of model internals. They must be tested on the target workload. OpenAI likewise recommends representative real-world evals and warns against assuming the highest effort is automatically the best trade-off.[^evals][^optimization][^guidance]

The defensible statement is therefore:

> A weaker model at high effort can overlap in quality with a stronger model at low or medium effort on a particular task distribution. That overlap does not create universal equivalence.

4. The real cost model: reasoning tokens are billed as output

For a simplified API comparison without caching or paid tools, use:

\[ C_m = p_{in,m}\cdot I + p_{out,m}\cdot G_m, \]

where:

• \(C_m\) is request cost on model \(m\);
• \(I\) is input tokens;
• \(G_m\) is all generated tokens, including visible output and hidden reasoning tokens;
• \(p_{in,m}\) and \(p_{out,m}\) are the model’s input and output rates.

Reasoning tokens are not returned as normal visible text, but they occupy context, appear in the usage object, and are billed as output tokens.[^reasoning]

At current GPT-5.6 rates:[^models]

\[ C_{\text{Luna}} = 1I + 6G_L, \]

\[ C_{\text{Terra}} = 2.5I + 15G_T, \]

\[ C_{\text{Sol}} = 5I + 30G_S, \]

when \(I\) and \(G\) are measured in millions of tokens and cost is in US dollars.

Luna versus Terra

With identical input, Luna is cheaper than Terra when:

\[ 1I + 6G_L < 2.5I + 15G_T, \]

or:

\[ G_L < 2.5G_T + 0.25I. \]

For an output-heavy task with a small prompt, Luna can use roughly up to 2.5 times as many generated tokens as Terra and still remain cheaper. Once token usage expands by three, five, or seven times, that price advantage may disappear.

Terra versus Sol

With identical input, Terra is cheaper than Sol when:

\[ 2.5I + 15G_T < 5I + 30G_S, \]

or:

\[ G_T < 2G_S + \frac{I}{6}. \]

For an output-heavy workload, Sol can become cheaper than Terra if it solves the problem with less than roughly half as many generated tokens.

Luna versus Sol

With identical input, Luna is cheaper than Sol when:

\[ G_L < 5G_S + \frac{2I}{3}. \]

Luna therefore has a large per-token price cushion against Sol. That cushion says nothing about answer quality, retries, or the cost of failure.

All three inequalities are calculations derived from OpenAI’s official prices.[^models]

5. API dollars and Codex credits preserve the same ratios

Under Codex’s current token-based credit system, rates per one million tokens are:

The Sol : Terra : Luna ratio is therefore 5 : 2.5 : 1 for both input and output—the same ratio as API dollar pricing. The break-even relationships above also apply to token-based Codex credits after multiplication by a common factor.[^codex-pricing]

Do not automatically transfer those formulas to every ChatGPT interface. A particular plan may meter messages, limits, or credits under its own rate card. Financial analysis should use the billing rules of the product where the workload actually runs.[^chatgpt-rate]

6. What else belongs in the cost calculation

The simplified token formula is useful, but a real production request can contain additional cost components:

• cached input;
• creation of a new prompt cache;
• web search, file search, containers, and other paid tools;
• retries after failures;
• parallel subagents;
• human review and correction.

For GPT-5.6, reasoning tokens are included in output billing. Tokens introduced through built-in tools are also billed at the selected model's token rates, while the tools themselves may carry separate fees.[^reasoning][^pricing]

Prompt caching changes the economics of long, repeated prompts. Cache reads receive a 90% discount relative to ordinary input, while GPT-5.6 cache writes are priced at 1.25 times the standard input rate. A system with a large, stable prefix can therefore have a materially lower effective input cost than the basic formula suggests.[^caching]

The GPT-5.6 model pages also specify higher rates when the input exceeds 272K tokens: the entire request is charged at 2 times the standard input rate and 1.5 times the standard output rate. This changes both the absolute cost and the importance of input in break-even calculations.[^long-context]

A production metric should therefore be broader than “price per token”:

\[ \text{Cost per accepted result} = \frac{\text{all tokens + tools + retries + review}} {\text{number of accepted results}}. \]

This is an operational metric proposed in this article. It reflects a basic economic reality: a cheap request that frequently requires rework can cost more than an expensive request accepted on the first attempt.

7. Why “thinks longer” usually means “slower,” but not by a fixed timer

Reasoning effort is not a fixed number of seconds. It controls the depth of reasoning available to the model, while the actual number of reasoning tokens depends on the task. OpenAI states that reasoning models may use anywhere from hundreds to tens of thousands of reasoning tokens, and that higher effort generally increases response time and token usage.[^reasoning][^subagents]

Text-generation latency is driven primarily by the selected model and the number of generated tokens; a substantial share of end-to-end latency commonly occurs during generation. A configuration that produces five times as many reasoning and response tokens will therefore usually suffer a meaningful latency penalty, even though the relationship need not be perfectly linear.[^latency]

The practical conclusion is simple:

> A lower price per token guarantees neither a lower total cost nor a lower latency.

It only gives the model a larger budget cushion that may be spent on a longer reasoning trace.

8. A useful experiment: GeneBench-Pro

GeneBench-Pro is a specialized benchmark containing 129 difficult tasks in multistage statistical reasoning across genetics, genomics, and adjacent biology. It is not a universal benchmark for coding, document work, or business analysis, so it should not be treated as an absolute ranking of the models. It is especially useful for this discussion, however, because it reports results across reasoning settings together with average token use.[^genebench]

In the table below:

• pass rate comes from Supplementary Table 1;
• tokens are the average full model trace plus final response;
• tool calls are excluded from that token figure;
• “output cost” is this article's calculation using the official output-token rate;
• input and tool fees are excluded.[^genebench][^models]

A necessary statistical caveat

The published results include confidence intervals. Luna Max, for example, has a 16.5% pass rate with a 95% interval of 11.6–21.7%, while Terra High has 16.2% with an interval of 11.6–21.2%. Those ranges almost completely overlap. The correct statement is therefore that they produced comparable nominal results in this experiment—not that Luna Max was proven superior.[^genebench]

9. Luna X-High versus Terra Medium: higher effort did not close the gap

In GeneBench-Pro:

• Luna X-High: 10.8%, 53.1K tokens, approximately $0.3186 of output cost;
• Terra Medium: 13.6%, 15.9K tokens, approximately $0.2385 of output cost.

Luna X-High used 3.34 times as many trace/response tokens, achieved a lower result, and had an output component about 34% more expensive. This is a concrete example in which “turning up” the weaker model neither reached the next tier's quality nor preserved its output-cost advantage.[^genebench][^models]

Total cost still depends on input. Luna saves $1.50 per million standard uncached input tokens relative to Terra. With identical input of roughly 53.4K tokens, that input saving would offset the output-cost difference in this comparison. This is a calculation from the standard rates. Luna X-High's measured benchmark quality would still remain lower.[^models]

The conclusion is not that Luna X-High is useless. It is that Luna X-High cannot be treated as an automatic substitute for Terra Medium. For short and medium inputs, Terra Medium is the more rational configuration in this experiment. With very long inputs, Luna may recover a total-cost advantage, but not necessarily a quality advantage.

10. Luna Max versus Terra Medium and Terra High: catching up can become economically absurd

The same benchmark reports:

• Luna Max: 16.5%, 118.2K tokens, $0.7092 of output cost;
• Terra Medium: 13.6%, 15.9K tokens, $0.2385 of output cost;
• Terra High: 16.2%, 22.2K tokens, $0.3330 of output cost.

Luna Max nominally exceeded Terra Medium and approximately matched Terra High. It did so while using:

• 7.43 times as many tokens as Terra Medium;
• 5.32 times as many tokens as Terra High;
• about 2.97 times the output cost of Terra Medium;
• about 2.13 times the output cost of Terra High.

These ratios are calculations from the published average token counts and official rates.[^genebench][^models]

With the same standard-priced input, Luna Max would become cheaper than Terra High only at approximately 250.8K identical input tokens. That is already close to the 272K threshold at which GPT-5.6 long-context pricing changes.[^models][^long-context]

This separates two very different questions:

• Can Luna Max reach Terra-level quality on some tasks? Yes, sometimes.
• Is Luna Max a rational substitute for Terra? Often, no.

For output-heavy tasks, this can be a particularly poor trade. Luna Max may still be justified when the input is extremely large, the task is tightly constrained, switching models is operationally undesirable, and first-party evaluations show a real gain. Without those conditions, Terra Medium and Terra High deserve a mandatory comparison.

11. Sol Low versus Terra Medium: the stronger model may win at lower effort

GeneBench-Pro also provides the reverse pattern:

• Sol Low: 14.4%, 5.6K tokens, $0.1680 of output cost;
• Terra Medium: 13.6%, 15.9K tokens, $0.2385 of output cost.

Sol Low achieved a slightly higher nominal result, used approximately 65% fewer tokens, and had an output component about 30% cheaper.[^genebench][^models]

Sol is more expensive on input. With identical uncached input, Terra Medium recovers the total-price advantage when the shared input exceeds approximately 28.2K tokens. This is a calculation from the official rates.[^models]

The point is not that Sol Low is universally better than Terra Medium. The point is:

> A stronger model at lower effort can be more efficient than a weaker model at medium effort because it finds a productive reasoning path sooner.

Here, that observation is supported by one specialized benchmark. It must not be generalized to every workload without evaluation.

12. Terra X-High versus Sol Medium: the central comparison for difficult professional work

This is one of the most useful pairs to A/B test in practice:

• Terra X-High: 18.8%, 31.1K tokens, $0.4665 of output cost;
• Sol Medium: 22.5%, 14.4K tokens, $0.4320 of output cost.

In GeneBench-Pro, Sol Medium was nominally stronger, used 2.16 times fewer tokens, and had an output component about 8% cheaper.[^genebench][^models]

Terra has cheaper input. With identical standard uncached input above approximately 13.8K tokens, the total cost of Terra X-High could become lower despite its more expensive output. This again shows why neither reasoning-token volume nor model price can be considered in isolation.[^models]

For a real workflow, the choice depends on its profile:

• short input, difficult reasoning, and expensive failure: Sol Medium may be more rational;
• long input, large code or document corpus, and acceptable quality trade-off: Terra X-High may retain a total-cost advantage;
• latency-sensitive work: 31.1K versus 14.4K generated tokens is a serious argument for Sol Medium, although actual wall-clock latency must be measured directly.[^latency]

13. Terra Max versus Sol Medium and Sol High: another warning against overdriving effort

Terra Max nominally exceeded Sol Medium by only 0.8 percentage points, with overlapping confidence intervals. It used 3.77 times as many tokens and had 1.89 times the output cost.[^genebench][^models]

Sol High nominally exceeded Terra Max, used 2.78 times fewer tokens, and produced an output component about 28% cheaper. With identical input, Terra Max could regain a total-cost advantage only above roughly 91.8K input tokens. That threshold is calculated from the standard rates.[^models]

The practical rule is:

> Once a workload reaches Terra X-High or Max, Sol Medium and Sol High should be included in the mandatory comparison set.

This is not a universal law. It is a rational testing policy supported by OpenAI's advice to compare effort settings on representative workloads and by the benchmark evidence above.[^guidance][^evals][^genebench]

14. The marginal return from Max declines

According to GeneBench-Pro, moving from xhigh to max produced:

• Luna: +5.7 percentage points for an additional 65.1K tokens;
• Terra: +4.5 percentage points for an additional 23.2K tokens;
• Sol: +1.9 percentage points for an additional 7.5K tokens.

These differences are calculated from Supplementary Table 1.[^genebench]

The quality gains are real in the reported point estimates, but they require substantial additional trace. Luna is the clearest example: Max improved materially over X-High, but average token use more than doubled from 53.1K to 118.2K.[^genebench]

This does not prove a universal law of diminishing returns for every task. It does support OpenAI's recommendation not to deploy max globally and to compare it directly with xhigh on the actual workload.[^guidance]

15. When Luna X-High or Max can still make sense

High-effort Luna can be rational when several conditions hold at the same time:

1. The task is clear and repeatable. Correctness criteria are known, outputs can be validated automatically, and ambiguity is limited. This matches OpenAI's stated role for Luna.[^codex-models]
2. The dominant failure mode is insufficient checking, not insufficient judgment. This is an engineering hypothesis that should be confirmed by reviewing failure traces.
3. Input is large or highly cacheable. Luna's cheaper input can offset additional generated tokens.[^models][^caching]
4. More effort produces a measured pass-rate gain. OpenAI recommends using High and X-High only where they show value and reserving Max for the hardest quality-first tasks.[^guidance]
5. Changing model tier reduces stability in a specific production pipeline. This must be demonstrated by evaluation rather than assumed.
6. The cost of failure is low, or an automatic validator protects the downstream system. Under those conditions, it may be reasonable to give the cheaper tier a larger reasoning budget.

When these conditions do not hold, Luna X-High or Max often becomes an attempt to compensate for a capability ceiling with brute-force compute.

16. When it is better to move directly to Terra

Terra is the natural baseline when a task:

• is not entirely mechanical;
• requires several tools;
• contains multiple dependent stages;
• involves debugging, planning, or checking assumptions;
• recurs frequently but does not require Sol's maximum capability headroom.

This aligns with OpenAI's description of Terra as a pragmatic all-rounder for everyday work with strong reasoning and tool use.[^codex-models]

A practical baseline is:

• Terra Medium for ordinary multistep work;
• Terra High for difficult debugging, migration plans, reviews, and substantial trade-offs;
• Terra X-High only when Medium or High fails the evaluation and Sol Medium does not offer a better result;
• Terra Max as a quality-first exception, not a default.

Those four bullets are this article's operating policy, consistent with the official principle of using the lowest effort that produces the required result.[^codex-models][^guidance]

17. When Sol Medium is more rational than an overdriven Terra

Sol Medium is particularly appropriate when the problem is:

• ambiguous;
• poorly formalized;
• dependent on autonomous strategy selection;
• constrained by many sources or conflicting requirements;
• expensive to get wrong;
• architectural, research-heavy, or dependent on long agentic follow-through.

OpenAI positions Sol for complex, open-ended, and high-value work. Codex Power also uses gpt-5.6-sol with Medium reasoning as its default configuration.[^codex-models]

For architecture, stack selection, a difficult migration, a large implementation plan, or an open-ended investigation, the comparison set should commonly include:

• Terra High;
• Terra X-High;
• Sol Medium;
• sometimes Sol High.

GeneBench-Pro shows that Sol Medium can exceed Terra X-High in both quality and token efficiency, but that result comes from one domain. The production decision must be made on the user's own tasks.[^genebench]

18. Sol High, X-High, and Max are not reserved only for “impossible” tasks

Describing these modes solely as tools for nearly impossible problems is too narrow. OpenAI presents High and X-High as settings for difficult multistep workflows, deep planning, complex debugging, research, and high-value work. max is intended for tasks where quality matters more than latency and token use.[^reasoning][^guidance]

Rational examples include:

• a final architecture decision with expensive consequences;
• a difficult security review;
• research involving multiple hypotheses and verification steps;
• a critical migration;
• a long agentic workflow in which an early mistake propagates at high cost.

A high-value decision still does not imply that Max should be selected automatically. Medium should be tested first, then High, then X-High. Max should follow only when it provides a measured gain.[^guidance]

19. Max and Ultra are fundamentally different modes

Max gives one selected agent more reasoning budget for one task. Ultra uses subagents to process suitable parts of complex work in parallel. In ChatGPT Work, Ultra applies maximum reasoning and can proactively delegate appropriate subtasks; in the API, the closest mechanism is the multi-agent beta.[^codex-models][^subagents][^guidance]

Ultra should not be understood as one more step above Max on the same scalar ladder. It is a different computational structure:

• Max deepens one reasoning stream;
• Ultra broadens the work across multiple streams;
• parallelism can reduce wall-clock time;
• total token consumption usually rises because every subagent performs its own model and tool work.[^subagents]

Ultra is best suited to tasks that decompose cleanly into independent branches: researching several sources, parallel security/test/maintainability reviews, examining separate modules, or producing several alternatives. OpenAI advises caution with parallel write-heavy workflows because simultaneous code changes can introduce conflicts and coordination overhead.[^subagents]

20. A “Sol adviser + Terra workers” architecture is reasonable

Local Codex supports custom agents with different models, reasoning settings, and instructions. OpenAI's documentation explicitly points to Terra for read-heavy scans, exploration, large-file review, and supporting-document work, while stronger GPT-5.6 configurations are appropriate for ambiguous multistep planning and final follow-through.[^subagents]

A practical topology can look like this:

Coordinator

Sol Medium or High

• decomposes the problem;
• defines success criteria;
• assigns independent branches;
• resolves contradictions;
• synthesizes the final answer.

Worker agents

Terra Medium

• codebase exploration;
• reading large documents;
• fact collection;
• running tests;
• building comparison matrices.

Terra High

• security review;
• architecture-risk analysis;
• edge-case analysis;
• adversarial review of the plan.

Luna Medium or High

• extraction;
• classification;
• normalization;
• format conversion;
• structured summaries.

Final review

Sol High

• checks global consistency;
• resolves conflicts between worker reports;
• identifies omitted risks;
• produces the final decision.

This is an architectural recommendation from this article, based on OpenAI's published model roles and support for per-agent model and reasoning configurations.[^subagents][^codex-models]

It is especially useful when the expensive model is needed for framing and synthesis while most reading and mechanical work can be delegated to cheaper workers. Savings are not guaranteed: subagents consume additional total tokens, so the number of branches, delegation depth, and returned context should be bounded.[^subagents]

21. Choosing a configuration by type of work

This table is a practical recommendation, not an official OpenAI routing matrix. Its factual basis is the published positioning of the models, model guidance for reasoning effort, and the subagent documentation.[^codex-models][^guidance][^subagents]

22. Diagnose the type of failure before raising effort

Increasing reasoning effort is not the right response to every failure.

Failure type A: the model failed to check something obvious

Examples:

• it did not cover every condition;
• it failed to reconcile two sources;
• it did not run or inspect a test;
• it missed an edge case;
• it stopped too early.

The next experiment may be to raise effort by one level, add explicit success criteria, or require a tool-based verification step.

Failure type B: the model framed the problem incorrectly

Examples:

• it misunderstood the objective;
• it selected a weak architecture;
• it missed the central trade-off;
• it could not maintain a long chain of dependencies;
• it confidently optimized the wrong metric.

The next experiment is more likely to be a higher model tier, better context, or better decomposition—not an immediate jump to Max.

This distinction is a diagnostic heuristic. OpenAI recommends examining real failure traces, making one targeted change, and rerunning the same evaluation cases rather than changing the prompt, model, and effort simultaneously.[^prompt-guidance][^optimization]

23. The right experiment is not “which model is smarter?” but “which configuration meets my SLA?”

Selecting a configuration requires a small but representative evaluation set. OpenAI treats evals as a core component of reliable AI applications and recommends test data that resembles actual production inputs.[^evals][^optimization]

At minimum, measure:

• the share of tasks completed fully successfully;
• the share accepted by a reviewer without edits;
• error severity;
• the number of retries;
• input, cached-input, and output/reasoning tokens;
• tool-call count;
• p50 and p95 latency;
• cost per request;
• cost per accepted result;
• human review time.

Each candidate should receive the same prompt, context, tools, and evaluation cases. Do not rewrite the prompt, change the model, and increase effort in the same experiment: the result will not reveal which variable caused the change. OpenAI's migration guidance recommends preserving the baseline, modifying one variable, and rerunning the evaluation.[^prompt-guidance]

A practical candidate set

For clear, high-volume tasks:

• Luna Medium;
• Luna High;
• Luna X-High;
• Terra Low;
• Terra Medium.

For ordinary difficult work:

• Terra Medium;
• Terra High;
• Terra X-High;
• Sol Low;
• Sol Medium.

For quality-first work:

• Sol Medium;
• Sol High;
• Sol X-High;
• Sol Max;
• multi-agent or Ultra when the task decomposes cleanly.

The winner is not the configuration with the largest benchmark score. It is the least expensive configuration that meets the required quality, latency, and risk thresholds.

24. Routing is usually better than one global model setting

Using one configuration for an entire product is rarely efficient. A routing policy is more useful:

If the task is clear, repeatable, and automatically verifiable:
    start with Luna Medium

If the task is multistep but familiar and well bounded:
    start with Terra Medium

If the task is ambiguous, high value, or requires autonomous strategy:
    start with Sol Medium

If the result fails because checking was insufficient:
    raise effort by one level

If the result fails because the framing or judgment was weak:
    move to the next model tier

If the task decomposes into independent branches:
    use subagents and keep the stronger model as coordinator

This is this article's proposed routing policy. It follows OpenAI's guidance to select the model for the workload, use the lowest sufficient effort, and apply multi-agent orchestration when the task can be separated into independent workstreams.[^guidance][^subagents]

A second useful pattern is result-based escalation:

1. a cheaper configuration performs the first pass;
2. a validator checks structure, tests, or factual constraints;
3. only failed or ambiguous cases escalate to a stronger configuration;
4. the stronger model receives a concise failure report rather than the entire noisy reasoning history.

Such a cascade can be more economical than running Sol High or Max on every request. This is an engineering recommendation that should be validated on the actual workload.

25. Direct answers to the central questions

Can Luna Max beat Terra Medium?

Yes, on some tasks. GeneBench-Pro shows a nominal crossover: 16.5% versus 13.6%. Luna Max, however, used 7.43 times as many trace/response tokens and had an output component almost three times as expensive. A quality crossover is not automatically an efficiency crossover.[^genebench][^models]

Can Luna X-High replace Terra Medium?

Sometimes, but there is no general rule. In GeneBench-Pro, Luna X-High was weaker and more expensive on output. This pair requires direct A/B testing; equivalence should not be assumed.[^genebench]

Can Terra X-High replace Sol Medium?

It can on some workloads, especially with long inputs and moderate failure cost. In GeneBench-Pro, however, Sol Medium achieved the higher result with the shorter trace. This is one of the most important pairs to test.[^genebench]

Why did OpenAI separate Luna, Terra, and Sol if effort can be increased?

Because model tier and reasoning budget expose different trade-offs. Luna optimizes high-volume economics, Terra balances capability and cost, and Sol provides the largest capability headroom. Effort changes the depth of work within each tier. This interpretation follows the published model positioning and the fact that model and effort are separate controls; OpenAI has not publicly disclosed the full internal architectural rationale.[^models][^guidance]

Is there any point in Luna Max?

Yes, but it is a niche configuration. It can be justified when the task remains narrow, input is very large or cacheable, additional effort measurably raises pass rate, and Terra does not produce better economics. Selecting Luna Max merely because Luna has a lower per-token price is a mistake.

Is Terra X-High or Sol Medium the main “workhorse” for difficult work?

For many professional workflows, this is indeed one of the most useful comparison pairs. Codex Power currently defaults to Sol Medium. Terra High or X-High can win on long-input, recurring work; Sol Medium can win on ambiguity, quality, and token efficiency. The answer belongs to workload-specific evaluations.[^codex-models]

Are Sol High, X-High, and Max only for nearly unsolvable problems?

No. They are appropriate for difficult, high-value work when the quality gain justifies latency and token consumption. Max should still not be automatic: OpenAI recommends demonstrating its advantage over X-High on representative tests.[^guidance]

Is Sol Ultra simply more reasoning?

No. Ultra is a multi-agent mode: it combines maximum reasoning with proactive delegation of independent work to subagents. This can reduce wall-clock time while increasing aggregate token use.[^subagents]

Is a Sol Ultra adviser with Terra workers reasonable?

Yes, particularly for read-heavy and parallel branches. Codex supports custom agents with separate model and reasoning settings, and OpenAI explicitly points to Terra for lighter parallel worker tasks. Agent count and delegation depth still need limits.[^subagents]

26. A practical operating policy

1. Start from the task type, not the prestige of the model.
2. Use the lowest effort that passes the evaluation.
3. Always compare Luna X-High/Max with Terra Medium/High.
4. Always compare Terra X-High/Max with Sol Medium/High.
5. Count input, reasoning/output, cache behavior, tools, retries, and review.
6. Optimize cost per accepted result, not cost per request.
7. Use Max for the hardest quality-first tasks only after measuring the gain.
8. Use Ultra only when the work genuinely decomposes into independent branches.
9. Keep the stronger model as coordinator and cheaper models as specialized workers when the workflow supports it.
10. Never generalize one benchmark result to an entire production workload.

Items 1–10 are the article's final recommendations, derived from OpenAI's model guidance, reasoning and subagent documentation, and the GeneBench-Pro analysis.[^guidance][^codex-models][^subagents][^genebench]

Final conclusion

The question “Can a weaker model at X-High or Max beat a stronger model at Medium?” has a simple answer:

Yes, sometimes. That does not mean it will be cheaper, faster, or more reliable.

Higher effort increases the reasoning budget available within the selected model. It does not guarantee promotion to the next capability tier. On some tasks, Luna Max can approach Terra High. On other tasks, Luna X-High does not reach Terra Medium. Terra Max may approach Sol Medium while using several times as many tokens. Sol Medium can sometimes be both stronger and more token-efficient than Terra X-High.

The correct question is therefore not:

> Which model is formally weaker or stronger?

It is:

> Which combination of model, effort, context, tools, and orchestration produces the lowest cost per accepted result under my quality and latency requirements?

At that level, Luna, Terra, Sol, Max, and Ultra stop being a marketing ladder and become ordinary engineering controls.

Sources

[^models]: OpenAI, Models — GPT-5.6 Sol, Terra, and Luna. Pricing, reasoning levels, context window, and maximum output. Accessed July 10, 2026. Official documentation.

[^codex-models]: OpenAI, Codex Models — Choosing Sol, Terra, and Luna; reasoning effort; Max and Ultra. Accessed July 10, 2026. Official documentation.

[^guidance]: OpenAI, Model guidance for GPT-5.6. Guidance on medium, high, xhigh, max, Pro, and multi-agent use. Accessed July 10, 2026. Official documentation.

[^reasoning]: OpenAI, Reasoning models. Reasoning tokens, output billing, reasoning mode, and effort. Accessed July 10, 2026. Official documentation.

[^pricing]: OpenAI, API Pricing. Token and built-in tool pricing. Accessed July 10, 2026. Official documentation.

[^codex-pricing]: OpenAI, Codex Pricing. Token-based credit rate card for GPT-5.6 Sol, Terra, and Luna. Accessed July 10, 2026. Official documentation.

[^chatgpt-rate]: OpenAI Help Center, ChatGPT Rate Card. Product-specific metering and the distinction between message-based credit rates and API/Codex token billing. Accessed July 10, 2026. Official help article.

[^caching]: OpenAI, Prompt caching. GPT-5.6 cache-write multiplier and cache-read discount. Accessed July 10, 2026. Official documentation.

[^long-context]: OpenAI, GPT-5.6 model pages. Higher pricing for input above 272K tokens. Accessed July 10, 2026. Sol, Terra, Luna.

[^latency]: OpenAI, Production best practices — Improving latencies. Effect of model choice and generated-token volume on latency. Accessed July 10, 2026. Official documentation.

[^genebench]: OpenAI, GeneBench-Pro: Evaluating Multistage Statistical Reasoning in Genetics and Genomics. 129 tasks, pass rates, confidence intervals, and token traces by reasoning setting. Official PDF.

[^subagents]: OpenAI, Subagents — ChatGPT Work and Codex. Parallel agents, token use, heterogeneous model settings, Ultra, and worker guidance. Accessed July 10, 2026. Official documentation.

[^evals]: OpenAI, Working with evals. Evaluation methodology for model selection and upgrades. Accessed July 10, 2026. Official documentation.

[^optimization]: OpenAI, Model optimization. Representative production inputs, baselines, and iterative measurement. Accessed July 10, 2026. Official documentation.

[^prompt-guidance]: OpenAI, Prompting guidance for GPT-5.6 Sol. Preserve the baseline, change one variable, and rerun the evaluation. Accessed July 10, 2026. Official documentation.

#GPT56 #OpenAI #Luna #Terra #Sol #Reasoning #ReasoningModels #Codex #MultiAgent #Subagents #AIEconomics #LLM #AI #AIModels