Choosing the Right GPT-5.6 Model and Reasoning Level in Codex

Codex asks for two related but different choices. The model determines the baseline capability, speed, and cost. The reasoning level determines how much work that model spends planning, exploring alternatives, checking edge cases, and revising its approach for one task.

This guide explains those choices through concrete questions that can be given to Codex. The examples are starting points, not universal performance guarantees. The best configuration is the least expensive one that repeatedly reaches an accepted, verified result without avoidable retries or human repair.

The GPT-5.6 product details in this guide were verified against official OpenAI documentation on 2026-07-13. Model availability and interface labels can vary by Codex surface, account, settings, and rollout.

A Non-Overlapping Atlas for the 15 Configurations

The fifteen choices are configurations, not fifteen independent models. They are three models combined with five reasoning levels. Do not climb them as one ladder.

OpenAI does not publish an exclusive task map for all fifteen configurations. The atlas below is a derived operating policy built from the official model roles, official reasoning guidance, independent measurements, and the requirement that one task route to one starting configuration. Its Do not select labels mean that the available evidence does not justify a distinct default role, not that the configuration is technically unavailable or incapable.

Choose the model branch first, using the first matching rule:

1. Use Sol when the correct scope, purpose, interpretation, evaluation criteria, architecture, or risk decision is still uncertain, or when a mistake has unusually serious consequences.
2. Use Terra when the target, purpose, system boundary, and evaluation criteria are settled, but implementation, review, or debugging still requires judgment inside a familiar repository.
3. Use Luna when the decisions and compatibility rules are already settled and correctness can be checked mechanically.

This precedence makes the branches mutually exclusive. A large file count does not move a settled mechanical task from Luna to Terra. A short task with unresolved product meaning does move from Luna or Terra to Sol.

A fixed file list or review range is not enough to choose Terra. The relevant question is whether the problem frame is settled: can the target, purpose, protected boundaries, and standard for an accepted result all be stated before the work begins? If yes, use Terra when applying that frame still requires judgment, or Luna when applying it is mechanical. If the work must discover or revise the frame, use Sol. High-consequence work can still require Sol even when the nominal scope is fixed.

The resulting routing list deliberately leaves six configurations without a default use:

Luna Low — Use

One localized, fully specified mechanical change with a targeted check. Example: rename one internal symbol and update its known references.

Luna Medium — Use

The same deterministic transformation repeated across several files or packages, with exceptions reported instead of redesigned.

Luna High — Use

A settled change that must trace explicit compatibility rules across generated files, schemas, serialization, or several dependency layers. The rules themselves are not open to interpretation.

Luna Extra High — Do not select

It does not have a sufficiently distinct default role after Luna High. If High omits dependencies, divide the deterministic work into smaller verified units and retry High. If the failure is judgment rather than tracing, move to Terra or Sol.

Luna Max — Do not select by default

Its strong benchmark value does not overcome its extreme latency as a general route. Consider it only when repeated repository-specific evaluations show an accepted-result advantage over Luna High and latency is unimportant.

Terra Low — Do not select

It has no stable role between the branches. Use Luna Medium or High when the decisions are settled, and Terra Medium when implementation judgment is actually required. The independent intelligence-cost comparison also places Terra Low behind a cheaper Luna alternative.

Terra Medium — Use

An ordinary feature, revision, or implementation in a familiar repository where the architecture and acceptance criteria are established but local judgment is necessary.

Terra High — Use

A reproducible, bounded bug whose success test and protected interfaces are clear but whose cause requires comparing several explanations and tracing dependencies.

Terra Extra High — Do not select

If the work is deterministic, divide it into smaller units and use Luna High. If deeper judgment or a broader system model is needed, use Sol Medium or High. The independent intelligence-cost comparison does not identify a unique value role for Terra Extra High.

Terra Max — Do not select by default

For settled execution, divide the work and use Luna High. For consequential judgment, use Sol High, Extra High, or Max. Consider Terra Max only if repeated repository-specific coding evaluations establish a lower accepted-result cost than both routes.

