Why You Should Give Copilot Its Own Fabric Capacity

You've turned on Copilot in Microsoft Fabric. Your team is asking questions in natural language, generating code, querying semantic models. It feels like progress.

Then someone in finance runs a particularly heavy Copilot session at 9am on a Monday, and your ETL pipelines start throttling. The Power BI refresh that the board relies on at 9:30 failed. You're now in a conversation you didn't want to have.

This is the moment most organisations hit when they start rolling out AI at scale inside Fabric. Not because Copilot is broken. But because they didn't separate the workloads.

There's a straightforward fix. And it takes about ten minutes to set up.

How Copilot Billing Works in Fabric

Before we get to the fix, it helps to understand how Copilot consumes resource in the first place.

There are no per-user Copilot licences in Fabric. Instead, every Copilot interaction - whether that's generating a PySpark notebook, asking a question in a data agent, or having Copilot build a Power BI report - consumes tokens, which are converted to capacity unit seconds and charged against your Fabric capacity.

Like all Fabric capacity, you're paying for reserved compute, the SKU you choose sets your cost floor regardless of usage. But Copilot consumption within that capacity is precisely metered in tokens converted to capacity unit seconds, so you can right-size the SKU based on actual AI demand rather than guesswork. And Copilot runs as a background job, which means usage is smoothed over a 24-hour window rather than hitting your capacity as an instant spike.

That helps smoothing. But it doesn't solve the underlying problem: when Copilot is sharing a capacity with your production workloads, there's always a risk that heavy AI usage compresses the headroom available for everything else.

The Dedicated Capacity Option

Microsoft built a solution into Fabric for exactly this scenario. You can designate a separate Fabric capacity specifically for Copilot and AI agent workloads.

Once enabled, it doesn't matter which workspace a user is in or how that workspace is licensed. Any Copilot query, any data agent interaction, any AI-related consumption routes to the dedicated capacity rather than your main one.

Your production pipelines and reporting workloads are completely isolated.

Five Reasons to Do This Before You Scale Copilot Access

1. Workload Isolation That Actually Holds

The moment you give 50 or 100 people access to Copilot, usage becomes unpredictable. Someone builds a data agent and points 40 colleagues at it. Someone else discovers they can generate entire notebooks in seconds and starts doing it for everything. These are good behaviours - you want people using the tools. But on a shared capacity, that enthusiasm has a ceiling, and it's the same ceiling your data engineers are working under.

A dedicated Copilot capacity removes that constraint. AI usage can grow independently without affecting the workloads your business is already depending on.

2. Visibility Into What AI Is Actually Costing You

Right now, if Copilot is sharing your main capacity, it's very difficult to answer the question "what are we spending on AI?" The Fabric Metrics App will show you capacity unit consumption, but unpicking AI from ETL from reporting from everything else is a manual exercise.

A dedicated Copilot capacity gives you a clean answer. Everything on that capacity is AI. You can monitor it, report on it, and make informed decisions about whether to scale it up or down.

3. A Natural Cost Ceiling While You're Still Learning

Fabric AI adoption tends to follow a pattern: slow start, then rapid uptake once people understand what it can do. That acceleration is good, but it can also produce unexpected cost spikes if you're not watching closely.

A dedicated capacity gives you a hard ceiling. You pick the SKU - you can start as low as F2 - and that defines your daily AI budget. If usage approaches the ceiling, you see it clearly. You can scale the capacity up deliberately, with full knowledge of why.

4. Better Governance When It Matters Most

For organisations in regulated sectors - financial services, pensions, legal - the ability to track, limit and audit AI usage isn't optional. A dedicated Copilot capacity makes governance significantly easier. You know exactly what's running, where, and at what cost. That's a much more defensible position than "it's mixed in with everything else."

5. Your Power BI developers will finally stop asking why they can't use Copilot

Without a dedicated Copilot capacity, whether a user can access Copilot depends entirely on which workspace their content lives in. Fabric capacity workspace? Yes. Pro workspace? No. PPU? It depends. For organisations with a mixed workspace estate, this creates a frustrating, unpredictable experience where some people have Copilot and others don't, seemingly at random.

Every user you assign gets consistent Copilot access regardless of which workspace their reports or semantic models live in. No more exceptions.

How to Set It Up

The configuration lives in the Fabric Admin Portal under Tenant Settings. You're looking for two settings:

• "Users can use Copilot and other features powered by Azure OpenAI" - this enables Copilot across the tenant.

