providers.json
Provider configuration lives in a global file at ~/.posit/ai/providers.json, separate from the general Config File, ~/.posit/assistant/settings.json.
The provider configuration modal writes this file for you as you add and edit providers.
Credentials never go in this file. Set API keys and tokens through the modal, which stores them separately.
For the list of supported providers, and for per-provider authentication and setup, see Providers.
Schema
The JSON schema lives at:
Posit Assistant points your file’s $schema at that URL when it first creates providers.json, and repairs the pointer if it is out of date. An editor with JSON Schema support then gives you completion, hover descriptions, and validation as you edit.
Settings reference
providers.json Settings Reference lists every key the file accepts, one table per provider. Look up a provider by its id:
| Provider | Provider id |
|---|---|
| Posit AI Pass | positai |
| Amazon Bedrock | bedrock |
| Anthropic | anthropic |
| Databricks | databricks |
| DeepSeek | deepseek |
| GitHub Copilot | copilot |
| Google Gemini | gemini |
| Google Vertex AI | google-vertex |
| LiteLLM | litellm |
| LM Studio | lmstudio |
| Microsoft Foundry | ms-foundry |
| Ollama | ollama |
| OpenAI | openai |
| OpenAI Compatible | openai-compatible |
| OpenRouter | openrouter |
| Portkey | portkey |
| Snowflake Cortex | snowflake-cortex |
| Custom providers | custom |
| Default (applies to every provider) | default |
Common configurations
You can combine any of these in one file.
Choosing which models appear
The models block controls what shows up in the model picker: discovery decides whether to ask the provider at all, allow and deny filter what comes back, overrides patches metadata on models it returns, and custom declares models it does not return itself. A provider that discovers its own models (through a /models endpoint) doesn’t need custom, but allow, deny, and overrides are still useful for trimming or adjusting what it reports.
{
"providers": {
"openai": {
"models": {
"allow": ["gpt-5.6", "gpt-5.6-mini"],
"overrides": {
"gpt-5.6": { "maxOutputTokens": 32000 }
}
}
}
}
}
Only allow specific providers
Set providers.default.enabled to false to hide every provider, then enable just the ones you want:
{
"providers": {
"default": { "enabled": false },
"anthropic": { "enabled": true },
"openai": { "enabled": true }
}
}
Route a provider through an enterprise proxy or gateway
Set a baseUrl for the proxy, plus any tenancy or routing headers it needs on every request:
{
"providers": {
"anthropic": {
"baseUrl": "https://my-proxy.example.com/v1",
"customHeaders": {
"x-gateway-tenant": "team-42"
}
}
}
}
Some providers need a version segment in that URL. See the baseUrl row in the settings reference.
customHeaders carries non-secret tenancy or routing metadata only. Assistant strips reserved headers such as Authorization and x-api-key, so use the provider’s credential field for anything that needs to authenticate. Four providers ignore customHeaders altogether: copilot, google-vertex, ollama, and lmstudio.
Redirect models that use different protocols
When a provider’s models do not all use the same API protocol, one baseUrl cannot redirect them all. Use endpoints to redirect every model on one protocol, or models.overrides to redirect a single model. Bedrock is the provider where this usually comes up:
{
"providers": {
"bedrock": {
"endpoints": {
"openai-chat": "https://my-proxy.example.com/bedrock/openai"
},
"models": {
"overrides": {
"openai.gpt-oss-120b": { "baseUrl": "https://my-proxy.example.com/gpt-oss" }
}
}
}
}
}
For each model, Assistant uses the first URL it finds in this order:
| Order | Where the URL comes from | Applies to |
|---|---|---|
| 1 | models.overrides["<model-id>"].baseUrl | The single model named in the key |
| 2 | endpoints["<protocol>"] | Every model using that protocol, such as openai-chat for gpt-oss models or openai-responses for GPT-5.x |
| 3 | The endpoint the provider reports | Models with no override above |
| 4 | baseUrl | Models the provider reports no endpoint for |
Claude models on Bedrock are the exception: they always go through the Anthropic Messages or Converse API using its AWS SDK endpoint, so none of the above applies to them.