Azure AI Foundry billing separates agent orchestration from model consumption, and that separation is where unexpected charges originate. Building and running a Foundry-native agent through prompts and workflows carries no added fee, but token consumption, tool connections, and hosted-agent compute are billed on top of it.
The distinction matters most under two conditions: workloads that retry failed tool calls or chain many agent steps, and subscription-level quota pools that concentrate every deployment’s usage into one shared ceiling. Both conditions are documented separately, and neither shows up as a single line on the monthly bill.
How Azure AI Foundry Billing Splits Across Meters
Foundry Agent Service itself does not charge for agent creation or execution when the agent runs on prompts and workflows native to Foundry. The charge instead flows through Foundry Models, priced by token consumption, independent of how many agent steps produced those tokens.
Tool use adds a second, separate cost surface. Foundry Tools and Foundry IQ connections — Azure Logic Apps connectors, Microsoft Fabric, SharePoint, Grounding with Bing Search, and any licensed data source — carry their own charges and licenses, on top of the token cost of the calls that invoke them.
Hosted agents, which run external frameworks such as Microsoft Agent Framework or LangGraph inside a Foundry-managed runtime, are billed differently again: by the container compute consumed per hour, not by token or by request.
Memory — Foundry’s managed long-term and short-term memory capability — is billed separately from all of the above, split further into long-term storage, short-term storage, and retrieval operations. A workload that leans on Memory for context persistence adds a fourth distinct meter to track.
Where Retries and Tool Calls Inflate Token Spend
The token meter is where volume surprises concentrate, particularly in automated pipelines rather than user-facing chat. Independent analysis of agentic CI/CD workloads found that a single review agent triggered on every pull request can consume several times the token cost of an equivalent customer-facing AI workload, because machine-triggered traffic runs on a different cadence than human traffic.
That analysis attributes the gap to throughput: CI/CD pipelines run on scheduled jobs, regression tests, and per-PR triggers rather than on user request frequency, and each triggered run can chain several agent steps, each making its own model call with its own context window.
The same source describes a recurring pattern among organizations that deploy agentic pipelines without per-step cost observability — a small bill in an early month, a moderate one the next, and then a bill large enough to prompt an executive review, without any single anomalous event causing it.
The underlying failure mode is attribution, not volume. A provider invoice itemizes spend by model and token type, but has no visibility into which internal repository, pipeline, or agent step generated a given call — that context exists only in the requester’s own metadata, which the platform team has to instrument itself.
Applied to Azure AI Foundry, the same mechanism applies to tool calls and retries: a hosted agent that retries a failed tool invocation, or an orchestration step that reruns a prior model call after a validation failure, generates additional token and possibly additional tool charges that Foundry’s billing summary does not separately flag as retry-driven.
Subscription-Level Quotas Change Who Feels the Overage
Microsoft changed how Foundry Models track quota starting after May 7, 2026: rather than allocating tokens-per-minute and requests-per-minute limits per resource or per region, onboarded models now draw from a single quota pool shared across all deployments of that model and version within a subscription.
Global Standard deployments share one pool across all regions in the subscription; Data Zone Standard deployments share one pool per data zone. Existing approved quota carries over automatically, but the practical effect is that one high-volume deployment can now exhaust capacity that other teams in the same subscription expected to have available.
Resource ceilings compound this: a subscription is capped at 100 Foundry resources per region, 250 projects per resource, and 32 model deployments per resource, which limits how finely a subscription owner can segment workloads to isolate a runaway pipeline from the rest.
Rate limits themselves vary sharply by model and are defined per region, per subscription, and per model or deployment type — meaning the token-per-minute ceiling that matters for cost planning is not a single Foundry-wide number but something to check per deployment in the Foundry portal’s quota page.
The four Foundry Agent Service billing meters do not appear as one invoice line, and each behaves differently under retries, tool use, or long-running agents:
| Billing meter | Charged separately from agent orchestration | What drives the charge |
|---|---|---|
| Agent creation/running via Foundry prompts and workflows | No additional charge | N/A |
| Model token consumption (Foundry Models) | Yes | Tokens processed per model call |
| Foundry Tools / Foundry IQ connections (Logic Apps, Fabric, SharePoint, Grounding with Bing, licensed data) | Yes | Separate charges and licenses per connector |
| Hosted agents (external frameworks on managed Foundry runtime) | Yes | Container compute consumed per hour |
| Memory (long-term, short-term, retrieval) | Yes | Billed separately per memory operation type |
None of these meters is inherently the expensive one; the risk is treating any single meter’s total as the whole picture. A pipeline that looks cheap on token spend can still generate a large bill through hosted-agent container hours or Memory retrieval operations.
What to Verify Before the Invoice Arrives
The public documentation does not establish a default alerting threshold inside Foundry Agent Service itself for token, tool, or compute spend — unlike third-party gateway tooling, which can enforce budget thresholds at defined percentages of a set limit before a request is throttled.
Separately, Microsoft is retiring Prompt flow, including its Foundry and Azure Machine Learning authoring experience, by April 20, 2027, and is directing existing workloads toward Microsoft Agent Framework — a migration that will also move where per-step cost instrumentation needs to live for teams currently relying on Prompt flow logging.
Before committing a production agent workload to Foundry, verify which quota scope — Global, Data Zone, or per-region — applies to each model in use via the Foundry portal’s quota page, confirm whether hosted-agent container hours or Memory retrieval are enabled for the workload, and set an external spend alert, since Foundry’s own documentation does not describe a built-in one at the time of writing.