Skip to content

Microsoft Foundry Models

Foundry Models is the model catalog and hosting service inside Microsoft Foundry. It offers models sold and supported by Azure, including all Azure OpenAI models, plus a much larger set from partners and the community, deployable as serverless APIs or on managed compute.1

Also known as Foundry Models, Azure OpenAI in Microsoft Foundry Models, Azure OpenAI Service, Foundry model catalog

Intended for
Application and AI developers, Data scientists, Enterprise architects, Procurement and platform owners
Runs on
Azure public cloud regions (model and type availability varies), Azure Government (separate Azure OpenAI model availability list)2

At a glance

What is it?
Microsoft Foundry Models is the part of Microsoft Foundry where teams find, compare and deploy AI models. Learn describes a catalog of more than 10,000 models with about 50 added each month; the product page says more than 11,000. The catalog has two groups. Models sold by Azure are hosted, billed and supported by Microsoft under Azure service-level agreements; they include all Azure OpenAI models, now documented as Azure OpenAI in Microsoft Foundry Models (formerly the standalone Azure OpenAI Service), and selected models from providers such as Black Forest Labs, Cohere, DeepSeek, Meta, Mistral AI and Microsoft. Models from partners and community, such as Anthropic's Claude family and Hugging Face models, are supported by their providers.123
What does it do?
Foundry Models lets you search and filter the catalog by provider collection, region, deployment option, lifecycle, industry and task, read model cards with benchmarks and license terms, compare models on leaderboards (preview), and deploy them. Serverless deployments expose an API that Microsoft hosts and usually bill per token; managed compute places model weights on dedicated virtual machines billed by core hours. Supported models can be fine-tuned, and a model router can pick a model per request to balance cost and performance.13
Who needs it?
Developers and data scientists who need to choose between models from several providers, keep usage on an Azure bill and under Azure controls, and decide where data is processed through global, data zone or regional deployment types. Teams that standardized on Azure OpenAI use Foundry Models as the current home of those models.
What does it need?1
  • An Azure subscription and a Foundry project in a region where the model is offered
  • For pay-per-token partner models, a billing account in a country or region where the provider offers the model
  • Virtual machine quota in your subscription for managed compute deployments
  • Acceptance of the model's license terms
What it is not
Foundry Models is not one model or one vendor: Microsoft documents a mix of Azure-sold models and partner models with different support, terms and billing. Partner and community models are billed through Azure Marketplace and supported by their providers, not Microsoft. Microsoft's Responsible AI review of Azure-sold models does not guarantee that risks are mitigated, so customers still evaluate models for their own use. Models are not permanent either: older versions are retired on a published schedule.1

Availability and licensing. Generally available as a service: the Foundry GA overview lists Models as GA, with managed compute as a preview deployment type (checked 26 Oct 2026). Each model has its own status; for example, Learn labels MAI-Thinking-1 and the listed MAI-Image models Preview. Serverless prices are shown before deployment (per token or reserved capacity); partner models bill through Azure Marketplace. No prices are quoted here.4

The problem it solves

Model choice changes quickly, and each provider has its own API, terms, regions and billing. Running several providers in production means several contracts, several security reviews and several ways to watch usage and cost.

Foundry Models puts models from Microsoft, OpenAI and many other providers behind one catalog and one Azure deployment process, with content filtering, choices about where data is processed, and fungible provisioned throughput across some Azure-sold models.1

How it works

Each catalog entry has a model card and one or more deployment options chosen by the provider.

  • Serverless deployment: Microsoft hosts the model and exposes an API, usually billed per input and output token. Types include Global, Data Zone and Regional variants of Standard (pay per token) and Provisioned (reserved capacity), plus Global Batch, Data Zone Batch and Developer.
  • Managed compute: model weights run on dedicated VMs, billed by VM core hours. It builds on Azure Machine Learning, needs VM quota and, per Learn, currently uses a hub-based project in Foundry (classic).
  • Content safety: serverless language models get default Azure AI Content Safety filters, billed separately; with managed compute you call the Content Safety APIs yourself.