Sol Low — Do not select

It has no sufficiently distinct default role. Use Terra Medium or High when the problem and system boundary are settled, and Sol Medium when the correct interpretation, scope, or problem model remains uncertain. Consider Sol Low only as a repository-specific latency experiment after it matches Sol Medium’s accepted-result quality.

Sol Medium — Use

Build the correct problem model or scope in an unfamiliar system, reconcile conflicting sources, or refine a decision through repeated objections.

Sol High — Use

A high-consequence review or decision spanning several systems, with multiple plausible causes, tradeoffs, or failure paths that must be compared explicitly.

Sol Extra High — Escalation only

Sol High has the right problem frame but leaves interacting deployment stages, partial failures, or conflicting constraints insufficiently resolved.

Sol Max — Escalation only

The hardest sequential quality-first problem where Sol Extra High has already produced a measurable gap and the expected improvement matters more than latency or credit use.

The usable escalation paths are therefore branch-specific:

• Settled and mechanically verifiable: Luna Low → Medium → High. If High still omits dependencies, divide the work into smaller verified units and retry High. Move to Terra or Sol when the failure reveals missing judgment rather than missing trace depth.
• Familiar implementation or bounded debugging: Terra Medium → Terra High → Sol Medium or High. Do not continue through Terra Extra High and Max by habit.
• Uncertain or consequential judgment: Sol Medium → High → Extra High → Max. Medium is the starting point because the branch exists precisely when a correct problem model or broader judgment is required.

The boundary between the two closest remaining choices is direct: use Terra High when what must be investigated and how success will be judged are already settled, while the work needs deeper tracing. Use Sol Medium when deciding what should be investigated or what counts as the correct interpretation is itself part of the task.

Repository-specific evaluations may overturn a skipped configuration, but that creates a local measured exception. It does not justify restoring the configuration to the general routing table.

Ask About the Actual Work

A useful model-selection question describes the work rather than asking which model is “best.” Include the goal, what is already known, what remains uncertain, the consequences of a mistake, and how the result will be verified.

I need to [goal]. The relevant context is [files, systems, or source material]. The main uncertainty is [unknown]. I must preserve [constraints], and the task is complete when [observable result]. The models available to me are [models], and the reasoning levels available to me are [levels]. Considering quality, latency, and credit use, recommend one configuration and explain the reason briefly.

Listing the available choices matters. Codex cannot reliably infer which options a particular surface or account currently exposes.

What the Two Controls Change

OpenAI describes GPT-5.6 Sol as the flagship model for complex coding, computer use, research, and cybersecurity. Terra is the balanced model for everyday work. Luna is the fastest and least expensive member of the family and is suited to clear, repeatable work.

The official Codex rate card, verified on 2026-07-13, places Terra between Luna and Sol in token credit rates:

Model	Input per 1M tokens	Cached input per 1M tokens	Output per 1M tokens
GPT-5.6 Luna	25 credits	2.5 credits	150 credits
GPT-5.6 Terra	62.5 credits	6.25 credits	375 credits
GPT-5.6 Sol	125 credits	12.5 credits	750 credits

These are token rates, not fixed prices per message. A configuration that emits more reasoning or answer tokens can cost more even when its model has a lower rate. Fast mode also consumes credits at a higher rate where supported.

Reasoning effort changes the depth of work within the selected model. Light in the Codex app, ChatGPT Work, and the IDE extension is called Low in the CLI. Medium provides more planning. High and Extra High allow deeper analysis across multiple steps, sources, or tradeoffs. Max gives one agent more time for the hardest problems. Ultra is different because it delegates separable parts to subagents rather than merely increasing one agent’s reasoning. OpenAI recommends Medium as a balanced starting point, High or Extra High only when measurement shows a quality gain, and Max only for the hardest quality-first workloads.

The central distinction is:

