[ENHANCEMENT] Azure provider to support Azure Foundry

[NWessel]

Problem (one or two sentences)

Many users are being locked to LLM's in their work tenants azure with Azure Foundry. A specific provider will help to support these users better.

Context (who is affected and when)

Users only allowed to using LLMS from their Azure

Desired behavior (conceptual, not technical)

A new provider, maybe based on the openai provider

Constraints / preferences (optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

No response

Proposed approach (optional)

No response

Trade-offs / risks (optional)

No response

[NWessel]

Claiming

[roomote]

I noticed you claimed this issue - happy to help if you would like assistance! I looked into the codebase and have some questions that might be useful for the implementation.

I see the existing "OpenAI-Compatible" provider already has Azure support via the openAiUseAzure flag and Azure AI Inference detection for *.services.ai.azure.com endpoints. To better understand the scope of a dedicated Azure Foundry provider, could you clarify:

1. Which Azure service are you targeting? For example:

   • Azure OpenAI Service (deployed models in your Azure subscription)
   • Azure AI Foundry (Azure AI Studio) model catalog
   • Azure AI Services with serverless API deployments

2. What authentication method is required? For example:

   • API key authentication
   • Azure Entra ID (Azure AD) token-based authentication (common in enterprise tenants)
   • Managed identity

3. What is missing from the current Azure support? The OpenAI-Compatible provider with openAiUseAzure enabled uses the official AzureOpenAI SDK client, but perhaps the UI/UX makes this unclear?

Understanding these details will help shape whether this needs:

• A completely new provider with dedicated UI
• Enhancements to the existing OpenAI-Compatible provider
• Better documentation/discoverability of existing Azure features

If you would like me to proceed with an implementation, please tag @roomote with answers to these questions or your preferred approach, and I will be happy to help!

[NWessel]

Hi @roomote

Using foundry, trying to get gpt-5.2-codex to work. It seems that azure api is not completely up to date with openai yet.
For example, this setting is not allowed in the api call when using the models in azure foundry: prompt_cache_retention

See discussion here: https://learn.microsoft.com/en-us/answers/questions/5623446/is-the-new-openai-prompt-cache-retention-setting-w

It will just use an api key for authentication

[roomote]

Thanks for the clarification @NWessel! I can see the issue - Azure Foundry does not support the prompt_cache_retention parameter that the OpenAI API accepts. I will explore the codebase to find where this parameter is being sent and create a fix to exclude it for Azure API calls. Will open a PR shortly!

[roomote]

Opened a draft PR with my attempt at addressing this: #10821

The fix detects Azure endpoints (*.azure.com and *.azure-api.net URLs) and skips the prompt_cache_retention parameter for those requests. This should allow gpt-5.2-codex and other models to work through Azure Foundry without the unsupported parameter causing API errors.

Feedback welcome! @NWessel if you get a chance to test this with your Azure Foundry setup, let me know if it resolves the issue.

[NWessel]

@roomote I really think it should be its own provider, where you can give a full url (so you can decide if you want to use a specific version or let it use newest by default) and an api key

[roomote]

I have seen your comment about making Azure Foundry its own dedicated provider with full URL and API key configuration. This makes sense for better control over API versions and a cleaner user experience.

I will explore the existing provider implementations and create a new Azure Foundry provider. Will open a PR to share progress shortly!