Model Routing / Agent Systems

GPT-5.6 Sol vs. Terra vs. Luna: an evidence-based routing policy for coding agents

The practical GPT-5.6 split is Sol for discovery, Terra for bounded execution, and Luna for repeatable processing - with a different verification contract for each.

A dark metal routing instrument with separate Sol, Terra, and Luna channels.
A Kyanite routing instrument: Sol investigates, Terra executes, Luna processes.

Executive summary — TL;DR / BLUF

  • Sol High is the discovery lane. Use it when the path, owner, or failure mode is still unknown. Give it an evidence target and an exit condition.
  • Terra Medium is the execution lane. Use it after the decision is made and the work has explicit files, behaviors, boundaries, and acceptance gates.
  • Luna is the processing lane. Use it for narrow, repeatable, high-volume tasks whose outputs can be checked by a schema, deterministic test, or sample audit.
  • Max is an escalation, not a default. DataCurve's current DeepSWE result shows a modest observed gain over High at roughly 2.4 times the estimated task cost, with slightly overlapping confidence intervals.
  • Fast and Ultra are separate controls. Fast is not currently documented for GPT-5.6; Ultra is multi-agent orchestration, not a reasoning level.
  • Current usage note: the five-hour restriction for Codex and ChatGPT Work is temporarily absent for Plus, Business, and Pro, but weekly limits remain. The reported reduced internal “juice values” were experiments that OpenAI says it reverted.

BLUF: do not choose a GPT-5.6 model by prestige. Route by uncertainty and by the cost of proving the answer is correct.

Model routing is a completion-contract problem

The important difference between Sol, Terra, and Luna is not simply “smart, cheaper, cheapest.” Each model is most reliable when the agent is given a different definition of done. Sol needs a research boundary. Terra needs a specification. Luna needs a validator.

ModelJobCompletion contractFailure to design around
SolDiscoverQuestion, evidence target, protected boundaries, and stop conditionContinuing after the useful answer or widening scope without evidence
TerraExecuteApproved plan, named files, acceptance gates, and required testsTreating unresolved uncertainty as if it were an implementation detail
LunaProcessExact schema, examples, deterministic validator, and retry ruleLetting a cheap silent error propagate through the pipeline

OpenAI's current model-selection guidance describes the same capability ladder in product terms. The engineering move is to turn that ladder into a contract-and-verifier architecture.

What our first week changed

We used the three lanes across research, evaluation, websites, and agent systems. This was operational observation, not a controlled benchmark, so the claims below are field notes rather than universal rankings.

Sol was best when the work had to discover its own path. It carried long investigations and found consequential mistakes that a narrower pass could have missed. Its failure mode was persistence without a stopping rule: once the answer existed, it could keep exploring. The improvement was not a cleverer prompt. It was an explicit evidence target, protected boundaries, and a rule for when to stop.

Terra was strongest when the acceptance contract was already explicit. Given a bounded scope, it produced specific adversarial findings and clear approve-or-hold judgments. When hidden discovery remained, however, the apparent execution task was actually routed too early.

Luna was reliable when the output boundary was machine-checkable. Exact-schema JSON, extraction, metadata, and other constrained jobs repeatedly landed inside the requested shape. Some runs benefited from an explicit completion reminder. The model was not the whole control system; the schema and validator were.

A reference router for coding agents

def route(task):
    if task.uncertain or task.crosses_subsystems:
        return ("Sol", "high", "evidence + exit condition")
    if task.specified and task.bounded:
        return ("Terra", "medium", "acceptance gates")
    if task.repeatable and task.cheap_to_verify:
        return ("Luna", "lowest sufficient", "schema + validator")
    return ("Sol", "high", "evidence + exit condition")

The fallback matters. If work is neither bounded nor cheap to verify, it probably still contains discovery. Route that uncertainty deliberately before paying an executor to guess.

First constrain the router to the product surface