Change the model when baseline judgment is insufficient. Increase reasoning when the model understands the goal but does not explore, trace, or verify enough.

What Independent Benchmarks Add

The practical recommendations below are routing hypotheses, not measured universal optima. OpenAI’s documentation establishes intended roles, reasoning guidance, and Codex credit rates. Artificial Analysis published independent GPT-5.6 measurements on 2026-07-09 that provide an external check on capability, task cost, token use, and API latency.

The benchmark names are easy to confuse. They measure different slices of work:

Measure	What it combines	What it can support
Intelligence Index	Nine evaluations across professional, scientific, coding, and reasoning work	Broad capability and cost comparisons
Coding Index	Terminal-Bench v2.1 and SciCode	Coding and terminal problem-solving without a complete repository-workflow model
Agentic Index	GDPval-AA v2 and tau-cubed Banking	Tool-using professional and transactional work
Coding Agent Index	DeepSWE, Terminal-Bench v2, and SWE-Atlas-QnA, each paired with an agent harness	The closest external evidence here for coding-agent work

None of these measures repository conventions, a particular acceptance test, retries after review, or human repair. They should constrain a recommendation rather than be treated as a universal routing table.

The broad Intelligence Index shows a capability gradient rather than a simple rule that more reasoning always wins. Sol max leads this selected comparison at 59, while less expensive Luna and Terra configurations remain close enough that task shape and quality requirements can change the efficient choice.

The Coding Index narrows the gap. Sol max scores 78.3, while Luna max scores 77.2 and Terra max scores 76.7. A small difference on these two coding evaluations does not establish equivalent performance on every repository task, but it is evidence against assuming that Sol is automatically necessary for all coding work.

The Agentic Index separates the configurations more strongly. Sol max scores 54.0, ahead of Sol Extra High at 51.8 and Sol High at 48.5. This supports considering stronger configurations for work that depends on extended tool use and judgment, while still leaving the actual workflow as the final test.

Cost changes much more sharply than some benchmark scores. In this evaluation, Luna max costs about $0.21pertask,Terramax$0.55, and Sol max $1.04. Artificial Analysis also reports that Luna or Sol occupies the intelligence-versus-cost Pareto frontier ahead of every Terra effort level in this benchmark. That finding creates a useful tension with Terra’s official role as the balanced model. It means Terra should be treated as a candidate to evaluate, not assumed to be the empirical value winner for every workload.

The scatter plot makes the scope of that Pareto claim visible. Within this Intelligence Index and its estimated API cost per task, every tested Terra point is dominated by a Luna or Sol point. This does not establish the same ordering for coding-agent success, latency, Codex credit consumption, or accepted repository changes. It is evidence against treating the word “balanced” as proof that Terra always offers the best measured value.

Coding-Agent Evidence Is Closer to Codex Work

Artificial Analysis also evaluated the three models at Max reasoning in the Codex harness. The aggregate Coding Agent Index scores were 80 for Sol, 77 for Terra, and 75 for Luna. The corresponding average API costs per task were $7.08,$2.76, and $1.57.

The component results show a real capability gradient, but not a proportionate one. Sol Max leads each component, while Terra Max and Luna Max remain relatively close at much lower API cost. This supports Sol for quality-first coding-agent work and supports testing Terra or Luna when the acceptance threshold does not require the last few benchmark points.

This chart compares only Max configurations. It cannot establish that Terra Medium is better or worse than Luna High, Luna Max, or Sol Medium for ordinary code changes. That missing comparison is one reason the practical recommendations remain starting hypotheses.

Latency and Token Use Can Reverse a Paper Ranking

The following Artificial Analysis API measurements illustrate why cost and benchmark score are insufficient by themselves:

Configuration	Intelligence Index	Time to first token	Output speed
Luna Medium	38	1.89 s	196.0 tokens/s
Terra Medium	46	1.50 s	115.8 tokens/s
Sol Medium	54	6.61 s	60.8 tokens/s
Luna Max	51	103.52 s	215.1 tokens/s
Terra Max	55	164.26 s	141.1 tokens/s
Sol Max	59	193.39 s	69.2 tokens/s

