What it does

Copilot in Fabric and Power BI runs on paid Fabric capacity, not on a per-user Copilot add-on. Usage is metered as Capacity Units billed by the tokens each request processes, and admins switch it on through tenant settings.

Key facts

• Capacity floor: Copilot needs at least an F2 or P1 SKU. The old F64 minimum was removed on 28 April 2025, so smaller capacities now qualify.
• Billing is consumption-based: metered in Capacity Units against your capacity, priced by tokens processed. Roughly 1,000 tokens is about 750 words, and input and output tokens are rated differently.
• Rough scale: an F64 has 1,536 CU-hours a day and each Copilot request runs around 0.11 CU-hours, so a capacity can absorb thousands of requests a day before exhaustion. Use this as an order-of-magnitude guide, not a promise.
• Fabric Copilot capacity: you can designate a capacity purely to collect and bill a group's Copilot usage, charging it there instead of to the capacity holding their content.
• Enablement is an admin action in the Fabric/Power BI admin portal tenant settings, and it can be scoped to security groups.
• Cross-geo processing is a separate tenant setting. Turn it on and prompts may be processed in another region where Azure OpenAI is available, possibly outside your compliance boundary.
• There is no separate per-user Copilot licence for Fabric/Power BI Copilot. The capacity is the licence.

When to use / skip

Any Fabric or Power BI Copilot rollout starts here. Get the capacity floor, the billing model and the tenant switches sorted before anyone touches a feature. Skip promising Copilot on a client's existing setup until you've confirmed they run at least F2/P1 paid capacity. Pro-only or Premium-Per-User-only estates without a Fabric capacity don't qualify, and that's a common surprise.

Configuration decisions

• Confirm the client has qualifying paid capacity (F2/P1 or higher) before scoping any Copilot work.
• Decide whether to run a dedicated Fabric Copilot capacity for billing isolation or let usage hit the content capacity.
• Choose the cross-geo processing setting deliberately against the client's data-residency rules.
• Scope tenant enablement to security groups rather than switching it on tenant-wide by default.
• Size capacity with Copilot headroom in mind; heavy use competes with your other Fabric workloads for CUs.

Gotchas

• Copilot consumption shares the same CU pool as the rest of the capacity. A busy Copilot week can slow other workloads or trigger throttling.
• Bursty token-based billing is hard to forecast. Watch the Capacity Metrics app early in any rollout.
• The F2 floor is recent. Older guidance and blog posts still cite F64. Don't trust stale numbers.
• Cross-geo processing can quietly move prompts out of region. Check it before a client with residency obligations goes live.
• Removing the SKU floor lowered the entry bar but not the risk of a small capacity being swamped by Copilot demand.

Consultant notes

• Capacity sizing is the real cost conversation. Frame Copilot as another CU consumer competing for the same pool, not a flat add-on.
• The dedicated Fabric Copilot capacity pattern is useful when finance wants Copilot spend ring-fenced and attributable.
• Always check the SKU floor and per-request CU figures live. Both have changed inside the last year and will again.

---

Re-verify the F-SKU floor, per-request CU cost and cross-geo behaviour against current Learn docs before quoting any client.