AI & Cloud Infrastructure

Running GPT-5.6 the enterprise way on Microsoft Foundry

By Technspire TeamJuly 15, 20268 views

On 9 July 2026, Microsoft made the full GPT-5.6 series generally available in Microsoft Foundry, day-and-date with OpenAI's own launch. Three models arrived at once: Sol for deep reasoning and agentic work, Terra as the balanced enterprise workhorse, and Luna for high-volume, latency-sensitive traffic. The same announcement shipped a new Asia-Pacific Data Zone, took the hosted agents runtime to general availability with VNet integration, and put concrete list prices on the table: Sol at $5.00 per million input tokens, Terra at $2.00, Luna at $0.20. For Swedish and EU teams that consume OpenAI models exclusively through Azure for data-residency reasons, this is the release to plan a quarter around. Same-day availability means no waiting for parity with the OpenAI API, and the deployment surface (Global Standard, Data Zones, provisioned throughput) is where the real enterprise decisions live. This guide walks through those decisions with the July 9 facts in hand.

What shipped on July 9

Three models, three price points

Microsoft positions the series explicitly by workload. Sol "delivers the most advanced reasoning capabilities yet, supporting extended reasoning, agentic workflows, and code-focused scenarios." Terra is the balanced option, pitched as "ideal for scaling intelligent applications across the enterprise." Luna is the fastest and cheapest, aimed at high-volume, latency-sensitive workloads. Standard Global pricing per million tokens at launch:

  • GPT-5.6 Sol: $5.00 input, $0.50 cached input, $6.25 cache writes, $30.00 output.
  • GPT-5.6 Terra: $2.00 input, $0.20 cached input, $2.50 cache writes, $12.00 output.
  • GPT-5.6 Luna: $0.20 input, $0.02 cached input, $0.25 cache writes, $1.20 output.

Two details deserve attention before you model costs. First, cached input is a tenth of the regular input price across all three models, so prompt-caching discipline moves from nice-to-have to a first-order cost lever. Second, Microsoft announced a promotional window for Sol: from 1 September through 30 November 2026, Sol input drops to $4.00 and output to $20.00 per million tokens. If you have a Sol-heavy proof of concept queued for autumn, the promotion effectively funds part of it.

The specs that matter for architecture

The Foundry model catalog lists gpt-5.6-sol (version 2026-07-09) with a 1,050k-token context window and a 128k-token maximum output, accepting text and image input and producing text. That context window changes what "retrieval" means for some workloads: a full contract pack, a quarter of support tickets, or an entire mid-sized codebase now fits in a single request. It does not make retrieval obsolete, because a million tokens of input at $5.00 per million is real money on every call, and cached-input pricing only helps when the long prefix is stable. Treat the window as headroom for stable, cacheable context, not as an invitation to stop ranking what you send.

Global deployment spans 28 regions at launch. The catalog offers the familiar consumption choices: pay-as-you-go or reserved provisioned throughput units (PTUs) for predictable latency at predictable spend.

Deployment types: where your tokens are processed

Foundry separates the model question from the residency question through deployment types, and this is the part of the launch that matters most for EU teams.

Global Standard

Requests can be routed to capacity anywhere in Microsoft's global fleet. You get the best availability and the launch-day price list quoted above. Data at rest stays in the resource's region, but inference processing can happen outside the EU. For many internal workloads that is acceptable; for others, your DPO will say no before you finish the sentence.

Data Zones: the EU boundary, and now an Asia-Pacific one

Data Zones have been the pragmatic middle ground since Microsoft introduced them for the EU and the US in late 2024: requests are load-balanced across multiple regions, but only regions inside the zone you selected. The EU Data Zone spans Azure regions located in EU member states, so prompts and completions are processed and stored within that boundary while you still get better capacity pooling than a single-region deployment. The July 9 announcement extends the model geographically: an Asia-Pacific Data Zone is now generally available, which matters if your organisation serves APAC subsidiaries under local data-handling commitments.

