Seven Ways to Cut Costs in Fabric, in Order

Issue #03 · FinOps Uncensored • Production Reality Briefing

• Azure OpenAI GPT-4o, GPT-4o-mini and GPT-4.1-mini retire on 14 April 2027
• Anthropic halves prompt-cache reads on Claude Sonnet 5.5 to $0.10/1M tokens
• How to cut your Microsoft Fabric capacity costs
• Playbook: audit every Fabric capacity, then pause the ones that sleep
• Cost comparison: retiring Azure OpenAI models vs. replacement pricing

Microsoft has notified Azure OpenAI customers (Service Health tracking ID MR5M-CG0) that four model versions will be retired on 14 April 2027. After that date they will no longer be available or operable. Each one has a default replacement, and which replacement you get depends on how the deployment is set up.

Note: These are the default replacements from the Service Health notice. Microsoft's public retirement schedule may lag behind it, so check the notice in your own tenant (Azure portal → Service Health) for the upgrade target of each deployment.

• Standard deployments set to auto-upgrade move to the default replacement automatically on the retirement date.
• Provisioned (PTU) deployments are never upgraded for you. You have to migrate them yourself, to the model of your choice.
• Deployments with auto-upgrade turned off stop working on 14 April 2027 (requests return 410 Gone) unless you redeploy them on a supported model.

For most Global and Data Zone workloads the change is good news: gpt-6-luna is priced well below every retiring model, up to 96% cheaper than GPT-4o. The risk sits on the Regional path. A Regional GPT-4o-mini deployment moves to gpt-5-mini, whose output price is 3.3 times higher. Because gpt-5-mini is a reasoning model, its "thinking" tokens are billed as output too, so the real cost per request rises by more than that. The full pricing breakdown below has the numbers for each model.

1. 1List your deployments on the retiring versions and note each one's deployment type and upgrade setting.
2. 2Test the replacement model on real prompts for quality, latency and cost, as Microsoft recommends.
3. 3Move Regional GPT-4o-mini workloads to Global or Data Zone gpt-6-luna where your data-residency rules allow it.
4. 4Plan and run the migration for every Provisioned (PTU) deployment early, while capacity is still available in your region.

🔗 Official Azure OpenAI retirement schedule →

Since 7 October 2026, cached input on Claude Sonnet 5.5 costs $0.10 per 1M tokens instead of $0.20. That is 5% of the $2.00 base input price, down from 10%. Cache writes and all other Sonnet 5.5 prices are unchanged. Reused context such as long system prompts, documentation or codebases now costs 95% less than sending it fresh.

Any workload that sends the same large prefix again and again: agents with long system prompts and tool definitions, chat over the same documents, and coding assistants that resend a codebase. The cheaper the cache read, the bigger the gap between a well-cached workload and one that misses the cache.

