Leia em português: Work IQ, Fabric e Foundry: três moedas na mesma solução
The agent answers one question, but the bill crosses several services. Context comes from Microsoft 365, the number comes from Fabric, and a Foundry model produces the answer. Looking only at the model token usage leaves part of the work outside the budget. The problem surfaces when three teams arrive at the same meeting with three different units and nobody can explain the complete cost of the workflow.
The currency follows the call
What is an agent billing map?
It connects operation, service, consumption unit, and budget owner. It is an architecture artifact for custom agents, not a new billing product.
The Microsoft IQ map explained which question each layer answers. This article covers the billing boundary: what each call consumes and who owns the budget. Caching, batch, and PTU comparisons belong to the AI FinOps article.
| Workflow layer | Main unit | Financial boundary |
|---|---|---|
| Work IQ API | Copilot Credits | Billing plan and policies in Microsoft 365 |
| Fabric data agent or ontology | CU-seconds of consumption | Fabric capacity and separately billed services |
| Model in Microsoft Foundry | Tokens or PTUs per hour | Deployment, resource, and purchasing model |
| Foundry IQ | AI Search retrieval; an LLM when used | AI Search and Azure OpenAI; not a unified currency |
Sources checked on October 11, 2026. The values below identify both operation and source. Monetary prices depend on plan, region, and agreement; there is no universal quote per “question to Microsoft IQ.”
The problem it solves
A user license does not pay for every API; purchased capacity does not make a workload costless. A short answer can require substantial retrieval, planning, and query execution.
The map prevents three mistakes: adding incompatible units, confusing attributed cost with incremental charges, and counting work already included in another meter twice. It also forces an operational decision: who approves increased consumption as the agent grows?
How it works — step by step
- Draw the calls needed to answer, including retrieval, queries, model inference, tools, and additional attempts.
- Identify each endpoint and meter. “Uses Fabric” does not distinguish a data agent, an ontology, and a warehouse query.
- Separate variable consumption, purchased capacity, storage, and access licensing.
- Convert units using the price applicable to the plan; explicitly allocate shared capacity.
- Reconcile aggregates with each service report and assign a budget owner.
- Control the workflow in the application: bound attempts, sources, and context without turning failures into empty answers.
Work IQ: a user license does not close the bill
The Work IQ API uses Copilot Credits. Its overview distinguishes Copilot experiences from custom and third-party agent calls: a Microsoft 365 Copilot license does not remove usage-based billing for those agents.
The Copilot Credits Guide, October 2026 edition, separates two components:
- Chat/Context: variable grounding, retrieval, and reasoning consumption, driven by models, runtime, context, and tools.
- Tools API: a static component of 0.1 Copilot Credit per API call for actions and tools.
The guide reference price for the pay-as-you-go meter is US$0.01 per Copilot Credit. A call covered by the static component therefore corresponds to US$0.001 under that plan. This is not the price of a complete task or any MCP tool from another provider.
The Work IQ MCP article explains operation and path. Here, the financial consequence is different: when the application makes multiple billable calls, count each one. Calling Chat/Context as well does not make its variable component disappear.
P3 has an annual commitment and unused credits expire. Retail pricing is not every agreement’s effective rate; a credit does not represent a fixed token count.
Fabric: CU consumption is not a price per answer
Microsoft Fabric capacity is a shared pool. CU-seconds, or CU-s, measure operation consumption; they are not a currency you can add directly to Copilot Credits.
For the Fabric data agent, the resource-specific page publishes the AI Query rates:
| Processing component | Unit | Consumption |
|---|---|---|
| Uncached input | 1,000 tokens | 100 CU-s |
| Cached input | 1,000 tokens | 10 CU-s |
| Output | 1,000 tokens | 400 CU-s |
Agent instructions, context, and history contribute to input; do not count only the typed question. Generated query execution is metered separately in the corresponding engine. Counting only AI Query excludes the work required to obtain the data.
The ontology has a different table
The new ontology experience, still in preview, has three meter groups:
- Ontology Discovery: 1,000 CU-seconds per metered definition read.
- Ontology Logic and Operations: Eventhouse and Graph consumption at the child item’s rate.
- Ontology AI Reasoning: dynamic consumption, based on the tokens and resources used by the task.
Do not apply the AI Query table to the ontology. The current page does not publish a universal fixed token conversion for Ontology AI Reasoning. The four meters of the old experience do not describe the new one.
Discovery is not a price per click either: when the cached definition is current, navigation normally causes no additional read. The interface can read again after saving or refreshing, and automatic refresh occurs approximately every 20 minutes while it remains open. Closing the tab avoids unnecessary refresh reads; it does not replace controlling application calls.
OneLake, storage, and read/write operations have separate charges. Idle capacity can absorb consumption without immediately changing the invoice, but it uses headroom other workloads could need. Scaling capacity or enabling overage can change cash spending: attributed consumption and incremental cost are different questions.
Foundry: the model is not the complete bill
In Microsoft Foundry, standard deployments bill by token; provisioned deployments bill per PTU per hour, or use reservations. Allocated PTUs cost money even without requests. Tokens remain useful for measuring utilization, but do not become a second per-token charge for the same provisioned inference.
Foundry Agent Service adds no charge for creating or running native prompt and workflow agents. That does not make the solution free: models, tools, and connections can incur charges. Hosted agents bill for container compute per hour; they are a different offering.
Foundry IQ adds the AI Search boundary
Foundry IQ uses Azure AI Search knowledge bases. Agentic retrieval bills retrieval tokens during subquery execution and semantic ranking; when LLM planning or synthesis is used, Azure OpenAI bills its tokens separately.
Do not automatically add a classic semantic ranker per-query charge to the same agentic retrieval: the billing models differ. Include classic queries actually executed outside that pipeline.
The free retrieval plan has a monthly allowance. Once exhausted, requests that would require paid usage return a payment-required error; the standard plan permits paid continuation and requires Basic or higher.
Starting with service API 2026-04-01, retrieval billing consent is controlled by knowledgeRetrieval, independently of semanticSearch. Migrating versions without reviewing this can interrupt the workflow.
Also separate availability from price: the stable version supports minimal, extractive retrieval with GA sources; LLM planning, synthesis, and non-minimal capabilities remain in preview in the documentation checked.
A use case: the insurance claim
Revisit the reference article’s residential flooding claim. The analyst needs coverage, inspection, and policy conditions. The agent prepares the assessment; the analyst decides, without an automatic payment instruction.
| Assessment component | Call | Financial record |
|---|---|---|
| Report and inspection | Work IQ Tools | Billable calls → credits |
| Policy status, coverage, and amount | Fabric data agent | AI Query → CU-s; engine extra |
| Manual and synthesis | Foundry IQ + model | Search + tokens or PTUs; no double count |
The plan selects necessary sources; it does not call everything by default. Tool integration is covered in the reference article. Here we instrument its financial boundary, without copying reports or personal data into consumption records.
A calculated example, not a simulated invoice
Imagine a custom agent preparing a case assessment for an analyst. The example is illustrative: calculations checked against documentation, not executed in a tenant.
Work IQ. Assume 20 billable Tools calls: 20 × 0.1 = 2 Copilot Credits. Under the reference PAYG plan, 2 × US$0.01 = US$0.02. Any additional Chat/Context consumption needs another line.
Fabric data agent. Assume 2,000 uncached input tokens and 500 output tokens. The calculation is (2,000 × 100 + 500 × 400) / 1,000 = 400 CU-s, or approximately 0.111 CU-hour, excluding query execution.
Ontology, if also queried. One metered definition read adds 1,000 CU-s. The subtotal for these two consumption components would be 1,400 CU-s, approximately 0.389 CU-hour. It excludes dynamic reasoning, child items, and OneLake.
To illustrate allocation, use a hypothetical US$0.18/CU-hour rate: 1,400 / 3,600 × US$0.18 = US$0.07 of attributed cost. This is neither a quote for your agreement nor an automatic per-call charge. For purchased capacity, allocation must reconcile amortized cost, utilization, and headroom.
Foundry. For standard inference, keep uncached input, cached input, and output tokens separate and apply their model/deployment rates. For PTUs, allocate a share of capacity cost over the period. Add AI Search and other services actually used.
Attributed workflow cost =
Work IQ converted under the credit plan
+ allocated Fabric capacity + separate charges
+ Foundry model: tokens OR allocated PTU cost
+ applicable AI Search + tools + storage
Do not publish “US$0.09 per assessment”: the example has components not yet calculated. The useful unit is cost attributed to a workflow with a declared scope, not a number pretending to include absent services.
In practice: recording claim consumption
Python 3.10+, standard library only. Save as example.py and run python example.py. Counters are illustrative, not actual API responses. tools_calls represents billable Tools calls, not every MCP message; model tokens and components without rates stay separate.
import json
from decimal import Decimal as D
COUNTERS = (
"tools_calls", "fabric_uncached_tokens", "fabric_cached_tokens",
"fabric_output_tokens", "discovery_reads", "foundry_uncached_tokens",
"foundry_cached_tokens", "foundry_output_tokens",
)
def attribute_partial(trace_id: str, counters: dict[str, int],
model_mode: str) -> dict[str, object]:
if not isinstance(trace_id, str) or not trace_id.strip():
raise ValueError("A nonempty application trace_id is required")
if set(counters) != set(COUNTERS) or any(
type(value) is not int or value < 0 for value in counters.values()
):
raise ValueError("Provide exactly the nonnegative integer counters")
if model_mode not in {"standard", "provisioned"}:
raise ValueError("Declare standard or provisioned model billing")
credits = D(counters["tools_calls"]) * D("0.1")
ai_query = (
D(counters["fabric_uncached_tokens"]) * 100
+ D(counters["fabric_cached_tokens"]) * 10
+ D(counters["fabric_output_tokens"]) * 400
) / 1000
discovery = D(counters["discovery_reads"]) * 1000
return {
"trace_id": trace_id,
"basis": "illustrative",
"work_iq_credits": str(credits),
"fabric_ai_query_cu_s": str(ai_query),
"fabric_discovery_cu_s": str(discovery),
"foundry_mode": model_mode,
"foundry_tokens": {
"uncached_input": counters["foundry_uncached_tokens"],
"cached_input": counters["foundry_cached_tokens"],
"output": counters["foundry_output_tokens"],
},
"work_iq_tools_reference_usd": f"{credits * D('0.01'):.4f}",
"fabric_hypothetical_allocation_usd":
f"{(ai_query + discovery) / 3600 * D('0.18'):.4f}",
"complete_workflow_cost_usd": None,
"unpriced": [
"Chat/Context", "query engines", "ontology reasoning",
"OneLake", "Foundry model or PTU", "AI Search", "tools/compute",
],
}
usage = {
"tools_calls": 20, "fabric_uncached_tokens": 2000,
"fabric_cached_tokens": 0, "fabric_output_tokens": 500,
"discovery_reads": 1, "foundry_uncached_tokens": 1500,
"foundry_cached_tokens": 0, "foundry_output_tokens": 250,
}
print(json.dumps(attribute_partial("sinistro-demo-001", usage, "standard"),
indent=2))
Example output, checked by local execution:
{
"trace_id": "sinistro-demo-001",
"basis": "illustrative",
"work_iq_credits": "2.0",
"fabric_ai_query_cu_s": "400",
"fabric_discovery_cu_s": "1000",
"foundry_mode": "standard",
"foundry_tokens": {"uncached_input": 1500, "cached_input": 0, "output": 250},
"work_iq_tools_reference_usd": "0.0200",
"fabric_hypothetical_allocation_usd": "0.0700",
"complete_workflow_cost_usd": null,
"unpriced": [
"Chat/Context", "query engines", "ontology reasoning",
"OneLake", "Foundry model or PTU", "AI Search", "tools/compute"
]
}
The code validates input and calculates components; it does not call services or reconcile invoices. unpriced lists components to measure or price, when used. For provisioned inference, tokens remain utilization, not a second tariff. Preserve attempts and measurement provenance in a real application; trace_id does not automatically connect dashboards.
Who owns the budget and the limit?
Define three responsibilities: the Microsoft 365 administrator for credit policies; the capacity administrator for Fabric; and the resource/deployment owner for Foundry and AI Search. One person can hold several roles, but the workflow needs an accountable owner.
Use application correlation, with service, operation, attempts, and consumption provenance. Dashboards do not necessarily accept the identifier or provide task-level cost; reconcile aggregates.
In the Microsoft 365 admin center, use Copilot > Cost management. In Fabric, follow AI Query, Ontology Discovery, and other operations in Capacity Metrics. In Azure, reconcile resources and billing models.
These dashboards are not an instant brake: the documentation specifies 4-hour refresh for the credit Overview and 2-hour refresh for Consumption. Control retries and operational budgets in the application; disclose failures instead of retrying until the limit is consumed.
Production best practices
- Version the map: endpoint, operation, price, region, plan, source-check date, and owner.
- Separate caches: model caching, data agent cached input, and ontology definition caching have different financial effects.
- Bound fan-out and retry: multiple sources and attempts can increase consumption even when the final answer is short.
- Allocate without duplication: the full capacity invoice and the agent’s share are not two costs to add to the consolidated total.
- Treat allowances and preview as conditions: do not project sustained operation as if every call were free.
- Optimize with quality: reducing context or reasoning is a saving only if it preserves the answer the business needs.
Frequently asked questions (FAQ)
Does Microsoft 365 Copilot remove Work IQ API charges?
Not for custom and third-party agents. The access and pricing page distinguishes those calls from experiences covered by the license.
Does a question cost 0.1 Copilot Credit?
Not necessarily. That is the static component per Tools API call, not a universal question or task tariff.
If Fabric is already paid for, does the agent cost nothing?
The invoice might not increase immediately, but the agent consumes capacity and competes for headroom. Show attributed cost and incremental impact separately.
Do Foundry IQ and the model use the same meter?
No. AI Search measures retrieval; Azure OpenAI meters the LLM when used. Agent, knowledge, and model calls can cross resources and budgets.
Conclusion
Architecture decides where work happens; the meter decides how it appears on the bill. Before choosing the cheapest model, identify the calls it will trigger. A reliable budget preserves original units, converts using the correct plan, allocates capacity, and names the owner accountable for growth.
Official references
- Work IQ access and pricing.
- Copilot Credits Guide — pricing and Work IQ.
- Copilot Credit billing and cost management.
- Monitor credit consumption.
- Fabric data agent consumption.
- New ontology billing.
- Fabric capacity pricing.
- Foundry Agent Service billing.
- Foundry IQ requirements and billing.
- Agentic retrieval billing model.
- Retrieval billing consent.
- Foundry tokens and provisioned throughput.
👉 If you are composing an agent with Microsoft 365, Fabric, and Foundry — especially on shared capacity, this is the point to map the bill before expanding usage. Want to discuss agent FinOps? Reach out on LinkedIn.