A routing policy cannot select a model the current product does not expose. “GPT-5.6” means different controls in ChatGPT, Codex, and the API, so record the surface as part of the route.

  • Standard ChatGPT: OpenAI's current help documentation says GPT-5.6 uses Sol for Medium, High, and Extra High. Terra and Luna are not selected there.
  • ChatGPT Work and Codex: eligible paid plans can expose Sol, Terra, and Luna. Max and Ultra depend on the product and plan.
  • API: the three models support none, low, medium, high, xhigh, and max reasoning effort.

Check GPT-5.6 in ChatGPT and the API model pages when implementing the policy. A model-picker screenshot is not an architecture contract; availability can change independently across products and plans.

Escalate reasoning effort only after diagnosing the failure

Reasoning effort is a second routing dimension. Higher effort gives the same model more room to explore, use tools, and revise, but it cannot repair a wrong premise, missing permission, broken test environment, or underspecified deliverable.

Sol effortDeepSWE v1.1 scoreEstimated cost per task
High69.4%$3.47
Extra High70.7%$4.70
Max72.7%$8.39

Those July 9, 2026 values come from DataCurve's raw DeepSWE v1.1 artifact. High to Max adds 3.3 observed percentage points while estimated task cost rises from $3.47 to $8.39 - about 2.4 times. The set contains 113 tasks, and the reported 95% confidence intervals for High and Max overlap slightly.

That makes Max a diagnosed escalation: use it after High failed because exploration ended too soon or a hard branch was not followed. It is poor compensation for a bad brief. The benchmark is evidence from one harness, not a guaranteed gain on a particular repository.

Keep three cost systems separate

API price, benchmark-estimated cost, and Codex credits are not interchangeable units. OpenAI currently publishes API prices of $5/$30 per million input/output tokens for Sol, $2.50/$15 for Terra, and $1/$6 for Luna. For most plans, the current Codex card maps those same input/output quantities to 125/750 credits for Sol, 62.5/375 for Terra, and 25/150 for Luna, with lower cached-input rates.

A benchmark's dollars-per-task number belongs to its own harness. A real agent run also pays for context, cached input, tool output, retries, validation, and any parallel branches. Use the live Codex rate card for credits and measure verified completion cost in the system itself.

P.S. Current limits and the reported “juice” change

As of July 12, 2026, the five-hour usage window for Codex and ChatGPT Work does not currently apply to Plus, Business, or Pro. OpenAI product lead Tibo Sottiaux wrote that the change is temporary; an accessible contemporaneous report reproduces the announcement. Weekly limits remain. Treat this as a live operating condition, not a permanent entitlement or unlimited usage.

A separate public follow-up reproduced in this screenshot thread addressed the smaller internal reasoning budgets - the “juice values” discussed online. Sottiaux said OpenAI tested those values while diagnosing unexpectedly high consumption and then reverted the experiment. The exact reduced numbers circulating in screenshots are therefore not a current documented interface or stable API contract.

For a production router, treat both facts as current-state notes. Target published model and effort controls, watch the live usage surface, and re-measure behavior rather than encoding temporary limits or inferred internal budgets.

Do not collapse Max, Fast, and Ultra into one ladder

  • Max expands reasoning effort for one GPT-5.6 model.
  • Fast is a higher-credit Codex inference option, but the current Speed documentation lists GPT-5.5 and GPT-5.4 - not GPT-5.6 - as supported.
  • Ultra is a separate multi-agent setting that coordinates four agents by default. It is not another single-agent reasoning level above Max.

Ultra earns its overhead when branches can produce independent evidence: separate subsystem reviews, competing implementations, or research questions without shared mutable state. It wastes context and creates collision risk when every worker needs the same files, decision, or sequential dependency.

The verifier belongs in the routing table

LaneRequired evidenceTypical verifier
Sol discoveryReproduction, cited investigation, or decision recordTest, source audit, or independent review
Terra executionBounded diff plus every acceptance gate named in the planTargeted tests, lint, type checks, and diff review
Luna processingStructured output conforming to the requested contractSchema, deterministic check, sample audit, or stronger-model review
The economical model is the one with the lowest total cost to a verified result, not the lowest token price.