Verify before you promise. The launch announcement confirms GPT-5.6 general availability and the new Asia-Pacific zone, but it does not enumerate which GPT-5.6 variants are live in the EU Data Zone deployment type on day one. Model availability per deployment type has historically trailed Global by days to weeks and varies by variant. Before you commit a residency-sensitive workload to GPT-5.6, check the model catalog and your subscription's quota page for an EU Data Zone entry for the specific variant, and get the answer in writing if a customer contract depends on it.

Provisioned throughput

PTUs remain the right answer when latency variance is a product problem or when finance wants a fixed monthly number. The catalog lists PTU reservation as an option for the GPT-5.6 series. The classic pattern still applies: size PTUs for your baseline, and spill burst traffic to pay-as-you-go through a router or API Management policy.

Hosted agents go GA, with the isolation story enterprises asked for

The second half of the announcement is about running agents, not just calling models. The hosted agents runtime in Foundry is now generally available across multiple frameworks, and the GA feature list reads like a direct response to enterprise security reviews:

  • VNet integration: hosted agents can run with network isolation inside your Azure Virtual Network, so agent traffic to internal APIs, databases and private endpoints never traverses the public internet.
  • Voice Live: hosted agents with Voice Live are generally available, bringing real-time voice scenarios under the same runtime.
  • Toolboxes: generally available, giving you a governed catalogue of tools an agent may call rather than ad-hoc tool wiring per agent.
  • Tracing and evaluation: generally available for hosted agents, which is the observability layer your risk function will ask about.
  • Publishing to Microsoft Teams and Microsoft 365 Copilot: announced as generally available the week following the July 9 post, closing the loop from agent runtime to the surfaces where Swedish office workers actually live.

A further set of capabilities sits in preview: memory and routines and an agent optimizer in public preview, resilient task support and ROI tracking in private preview. Treat previews as evaluation material only; nothing in preview belongs in a production dependency or a customer commitment.

The practical significance of VNet-isolated hosted agents is that it removes the most common blocker we see in Swedish enterprise architecture reviews. Until now, teams that wanted managed agent hosting had to accept egress patterns their network security teams disliked, or self-host the orchestration layer on AKS or Container Apps to keep traffic private. A GA runtime that joins your VNet lets you keep the managed operational model and still satisfy a private-endpoints-only network policy. If you built a self-hosted orchestration layer purely for network isolation, this release is the trigger to re-evaluate that decision.

A decision framework for the GPT-5.6 series on Foundry

Two decisions, taken in order. First the model, then the deployment type.

  • Default to Luna for classification, extraction, routing, summarisation at volume, and any latency-sensitive user-facing path. At $0.20 input and $1.20 output it is priced for traffic you previously would not have sent to a frontier-family model at all.
  • Step up to Terra when Luna's answers need review too often: multi-step reasoning over business documents, agent orchestration with several tool calls, drafting that goes to customers. This is the sensible enterprise default when you have no benchmark data of your own yet.
  • Reserve Sol for the workloads that justify $30.00 output pricing: complex code generation, long-horizon agentic tasks, research and analysis where a wrong answer costs more than the tokens. Schedule heavy Sol experimentation inside the September-to-November promotional window if you can.
  • Then pick the boundary: Global Standard when processing location is unconstrained, EU Data Zone when prompts must stay in the EU (pending the per-variant availability check above), single EU region when a specific regulator or contract demands it, PTUs when latency or budget predictability outranks flexibility.

Worked cost example

Our own arithmetic on the published list prices, for a hypothetical internal assistant processing 2 million input tokens and 0.3 million output tokens per working day:

Luna:  2M x $0.20 + 0.3M x $1.20  = $0.40 + $0.36 = $0.76/day
Terra: 2M x $2.00 + 0.3M x $12.00 = $4.00 + $3.60 = $7.60/day
Sol:   2M x $5.00 + 0.3M x $30.00 = $10.00 + $9.00 = $19.00/day