Azure-sold models are billed through Azure meters; partner and community models through Azure Marketplace.1

Microsoft Foundry Models architecture: components by layer and how they connectAgents & automationAI models & platformSecurity, identity &governanceCloud & hybridinfrastructureApps and agents: Call deployed models through the project endpointApps and agentsModel catalog and model cards: Search, filters, benchmarks and license termsModel catalog andmodel cardsModels sold by Azure (incl. Azure OpenAI): Microsoft-hosted, billed and supported modelsModels sold by Azure(incl. Azure OpenAI)Partner and community models: Provider-supported models billed through Azure MarketplacePartner and communitymodelsModel router: Chooses a model per requestModel routerAzure AI Content Safety filters: Screens prompts and outputs for harmful contentAzure AI Content SafetyfiltersServerless deployments: Microsoft-hosted API with Standard, Provisioned and Batch typesServerless deploymentsManaged compute: Dedicated VMs running model weightsManaged compute
Diagram as a list
  1. Agents & automation

    • Apps and agentsCall deployed models through the project endpoint
  2. AI models & platform

    • Model catalog and model cardsSearch, filters, benchmarks and license terms
    • Models sold by Azure (incl. Azure OpenAI)Microsoft-hosted, billed and supported modelsConnects to Serverless deployments
    • Partner and community modelsProvider-supported models billed through Azure Marketplace
    • Model routerChooses a model per requestConnects to Models sold by Azure (incl. Azure OpenAI)
  3. Security, identity & governance

    • Azure AI Content Safety filtersScreens prompts and outputs for harmful content
  4. Cloud & hybrid infrastructure

    • Serverless deploymentsMicrosoft-hosted API with Standard, Provisioned and Batch typesConnects to Azure AI Content Safety filters
    • Managed computeDedicated VMs running model weights
Components and connections as documented by Microsoft.

Capabilities

  • Two catalog groups12

    Models sold by Azure are hosted, billed and supported by Microsoft with Azure SLAs and include all Azure OpenAI models; models from partners and community make up most of the catalog.

    Why it matters: Buyers can choose between Microsoft support and a wider choice of specialized models.

    Limits: Partner models carry provider terms and support, and varying SLAs.

  • Serverless deployment types1

    Global, Data Zone and Regional processing across Standard, Provisioned and Batch types, plus a Developer type.

    Why it matters: Teams can match cost model and data processing location to each workload.

    Limits: Not every model offers every type; availability varies by model and region.

  • Managed compute14

    Model weights deploy to dedicated VMs with a REST endpoint, billed by core hours.

    Why it matters: Runs open models, such as Hugging Face models, that are not offered as serverless APIs.

    Limits: Requires VM quota and, per Learn, a hub-based project in Foundry (classic); the GA table lists managed compute as a preview deployment type.

  • Fine-tuning1

    Managed fine-tuning jobs and interactive training (preview) for compatible models.

    Why it matters: Adapts a model to company data or tasks without building one from scratch.

    Limits: Only certain models support fine-tuning, and adapter serving options are partly preview.

  • Model router23

    A Microsoft model that routes each request at runtime to balance cost and performance.

    Why it matters: Can lower cost for mixed workloads without hard-coding one model.

    Limits: Test answer quality on your own prompts before relying on routing.

  • Benchmarks and comparison14

    Model cards include benchmark tabs for select models, and leaderboards compare models.

    Why it matters: Supports an evidence-based shortlist before deployment.

    Limits: Leaderboards are preview and benchmarks cover select models only.

  • Microsoft MAI models2

    Microsoft lists MAI-Thinking-1 and several MAI-Image models among Azure-sold models; MAI-Voice and MAI-Transcribe are delivered through Azure Speech in Foundry Tools.

    Why it matters: Gives access to Microsoft's own frontier models next to OpenAI and partner models.

    Limits: Learn labels MAI-Thinking-1 and the listed MAI-Image models as Preview (checked 26 Oct 2026).

  • Lifecycle management1

    Microsoft publishes a model lifecycle policy, a retirement schedule and replacement suggestions; some models allow automatic version updates.

    Why it matters: Lets teams plan upgrades instead of being surprised by retirements.

    Limits: Applications must be retested when a model version changes or retires.

