GPT-5.6 Sol vs Terra vs Luna: Which Tier to Actually Use

OpenAI shipped GPT-5.6 on July 9, and instead of one model it shipped three. Sol, Terra, and Luna — same generation, three price points, and a launch post that spends more energy on benchmark bars than on the only question you actually have: which one do I send this task to, and when do I bump it up a tier?

That question has a real answer, and it isn’t “use the best one.” The best one, per token, costs five times what the cheap one does. Route everything to Sol and you’ll light money on fire. Route everything to Luna and you’ll ship broken code. The whole point of a three-tier lineup is that you’re supposed to move work between them, so let’s sort out where each piece of work belongs.

The three tiers at a glance

Here’s what OpenAI put on the table, per million tokens:

The naming doesn’t map to “big, medium, small” the way you’d expect, and that trips people up. Sol is the priciest, but OpenAI isn’t pitching it as the everyday flagship. It’s the specialist — the one tuned to grind through long, stateful agent runs where it holds context across dozens of tool calls and you’d rather pay more per token than babysit a cheaper model that loses the thread halfway through.

Terra is the one most teams will reach for when a task is genuinely hard. It’s the max-reasoning tier — the model you escalate to when Luna’s answer smells wrong. Luna is the default: fast, cheap, and good enough for the overwhelming majority of what an LLM app actually does all day.

If you only remember one sentence: Luna by default, Terra when it’s hard, Sol when it’s long.

One more axis worth watching: latency. Cheaper tiers usually answer faster, and Luna is quick enough that it’s often the right pick for anything user-facing where someone is waiting on the response — a chat reply, an autocomplete, a live suggestion. Terra and Sol spend more time reasoning, which is exactly what you want on a background job and exactly what you don’t want when a human is staring at a spinner. So the routing question isn’t only “how hard is this task,” it’s “is anyone waiting.” A hard task that a person is watching sometimes still wants Luna, because a fast decent answer beats a slow great one when the user’s attention is the scarce resource.

Why Luna is the right default

Most LLM calls in production aren’t hard. They’re classification, extraction, summarization, drafting, reformatting — work you run thousands of times a day where the model just needs to be competent and consistent. For that, Luna at $1/$6 is the obvious home.

The mistake I see teams make is benchmarking their models on their hardest problem and then routing everything through whatever won. Your hardest problem is maybe 5% of your call volume. The other 95% doesn’t care whether the model can solve a competition math proof. It cares whether it can pull a date out of an email correctly, ten thousand times, without drifting.

Where Luna’s quality actually drops off is predictable: multi-step reasoning where an early wrong turn compounds, coding tasks that touch more than one file, and anything that needs the model to hold a plan across a long context and not lose the plot. On those, you’ll feel it — not as a crash, but as confidently-wrong output that looks fine until you check it. That’s the signal to escalate.

Terra and the coding reality check

Terra is where GPT-5.6 gets interesting for developers. On the Coding Agent Index it lands around 77, which puts it dead level with Claude Fable 5 — a model that, at $10/$50 per million tokens, costs four times as much on output. If you’ve been paying Fable-tier prices for agentic coding, Terra tied at a quarter of the output cost is the line worth pausing on.

I’d frame it carefully, though. “Tied on the index” is not “identical in your repo.” Aggregate coding benchmarks smooth over exactly the cases that bite you — the gnarly multi-file refactor, the subtle type error, the test that passes for the wrong reason. Anthropic still holds a real edge on the hardest real-repo work, which I got into when I ran the cost math on Fable 5 credits. But for the broad middle of coding-agent work — write the function, fix the bug, wire up the endpoint — Terra at $2.50/$15 is a genuinely strong value play, and that’s new.

Luna can code, to be clear. For a single-file change with a clear spec, it’s fine and it’s cheap. The dropoff comes when the task needs the model to reason about how three files interact, or to recover from its own mistake mid-task. That’s Terra’s job. If you’re routing coding work, the rule of thumb is: Luna for the mechanical stuff, Terra the moment there’s a diff spanning more than one file or a bug whose cause isn’t obvious.