Time to first token includes reasoning before the first answer token. Output speed measures generation after that point, so neither number alone is total task time. These API measurements also do not guarantee the same latency in a Codex product surface. They do show why Max should not be a routine default merely because it has the highest score.

Token use explains part of task cost. In the selected Max comparison, Sol uses about 15,000 output tokens per Intelligence Index task, while Luna and Terra each use about 19,000. A lower token rate therefore does not translate mechanically into the same proportion of savings. The relevant quantity is the total resource use required to reach an accepted result.

What the Evidence Does and Does Not Establish

The combined evidence supports keeping Terra Medium as a practical default candidate for ordinary bounded work. It has the official middle price position, OpenAI recommends Medium as a balanced effort, and the independent API measurements place Terra Medium between Luna Medium and Sol Medium in broad capability while showing competitive first-token latency. The evidence does not prove that Terra Medium wins on a particular repository task.

The same evidence supports Luna for explicit, mechanically verifiable work and Sol for work whose main difficulty is baseline judgment under uncertainty. It also supports skipping many adjacent configurations rather than climbing all model-and-reasoning combinations in sequence.

These charts justify four limits on the recommendations below:

1. A named starting configuration is a testable default, not a performance guarantee.
2. Higher reasoning can improve measured results, but the gain is not uniform or always proportional to cost.
3. A Pareto result is valid only for the quality, cost, and latency dimensions included in that comparison.
4. Representative tasks from the actual workflow remain the decisive evaluation because benchmark averages cannot price retries, review effort, or task-specific failure consequences.

Practical Questions

The examples below apply the atlas. When an example appears close to two settings, the model-branch rule decides first and the reasoning level decides second.

Which configuration should answer a model-selection question?

I am planning to do ~~~~. The models available to me are [models], and the reasoning levels available to me are [levels]. Considering quality, latency, and credit use, recommend one configuration and explain the reason briefly.

Start with Luna Light, or Luna Low in the CLI.

The question is a small classification task. Codex needs to compare the described workload with the available configurations, but it does not normally need to implement anything, inspect a repository deeply, or perform extensive verification. A stronger model or deeper reasoning usually adds cost and latency without changing the recommendation enough to justify them.

Use Terra Medium for the selection question only when making the recommendation requires inspecting substantial repository evidence or weighing unusually consequential constraints. For example, choosing a configuration for an unfamiliar migration with data-loss risk may itself be a meaningful analysis task.

I know the exact mechanical change. What should perform it?

Rename legacyUserId to userId in src/auth/ and update all references and tests in that directory. Do not change behavior or public API shapes. Run the targeted authentication tests and report any reference that could not be updated safely.

Start with Luna Light.

The desired transformation, boundary, and verification are explicit. The task may touch many files, but file count does not create ambiguity. Luna is enough when correctness can be specified before execution and checked mechanically afterward.

If the rename crosses generated code, external schemas, serialization formats, or compatibility boundaries, keep Luna but increase reasoning to Medium so it spends more effort tracing consequences. Move to Terra only if deciding what should remain compatible requires broader judgment.

I need a normal feature in a familiar repository. What should I use?

Add a DELETE /sessions/:id endpoint following the existing controller, service, and test patterns. Preserve the current authorization rules and error format. The task is complete when the new endpoint tests and the existing session test suite pass.

Start with Terra Medium.

This task needs repository navigation, a short implementation plan, coordinated edits, and tests, but the architecture and acceptance criteria are already established. Terra provides enough tool use and judgment for ordinary engineering work, while Medium supplies the planning needed to follow existing patterns reliably.

Increase to Terra High if the feature spans several modules, has backward-compatibility requirements, or repeatedly misses edge cases. Move to Sol when the task stops being ordinary implementation and begins requiring product or architectural decisions.

