OpenAI released GPT-5.6 Sol, Terra, and Luna on July 9, 2026. At launch, the gpt-5.6 alias routed to Sol. OpenAI positions Sol for frontier capability, Terra for a balance of intelligence and cost, and Luna for cost-sensitive, high-volume work. That is a useful catalog, but it is not an application routing policy.

Route by task evidence, not tier names

Start Luna on bounded transformations, label suggestions, candidate retrieval, and other tasks with cheap verification. Start Terra on multi-step tools, longer documents, or moderately complex code changes. Consider Sol for difficult debugging, high-value decision support, and workloads where evaluations demonstrate a capability gap. These are experiment starting points, not universal conclusions.

Do not upgrade because user text merely says a task is “complex” or “important.” Route on observable features: input size, number of tools, domain risk, expected verification cost, prior failures, and the service objective. A higher tier never removes approval requirements for external effects.

Keep a simple, inspectable rule before considering a learned router. A rule can be reviewed, replayed, and corrected when model behavior or pricing changes. Log the reason for every tier selection without recording sensitive prompt content.

Reasoning level is a second axis

GPT-5.6 supports several reasoning-effort levels from none through max. Evaluate tier and effort independently. A higher-effort Terra configuration may fit one workflow, while lower-effort Sol may meet another workload with less latency. “Most expensive model plus max effort” is not automatically a good production default.

For a migration from GPT-5.5, OpenAI recommends preserving the current effort as a baseline and comparing one level lower. Record model id, effort, prompt version, tool version, and evaluation date for every run. A moving alias is useful for continuous candidate tests; a controlled release should preserve the model resolution observed during qualification.

Do not optimize output tokens in isolation. A configuration that writes less but makes extra tool calls or needs more human repair may cost more end to end.

Qualify new features separately

The launch changelog lists Programmatic Tool Calling, explicit prompt caching controls, persisted reasoning, max effort, Pro mode, and beta multi-agent orchestration. They are not a bundle that must be enabled together. First hold the existing tool loop constant and change only the model. Add one new feature at a time and rerun the same evaluation.

Programmatic Tool Calling is attractive for bounded filtering, joining, or aggregation inside a hosted runtime. It is a poor place for an action that needs human judgment at every step. Multi-agent execution can reduce wall-clock time for cleanly separable research, but adds merge, tracing, and cost complexity. Pro mode needs a measured quality gain large enough to justify additional work and latency.

Persisted reasoning changes multi-turn context behavior, so test privacy, retention, stale assumptions, and task-boundary reset. Explicit caching changes cost accounting as well as performance. Each feature needs its own rollback switch.

Build an executable matrix

For each representative task, store the input fixture, allowed tools, expected facts, refusal conditions, and grader. Run all three tiers with the same prompt, tool schemas, budget, and data snapshot. Then test adjacent effort levels only for promising tiers. Measure task success, factual error, invalid calls, approval violations, tokens, latency, and estimated cost.

Express quality as a gate. For example, extraction must pass a target accuracy and produce zero cross-tenant calls; among qualifying configurations, select the lower-cost or lower-latency one. An average score must not hide high-impact tails. Report payment, permission, and privacy failures separately.

Use confidence only when it is calibrated against outcomes. Model-written confidence is not a safe router by itself.

Fallback must preserve authority

If a lower tier fails, escalation may reuse the same product task id and validated facts. Reconcile completed tools before retrying, so a new model does not repeat side effects. Fallback changes inference resources; it never adds tools, data scope, or authorization. After bounded escalation fails, transfer to a person and retain every attempt for diagnosis.

The three-tier family offers more granular capability and cost choices. Its value depends on explainable routing, frozen evaluations, and stable permission boundaries. Luna is a sensible first candidate for verifiable volume, Terra for many agentic workflows, and Sol for measured hard cases. Your own task distribution—not the model name—must establish the final boundary.