1. 1Put stable content first (system prompt, tool definitions, reference documents) and the changing content (the user's question, timestamps, request IDs) after it.
2. 2Keep the prefix byte-for-byte identical between requests. A timestamp or a reordered tool list at the top breaks the cache for everything after it.
3. 3Check cache_read_input_tokens in the API response. If it stays at zero on repeated requests, something in the prefix is changing.
4. 4Use the 1-hour cache only when the same prefix is reused across more than a few minutes. Its write costs 2x input, so it needs more reads to pay off.

🔗 Anthropic release notes, 7 October 2026 →

With Microsoft Fabric you pay for the size of the capacity you run, every hour it runs, not for the compute you actually use. A capacity sized for one busy hour costs the same during the 23 quiet ones. Most savings come from closing that gap: matching the size to the real load, moving load out of the peaks, and stopping or committing where it makes sense.

Every Fabric SKU gives you a fixed number of capacity units (CU): an F64 has 64, an F32 has 32. Three rules decide how far you can safely shrink:

• Smoothing. Background work (refreshes, pipelines, notebooks) is spread over 24 hours. Interactive work (people using reports) is spread over just 5 to 64 minutes, so it causes the sharp peaks.
• Throttling. Fabric lets you borrow ahead. Once more than 10 minutes of future capacity is used up, interactive requests are delayed. After 60 minutes they're rejected. When a full 24 hours is used up, background jobs are rejected too.
• Halving the SKU doubles the CU %. The work stays the same but the capacity is half the size. A capacity at 30% on F64 runs at about 60% on F32.

The Capacity Metrics app shows these numbers for each capacity. Look at 30 days, not one day.

1. 1Remove what nobody uses. Delete capacities with no workspaces or almost no load, or move their workspaces onto a shared capacity. These are the easiest savings.
2. 2Migrate legacy P SKUs. Microsoft no longer sells P SKUs, and each one retires at the end of its agreement term. Migration isn't automatic: buy the F SKU (P1 maps to F64 by capacity units), move the workspaces, then cancel the P SKU. Use the move to right-size too. F SKUs can be paused, resized and reserved, and F64 is a safe landing point for a P1, not a required one.
3. 3Right-size. A good rule of thumb: downsize when the average load would stay at or below about 60% on the smaller SKU and the busiest 24 hours at or below about 80%. If a smaller SKU would cause rejections, keep the current size and work on the peaks first.
4. 4Move background jobs out of the peak hours. Find the busiest hours and reschedule refreshes, pipelines and notebooks to quiet ones, often early morning or the weekend. Don't start every job on the hour.
5. 5Make the interactive load lighter. When the peaks come from report users, rescheduling won't help. Optimize the heaviest reports and semantic models: fewer visuals per page, simpler DAX, aggregations, import instead of DirectQuery where you can, and incremental refresh. Once the peaks are lower, try the smaller SKU again.
6. 6Pause what doesn't need to run 24/7. Pay-as-you-go capacities can be paused. Dev, test and business-hours-only capacities can be paused overnight and at weekends, either on a schedule or with a script. Don't pause an F64 that free viewers rely on: they can't open reports while it's paused.
7. 7Reserve what does run 24/7. For capacities that run all the time at a stable size, a 1-year reservation costs roughly 41% less than pay-as-you-go (an F64 in East US is about $5,003 a month reserved vs $8,410). Buy it last, only once the size is final.

• Reserving before you resize. A reservation locks in a size. Shrink first, then reserve.
• Sizing for the peak. One busy hour shouldn't decide the bill for the whole month. Fix the peak, then size for the normal load.
• Dropping below F64 without checking licences. Below F64, every report viewer needs a Power BI Pro or PPU licence (Pro is about $14 per user per month, and it's included in Microsoft 365 E5). Against a reserved F64, a reserved F32 saves money only if fewer than about 180 viewers would need a new licence.
• Pausing an overloaded capacity. Pausing settles any borrowed capacity straight away, and it shows up on the bill. Pause when the load is quiet.
• Forgetting storage. OneLake storage is billed separately and keeps growing. Clean up unused lakehouses, old tables and test copies.
• Leaning on overage. Compute above your capacity can be billed as overage at three times the pay-as-you-go rate, with no reservation discount, and overage is switched on by default for new capacities. Treat it as a safety net with a limit you set, not a way to run a smaller SKU.

Pick your most expensive capacity and look at its last 30 days. If the average is below about 30%, there's almost certainly a smaller size that fits. Then work down the list: remove, resize, smooth the peaks, pause, and reserve last. After each change, watch throttling for a week before you take the next step.

Steps 1, 6 and 7 above all start with the same question: which F SKU capacities exist, how big are they, and are they running right now? Fabric capacities are ordinary Azure resources, so one Azure Resource Graph query answers it across every subscription you can read, with a list-price estimate of what each one costs on pay-as-you-go.

Run this in Azure Cloud Shell (Bash) or any terminal with the Azure CLI signed in. The first run may ask to install the resource-graph CLI extension.

How to read the result:

• Sku and CUs: the number after the F is the capacity's CU count (F64 = 64 CUs).
• State: Active capacities are billing every hour; paused ones (shown as Paused or Suspended) are not billing for compute.
• EstPAYGMonthlyUSD: CUs × $0.18 × 730 hours, the list price if the capacity runs all month. An F64 comes to about $8,410. Capacities covered by a reservation cost less than this.

Legacy P SKUs are bought through Microsoft 365, not Azure, so they won't appear in this query. Find them in the Fabric admin portal under Capacity settings.

What it saves: an F8 dev capacity costs about $1,051 a month running 24/7 (8 × $0.18 × 730 hours). Running it only 10 hours a day on 22 working days (220 hours) brings it to about $317, saving roughly $734 a month, or 70%.

Run it on a schedule: put the two commands in an Azure Automation runbook or a Logic App, with a managed identity that has Contributor rights on the capacity. Resume it before the working day starts and pause it after the last scheduled job finishes.

• Don't pause an F64 or larger that free users rely on. They can't open reports while it's paused.
• Pausing a reserved capacity saves nothing, because the reservation keeps billing.
• Any smoothed usage still waiting to be burned down is billed the moment you pause, so pause after the day's heavy jobs, not in the middle of them.
• Refreshes, pipelines and notebooks scheduled during the pause will fail. Move them or resume first.

🔗 Microsoft guide: pause and resume a Fabric capacity →

Before letting Azure auto-upgrade your deployments on 14 April 2027, compare the pay-as-you-go token rates on each replacement path. All prices are Global Standard list prices in US dollars per 1 million tokens, shown as Input / Cached input / Output. Data Zone and Regional deployments cost roughly 10% more, but because that premium applies to both the retiring and the replacement model, the percentage changes stay the same. Check the Azure OpenAI pricing page for your exact region and deployment type.

gpt-6-luna prices are for standard-length prompts. Long-context requests on gpt-6-luna are billed at a higher rate, so check the long-context price if your prompts are very large.

1. 1Reasoning tokens are billed as output. gpt-5-mini is a reasoning model and always thinks: the tokens it spends "thinking" are charged at the output rate, so its 3.3x higher output price turns into an even bigger bill per request. It doesn't accept none, so set reasoning_effort to minimal for simple, non-reasoning tasks. gpt-5.1 defaults to none, so it only spends reasoning tokens if your code raises the effort. Check that migrated calls don't.
2. 2Cheaper usually means smaller. A model priced 96% below GPT-4o is unlikely to behave exactly like it. Test output quality on your own prompts before you switch production traffic, as Microsoft itself recommends.
3. 3Moving to Global changes where data is processed. The cheapest path for Regional workloads is Global or Data Zone gpt-6-luna, but only where your data-residency rules allow it.

17–20 November 2026 · Moscone Center, San Francisco. Meet the CloudHiro team and discover how we bring Azure-native FinOps intelligence and cloud cost optimization to enterprise environments.

👉 Schedule a meeting →

To cleaner architectures and lower cloud bills,
The CloudHiro Team