Azure AI Foundry Pricing: Models, Agents & Cost Guide

Last reviewed September 20, 2026 · Pricing changes should be verified in the official Azure meter for your region.

What Azure AI Foundry includes

Microsoft Foundry is a broader application and model platform, not merely another name for one chat model endpoint. Depending on the workload, a team may use a model catalog, a managed model deployment, agent orchestration, evaluation, safety controls, tracing, retrieval, or connected tools. Each layer can have a different price source and a different unit of measure.

That distinction matters for searchers comparing azure ai foundry pricing with a direct API price. A model table can help you estimate tokens, but it cannot by itself predict the cost of a long-running agent that calls search, stores files, invokes a tool, retries a request, and runs in a specific region. The right first question is: “Which meters appear in one representative request?”

Foundry is therefore best budgeted as a workload. Start with the user action, draw the calls it triggers, assign a meter to each call, and then add a monthly volume assumption. This approach also makes it easier to compare Foundry with direct OpenAI, Gemini, Anthropic, or other API routes without mixing platform fees and model token fees.

Azure AI Foundry pricing components to separate

The table below is a planning framework. It is intentionally not a fixed rate card: official meters, regional availability, model terms, and feature pricing can change. Use it to avoid leaving an important cost category out of your estimate.

Do not add every row to every estimate. Include the rows your architecture actually uses, and label uncertain values as assumptions until the Azure calculator or service meter confirms them.

How Azure AI Foundry model pricing works

For a token-priced model, the basic estimate remains straightforward: input tokens and output tokens have separate rates, usually normalized to a fixed token unit. The difficult part is choosing the correct rate row. Model family, deployment type, region, context tier, cached input, batch processing, image or audio input, and provisioned throughput can all change which meter applies.

Use the AI token calculator to turn a sample prompt and expected response into a rough token count, then use the LLM cost calculator to test monthly volume. These tools are planning aids; the final Azure number should come from the official model and region documentation.

Input and output are not interchangeable

Chatbots, extraction pipelines, and long-document assistants often have very different input/output ratios. A summarization job may send a large document and return a short answer, while a coding agent may send compact instructions and generate a much longer response. Record both sides separately. If the workload uses cached context or batch processing, model those as explicit scenarios rather than silently applying the standard rate.

Example: estimate a Foundry workload before deployment

Suppose a support agent handles 20,000 conversations per month. Each conversation sends 3,000 input tokens and returns 700 output tokens. The agent also performs one search query and occasionally calls a ticketing tool. Do not call the result “the Foundry price” yet. It is only the model component plus two service categories that still need their own rates.

The useful output is a range with named assumptions, not a single impressive number. Keep a low, expected, and high case. When the workload is live, replace assumptions with logs: actual tokens, actual tool calls, actual retries, and actual storage or compute consumption.

Azure AI Foundry vs. Azure OpenAI pricing

These phrases overlap in search results, but they answer different planning questions. Azure OpenAI pricing is a focused model/API comparison: choose a pricing row, enter tokens and requests, and compare a direct OpenAI benchmark. Azure AI Foundry pricing asks a broader architecture question: which models and managed services participate in the workflow?

Use the Azure OpenAI page when you already know the deployment is an Azure-hosted OpenAI model and you mainly need token economics. Use this Foundry guide when the workload includes model choice, agents, evaluation, grounding, search, tools, or multiple Azure services. A Foundry project may contain an Azure OpenAI call, but the project total can be larger than that call.

For cross-provider decisions, keep the page roles separate. Compare model rows on the AI API comparison page, estimate token mix with the calculators, and then add Azure-specific region, capacity, service, and governance assumptions from first-party documentation.

A five-step Azure AI Foundry pricing workflow

1. Define one user task. Write the request, expected response, quality target, and acceptable latency.
2. Draw the trace. List model calls, agent steps, retrieval, search, tools, storage, evaluation, and retries.
3. Assign meters. Use the model pricing row and official Azure page for every service that appears in the trace.
4. Run three scenarios. Calculate low, expected, and high volume with different output lengths and retry rates.
5. Validate after launch. Compare the estimate with usage logs and update the assumptions before committing to a migration or budget.

Important limitations

This page is a cost-planning guide, not an Azure invoice simulator. Similar model names can have different meters across products or deployment modes. Search, grounding, image and audio inputs, provisioned capacity, fine-tuning, regional availability, taxes, discounts, quotas, and enterprise agreements may be outside a simple token calculation. Prices can also change after a model or service update.

For a production estimate, record the official page, model, deployment, region, currency, rate date, and assumptions used. If a rate is unavailable, leave it as an explicit unknown and test it in the official Azure pricing calculator instead of filling the gap with a competitor's number.