• "Capacities can be designated as Fabric Copilot capacities" - this unlocks the ability to assign a specific capacity for AI workloads.

  
  

Once both are enabled, you create a separate Fabric capacity (an F2 is sufficient to start), then designate it as the Copilot capacity through the tenant settings.

Assigning Users to the Copilot Capacity

The final step is assigning users. Inside the Capacity Settings for your dedicated Copilot capacity, you'll find the Copilot capacity section. Here you choose whether to apply it to the entire organisation or to specific users and groups.

Figure 1 - Capacity Settings: assigning users or groups to the dedicated Copilot capacity

In most cases you'll want to use specific security groups - this gives you control over who routes to the dedicated capacity and makes it straightforward to expand access in a managed way as adoption grows.

Only users assigned here will have their Copilot and AI agent usage billed against the dedicated capacity. Anyone not in scope will fall back to their workspace capacity - so make sure group membership reflects your rollout scope before you go live.

There's one additional setting worth noting: "Data sent to Azure OpenAI can be processed outside your capacity's geographic region." This allows Microsoft to use compute in adjacent regions to handle AI requests more efficiently. For most organisations this is fine to enable. If you have strict data residency requirements, review this with your compliance team before switching it on.

Monitoring Your Copilot Capacity Usage

Once your dedicated capacity is running, the Fabric Capacity Metrics app is where you go to understand what's actually happening. This is a free app you deploy from AppSource into your Fabric tenant, and it gives you a full breakdown of capacity unit consumption across all workloads.

What You See on the Copilot Capacity

For Copilot specifically, the most useful view is the Background Operations drillthrough. This shows every Copilot interaction that has run against the capacity, broken down by workspace, item kind, item name, and operation type.

What you're looking for in that view is the Operation column. Copilot interactions appear as "Copilot in Fabric" - which means you can filter the entire report to that operation type and see a clean picture of AI consumption in isolation.

Figure 2 - Copilot capacity metrics: Background Operations drillthrough showing 'Copilot in Fabric' operations against Dataflow items in the AI Demo workspace

Each row represents a discrete Copilot interaction. Because this is a dedicated Copilot capacity, there is no noise from pipelines, refreshes, or reporting workloads mixing into the view. You can see exactly which workspaces are driving usage and which item types are generating the most AI interactions.

What You See on the Main Fabric Capacity

Drilling through to the Background Operations on your main Fabric capacity tells a different story. Here you see the full range of platform workloads running in parallel: Lakehouse reads and writes, Dataflow operations, Warehouse processing, and OneLake operations via proxy and redirect.

F

Figure 3 - Main Fabric capacity metrics: Background Operations drillthrough showing mixed production workloads across Lakehouse, Dataflow and Warehouse item types

This view shows why separation matters. The operations visible here - OneLake Iterative Read, OneLake Write via Proxy, High Scale Dataflow, OneLake Read via Redirect - are the workloads your data pipelines and reporting estate depend on. These are the jobs you cannot afford to have compressed by AI traffic at peak times.

With a dedicated Copilot capacity in place, these two views remain cleanly separate. Your production metrics stay clean, and your AI metrics are actionable on their own terms.

For organisations that need to report on AI spend internally - or that need to demonstrate controlled AI usage to an auditor or regulator - this separation is the evidence.

What This Looks Like in Practice

A client running Fabric at F8 with a team of 30 active Fabric users enabled Copilot for the whole team on a shared capacity. Within two weeks, they noticed morning throttling on their daily data refresh jobs. The culprit was a data agent that had become popular with the business team - it was running dozens of queries per hour during working hours.

The fix: stand up an F2 dedicated Copilot capacity, redirect all Copilot workloads, and monitor. The production capacity went back to its baseline. The AI workload became fully visible. And when the data agent usage grew further, they had a clear case for scaling the Copilot capacity to F4 - based on actual consumption data, not guesswork.

The Bottom Line

Copilot and AI agents in Fabric are increasingly load-bearing features. As adoption grows, treating them as an afterthought on your main capacity creates risk - to production stability, to cost control, and to your ability to govern AI use responsibly.

A dedicated Fabric Copilot capacity addresses all three. It's a ten-minute change in the admin portal, and it's the right architecture to better understand Copilot usage and adoption.

Ready to review your Fabric capacity architecture?

MPowerUp are Microsoft Partners specialising in Microsoft Fabric, Power Platform, and AI implementation. Get in touch at www.mpowerup.co.uk