How to estimate the cost of a Foundry agent or a Copilot agent

An agent in Microsoft Foundry behaves like an Azure workload. Costs run service by service and meter by meter: model deployments, Azure AI Search, storage, functions, monitoring and networking. They show up in Azure Cost Management and you can break them down to the resource level.

An agent in Microsoft 365 Copilot behaves like a licensing and consumption platform. Costs sit in seats, in what those seats include, and in a few consumption meters that run alongside them. You will find most of them in the Microsoft 365 admin center, not in Azure.

That difference is not cosmetic. It determines who sees the bill, which admin portal you need, and whether you can set a hard limit at all.

Note the lines from the two usage meters in this diagram. They belong to Microsoft 365 Copilot capabilities but land on an Azure subscription. That is exactly the kind of cross-connection that breaks an estimate when you only look at the portal you happen to have access to.

The first two rows are the ones most often estimated wrongly.

More confusing still: "Copilot Credits" now appears twice in that table and they are two different things. Copilot Studio credits run through the Power Platform admin center and an Azure subscription. The Copilot Credits for Cowork and the Work IQ API run through the Microsoft 365 admin center, with their own admin portal, their own spending policies and their own purchasing model. Adding the two together as if they were one meter puts you structurally on the wrong number.

For Copilot Credit consumption in Microsoft 365, the number of credits per task depends on what the task does. Model responses, tool and skill calls, image generation and browser tasks all count towards consumption. Microsoft offers the Customer Cowork Estimator to model consumption for your own organisation. Use it rather than your own assumption about credits per task, because that number is exactly the variable an estimate falls over on.

For Copilot Studio, Microsoft Learn does publish a full rate table in credits: a classic answer costs 1, a generative answer 2, an agent action 5 and tenant graph grounding 10. For users with a Microsoft 365 Copilot licence, those four are zero-rated. That difference between licensed and unlicensed often decides the bill almost entirely, so model it separately rather than averaging across all your users.

The sequence per scenario is always the same:

1. Number of users, and what share of them actually uses the agent. Licensed users are not active users.
2. Requests per active user per month.
3. Model calls per request. This is the step almost everyone sets to one. An agent with a planner, a retrieval step and a summary is already at three.
4. Input tokens per call: system prompt, conversation history, retrieved context and the schemas of the tools you send along.
5. Output tokens per call, and whether the model generates reasoning tokens.
6. Cache hit rate, since cached input is billed at a lower rate.
7. Retry factor. Estimates without retries always disappoint in production.

Multiply that out, per model, against the current rate for input, cached input and output. Work through each model separately: an agent that classifies on a small model and only routes the hard steps to a large one has two rows in your spreadsheet, not one.

Azure AI Search has two models. With dedicated capacity you pay hourly for search units, calculated as replicas times partitions, regardless of whether anyone is searching. With serverless, which is still in preview, you pay for compute units and index size. Premium capabilities such as the semantic ranker, agentic retrieval and AI enrichment are billed separately in both cases.

The method Microsoft recommends for estimating this is simple and it works: take a sample of one to five percent of your data, index it, then measure index size, throughput and cost. Extrapolate from there to the full corpus. On serverless you measure compute unit consumption through the x-ms-request-charge header on your requests.

Alongside search capacity, do not forget embeddings. They split into two items: the one-off embedding tokens for initial indexing, and the recurring tokens for incremental updates. That second item is the one most often skipped, and on a living dataset it is structural.

• Observability. Log Analytics ingestion and retention are often the largest Azure Monitor item. Every prompt, completion and tool call you write away in full counts.
• Networking. Bandwidth, private endpoints, cross-region traffic and data movement between services.
• Storage growth. Versions, snapshots, soft delete and archive rehydration grow with time, not with usage.
• Data stores. Cosmos DB per RU/s or per consumed RUs plus storage, or Azure SQL per vCore plus storage and backup.
• Tool execution. Functions per execution and GB-seconds, Logic Apps per action and per connector, plus the downstream APIs you call yourself.
• Content Safety. Scanning every input, output, tool call and tool response multiplies the number of records.
• Environments. Dev, test, staging, load test and DR. Well-Architected Framework guidance is explicit that a cost model includes operational costs, reliability, testing, monitoring, backup and disaster recovery.
• Administration. The time spent setting up and watching budgets, tags and reporting is not an Azure meter, but it is a cost.

On the Microsoft 365 Copilot side, usage-based billing supports budgets, alerts, spending policies and hard caps in the Microsoft 365 admin center. You can genuinely make consumption stop. Worth knowing: spending policies only set limits, they do not reserve credits. And a running task that goes over a user's limit is allowed to finish and is then not billed.

On the Azure side it is different. Azure Cost Management has budgets and alerts, but they signal rather than stop. Microsoft states explicitly that Azure OpenAI does not offer a hard limit of the kind that exists elsewhere. If you want consumption to actually stop, you build that yourself with an action group that triggers automation.

Get your allocation right at the same time. Every Foundry project is tagged automatically with a project tag you can filter on in Cost Analysis; that chargeback capability is still preview and only works for models sold by Azure, not for marketplace models. You will find Azure OpenAI in Cost Management under Cognitive Services, where you filter on service tier. Meters appear as a model name with a GUID, one per model per Foundry resource. Meters for partner and community models attach to the resource group rather than the Foundry resource, so scope your analysis to the resource group.