Implementation checklist

  1. Classify the task by uncertainty: discovery, bounded execution, or repeatable processing.
  2. Record the product surface and verify that the intended model and effort control exist there.
  3. Attach the right completion contract: evidence plus exit condition, acceptance gates, or schema plus validator.
  4. Begin unclear hard work with Sol High. Escalate to Max only after diagnosing insufficient exploration.
  5. Hand decided work to Terra and high-volume verifiable units to Luna.
  6. Measure verified completions, retries, review time, latency, and token or credit use - not output volume alone.

This policy makes model choice auditable. A failed task can be traced to the route, contract, environment, or verifier instead of being dismissed as “the model was not smart enough.” For the owner/operator version focused on approval and business risk, read the PuenteWorks companion: use the cheapest AI model that can reliably finish the job.

FAQ

Is Sol always the best GPT-5.6 model for coding?

No. Sol is the strongest discovery route when the path is unclear. Terra is often the better engineering route once a plan is bounded, and Luna is more efficient for narrow transformations with deterministic validation.

Should coding agents default to Sol High or Max?

Start difficult, uncertain work at Sol High. Escalate to Max only after identifying that insufficient exploration—not a bad brief or environment—caused the failure.

Can Luna run a complete coding-agent session?

It can run a constrained session, but its strongest system role is often inside a workflow: classification, extraction, naming, summaries, and other repeated work whose output can be checked automatically.

Is Ultra more intelligent than Max?

No. Max increases reasoning effort for one model. Ultra coordinates multiple agents. Parallelism helps only when the work can be decomposed without duplicating context or colliding on shared state.

Do Codex and ChatGPT Work currently have a five-hour usage window?

As of July 12, 2026, OpenAI says the five-hour restriction for Codex and ChatGPT Work temporarily does not apply to Plus, Business, or Pro. Weekly limits remain, so this is not unlimited access or a permanent contract.

Were GPT-5.6 juice values permanently reduced?

No current public specification says that. Tibo Sottiaux said the internal reasoning-budget experiments were reverted. Route against published effort controls and verify behavior on your own workload.

Sources and limits

Fact-checked July 12, 2026. Product availability, prices, rate cards, usage limits, and benchmark results can change. The field notes are observational, and the routing policy should be validated against your own repositories and verification costs.

Work with Kyanite

Want this working in your environment?

If this post describes a Kyanite tool or result you need, implementation help can cover setup, advising, docs, examples, checks, and a usable handoff.

Fit boundary

Kyanite offers help grounded in its tools, products, and build practice. Broader consulting routes through PuenteWorks.

Keep following the system.

Agents need verifiable tools, not better prompt theater

The useful agent pattern is not a prettier prompt. It is a tool surface the agent can call, inspect, verify, and revise.

Repo history is a product signal

A repo is not just storage. It is evidence of decisions, repairs, release behavior, naming drift, test gaps, and what the builder actually knows how to finish.

Implementation help is part of the product surface

A useful open-source tool still needs a path from public repo to working environment. That path is product work, not an afterthought.

Why mcp-video matters

mcp-video is a video editing MCP server that gives AI agents direct handles on timelines, effects, FFmpeg, and finished media.

Infinite monkeys, LLMs, and the room around the machine

The argument behind the video: output quality is not just probability. It is architecture, filters, and human taste.

What a working AI tool needs before people can use it

A practical checklist for turning a working tool, workflow, or rough app into something other people can understand, install, and use.

MCP server implementation checklist

The checklist Kyanite uses to decide whether an MCP server is a toy, a usable tool, or something worth implementing.

Repo archaeology turns history into proof

Why commit history is one of the strongest proof sources for learning diagnostics, implementation help, and engineering trust.

AI discovery needs more than a sitemap

What Kyanite adds so search engines and AI assistants can understand the tools, products, proof, and support path.