OpenAI model selection guide
The practical answer: choose Sol when the work is ambiguous, consequential or premium-quality; Terra when you need strong everyday reasoning at a better cost and speed balance; and Luna when the task is clear, repeatable and high-volume. Then set reasoning effort separately. Max, Ultra, Pro, verbosity and speed are not bigger model tiers.
Evidence: current official OpenAI documentation
Kingy.ai testing: no independent benchmark claimed
The 30-second answer
If you are unsure in Codex or ChatGPT Work, start with Sol at Medium effort. That is OpenAI’s documented Power default. For a production API workload, use that as the quality baseline, then test Terra at the same effort. Test Luna for constrained jobs that are easy to score.
- Sol: hard debugging, open-ended research, high-stakes analysis, complex computer use and polished deliverables.
- Terra: everyday coding, support, document work, conversational applications and production agents.
- Luna: extraction, classification, routing, transformation, structured summaries and large batches.
- Raise effort only when a lower setting misses planning, evidence or verification.
- Max is deeper work on one task. Ultra delegates separable work to subagents. Pro is an API execution mode that spends more model work before returning one answer.
Related reading: this guide focuses on configuration and routing. For launch data and published evaluations, see Kingy.ai’s GPT-5.6 benchmarks, specifications and pricing analysis. For the broader market, see the best AI model API routing guide.
Methodology: specifications, prices, API fields and availability were checked against OpenAI’s latest-model guide, individual model pages, ChatGPT Work and Codex model guide, API reference, pricing and deprecation pages on July 10, 2026. Recommendations are Kingy.ai editorial starting points—not undisclosed hands-on tests or universal rankings.
Why this feels confusing: there are seven separate controls
OpenAI’s interface can make model, effort and execution choices look like one ladder. They are not. Moving from Terra to Sol changes the model. Moving from Medium to High changes how much reasoning the selected model may use. Pro changes the API execution mode. Ultra changes orchestration by bringing in subagents. Verbosity changes the visible answer. A delivery tier changes latency economics.
| Surface or control | Current terminology | What it actually changes |
|---|---|---|
| ChatGPT Work, Codex app and IDE | Light, Medium, High, Extra High, Max; Ultra where eligible | Effort increases through Max. Ultra adds proactive delegation for suitable work. |
| Codex CLI or configuration | Low, Medium, High, xhigh/Extra High and Max; lower levels are model-dependent | model_reasoning_effort tunes the selected model. OpenAI documentation also groups Ultra here in one place, creating a terminology conflict discussed below. |
| GPT-5.6 API effort | none, low, medium, high, xhigh, max |
reasoning.effort controls reasoning depth. The documented default is Medium. |
| API execution mode | standard or pro |
reasoning.mode changes how much model work is applied before one final answer. |
| API orchestration | Multi-agent beta | multi_agent.enabled lets a root GPT-5.6 agent coordinate subagents. This is separate from effort. |
| Visible answer | low, medium, high verbosity |
text.verbosity changes output detail—not intelligence or reasoning effort. |
| Codex presets | Power, Powerful, Efficient, Advanced | Power is explicitly Sol plus Medium. OpenAI describes Powerful and Efficient directionally but does not publish stable exact recipes. |
Ordinary ChatGPT conversations may expose a different subset depending on plan and workspace policy. OpenAI’s current GPT-5.6 in ChatGPT help page is the source to check for consumer-plan availability. Do not assume a Codex label maps one-to-one to a ChatGPT or API control.
Choose the model first: Sol, Terra or Luna
| Model | Choose it when | Downgrade or avoid when | Standard API price per 1M tokens |
|---|---|---|---|
Solgpt-5.6-solgpt-5.6 alias |
The problem is ambiguous, difficult, high-value or needs unusually strong judgment and polish. | A cheaper configuration reliably passes the same acceptance test, or latency and volume dominate. | $5 input $0.50 cached input $6.25 cache write $30 output |
Terragpt-5.6-terra |
You need strong everyday reasoning and tools with a better capability/cost balance. | The work is entirely mechanical and scorable, or failures reveal a need for Sol’s depth. | $2.50 input $0.25 cached input $3.125 cache write $15 output |
Lunagpt-5.6-luna |
The task is clear, repeatable, high-volume and objectively verifiable. | Ambiguity, consequences, open-ended judgment or premium polish increase. | $1 input $0.10 cached input $1.25 cache write $6 output |
Sol: pay for uncertainty
Sol is the flagship and the target of the unsuffixed gpt-5.6 alias. Use it when the cost of a shallow plan, missed dependency or mediocre final deliverable is greater than the model premium.
Good examples: repo-wide debugging, strategic research, complex computer use, security review and final editorial synthesis.
Terra: the production baseline
Terra is the pragmatic all-rounder. It is often the right model to challenge a Sol baseline: hold the prompt and effort constant, then see whether Terra still passes.
Good examples: everyday coding, business documents, support workflows, conversational apps and supporting-document review.
Luna: scale what is well specified
Luna is not merely a weak default. It is the economic choice when success is explicit and failures are easy to detect. A narrow rubric is its friend.
Good examples: routing, extraction, classification, transformation, templated summaries and high-volume subagent work.
All three model pages currently list the same 1,050,000-token context window, 922,000 maximum input, 128,000 maximum output and February 16, 2026 knowledge cutoff. They accept text and image input, return text and support streaming, structured outputs, function calling, file search, web search and prompt caching. See the official pages for Sol, Terra and Luna. Those shared specifications are why context length alone cannot choose the model for you.
Reasoning levels explained: use the lowest one that passes
Reasoning effort is a tuning knob, not a status symbol. OpenAI’s migration guidance explicitly recommends starting with your current setting, then testing the same setting and one level lower. More effort can improve difficult work, but it increases response time and token use. For GPT-5.6, the model-specific API list is none, low, medium, high, xhigh and max.
| Level | Best starting use | Signal it is too low | Signal it is wasteful |
|---|---|---|---|
| None API where supported |
Latency baseline, direct transformations and tasks needing almost no planning. | Skipped validation, brittle tool use or shallow handling of exceptions. | It already passes reliably; do not add reasoning by habit. |
| Light / Low | Quick, well-scoped work, classification, extraction and mechanical edits. | The model misses dependencies, edge cases or required checks. | Outputs are simple, stable and objectively accepted at a lower setting. |
| Medium | The balanced default for normal planning, coding and judgment. | Multi-step tasks regularly need correction or incomplete evidence must be recovered. | A low-effort version passes the same eval with lower latency and cost. |
| High | Difficult multi-step work, debugging and research with several sources or tradeoffs. | Important hypotheses, contradictions or verification steps remain unaddressed. | Quality does not improve measurably over Medium. |
| Extra High / xhigh | Demanding review, security reasoning, complex architecture and high-stakes synthesis. | The task still needs broader exploration or more careful checking. | The task is mostly execution, not reasoning, or a lower setting already meets the rubric. |
| Max | The hardest quality-first single task when depth matters more than speed or usage. | Compare with xhigh; if Max still does not pass, improve the prompt, tools, evidence or workflow rather than escalating blindly. | The gain over xhigh is immaterial or the work should be split into independent streams instead. |
Light versus Low: OpenAI currently uses Light in the Codex app, ChatGPT Work and IDE extension, while the CLI uses Low. Extra High versus xhigh: these are the human-readable and configuration/API forms used for the upper effort setting. The generic reasoning guide mentions model-dependent minimal, but the GPT-5.6-specific guide does not include it in the family list; use the model-specific list.
Max vs Ultra vs Pro: three different mechanisms
| Control | What changes | Best fit | Poor fit | How it is enabled |
|---|---|---|---|---|
| Max | More reasoning by one selected model on one coherent task. | An exceptionally difficult analysis, review or optimization problem. | Routine work or a task that actually contains independent workstreams. | App setting or API reasoning.effort: "max". |
| Ultra | Maximum-depth product behavior plus proactive delegation to subagents for separable work. | Large research, review or implementation tasks that divide cleanly. | Ordered chains, tightly shared state or one dominant bottleneck. | Eligible ChatGPT Work/Codex accounts and supported models. |
| Pro mode | The Responses API applies more model work before returning one final answer. Effort remains a separate choice. | High-value work where a marginal reliability gain justifies latency and token use. | High-volume, latency-sensitive work or workflows where evals show no gain. | reasoning.mode: "pro" with the same GPT-5.6 model slug. |
| API Multi-agent beta | A root GPT-5.6 instance can spawn and coordinate subagents that share its model and tools. | Parallel evidence gathering, component reviews and independent work packages. | Side-effect-heavy work, ordered dependencies or jobs that cannot be meaningfully partitioned. | Beta Responses API with multi_agent.enabled. |
Documentation conflict to know: OpenAI’s primary model guide defines Ultra through subagent orchestration. The subagents page also lists ultra under model_reasoning_effort. The GPT-5.6 API effort list stops at max, while API Multi-agent is a separate beta field. The safe interpretation is to treat Ultra as a product-level composite option—not a valid Responses API effort value. Do not send reasoning.effort: "ultra".
Ultra and API Multi-agent are related ideas, not guaranteed identical implementations. OpenAI describes API Multi-agent as “similar to ultra mode in Codex.” The beta defaults to three concurrent subagents, and extra workers can increase total token use. Use parallelism only when it reduces wall-clock time without fragmenting the judgment that must remain coherent. See OpenAI’s Multi-agent guide.
The practical workload matrix
These combinations are starting points. The escalation trigger matters more than the label: move upward when a representative acceptance test fails, and move downward when a cheaper setup keeps passing.
| Workload | Start here | Consider | Change when | Measure |
|---|---|---|---|---|
| General writing and editing | Terra, Medium | Sol for nuance or publication polish | Luna/Low for templated edits; Sol/High for difficult synthesis | Acceptance rate and revision distance |
| Polished long-form documents | Sol, High | Ultra for separable research; Pro for valuable final review | Use Terra when the same rubric remains satisfied | Revision cycles and factual corrections |
| Coding and refactoring | Terra, Medium | Sol/High for repo-wide ambiguity | Use Luna for mechanical transformations; Sol for architectural uncertainty | Tests passed and regressions |
| Debugging | Sol, High | Ultra for independent hypotheses | Use Terra for a localized, reproducible bug | Time to verified root cause |
| Security or high-stakes review | Sol, xhigh | Pro; Ultra by independent component | Do not downgrade without evals and human review | Confirmed findings and false positives |
| Research and synthesis | Sol, High | Ultra by research question | Use Terra for narrow source summaries | Citation coverage and contradiction handling |
| Computer use | Terra, Medium | Sol for ambiguous recovery | Use Luna for deterministic routines with strong validation | Completion and recovery rates |
| Extraction, classification and routing | Luna, None/Low | Terra for ambiguous labels | Escalate uncertain cases, not the entire batch | Field accuracy, F1 or reviewer agreement |
| Structured summaries and batch transformation | Luna, Low | Terra when prioritization matters | Raise effort only after required-field failures | Completeness and accepted outputs per dollar |
| Customer support or conversational apps | Terra, Low/Medium | Luna for FAQ flows; Sol for risky escalations | Route by ambiguity and consequence | Resolution, latency and escalation accuracy |
| Tool-heavy agents | Terra, Medium | Sol/High for dynamic decisions | Use Multi-agent only for separable branches | End-to-end success and failed tool calls |
| Large-document review | Sol, High | Ultra by document or section | Use Terra for narrow extraction | Issue recall and source citations |
| Subagent workers | Luna/Low or Terra/Medium | Sol as coordinator | Match each worker to its actual task complexity | Pass rate per cost and wall-clock time |
| Final consequential decision | Sol, xhigh | Pro; Ultra for evidence gathering only | Human approval remains required | Critical miss rate and evidence completeness |
For deeper Codex-only routing examples, see Kingy.ai’s guide to Low, Medium, High and Extra High reasoning levels. The durable rule is unchanged: define “done,” choose the model for task shape, and tune effort only after observing a failure.
API examples: configure each axis explicitly
A balanced production request
import OpenAI from "openai";
const client = new OpenAI();
const response = await client.responses.create({
model: "gpt-5.6-terra",
reasoning: {
effort: "medium",
context: "current_turn"
},
text: { verbosity: "medium" },
input: "Review this support policy and return the five operational risks."
});The model, effort, reasoning continuity and visible detail are separate fields. Use reasoning.context: "all_turns" only when earlier reasoning remains relevant and the request has access to prior response items through previous_response_id, a conversation or complete replay.
Pro mode for one difficult answer
const response = await client.responses.create({
model: "gpt-5.6-sol",
reasoning: {
effort: "high",
mode: "pro"
},
input: "Find failure modes in this database migration plan and rank them by severity."
});Pro mode keeps the selected GPT-5.6 model and effort; it is not a separate GPT-5.6 Pro model slug. Tokens from the additional model work are aggregated into reported usage and billed at the selected model’s rates.
Multi-agent beta for truly parallel work
const response = await client.beta.responses.create({
model: "gpt-5.6-sol",
input: "Review the security, data migration and rollback sections independently, then synthesize the risks.",
multi_agent: {
enabled: true,
max_concurrent_subagents: 3
},
betas: ["responses_multi_agent=v1"]
});Multi-agent is beta, its item schemas may change, and subagents share the request’s model and tools. It is not a shortcut for one tightly coupled chain. OpenAI also notes that reasoning summaries and max_tool_calls are not supported when Multi-agent is enabled.
How to choose with your own evaluation
The definitive model choice is not a universal table. It is the least expensive configuration that reliably passes your work. A small, honest evaluation beats a large collection of launch benchmarks that do not resemble the job.
- Collect representative tasks. Include normal inputs, hard cases and the failures that cost you time.
- Define pass/fail before testing. Required facts, tools, schema fields, citations, safety rules and human approval boundaries should be explicit.
- Start with a quality baseline. Sol at Medium is reasonable when you have no prior data.
- Change one axis at a time. Compare Terra at the same effort before changing both model and effort.
- Measure the whole workflow. Track task success, completeness, evidence, tool success, latency, tokens, retries and total cost.
- Test one cheaper configuration. Try one lower effort, then a lower-cost model, while keeping the acceptance test fixed.
- Route exceptions. Let Luna or Terra handle the common case and escalate uncertain or consequential cases to Sol.
Do not confuse fewer calls with a better system. A configuration is more efficient only if the final answer still contains the required evidence and passes the task. Likewise, “highest effort” is not a quality guarantee when the prompt, tools or source material are the real problem.
Pricing, credits and speed: keep the systems separate
The table below uses OpenAI’s live API prices retrieved July 10, 2026. Each cell lists input / cached input / cache write / output dollars per one million tokens. Batch and Flex share the same short-context token prices; they differ operationally. Priority offers lower and more consistent latency at premium rates.
| Model | Standard, short context | Standard, over 272K input | Batch/Flex, short context | Batch/Flex, over 272K input | Priority, short context |
|---|---|---|---|---|---|
| Sol | $5 / $0.50 / $6.25 / $30 | $10 / $1 / $12.50 / $45 | $2.50 / $0.25 / $3.125 / $15 | $5 / $0.50 / $6.25 / $22.50 | $10 / $1 / $12.50 / $60 |
| Terra | $2.50 / $0.25 / $3.125 / $15 | $5 / $0.50 / $6.25 / $22.50 | $1.25 / $0.125 / $1.5625 / $7.50 | $2.50 / $0.25 / $3.125 / $11.25 | $5 / $0.50 / $6.25 / $30 |
| Luna | $1 / $0.10 / $1.25 / $6 | $2 / $0.20 / $2.50 / $9 | $0.50 / $0.05 / $0.625 / $3 | $1 / $0.10 / $1.25 / $4.50 | $2 / $0.20 / $2.50 / $12 |
Prompts above 272,000 input tokens use 2× input and 1.5× output pricing for the full request. Priority does not support long context. Batch is priced lower with up to a 24-hour turnaround and separate limits; Flex trades speed and availability for Batch-level token rates. Regional processing can add a data-residency uplift. Always check OpenAI’s live API pricing before budgeting.
ChatGPT and Codex credits are not API dollars
OpenAI currently lists GPT-5.6 credit rates per one million input / cached input / output tokens of 125 / 12.5 / 750 for Sol, 62.5 / 6.25 / 375 for Terra and 25 / 2.5 / 150 for Luna. Message estimates vary with task complexity, context, effort, retrieval, caching and tools, so prompt length alone does not predict usage. Check the current Codex pricing and limits page for your plan.
Fast mode is not Priority processing
Codex Fast mode consumes ChatGPT credits; API Priority processing uses API billing. As of this fact-check, OpenAI’s Fast mode page explicitly documents GPT-5.5 and GPT-5.4, not GPT-5.6. Do not assume GPT-5.6 Fast support unless the current product catalog exposes it. API-key sessions use API service tiers instead of ChatGPT Fast credits.
When Sol, Terra and Luna are the wrong category
GPT-5.6 is a broad reasoning family, not the answer to every modality. Route specialist jobs to specialist systems, then use GPT-5.6 for planning, orchestration or analysis around them when useful.
| Need | Current specialist route to evaluate | Watch-out |
|---|---|---|
| Live speech-to-speech | gpt-realtime-2.1 or lower-cost gpt-realtime-2.1-mini |
Use the Realtime API rather than forcing a text workflow into live audio. |
| Transcription | gpt-4o-transcribe, mini or diarization variants |
Choose diarization when speaker attribution matters. |
| Image generation or editing | gpt-image-2 |
GPT-5.6 accepts image input but returns text; it is not the image renderer. |
| Video generation | sora-2 or sora-2-pro |
OpenAI’s deprecation page lists the Videos API for shutdown on September 24, 2026 with no replacement currently named. |
| Embeddings | text-embedding-3-small or text-embedding-3-large |
Use embeddings for retrieval and similarity rather than generation. |
| Moderation | omni-moderation-latest |
Do not replace a dedicated safety classifier with a prose prompt. |
| Deep research aliases | Check current model guidance; OpenAI lists gpt-5.5-pro as the replacement route |
o3-deep-research and o4-mini-deep-research are scheduled to shut down July 23, 2026. |
These dates are unusually volatile. Verify them on OpenAI’s deprecations page before starting a new integration.
Frequently asked questions
Which is better: Sol, Terra or Luna?
None is universally better. Sol is the quality-first choice for ambiguity and consequence, Terra is the everyday balance, and Luna is the speed-and-cost choice for clear repeatable work. The best configuration is the least expensive one that reliably passes your task.
Which model should a beginner choose?
Start with Sol at Medium effort when you have no evaluation data. Learn what a good result looks like, then compare Terra at the same effort. Move to Luna only when the task is constrained and easy to score.
Is Terra good enough for coding?
Yes, Terra is a sensible everyday coding baseline. Use Sol when the repository is unfamiliar, the change is architectural, debugging is ambiguous or a missed dependency would be costly. Use Luna for mechanical edits backed by strong tests.
When should I use Luna?
Use Luna for clear, repeatable and high-volume tasks such as extraction, classification, routing, transformation and structured summaries. It works best when the output schema and acceptance test are explicit.
Is higher reasoning always better?
No. Higher effort generally takes longer and uses more tokens, and it may not improve a routine task. Start at Medium or lower, measure failures, and increase effort only when it produces a meaningful gain on representative work.
Is Light the same as Low?
They are the current human-interface and CLI terms for the lower reasoning setting in OpenAI’s Codex guidance. Availability remains surface- and model-dependent, so use the exact label or API enum supported by your environment.
What is the difference between Max and Ultra?
Max gives one selected model more time to reason about one task. Ultra adds proactive delegation to subagents for work that divides into meaningful independent parts. Most tasks need neither.
Is Pro a separate GPT-5.6 model?
Not in the API. Pro is a Responses API execution mode enabled with reasoning.mode: "pro" on the selected Sol, Terra or Luna model. It is separate from the ChatGPT Pro subscription and from reasoning effort.
Which combination is fastest or cheapest?
Luna at None or Low effort is the natural latency-and-cost baseline for simple work. Total cost can still rise if it produces more tokens, retries or failures, so measure the completed workflow rather than only the published token rate.
Can all three models be used through the API?
Yes. The current API model IDs are gpt-5.6-sol, gpt-5.6-terra and gpt-5.6-luna. The gpt-5.6 alias currently routes to Sol.
What is the current default?
OpenAI documents the Power preset in Codex and ChatGPT Work as Sol with Medium reasoning. Consumer ChatGPT options vary by plan and workspace policy, while the GPT-5.6 API also defaults to Medium effort.
How should I benchmark my workflow?
Use representative tasks, define pass/fail before testing, hold the prompt constant, change one axis at a time, and track success, completeness, evidence, tool calls, latency, tokens, retries and total cost. Choose the least expensive setup that keeps passing.
The rule to remember
Model choice pays for task shape; effort pays for reasoning depth; Ultra pays for parallelism; Pro pays for additional quality-first execution; verbosity pays for visible detail. Start with Sol plus Medium when you are uncertain. Then earn your way down the cost curve with evidence: Terra for the everyday case, Luna for the well-specified case and higher settings only for measured failures.
Corrections and updates: Kingy.ai reviews this guide against official OpenAI sources at least weekly. Material changes to model IDs, settings, availability, pricing or deprecations will update the article and change log. A no-change audit will not be presented as a substantive update. See Kingy.ai’s editorial and sponsorship standards.
Update log
- July 10, 2026: Initial publication. Verified GPT-5.6 model roles, model specifications, reasoning effort values, Pro mode, Multi-agent beta, pricing, surface terminology and deprecation dates.