GPT-5.6: What Sol, Terra, and Luna Actually Mean for Developers

OpenAI released GPT-5.6 last week, and for once the naming is the most interesting part. The family ships as three models: Sol (flagship), Terra (balanced), and Luna (fast and cheap). The number tells you the generation. The name tells you the capability tier. Those tiers are meant to be durable, so when GPT-5.7 arrives, "Terra" will still mean the same thing it means today.

That sounds like marketing until you remember the last three years of model names. Anyone who has maintained a config file full of dated model strings knows exactly why this matters.

The lineup and pricing

Per OpenAI's announcement, the family breaks down like this:

The headline claim worth testing: Terra matches GPT-5.5 performance at half the price. If that holds for your workload, migrating is a config change that cuts your bill in two. That's the kind of upgrade you do on a Tuesday.

Sol is pitched at agentic coding, science, and cybersecurity work, and it notably completed a U.S. government review before release. The Sol preview post pairs those capability claims with what OpenAI calls its most advanced safety stack to date.

The caching changes are the sleeper feature

GPT-5.6 introduces prompt caching rules that are worth more attention than the benchmarks:

• Explicit cache breakpoints. You now mark where the cacheable prefix ends instead of hoping the automatic heuristics figure it out.
• A 30-minute minimum cache life. Cached prefixes are guaranteed to survive for half an hour.
• Cache writes cost 1.25x the uncached input rate. Cache reads keep the 90% discount.

If you run agents or chat products with long system prompts, do the math on your traffic pattern. A prompt that gets reused within 30 minutes now costs 25% extra once and then 90% less on every subsequent hit. For anything with steady traffic, that's a large, predictable saving. For sporadic traffic with gaps longer than the cache life, you're paying the 1.25x write penalty repeatedly and getting nothing back.

[!TIP] Structure prompts with the static content first (system prompt, tool definitions, few-shot examples) and volatile content last. That was already best practice; explicit breakpoints now make it directly billable engineering.

Which tier should you actually use?

The boring answer is the right one:

• Default to Terra. It's the balanced tier for a reason, and the 2x price cut over GPT-5.5 makes it the obvious migration target.
• Luna for volume. Classification, extraction, summarization pipelines, anything where you call the API thousands of times an hour and latency matters more than brilliance.
• Sol when the task fails on Terra. Agentic coding sessions, multi-step tool use, hard reasoning. At $30 per million output tokens, you want evidence it's needed, not vibes.

Simon Willison's early notes are a good independent read on the family, and MarkTechPost has details on the programmatic tool calling added to the Responses API alongside the launch.

What the tier choice actually costs you

Headline per-token rates are the least useful way to compare tiers, because the thing that varies between them is not just price, it is how many attempts a task takes.

Model the workload instead. A useful shape to reason about: 30,000 input tokens, 800 output, 20,000 requests a month, with 60 percent of input served from a warm cache. On that footing the spread across the current field runs from roughly $20 a month at the cheapest tier to over $20,000 at the most expensive, a spread of about 1,000x for the same nominal work. You can run your own numbers in our LLM cost calculator, which models the caching and batch rates most comparisons leave out.

Two adjustments matter more than the tier you pick:

Reasoning tokens bill as output. A request that returns 200 visible tokens after thinking at length can bill like one that returned several thousand. If your workload uses extended or adaptive reasoning, your real output figure is well above what you see in the response, and output is typically five times the input rate.

Long-context tiers. Some providers charge more once a single prompt crosses a threshold. Every xAI Grok model doubles its rate at 200,000 tokens, for example. A calculator that ignores that under-reports long-context work by half.

Picking a tier without benchmarking everything

A practical routine that avoids running a full evaluation against every model:

1. Start one tier above what you think you need. Establishing that the task is solvable at all is worth more than saving money on a version that cannot do it.
2. Once it works, step down one tier and re-run your evaluation set. Keep stepping down until quality drops, then go back up one. This costs a handful of runs and usually lands two tiers below where teams stop by default.
3. Measure cost per completed task, not per million tokens. A cheaper model needing two attempts, a longer prompt, and a human check is not cheaper.
4. Route by difficulty rather than picking one model. A small model handling the routine bulk with a frontier model taking the remainder is almost always cheaper than either alone. Model the two tiers separately and add them.

Availability

The models are rolling out now, with general availability promised in the coming weeks. If you're running evals before switching (you should be), the pricing above is already live to test against.

The durable-tier naming is the real story here. If OpenAI sticks to it, "we run Terra" becomes a stable architectural decision instead of a model string you revisit every quarter. That's a small thing that removes a recurring migration tax, and after three years of dated snapshot names, it's overdue.