The bug is reproducible, but its cause is unclear. What should I use?

Reproduce the refresh-token failure described in issue-184.md. Trace the request from auth-client.ts through the token endpoint and compare all plausible causes before editing. Do not change the public session API. Add a regression test that fails before the fix and passes afterward, then run the existing authentication suite.

Start with Terra High.

The scope and success test are clear, but the model must trace dependencies, compare competing explanations, and avoid stopping at the first plausible cause. Higher reasoning addresses that exploration and verification burden without assuming that the task needs Sol’s stronger baseline judgment.

Move to Sol Medium if the failure spans unfamiliar services, lacks a reliable reproduction, or depends on ambiguous product behavior. Those conditions change the problem from bounded debugging into defining the right system boundary and deciding which explanation matters. Increase to Sol High only if several plausible causes or consequential failure paths remain after that broader diagnosis, or if the eventual decision carries unusually high risk.

I do not yet understand the repository or the correct scope. What should I use?

Determine why stale plugin junctions remain across several Git worktrees. First distinguish tracked sources, generated state, cache directories, and links. Explain the responsible lifecycle before proposing a change. Do not delete or modify anything during diagnosis. Cite the files and commands that support the conclusion.

Start with Sol Medium.

The task is not merely to find a text match. Codex must construct the right model of an unfamiliar system, determine which evidence matters, and avoid treating symptoms as causes. Sol is useful because the main difficulty is baseline judgment under incomplete context. Medium is enough initially because the request is diagnostic and bounded by an explicit evidence requirement.

Increase to Sol High if several lifecycle explanations remain viable after inspection or if the fix requires redesigning ownership, cleanup, and failure recovery.

I need to plan a high-risk migration. What should I use?

Review this zero-downtime database migration plan for failure modes that could cause data loss, inconsistent reads, or extended downtime. Trace compatibility across the old application version, the new version, the database schema, and rollback. For each material risk, cite the relevant step and propose a specific mitigation. Do not implement the migration.

Start with Sol High.

The answer requires broad technical judgment, careful tradeoffs, and consequences that are expensive to miss. High reasoning gives the model room to trace dependencies and failure paths. Sol supplies the stronger baseline capability needed when several systems and competing safety properties must be considered together.

Use Sol Extra High when the plan includes many deployment stages, partial failures, or conflicting constraints. Reserve Max for a genuinely difficult sequential problem where Extra High has already produced an incomplete result and the additional depth has a measurable chance of improving it.

I have a settled plan and only need repeated execution. What should I use?

Apply the approved import migration shown in migration-example.md to every package under packages/. Follow the example exactly. Do not alter generated files or package APIs. Run the migration check and list any package that does not match the established pattern instead of improvising a fix.

Start with Luna Medium.

The judgment-heavy decision has already been made. The remaining work is repeatable, but Medium reasoning helps Codex track exceptions and avoid omissions across a batch. This is a common point where a workflow designed with Sol or Terra can be operated more efficiently with Luna.

Escalate individual exceptions to Terra rather than moving the entire deterministic batch to a stronger model.

I need a polished document from several sources. What should I use?

Write a standalone explanation of how the authentication flow works using architecture.md, the current implementation, and the public API specification. Reconcile differences between the sources, identify any unresolved conflict explicitly, and cite the evidence for each important claim. Preserve the public terminology and do not invent behavior that the sources do not establish.

Start with Sol Medium.

The work requires synthesis and judgment about conflicting or incomplete evidence, not just summarization. Sol is appropriate because accuracy, terminology, and global coherence matter. Medium provides enough reasoning when the source set and output boundary are clear.

Use Terra Medium instead when the sources agree and the task is simply to document settled code. Increase Sol to High when the sources materially conflict or publication quality requires substantial restructuring and careful qualification.

I need to decide whether one paragraph belongs in an existing article. What should I use?

Review whether the following paragraph should be added to article A. Judge it against the article’s purpose, intended reader, argument, structure, and existing content. Conclude with add, add after revision, or do not add. If it belongs, recommend its position and any necessary edits.