Practical use cases

A product team must pick a model for a new feature but cannot judge quality from marketing claims.
Approach
Shortlist with leaderboards and benchmarks, then evaluate candidates on your own data in Foundry.
Role of Microsoft Foundry Models
Foundry Models provides the catalog, comparison and deployments.
Data, infrastructure and skills
Foundry project, test dataset and evaluation criteria.
Type of benefit
Better model choice
Caveats
Leaderboards are preview and benchmarks exist only for select models.
First step
Compare two or three models side by side on real tasks.
A regulated firm must keep model processing within a geography.
Approach
Use Data Zone or Regional deployment types instead of Global.
Role of Microsoft Foundry Models
Foundry Models offers the processing location choice per deployment.
Data, infrastructure and skills
A region and model that offer the required deployment type.
Type of benefit
Data residency control
Caveats
Not every model offers every deployment type in every region.
First step
Check the region availability table for your model.
Costs grow because every request goes to a large model.
Approach
Deploy the model router so simple requests can go to smaller models.
Role of Microsoft Foundry Models
The router selects a model per request.
Data, infrastructure and skills
A router deployment and a set of representative prompts.
Type of benefit
Cost control
Caveats
Routing can change answer style or quality; evaluate before switching traffic.
First step
Run your prompt set through the router and compare results.

Who uses it

Works with

Optional integration

  • Microsoft Foundry Agent ServiceAgent Service works with models from the Foundry catalog and lets you swap models without code changes.
  • Azure AI SearchAgentic retrieval uses an Azure OpenAI model for query planning and answer synthesis.
  • Foundry ToolsMAI-Voice and MAI-Transcribe models are delivered through Azure Speech in Foundry Tools.

Complementary tools

  • Azure Machine LearningManaged compute builds on Azure Machine Learning and uses its registries.
  • Foundry ToolsFor generative tasks Microsoft points to Foundry; MAI speech models are delivered through Azure Speech.

Same family

  • Microsoft FoundryThe product page lists Foundry Models as a service built into Foundry.

Alternative approaches

Required by

Optional integration for

Relationship labels follow Microsoft's documentation. "Alternative approaches" does not mean one is better: each profile says when it fits.

Getting started

  1. Browse the catalog

    Filter the Foundry Models catalog by collection, deployment option, lifecycle and task.

    Check: The model card's license and details tabs fit your use case.

  2. Check region and offer availability

    Use the region availability pages for Azure-sold and partner models.

    Check: Your project region supports the deployment type you need.

  3. Deploy or use instant access

    Create a serverless deployment, or call a supported model by name with instant access (preview).

    Check: The model answers in the model playground.

  4. Call it from code

    Use the OpenAI client or the project client against your project endpoint and v1 routes.

    Check: A test request from code returns a response.

  5. Plan for retirement

    Review the model retirement schedule and enable automatic updates where offered.

    Check: Each production deployment has a known retirement date and replacement.

Official resources

Deciding whether you need it?

Three free tools apply Microsoft's own published guidance to your situation, and say when Microsoft Foundry Models or any new technology is not needed.

Sources

Each statement above links to the source it comes from. Labels say who reported it.

  1. Microsoft Foundry Models overview (opens in a new tab) Microsoft · Vendor-reported · link checked 27 Oct 2026
  2. Foundry Models sold by Azure - Microsoft Foundry (opens in a new tab) Microsoft · Vendor-reported
  3. Foundry Models product page (opens in a new tab) Microsoft · Vendor-reported · link checked 27 Oct 2026
  4. Microsoft Foundry portal general availability overview (opens in a new tab) Microsoft · Vendor-reported · link checked 27 Oct 2026
  5. Technology plan for AI agents (Cloud Adoption Framework) (opens in a new tab) Microsoft · Vendor-reported · link checked 27 Oct 2026
  6. What is Microsoft Foundry? (opens in a new tab) Microsoft · Vendor-reported · link checked 27 Oct 2026

Fill out the form below to request your copy.

Name(Required)