Terra with 60% of input served from cache:
  0.8M x $2.00 + 1.2M x $0.20 + 0.3M x $12.00
  = $1.60 + $0.24 + $3.60 = $5.44/day (28% saving)

The spread is the point: a 25x difference between Luna and Sol on identical traffic. Model-per-route beats model-per-application. Put a cheap router in front, send the bulk of traffic to Luna, escalate to Terra or Sol on defined criteria, and structure prompts so the stable prefix (system prompt, tool definitions, reference material) caches. At a tenth of the input price, cache hits are where the budget goes to survive.

The Swedish and EU angle

Day-and-date availability changes the procurement conversation. For years the true answer to "can we get the newest OpenAI model through Azure?" involved a lag, and some teams quietly routed around procurement to the OpenAI API to get early access. GPT-5.6 arriving in Foundry on launch day removes that excuse. The compliant path and the current-model path are now the same path, which makes it easier to hold the line on a single, contracted, Azure-based route to OpenAI models under your existing Microsoft agreement, DPA and EU model clauses.

Residency documentation should name the deployment type, not just the service. "We use Azure OpenAI in Sweden Central" and "we use a Global Standard deployment" describe very different data flows. Your records of processing and any transfer-impact assessments should state the deployment type per workload, because that is what determines where inference happens. The EU Data Zone gives you a defensible, documented boundary with more capacity than a single region; use it as the default for anything touching personal data, and reserve Global Standard for workloads your DPO has explicitly cleared.

VNet-isolated agents map onto NIS2-era network controls. Organisations in scope of NIS2 are documenting network segmentation and access control around every new system. An agent runtime that joins your VNet, calls internal systems over private endpoints, and produces traces and evaluations you can hand to an auditor is far easier to approve than one that reaches your ERP over the public internet. The GA of tracing and evaluation matters here as much as the isolation itself: controls you cannot evidence might as well not exist in an audit.

Mind the AI Act clock on agent deployments. With general-purpose AI obligations already in force and high-risk obligations approaching on the EU AI Act timeline, any agent you publish to Teams or Microsoft 365 Copilot for internal use still needs an owner, a documented purpose, and a record of what tools it may call. Toolboxes and hosted-agent tracing give you the technical substrate for that documentation; the governance decision about which agents exist and why remains yours.

Checklist: your first two weeks with GPT-5.6

  • 1. Confirm EU Data Zone availability for the specific GPT-5.6 variants you need, in the catalog and your quota page, before promising residency to anyone.
  • 2. Re-run your evals. Point your existing evaluation suite at Luna first, then Terra, then Sol. Route by measured quality per task, not by model reputation.
  • 3. Model the costs with caching included. Cached input at one tenth of list price rewards prompt structures with long stable prefixes. Restructure prompts before you renegotiate budgets.
  • 4. Book Sol experiments for the promotional window. $4.00 input and $20.00 output from 1 September to 30 November 2026 is a meaningful discount for reasoning-heavy pilots.
  • 5. Pilot one hosted agent with VNet integration. Pick an internal workflow, wire it through a Toolbox, and let your network and security teams inspect the isolation model on a low-stakes case.
  • 6. Hold previews at arm's length. Memory, routines, resilient tasks and ROI tracking are preview features. Evaluate them; do not depend on them.
  • 7. Update your processing records. Add deployment type per workload to your GDPR documentation, and note the EU Data Zone boundary explicitly where it applies.

GPT-5.6 in Foundry is less about a single headline model and more about the deployment machinery around it finally matching what EU enterprises need: current models on launch day, a documented EU processing boundary, and an agent runtime that fits inside your network perimeter. Teams that sort out routing, caching and residency documentation now will spend the autumn shipping instead of re-architecting.

Sources