Start with Terra Medium.

Comparing a paragraph with an existing article is normally a bounded editorial task. It requires meaningful judgment about relevance, flow, repetition, and placement, but it does not usually require Sol’s broader baseline capability.

Use Sol Medium when the paragraph could change the article’s central claim or overall structure, when it conflicts subtly with existing material, when several interpretations remain plausible, or when deciding whether it belongs requires restructuring the article as a whole.

I need to trace and maintain Reading Graph relationships for an Insight Vault document. What should I use?

Inspect the target document and every candidate endpoint in full. Apply the repository’s Reading Graph acceptance gate and select only the strongest direct reader function among dependsOn, continuesTo, clarifiedBy, comparesWith, and expandsTo. Do not create a relationship from shared topics, links, tags, folders, or title similarity alone. Write a reason that proves the selected relationship, preserve one stored relationship per unordered pair, then run the required graph validation.

Start with Terra Medium.

The repository already defines the graph semantics, acceptance tests, storage direction, and validation rules. The remaining task is bounded curation inside a familiar system: inspect both documents, identify the future reader’s action, reject weak candidates, and write the correct metadata. That requires more semantic judgment than a mechanical edit, but it does not require Sol when the target document’s central purpose and the graph rules are already clear.

Use Terra High when the target set is fixed but the audit must compare many endpoint documents, distinguish direct relationships from paths, and reconcile duplicate-pair or direction constraints. Use Sol Medium instead when the document’s central learning question, the intended reader action, or the boundary between relationship types must first be reconstructed. Use Luna Medium only after the semantic relationships have already been approved and the remaining work is a deterministic metadata or ID update.

I need to verify whether a model-selection rule is itself sound. What should I use?

Review the following model-selection rule: “Use Terra Medium to decide whether a paragraph belongs in an existing article, and use Sol Medium when the paragraph changes the central claim or structure, conflicts subtly with existing material, or requires broader restructuring.” Compare the rule with the documented GPT-5.6 model roles and the actual difficulty of the editorial task. Identify overgeneralizations, unsupported guarantees, or unclear boundaries, then propose a more precise rule.

Start with Sol Medium.

This is not another routine paragraph review. It asks Codex to test the routing principle itself, separate official model descriptions from derived practical guidance, and challenge the boundary between ordinary editorial judgment and broader structural judgment. Sol Medium is a reasonable one-time audit setting. High is unnecessary unless the review must reconcile substantial conflicting evidence or evaluate many representative tasks.

I am refining a decision through repeated conversation. What should I use?

Help me refine this model-selection guide through multiple rounds of questions and objections. Reconsider earlier conclusions when I identify a conflict, distinguish official positioning from benchmark evidence and practical inference, and keep the recommendations consistent with the guide’s central rule. Do not edit the document until I ask.

Start with Sol Medium while the decision criteria or boundaries remain unsettled.

This kind of conversation is not merely a sequence of small questions. Each objection can change the interpretation of earlier evidence, expose an unsupported assumption, or move the boundary between two configurations. The main difficulty is maintaining a coherent model of the whole argument while repeatedly deciding what the actual question should be. That favors Sol’s broader baseline judgment, while Medium provides enough reasoning for careful reconsideration without assuming that every exchange needs a quality-first setting.

Lower the configuration after the discussion resolves the uncertainty. Use Terra Medium to apply an agreed, bounded revision that still requires editorial judgment, or Luna Light for a fully specified mechanical change. The useful unit of selection is therefore the current phase of the work, not the entire conversation: use Sol Medium to settle the decision, then move down when only execution remains.

The work has several independent tracks. Should I use Ultra?

Review this large pull request in four independent tracks: security, test coverage, performance, and maintainability. Each track must cite relevant files and rank only material findings. Combine duplicate findings and return one severity-ordered review. Do not modify the branch.

Use Ultra when those tracks can make meaningful progress independently.

