GPT-5.6 Sol vs Terra vs Luna: an Azure routing playbook

On 9 July 2026, OpenAI released the GPT-5.6 series to the public in three tiers: Sol, the flagship for hard problems and long autonomous runs; Terra, the balanced model for everyday work; and Luna, the fast and inexpensive tier. Alongside the models came ChatGPT Work, an agent product built to carry out whole jobs rather than answer single questions. For Azure-first teams the release landed close to home immediately. Microsoft made all three models generally available in Microsoft Foundry the same day, and OpenAI announced that GPT-5.6 becomes the preferred model in Microsoft 365 Copilot across Word, Excel, PowerPoint and Chat.

A three-tier family is not just a bigger menu. It forces a routing decision on every workload you run against Azure OpenAI or Foundry: which jobs justify Sol pricing, which jobs Luna handles at a fifth of the cost, and where Terra earns its place in the middle. Getting that split wrong in either direction is expensive. Route everything to Sol and your token bill can quintuple for no visible quality gain on routine tasks. Route everything to Luna and your agent workflows quietly degrade. What follows is a practical routing framework and the token math, worked through in SEK.

What OpenAI shipped on 9 July

Three tiers, one family

All three models share the same core capabilities: a 1 million token context window, 128,000 maximum output tokens, and a knowledge cutoff of 16 February 2026. The launch also brought programmatic tool calling, the ability to spin up subagents from within a run, and explicit prompt cache breakpoints that give developers direct control over what gets cached between requests. The tiers differ in depth of reasoning, speed and price, not in surface features.

OpenAI's launch-day API list prices, per million tokens: Sol at 5 dollars input and 30 dollars output, Terra at 2.50 and 15, Luna at 1 and 6. On the quality side, launch-day independent testing by Simon Willison reported Sol setting a new high of 53.6 on Agents' Last Exam, a benchmark for long-running professional workflows, while trailing Anthropic's Claude Fable 5 on SWE-Bench Pro (64.6 percent against 80 percent). Read that as a useful early signal rather than a verdict: Sol looks strongest on sustained multi-step work, and coding-heavy teams should run their own evals before switching defaults.

An unusual road to release

The public launch followed a limited preview that began on 26 June for a small group of trusted partners, while OpenAI worked with US government partners on safety evaluations. That process traces back to a June executive order asking major AI developers to voluntarily submit frontier models for government review. OpenAI said the released models carry safeguards built to withstand real-world adversarial pressure, while also signalling that pre-release government evaluation should not become the long-term default. For EU buyers the relevant point is simpler: the models you can now deploy on Azure went through an extra external safety pass before general availability, which is worth a line in your own model risk documentation.

Same-day availability on Microsoft Foundry

Microsoft's announcement made Sol, Terra and Luna generally available in Microsoft Foundry on launch day, across its existing global regions with Global, Data Zone and Regional deployment options. The Foundry model router and prompt caching support the new family, and Foundry's hosted agents reached general availability in the same announcement. For Swedish teams this matters because the deployment-type choice, covered below, is where your data residency story lives.

A routing playbook: which tier for which job

Start from the job, not the model. The failure mode we see most often in Azure OpenAI estates is a single deployment name hard-coded into every service, chosen once when the platform team onboarded the API. Tiering only pays off if routing is an explicit, per-workload decision.

Routing rules of thumb. Default to Luna and escalate on evidence, not instinct. A tier upgrade is justified when a cheaper tier measurably fails your eval set, not when a demo feels smarter.

Luna: classification, extraction, routing and intent detection, summarisation of routine documents, RAG answers over well-curated indexes, autocomplete-style assistance, high-volume batch enrichment. Anything where the retrieved context does the heavy lifting and the model mostly reformulates.
Terra: everyday copilot chat, drafting and rewriting business documents, multi-turn assistants with tool calls, moderate code generation, RAG where synthesis across several sources is required. The sensible default for interactive workloads that face employees.
Sol: agent planners and orchestrators, long autonomous runs, hard analytical work (legal, scientific, complex financial reasoning), gnarly debugging and architecture tasks, anything where a wrong answer is costly and a human will not review every output.

Two structural patterns follow from the price spread. First, split your agents: put Sol in the planner seat and let Terra or Luna execute the individual steps. The new subagent support makes this split a first-class pattern rather than a hack. Second, treat the Foundry model router as infrastructure for the boring middle. It can arbitrate between Terra and Luna on interactive traffic, while Sol stays behind an explicit allowlist of workloads that have earned it.

Escalation, in both directions

Build a downgrade path too. Teams add tier upgrades under pressure and never revisit them. Put a quarterly review in the platform calendar: for each Sol workload, rerun its eval set on Terra and check whether the gap still exists. Model families improve underneath you, and yesterday's Sol-only task is often next quarter's Terra task at half the price.

The token math in SEK

The examples below use OpenAI's launch-day list prices and a deliberately round illustrative rate of 10 SEK per US dollar. Plug in your actual Foundry deployment prices and the current exchange rate before you take any number to a budget meeting; the point here is the ratios, which survive currency movement. Volumes are stated assumptions, not measurements.

Example 1: an internal RAG assistant

Assume 2,000 queries per workday, each carrying about 6,000 input tokens (system prompt, retrieved chunks, history) and producing 500 output tokens. That is 12 million input and 1 million output tokens per day.

Per day (12M in / 1M out), at 10 SEK/USD:

Luna:  (12 x 1)   + (1 x 6)  = 18 USD  ~ 180 SEK/day  ~  3,960 SEK / 22-day month
Terra: (12 x 2.5) + (1 x 15) = 45 USD  ~ 450 SEK/day  ~  9,900 SEK / month
Sol:   (12 x 5)   + (1 x 30) = 90 USD  ~ 900 SEK/day  ~ 19,800 SEK / month

If your retrieval pipeline is good, Luna answers most of these queries indistinguishably from Sol, and the annual difference is roughly 190,000 SEK for one assistant. That money is usually better spent improving the index than upgrading the model.

Example 2: a nightly document batch

Assume 5,000 documents per night at 4,000 input and 400 output tokens each: 20 million in, 2 million out. Luna costs about 32 dollars per night, roughly 320 SEK, or about 9,600 SEK across a 30-night month. The same batch on Sol runs about 1,600 SEK per night, around 48,000 SEK per month. Batch enrichment is the clearest Luna territory in the whole portfolio, and it is also where Foundry's Batch pricing and prompt caching stack further discounts on top.

Example 3: a split-tier agent pipeline

Assume 50 agent runs per day, each consuming 200,000 input and 20,000 output tokens across all steps: 10 million in, 1 million out daily. Running everything on Sol costs about 80 dollars per day, roughly 800 SEK. Now split it: the planner takes about a tenth of the tokens on Sol (around 8 dollars), and Terra executes the rest (around 36 dollars). Total: about 44 dollars, or 440 SEK per day. The split saves roughly 45 percent while keeping the hardest reasoning on the strongest model. Push the mechanical steps down to Luna and the saving grows further.

Cache before you upgrade

The explicit prompt cache breakpoints in this release deserve attention before any tier debate. Most enterprise prompts are dominated by stable prefixes: system instructions, tool definitions, policy text. Marking those as cache breakpoints cuts the effective input cost on repeated traffic and often changes the routing calculus more than a tier swap does. Output tokens cost six times input on every tier, so terse output formats and structured outputs remain the cheapest optimisation available.

ChatGPT Work and the Copilot governance question

ChatGPT Work, launched the same day, combines workspace agents, the Codex desktop app and hosted sites into one product. You give it an outcome, it gathers context from connected apps and files, works for hours if needed, and delivers finished spreadsheets, slides, documents or web apps. Bloomberg framed it as an agent that fields tasks for hours, and that framing is right: this is a shift from assistant to delegated worker, competing directly with Microsoft 365 Copilot in accounts that run both vendors.

For Microsoft-standardised organisations the more immediate governance item is inside Copilot itself. Per Microsoft's message center notice MC1422074, OpenAI models become available as a subprocessor in Microsoft 365 Copilot from 9 July, initially disabled by default, with the setting automatically enabled on 24 July for eligible customers whose admins take no action. That is an eleven-working-day window from launch, and it lands in Swedish holiday season. If your data protection assessment for Copilot was written against the previous processing chain, review the subprocessor change in the Microsoft 365 admin center before the auto-enable date rather than discovering it in August.

The Swedish and EU angle

Data residency is a deployment-type decision, not a model decision. On Foundry, the same GPT-5.6 tiers are offered through Global, Data Zone and Regional deployments. Global deployments route inference to capacity anywhere; EU Data Zone deployments keep processing within the EU boundary; Regional deployments pin it to a specific region. If your Article 30 records or DPIA state that inference stays in the EU, standardise on Data Zone deployments for all three tiers and write the deployment type into your platform's provisioning templates so nobody creates a Global deployment by accident. Expect Data Zone pricing to carry a premium over Global; that premium is the measurable cost of your residency commitment, and it belongs in the same SEK spreadsheet as the tier choice.

The AI Act does not change your tier choice, but it does change your paperwork. GPT-5.6 is a general-purpose AI model whose provider obligations under the AI Act sit with OpenAI and, for the Azure-hosted service, with Microsoft's documentation chain. As a deployer you inherit transparency and, for any high-risk use cases, risk-management duties that are indifferent to whether Sol or Luna answered. What the tiering does affect is documentation hygiene: if your model inventory listed one model per system, it now needs to record which tier each workload routes to and why, because routing is a material change to system behaviour.

Procurement should buy routing freedom, not a model name. Swedish public-sector frameworks and enterprise agreements alike have a habit of naming a specific model in the contract. This release is a reminder to specify capability requirements and eval thresholds instead, with the freedom to route between tiers and successors. A contract that says "GPT-5.6 Sol" ages badly; one that says "models meeting eval suite X at cost ceiling Y per thousand interactions" lets you capture every future price-performance improvement without a contract change.

Takeaways

1. Inventory current deployments. List every service calling Azure OpenAI or Foundry, which model it uses today, and its monthly token volumes in and out.
2. Classify each workload against the routing rules. Default to Luna, promote to Terra for interactive synthesis, reserve Sol for planners, long autonomous runs and provably hard reasoning.
3. Do the SEK math per workload. Use your real volumes, Foundry deployment prices and the current exchange rate. Ratios of 1 : 2.5 : 5 on input make the spreadsheet quick.
4. Build the split-agent pattern. Sol plans, Terra and Luna execute. Use the new subagent support instead of custom orchestration glue.
5. Set cache breakpoints before upgrading tiers. Stable prompt prefixes are the cheapest tokens you will ever buy.
6. Review the Copilot subprocessor setting before 24 July. MC1422074 auto-enables OpenAI models as a subprocessor for eligible tenants; decide deliberately, in writing.
7. Pin Data Zone deployments in templates. Make EU processing the default that requires no human vigilance.
8. Schedule a quarterly downgrade review. Rerun Sol workloads against Terra on your eval set and reclaim budget where the gap has closed.