Repository navigation
[FEATURE]: Support duplicate provider config sections #23742
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Support duplicate provider config sections so users can define multiple instances of the same provider, especially Azure, with different endpoints, regions, resource hubs, deployments, and API keys. This is needed because Azure OpenAI / Azure AI Foundry model availability is often split across regions and hubs, so a single Azure config is not always sufficient.
It would also be useful if each duplicated provider config could declare a based_on-style identifier pointing to the underlying provider type, for example azure. That way, OpenCoder could still apply default provider logic and default model configuration correctly, while allowing multiple distinct Azure provider instances in one config.
This would improve support for real-world Azure setups, reduce config workarounds, and make multi-region / multi-resource deployments much easier to manage.
Detailed explanation
Add support for duplicate provider configuration sections so a single OpenCoder setup can define multiple instances of the same provider, especially for Azure. This would allow users to configure multiple Azure resources, multiple regions, and different API keys under separate entries, rather than being limited to a single Azure provider block.
This is particularly important for Azure OpenAI and Azure AI Foundry workflows, where model availability is often split across regions and resource hubs. In practice, a team may need one Azure resource for models deployed in one region, another resource for models only available in a different region, and separate credentials depending on environment, subscription, or organisational boundaries. At the moment, if only one config section per provider is supported, this makes those setups awkward or impossible to express cleanly.
It would also help to allow each duplicate provider entry to specify a based_on-style identifier, or equivalent inheritance/reference field, so OpenCoder still knows which underlying provider type it should treat that config as. That would preserve the ability to apply existing default provider logic and default model configuration behaviour without requiring every duplicated entry to fully redefine provider semantics from scratch.
For example, a user might define multiple Azure provider entries, each with its own endpoint, region, resource hub, deployments, and API key, while still marking them as based on azure. OpenCoder could then continue to apply Azure-specific defaults and model handling consistently, while still treating each entry as a distinct target configuration.
Benefits:
- Supports real-world Azure deployments spanning multiple regions and resource hubs
- Makes it possible to use models that are not all available from the same Azure resource
- Preserves default provider and model config behaviour through a based_on or inheritance-style reference
- Improves flexibility for organisations with separate environments, subscriptions, or credentials
- Reduces the need for config hacks, manual swapping, or maintaining multiple separate config files
In short, this would make Azure support much more practical for users operating across more than one Azure resource or region, while keeping configuration behaviour predictable and aligned with existing provider defaults.
Proposed json config changes
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"Rider": {
"type": "remote",
"url": "http://127.0.0.1:64342/stream"
}
},
"autoupdate": true,
"skills": {
"auto_discovery": true
},
"provider": {
"azure-uk-south": {
"based-on-id": "azure", //this is how opencode would know to inherit all the properties of the "azure" provider, and then override the options and models with the ones specified here
"options": {
"resourceName": "uk-south-resource-1",
"baseURL": "https://uk-south-resource-1.services.ai.azure.com/openai/v1/",
"apiKey": "12345"
},
"models": {
"gpt-oss-120b": {
"id": "gpt-oss-120b",
"name": "gpt-oss-120b on Azure UK South, subscription 12345",
"tool_call": true,
"limit": {
"context": 128000,
"output": 8192
},
"options": {
"thinking": "high"
}
}
}
}
},
"azure-sweden-resource1": {
"based-on-id": "azure", //this is how opencode would know to inherit all the properties of the "azure" provider, and then override the options and models with the ones specified here
"options": {
"resourceName": "sweden-central-resource-1",
"baseURL": "https://sweden-central-resource-1.openai.azure.com/openai/v1",
"apiKey": "123"
},
"models": {
"gpt-5.4-pro": {
"id": "gpt-5.4-pro",
"name": "gpt-5.4-pro on Azure Sweden, subscription 123",
"tool_call": true,
"options": {
"thinking": "high"
}
}
}
}
}
Activity
github-actions commentedon Jul 3, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.