Ultra is useful here because separate agents can inspect different risk dimensions in parallel. The benefit comes from decomposition and lower wall-clock time, not from treating Ultra as a universally smarter answer mode.

Do not use Ultra when the work is tightly sequential, when every step depends on the immediately previous result, or when the requirements are too unclear to divide safely. In those cases, use a single Sol run with an appropriate reasoning level.

Diagnose a Weak Result Before Escalating

The failure mode reveals which control to change.

If Codex understands the goal but skips dependencies, alternatives, edge cases, rollback, or verification, increase reasoning within the same model first. The baseline judgment may already be sufficient.

If the result is locally correct but globally inappropriate, misunderstands the product goal, misses implicit architectural relationships, or makes weak tradeoffs even after deeper reasoning, move from Luna to Terra or from Terra to Sol.

Move downward when uncertainty disappears. Once a cause is confirmed, a plan is approved, or tests fully specify the expected behavior, the remaining execution may no longer need the model or reasoning level used during discovery.

Improve the Question Before Increasing the Setting

A vague request can waste a strong configuration. Before escalating, make four things explicit:

1. Goal: What should be changed, decided, or produced?
2. Context: Which files, systems, errors, sources, or examples matter?
3. Constraints: What behavior, interface, boundary, or safety property must remain intact?
4. Done when: What observable evidence establishes completion?

Compare these two questions:

Fix the authentication bug.

Reproduce the refresh-token failure described in issue-184.md. Trace the request from auth-client.ts through the token endpoint. Do not change the public session API. Add a regression test covering token expiry during concurrent requests. The task is complete when the test fails before the fix, passes afterward, and the existing authentication suite remains green.

The second question narrows the search space, protects important boundaries, and supplies a verification loop. That improvement can matter more than moving directly to a stronger model or the maximum reasoning level.

Measure the Cost of an Accepted Result

The cheapest first response is not necessarily the most efficient workflow. Include retries, human correction, review time, and failed approaches when comparing configurations.

A Luna run that needs repeated repair may cost more than one Terra run. A Sol Max run that produces the same accepted result as Terra Medium is also inefficient. Evaluate representative tasks against an objective quality floor, then keep the least expensive configuration that consistently meets it.

Use a small repeated comparison instead of judging from one impressive or disappointing run. Select several tasks from each recurring class, give every configuration the same prompt and repository state, and record:

Measure	Why it matters
Accepted on the first run	Separates apparent progress from a usable result
Required tests and checks passed	Supplies an objective quality floor
Human repair or follow-up turns	Captures hidden workflow cost
Incorrect or unnecessary scope changes	Detects globally inappropriate work
Total credits or tokens	Measures actual consumption rather than model price alone
Wall-clock completion time	Includes reasoning delay, tool use, and retries

Keep a configuration only when its advantage repeats across representative tasks. One benchmark point, one repository task, or one model’s official positioning is not enough to establish a durable default.

The durable selection rule is:

Use the question to expose the uncertainty, consequence, and verification burden. Then choose the least expensive configuration that repeatedly reaches the required result.

References

• Codex Models. Official descriptions of Sol, Terra, Luna, reasoning levels, Max, Ultra, and the Sol Medium Power default.
• Codex Best Practices. Prompt structure and reasoning-level guidance.
• GPT-5.6 Model Guidance. Current GPT-5.6 roles and reasoning-calibration guidance.
• Codex Pricing. Official Codex credit rates by model and token type.
• GPT-5.6 Benchmarks across Intelligence, Speed and Cost. Independent benchmark methodology, results, and cost analysis published on 2026-07-09.
• GPT-5.6 Luna Medium. Independent capability, output-speed, latency, token-use, and API-cost measurements.
• GPT-5.6 Terra Medium. Independent capability, output-speed, latency, token-use, and API-cost measurements.
• GPT-5.6 Sol Medium. Independent capability, output-speed, latency, token-use, and API-cost measurements.