What about Sol for coding? I’d mostly skip it. On a per-diff basis Sol doesn’t buy you much over Terra on code correctness — the reasoning gap between the two closes fast on well-scoped programming tasks. Where Sol earns its price is duration, not difficulty: an agent that codes and runs the tests and reads the failures and tries again, across a long session, without losing track of what it was doing. If your coding is one prompt to one diff, Terra. If it’s an autonomous loop that runs for twenty minutes, Sol starts to make sense.

The cost-per-task math nobody runs

Per-million-token prices are abstract. What matters is what a task costs, so here’s the arithmetic on three realistic shapes of work. I’m using round token counts — adjust to your own traffic, but the ratios hold.

A quick bug fix — say 20K tokens of context in, 5K of output:

A batch job — 10,000 classification calls, roughly 1K in and 200 out each:

A long-horizon agent run — one big task that accumulates 500K input tokens across tool calls and emits 100K:

Two things jump out. First, on high-volume batch work, the tier choice is a 5x swing — that classification job is $22 on Luna or $110 on Sol, for output most people couldn’t tell apart on a spot check. That’s the single most expensive routing mistake you can make, because it’s silent and it repeats.

Second, on a one-off long agent run, the absolute numbers are small enough that the tier barely matters. $1.10 versus $5.50 is not a decision worth agonizing over if the run does something valuable and you do it occasionally. This is why Sol makes sense as a specialist even at its price: you’re not running it a million times, you’re running it on the tasks where finishing correctly is worth $5. Reserve the premium for low-volume, high-stakes work and it stays cheap in aggregate.

Where ChatGPT Work fits

Alongside the API tiers, OpenAI launched ChatGPT Work — a new agent surface aimed at getting things done inside your actual work tools rather than just answering in a chat box. It connects to your files, your calendar, your inbox, and runs multi-step tasks on your behalf: pull the numbers from these three docs, draft the summary, put it on the calendar.

Under the hood it leans on the reasoning tiers — Terra-class work for the planning, escalating where it needs to. You don’t pick the model; the product does. And that’s the whole point of it. ChatGPT Work is for the person who wants outcomes, not a routing layer to configure.

So when do you use it over the raw API? Use ChatGPT Work when the task is yours, personal, and bounded — you, doing your job, wanting an agent to handle the busywork. Use the API when the task is your product — something you run for users, at volume, where you need to control cost, latency, and which tier handles what. The moment you care about the per-task math above, you’ve outgrown ChatGPT Work and you want the API with your own routing. The two aren’t competitors; they’re different buyers.

A routing table you can actually use

Here’s how I’d wire it up as of July 2026. Start every task at the lowest tier that plausibly handles it, and escalate on a trigger, not a hunch.

The escalation triggers are the part that matters. “Escalate when it’s hard” is useless advice because everything feels hard until you’ve measured it. “Escalate when the diff spans more than one file” is a rule you can actually put in code. Build the triggers into your router and you stop making the decision case by case.

Don’t hardcode this — you’ll be re-routing in a month

Two caveats before you commit any of this to production.

One: these tiers will move. OpenAI ships fast, prices drift, and a competitor’s launch can make today’s routing wrong overnight. The June cross-vendor picture I laid out in the GPT-5.6 vs Gemini vs Claude routing guide has already shifted just from GPT-5.6 actually shipping. Whatever table you build, expect to redraw it.

Two: this is an argument for a routing layer, not a favorite model. If your tier selection lives in scattered if statements across your codebase, every price change is a migration. Put it behind an LLM gateway and tier routing becomes config you change in one place — which, in a market where three tiers launched in a single week, is worth the setup cost.

The thing I’d do this week isn’t pick a tier. It’s take one workflow you run constantly, run it on Luna, and watch where it fails. That failure boundary — the exact point where Luna stops being good enough — is your escalation trigger, and it’s specific to your work in a way no launch benchmark can tell you. Find it once and the routing writes itself.