A CFO at a manufacturing group running Dynamics 365 Finance and Supply Chain recently signed off on an F64 Fabric capacity so the FP&A team could start using Power BI Copilot to draft variance commentary and summarize demand forecasts. Three weeks later, an IT director flagged something the approval memo never mentioned: two hundred report viewers across the business no longer needed Power BI Pro licenses at all. That wasn’t a bug or a surprise discount. It was a separate Fabric licensing rule that happens to kick in at the exact same capacity size Copilot is often recommended for, and the two get conflated constantly in vendor pitches and budget spreadsheets alike.
That conflation is the real problem for anyone trying to budget a Power BI Copilot rollout against a Dynamics 365 reporting program. Copilot in Power BI is not a per-seat add-on the way Microsoft 365 Copilot is. It is billed against Fabric capacity consumption, measured in capacity units, and organizations can even designate a specific Fabric Copilot capacity purely to centralize that billing. Whichever capacity ends up holding that designation is shared with every other Fabric workload your organization runs on it. Getting the cost model wrong in either direction, assuming it is included in your existing Pro licenses, or assuming it behaves like a fixed monthly fee, leads to budget requests that are either laughably low or defensively padded past what the workload actually needs.
What Copilot Actually Consumes, and Why the Rate Card Looks Strange
Microsoft’s own Fabric documentation describes Copilot consumption in capacity unit seconds, priced per 1,000 tokens, and the input and output rates are not the same. Input prompt tokens consume 100 CU seconds per 1,000 tokens, cached input tokens (system instructions, schema context, and conversation history that Fabric automatically caches without any configuration) consume only 10 CU seconds per 1,000 tokens, and output tokens, the actual generated text, consume 400 CU seconds per 1,000 tokens. That four-to-one gap between input and output pricing matters in practice: a Copilot-generated narrative summary of a Dynamics 365 SCM inventory report produces far more output tokens than the prompt that requested it, so output pricing dominates the bill.
Take a request with 2,000 input tokens and 500 output tokens, a reasonably typical size for a Copilot-drafted commentary on a Power BI report built over Dataverse or F&O entity data. The math works out to (2,000 × 100 + 500 × 400) ÷ 1,000, which is 400 CU seconds, or roughly 6.67 CU minutes. On its own that number means nothing to a finance leader. What it means in context is the second thing worth understanding: how that consumption gets classified against your capacity.
Background Job Smoothing Changes the Real Exhaustion Risk
Microsoft classifies Copilot operations as background jobs rather than interactive ones, and background jobs get smoothed over a 24-hour window instead of the 5-minute window used for interactive report rendering. Throttling only begins once the capacity has already committed all of its available CU budget for the next 10 minutes. Microsoft’s own documentation walks through this with an F64 example: an F64 SKU carries 64 × 24, or 1,536, CU hours in a single day. A single Copilot request consuming roughly 6.67 CU minutes works out to about 0.11 CU hours, which means an F64 capacity could theoretically absorb well over 13,000 such requests before exhaustion, assuming nothing else on that capacity is consuming CU budget at the same time.
That last clause is where the real governance risk sits, and it’s a genuinely different risk than “Copilot is expensive.” When capacity is exhausted, Microsoft’s documentation is direct about the consequence: all operations shut down, not just Copilot. If your Dynamics 365 reporting workspace, your dataflows, your semantic model refreshes, and your Copilot usage all live on the same Fabric capacity, and a finance analyst runs an unusually large batch of Copilot-assisted narrative generation during month-end close, everyone else’s scheduled refreshes and interactive reports can stall on that same capacity at the same time. This is an argument for isolating Copilot consumption onto its own designated capacity rather than an argument against adopting it at all, and Microsoft built a specific mechanism for exactly that.
The Fabric Copilot Capacity Designation Is Not the Same Thing as F64
Since April 2025, Microsoft has allowed organizations to designate any capacity of F2 or larger, not just F64 and above as originally required at the January 2025 preview launch, as a dedicated “Fabric Copilot capacity.” A Fabric admin enables Copilot for the organization, authorizes a capacity admin to make that designation, and the capacity admin then assigns user groups whose Copilot usage should bill there instead of wherever their content happens to be hosted. Once that’s done, no further action is needed. Users assigned this way can be on Pro, PPU, Trial, Premium capacity, or Fabric capacity license modes, though Embedded is explicitly not supported.
This solves a specific budgeting problem: without it, Copilot costs get spread across whatever capacity holds each user’s content, which makes centralized cost tracking nearly impossible for an IT Director trying to build a clean Copilot line item. With a designated Copilot capacity, every dollar of Copilot consumption lands in one place on the bill, separate from your Dynamics 365 reporting workspace’s own capacity consumption for refreshes and interactive use. Worth noting for architects planning this out: Fabric Copilot on other workloads (Data Factory, Data Engineering, Data Warehouse, Data Science, Real-Time Intelligence, and Activator) is only available on capacities smaller than F64, while Power BI Copilot specifically remains available regardless of capacity size. If your organization runs Copilot across multiple Fabric experiences, not just Power BI, that asymmetry affects which capacity size you actually want for the designation.
Why the F64 Threshold Gets Conflated With Copilot Pricing, and Why That Matters for Your Budget
Separately from anything Copilot-related, Microsoft’s Fabric licensing model has long included a straightforward rule: on any F SKU smaller than F64, every person viewing Power BI content needs a Pro, PPU, or individual trial license. At F64 or larger, a user with only a free Fabric license can view content, provided they hold a viewer role on the workspace. This rule exists independent of Copilot and predates Copilot’s current billing model by a wide margin. It’s an artifact of how Microsoft licenses Power BI content consumption at scale, not a Copilot feature.
The reason this matters for a CFO’s budget conversation is that vendors and consultants routinely present F64 as “the tier where Copilot gets cheap,” when the more accurate framing is that F64 is where per-viewer Pro licensing gets cheap, and Copilot’s own cost is a completely separate, consumption-based line that scales with usage regardless of which SKU size you land on. An organization with two hundred report viewers and modest Copilot usage might genuinely benefit from an F64 capacity purely for the license consolidation, independent of whether Copilot ever gets turned on. An organization with heavy Copilot usage across a small number of power users, finance analysts drafting narrative variance reports all day, might be better served by a smaller designated Copilot capacity and leaving Pro licensing exactly where it is. These are two different decisions being made to look like one decision, and separating them is the actual budgeting exercise.
What This Means for a Dynamics 365 Reporting Rollout
For an IT Director or CFO evaluating Power BI Copilot against Dynamics 365 Finance, Supply Chain, or Customer Engagement reporting, start by quantifying how many people will actually draft Copilot-assisted narratives, distinct from how many simply view the resulting reports, since those two populations drive different cost levers entirely. From there, model consumption using the token rates above against your actual reporting cadence rather than a vendor’s generic estimate, since output-heavy use cases like automated commentary generation consume capacity differently than short, targeted Q&A against a semantic model. Finally, decide separately whether an F64-or-larger capacity makes sense for license consolidation, and treat that as independent from whichever capacity you designate for Copilot billing.
Fabric’s list pricing follows the capacity unit count linearly, so an F64 capacity costs roughly thirty-two times an F2 capacity’s pay-as-you-go rate, and Microsoft’s own reservation pricing page states that a one- or three-year commitment can reduce that rate by roughly 41 percent compared to pay-as-you-go. Given how directly usage scales with cost here, that reservation discount is worth pricing into any multi-quarter Copilot rollout plan rather than treating it as an afterthought once the pilot succeeds.
None of this makes Power BI Copilot a bad investment for a Dynamics 365 reporting program. It makes it a capacity planning exercise with its own governance questions, closer to provisioning compute than provisioning software seats. Organizations that treat it as the latter tend to either under-budget it or, more commonly, over-provision a capacity size for reasons that had nothing to do with Copilot in the first place. It’s the kind of distinction our team at Routeget Technologies walks clients through before a single dollar of Fabric capacity gets provisioned, since separating the licensing decision from the consumption decision up front is what keeps a Copilot rollout from turning into an unplanned line item six months later.
#PowerBICopilot #FabricCapacity #CopilotCostGovernance #DynamicsFinanceOps #EnterpriseAI #FinanceTransformation