Providers

Posit Assistant works with a range of model providers, though the exact set and how you set them up varies by platform. Custom providers aren’t listed in the table below, since they’re user-declared rather than a single built-in provider — see its own section instead.

Available providers

Provider	Authentication
Posit AI Pass	Sign in (OAuth)
Amazon Bedrock	AWS credentials
Anthropic	API key
Databricks Preview	Workspace URL + token or OAuth
DeepSeek	API key
GitHub Copilot (Positron only) Preview	Sign in (OAuth)
Google Gemini	API key
Google Vertex AI (Gemini Enterprise Agent Platform) Preview	Google Cloud credentials
LiteLLM (Positron 2026.09.0-128+) Preview	Base URL (API key optional)
LM Studio (Local)	No credentials
Microsoft Foundry	API key or Microsoft Entra ID
Ollama (Local)	No credentials
OpenAI	API key
OpenAI Compatible (Legacy)	Base URL + API key (optional)
OpenCode Preview	API key
OpenRouter (not yet available in Positron)	API key
Portkey (Positron 2026.09.0-128+) Preview	Base URL + API key
Snowflake Cortex	connections.toml or API key

A Preview badge means the provider is relatively new or hasn’t had extensive testing — it may work well, but behavior can change without notice. A provider with no badge is a broadly supported, production-ready path.

OpenAI Compatible is legacy: it predates Custom providers and still works, but a custom entry with type: "openai-compatible" is the recommended path for a new OpenAI-compatible endpoint. See Custom providers below.

LiteLLM and Portkey need Positron build 2026.09.0-128 or newer. On earlier Positron releases — including every public 2026.08.x build — Assistant can’t register them at all: it deliberately keeps them unsupported there rather than writing a providers.json block that would trip the host’s own older, strict reader. RStudio, Standalone, Desktop, Connect, and the TUI have no such restriction.

Don’t see your provider listed? See Custom providers.

Configuring Providers

How you configure providers depends on your platform:

• RStudio — Providers can be configured through the assistant settings UI.
• Terminal (TUI) — Press Ctrl+O to open the provider configuration screen, where you can sign in or enter credentials for supported providers.
• Positron — Run the Configure Language Model Providers command to sign in or enter credentials for most providers. LiteLLM, Portkey, and other custom providers use the separate Posit Assistant: Configure Additional AI Providers command instead, available on Positron 2026.09.0-128 and newer.

For most API-key providers (Anthropic, OpenAI, Gemini, DeepSeek, OpenRouter, etc.), you just need an API key from the provider’s website. Provider Setup below covers the providers that need more than that.

Anything the settings UI doesn’t cover is set in the global provider config file, providers.json — proxy base URLs and custom headers, which models appear in the picker, disabling providers, declaring your own custom providers, and the connection settings a few providers need. See the settings reference for every key the file accepts.

Provider Setup

Posit AI Pass

Posit AI Pass is a managed service from Posit that gives you access to frontier LLMs through a single account. It’s the easiest way to get started — sign in once with no API keys to manage. See the Posit AI Pass documentation for account setup, available models, and billing.

Amazon Bedrock

Amazon Bedrock uses AWS credentials rather than an API key. Configure access using the AWS CLI:

1. Install the AWS CLI and run aws configure to set up your credentials.
2. Ensure your IAM user or role has permissions to invoke Bedrock models (bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream) and to discover them (bedrock:ListFoundationModels and bedrock:ListInferenceProfiles). Without bedrock:ListInferenceProfiles, model listing still works in us-, eu-, and ap- regions via a legacy fallback, but other regions (such as ca-central-1 or me-central-1) require it and will show no models.

OpenAI gpt-oss and GPT-5.x models use Bedrock Mantle. The simplest setup is AWS’s AmazonBedrockMantleInferenceAccess managed policy. A custom least-privilege policy should include AWS’s documented Mantle inference permissions: bedrock-mantle:CreateInference, bedrock-mantle:GetProject, bedrock-mantle:ListProjects, and bedrock-mantle:ListTagsForResource, plus bedrock-mantle:ListModels for model discovery. On a model’s first use in an account it also needs aws-marketplace:Subscribe and aws-marketplace:ViewSubscriptions (scoped with aws:CalledViaLast = bedrock-mantle.amazonaws.com), unless an administrator has already enabled the model. Those Marketplace permissions are no longer needed after subscription; see AWS’s model access guide.

Set the region and profile with aws.region and aws.profile in providers.json, or with the AWS_REGION and AWS_PROFILE environment variables. If you set neither, Bedrock falls back to us-east-1.

If you use AWS SSO and your session expires, Posit Assistant shows a notification. In the graphical desktop and web apps (Standalone, Desktop, Connect, and RStudio) it carries a Sign in again button — one click opens the provider configuration and starts the refresh. In the Positron extension and the TUI, the notification instead directs you to run aws sso login, then click Reload model list. The provider row shows the same Sign in again button. Either way, your credentials are refreshed in place — silently when a refresh token is cached, otherwise via a browser sign-in that shares the AWS CLI’s SSO cache (so aws sso login and Sign in again are interchangeable). When the browser runs on the same machine as Posit Assistant, sign-in uses the same PKCE flow as the AWS CLI: the browser rides your existing SSO session and redirects straight back, with no code to copy. The first sign-in with a new client registration asks you to allow access once; later sign-ins skip that page (the registration is shared with the AWS CLI’s cache, so consent given to aws sso login carries over). On remote or headless hosts (and whenever the local listener can’t start) it falls back to the device-code flow, which shows a code you can enter from any device’s browser. If no refresh can be attempted, Posit Assistant falls back to the configuration form.

Bedrock support is experimental in both AWS GovCloud regions: us-gov-west-1 and us-gov-east-1. Standard endpoints are used by default. To require AWS FIPS endpoints, set AWS_USE_FIPS_ENDPOINT=true, or set use_fips_endpoint = true in the selected AWS profile in your shared AWS config file. The environment variable takes precedence over the profile setting, including an explicit value of false. use_fips_endpoint is an AWS shared-config setting, not a providers.json field.

Mantle availability is model- and region-specific, so changing regions can legitimately change which gpt-oss and GPT-5.x models appear in the model picker.

AWS does not publish FIPS endpoints for Mantle. When FIPS is enabled, Posit Assistant skips Mantle discovery and does not offer or invoke Mantle models; other Bedrock models use the FIPS control-plane and runtime endpoints.

For Mantle Responses models, Posit Assistant sends store: false. This disables retrievable Responses storage, but it does not guarantee zero retention: AWS account/project retention policy is separate and should be configured to match your organization’s data-handling requirements.

Google Vertex AI

Google Vertex AI, also called Gemini Enterprise Agent Platform (GEAP), uses Google Cloud Application Default Credentials. Install the Google Cloud CLI, then authenticate:

gcloud auth application-default login

When these credentials expire, Posit Assistant shows a notification with a Sign in again button — one click opens the provider configuration and re-runs the login for you (the Google Cloud CLI opens its own browser window, so this requires a browser colocated with the host). The provider row shows the same Sign in again button. If the CLI isn’t installed or the host is remote or headless, Posit Assistant falls back to the configuration form.

Set your project and location with googleCloud.project and googleCloud.location in providers.json. location defaults to us-central1 if you leave it out.

Microsoft Foundry

Microsoft Foundry supports two authentication methods:

• API key (default). Enter the key for your Foundry resource along with its base URL.
• Microsoft Entra ID (experimental). Use ambient Azure credentials instead of an API key, for organizations that disable API-key authentication on their Foundry deployments. Authenticate with the Azure CLI (az login); managed identity, workload identity, and environment service principals also work through Azure’s DefaultAzureCredential chain. See Microsoft’s keyless authentication guidance for setup.

Entra mode is selected per deployment in the provider’s configuration form, or with azure.authMode in providers.json. The token scope defaults to https://cognitiveservices.azure.com/.default; set azure.scope (e.g. to https://ai.azure.com/.default) or azure.tenantId if your deployment requires it. No secret is stored in Entra mode — tokens are acquired and refreshed by the Azure credential chain.

Snowflake Cortex

Posit Assistant can authenticate to Snowflake Cortex two ways:

• From a connections.toml connection (recommended). If you already have a Snowflake connections.toml (used by the Snowflake CLI and Python connector), the configuration screen discovers its connections and lets you pick one. The credential is then acquired automatically based on the connection’s authenticator — external-browser single sign-on (EXTERNALBROWSER), key-pair JWT (SNOWFLAKE_JWT), a programmatic access token, or OAuth. The account host is derived from the connection’s account/host/region, so no base URL is needed.
• With a token and base URL. Alternatively, enter a token directly along with a base URL pointing to your account’s Cortex endpoint.

connections.toml is discovered from the standard locations ($SNOWFLAKE_HOME, ~/.snowflake, or the per-platform default directory). To point at a specific directory or pick a named connection, set snowflake.home and snowflake.connectionName in providers.json.

Custom providers

Use this for a provider Posit Assistant doesn’t ship built in — a self-hosted model server, an internal gateway, or any endpoint that speaks the OpenAI-compatible, Anthropic, LiteLLM, or Portkey wire protocol. Use the provider configuration modal where it is available. Otherwise, declare entries under providers.custom in providers.json. Key each entry by a name of your choosing, which is also the display name, and give it a type:

{
  "providers": {
    "custom": {
      "acme-ai": {
        "type": "openai-compatible",
        "baseUrl": "https://ai-gateway.acme.com"
      }
    }
  }
}

The providers.custom.{name}.type row in the settings reference lists every type you can declare.

The built-in openai-compatible provider predates Custom providers and still works, but a custom entry with type: "openai-compatible" is the recommended path for an OpenAI-compatible endpoint going forward.

litellm and portkey are also supported custom types (both preview), for connecting to more than one gateway or presenting one under your organization’s own name — see LiteLLM and Portkey below for each gateway’s own credential and model-discovery contract.

A custom provider that needs no API key. When the endpoint authenticates another way — a local proxy that adds SSO credentials, say — a custom anthropic entry can declare that no API key is needed:

{
  "providers": {
    "custom": {
      "corp-sso-proxy": {
        "type": "anthropic",
        "baseUrl": "http://localhost:8787",
        "apiKeyOptional": true
      }
    }
  }
}

The entry is then ready from its baseUrl alone, and Assistant sends no Authorization or x-api-key header. Custom openai-compatible entries are key-optional already and need no flag. Like any providers.json key, an administrator can pin apiKeyOptional fleet-wide through POSIT_AI_PROVIDERS_ENFORCED.

OpenCode

OpenCode offers two model services:

• OpenCode Go — a subscription serving a curated set of open coding models.
• OpenCode Zen — curated, benchmarked models, pay per request (with a free tier).

Posit Assistant lists OpenCode as a single provider entry with a Go/Zen product selector next to the API-key field, because one OpenCode workspace key works for both services. Pick the product, paste the key once, and save — the model list refreshes immediately to the selected service’s catalog. Switching products later reuses the saved key; there’s no need to paste it again. You can create a key at opencode.ai, enter it in the settings UI, or set the OPENCODE_API_KEY environment variable. No other configuration is needed — models are discovered automatically, and each model is reached over the wire protocol OpenCode documents for it (OpenAI Responses, Anthropic Messages, Gemini generateContent, or OpenAI Chat Completions).

The product choice defaults to Go. To change it outside the settings UI, set providers.opencode.product to "zen" in providers.json — this is also the way to choose Zen in the TUI, which has no product selector. The selector is disabled when an administrator has pinned the product or when an explicit baseUrl override is in effect, since the override makes the product choice inert.

If you subscribe to both products at once (a Go subscription plus Zen pay-per-request), use the built-in OpenCode entry and switch between them with the product selector — the saved key is reused on each switch. Configuring one product as an OpenAI Compatible custom provider instead is not supported: the session header OpenCode requires on inference requests is applied only by the built-in provider.

LiteLLM

Connect to a LiteLLM proxy and use any of the models it serves. A base URL is required (e.g., http://localhost:4000); an API key is optional and only needed when the proxy is protected by a master or virtual key.

Claude models served through the proxy — whether from Anthropic directly, Amazon Bedrock, or Google Vertex AI — keep full prompt caching and extended-thinking support. Posit Assistant sends explicit cache breakpoints with each request, so LiteLLM’s server-side automatic caching can be left disabled.

To connect to more than one gateway, or to present a gateway under your organization’s own name, declare custom providers with type: "litellm" under providers.custom — see Custom providers above.

Each model the gateway serves is routed over its natural wire protocol. Claude models use LiteLLM’s Anthropic-shaped /v1/messages endpoint, preserving prompt caching and extended thinking as described above. OpenAI reasoning models (o-series, GPT-5.x) use /v1/responses and offer thinking-effort levels, with reasoning continuity preserved across turns. All other models (non-reasoning OpenAI models, Gemini, local models, etc.) use /v1/chat/completions; these get conservative capabilities without thinking-effort levels.

Administrators can override the routing in ~/.posit/ai/providers.json: set providers.litellm.models.overrides["<model-id>"].protocol to change the protocol for a single model, or set a connection-level providers.litellm.protocol to force every model through one protocol. Valid values are anthropic-messages, openai-chat, and openai-responses — bedrock-converse and google-generative cannot be routed through LiteLLM and are rejected.

Portkey

Connect to Portkey — either the hosted Portkey service or a self-hosted Portkey OSS gateway. Both a base URL and an API key are required, and the base URL determines what the key means:

• Hosted Portkey (https://api.portkey.ai/v1): the key is your Portkey API key. Models are discovered automatically from your Portkey Model Catalog and use catalog IDs of the form @provider-slug/model. Discovery currently lists the Claude models in your catalog; other model families are pending verification and are not yet listed.
• Self-hosted gateway (any other URL, e.g. http://localhost:8787): the gateway is stateless, so the key is the API key of a single upstream service (Anthropic by default), and there is no model discovery — declare the models you use under providers.portkey.models.custom in ~/.posit/ai/providers.json.

Because the base URL determines what the key is, there is no default URL — a defaulted URL could silently send a self-hoster’s upstream key to hosted Portkey. A connection with a key but no base URL fails locally, before any request, with an error explaining the fix. The settings UI always saves a base URL (hosted is prefilled), so this only affects environment-only setups, which must set PORTKEY_BASE_URL.

For hosted Portkey, no model configuration is needed — enter your Portkey API key in the settings UI (the hosted base URL is prefilled and saved), or set the environment variables:

{
  "providers": {
    "portkey": {
      "baseUrl": "https://api.portkey.ai/v1"
    }
  }
}

For a self-hosted gateway fronting Anthropic (the default upstream), the stored key is your Anthropic API key. Declared Claude models need no protocol — they route over the Anthropic wire protocol with full prompt caching and extended thinking:

{
  "providers": {
    "portkey": {
      "baseUrl": "http://localhost:8787",
      "models": {
        "custom": [
          {
            "id": "claude-sonnet-4-6",
            "name": "Claude Sonnet 4.6",
            "maxContextLength": 200000,
            "supportsTools": true,
            "supportsImages": true,
            "supportsToolResultImages": true,
            "supportsWebSearch": false
          }
        ]
      }
    }
  }
}

To front a different upstream, set the x-portkey-provider routing header in customHeaders and declare models with the matching protocol. Here the stored key is your OpenAI API key:

{
  "providers": {
    "portkey": {
      "baseUrl": "http://localhost:8787",
      "customHeaders": {
        "x-portkey-provider": "openai"
      },
      "models": {
        "custom": [
          {
            "id": "gpt-4o-mini",
            "name": "GPT-4o mini",
            "maxContextLength": 128000,
            "supportsTools": true,
            "supportsImages": true,
            "supportsToolResultImages": false,
            "supportsWebSearch": false,
            "protocol": "openai-chat"
          }
        ]
      }
    }
  }
}

A self-hosted connection serves one upstream — multi-provider access through a single connection is what the hosted Model Catalog provides.

Custom providers.custom.<name> entries may also use type: "portkey" on Node-backed surfaces. That custom form is limited to a noncanonical self-hosted gateway or credential-injecting front proxy: declare bare upstream IDs in models.custom, normally set models.discovery to "off", and do not put secrets in customHeaders. There is no custom-ID environment mapping. providers.json itself never holds a credential, but the provider configuration modal on Node-backed graphical surfaces (Standalone, Desktop, Connect, RStudio) has an optional API key field for a custom Portkey entry, stored separately through the credential store; a hand-authored entry, or one added through the TUI, still needs a gateway that doesn’t require a client key. Use the built-in Portkey provider for hosted Portkey, which always requires a key.

Each model is routed over its natural wire protocol. Models with no declared protocol (including hosted Claude catalog models) use the Anthropic-shaped /v1/messages route, preserving prompt caching and extended thinking. A declared protocol of openai-chat routes over /v1/chat/completions, and openai-responses routes over /v1/responses (passed through for OpenAI upstreams, with reasoning continuity preserved across turns). To change the protocol for a single model, set providers.portkey.models.overrides["<model-id>"].protocol. Valid values are anthropic-messages, openai-chat, and openai-responses.

customHeaders is never a credential channel: the Portkey credential headers x-portkey-api-key and x-portkey-virtual-key are ignored there — the stored API key is the only credential. The routing headers x-portkey-provider and x-portkey-config apply to chat requests only; hosted model discovery always queries the full catalog.

Ollama

Ollama runs models locally on your machine. Install Ollama, pull a model, and you’re ready to go:

ollama pull llama3.2

No API key or credentials are needed. Posit Assistant talks to Ollama at http://localhost:11434 by default; if it’s running elsewhere, point at it with the OLLAMA_ENDPOINT environment variable or endpoint in providers.json.

LM Studio

LM Studio provides a local model server with a graphical interface. Install LM Studio, download a model, and start the local server. No API key or credentials are needed. Posit Assistant talks to LM Studio at http://localhost:1234/v1 by default; if it’s running elsewhere, point at it with the LMSTUDIO_ENDPOINT environment variable or endpoint in providers.json.

Databricks

Posit Assistant can discover and use models served by a Databricks workspace (Model Serving foundation models, external models, and custom serving endpoints). Every authentication method requires the workspace URL, such as https://dbc-example.cloud.databricks.com.

On RStudio and the Terminal (TUI), authenticate with a personal access token or service-principal OAuth. See the Databricks reference for setup, environment variables, and model availability details. The workspace host also goes in providers.json, as databricks.host.

GitHub Copilot

GitHub Copilot works as a model provider in Positron. Ensure you have a GitHub account with Copilot enabled.

To set up GitHub Copilot in Positron:

1. Run the Authentication: Configure Language Model Providers command from the Command Palette.
2. Select GitHub Copilot from the provider list.
3. Authenticate through the browser when prompted.
4. If you use GitHub Enterprise (GHE.com), add your enterprise URL to the github-enterprise.uri setting. Then configure authProvider as "github-enterprise" in settings.json under github.copilot.advanced.

Environment Variables

Provider credentials can also be set via environment variables. Environment variables take precedence over file-based configuration.

Environment variables must be set before the host environment (RStudio) starts, so for day-to-day IDE use the settings UI or providers.json reference is usually more practical. Environment variables are most useful for the TUI, CI/CD pipelines, and containerized deployments.

Variable	Description
ANTHROPIC_API_KEY	API key for the Anthropic provider
ANTHROPIC_BASE_URL	Custom base URL for the Anthropic provider
OPENAI_API_KEY	API key for the OpenAI provider
OPENAI_BASE_URL	Custom base URL for the OpenAI provider
GEMINI_API_KEY	API key for the Gemini provider
GEMINI_BASE_URL	Custom base URL for the Gemini provider
OPENAI_COMPATIBLE_API_KEY	API key for the OpenAI Compatible provider
OPENAI_COMPATIBLE_BASE_URL	Custom base URL for the OpenAI Compatible provider
MS_FOUNDRY_API_KEY	API key for the Microsoft Foundry provider
MS_FOUNDRY_BASE_URL	Custom base URL for the Microsoft Foundry provider
MS_FOUNDRY_AUTH_MODE	Foundry authentication mode: apikey (default) or entra
MS_FOUNDRY_ENTRA_SCOPE	Entra token scope for Foundry (default https://cognitiveservices.azure.com/.default)
MS_FOUNDRY_TENANT_ID	Azure tenant ID for Foundry Entra authentication
OPENROUTER_API_KEY	API key for the OpenRouter provider
DEEPSEEK_API_KEY	API key for the DeepSeek provider
DEEPSEEK_BASE_URL	Custom base URL for the DeepSeek provider
SNOWFLAKE_TOKEN	API token for Snowflake Cortex
SNOWFLAKE_BASE_URL	Custom base URL for the Snowflake Cortex provider
DATABRICKS_HOST	Workspace URL for the Databricks provider
DATABRICKS_TOKEN	Personal access token for the Databricks provider
DATABRICKS_CLIENT_ID	Service-principal OAuth client ID for Databricks
DATABRICKS_CLIENT_SECRET	Service-principal OAuth client secret for Databricks
AWS_REGION	AWS region for the Bedrock provider
AWS_PROFILE	AWS profile for the Bedrock provider
AWS_USE_FIPS_ENDPOINT	Use AWS FIPS endpoints for Bedrock; equivalent to use_fips_endpoint in the selected AWS shared-config profile
AWS_ACCESS_KEY_ID	AWS access key ID for the Bedrock provider
AWS_SECRET_ACCESS_KEY	AWS secret access key for the Bedrock provider
AWS_SESSION_TOKEN	AWS session token for the Bedrock provider
GOOGLE_CLOUD_PROJECT	Google Cloud project for the Vertex AI provider
GOOGLE_CLOUD_LOCATION	Google Cloud location for the Vertex AI provider
POSITAI_BASE_URL	Custom base URL for the Posit AI Pass provider
OLLAMA_ENDPOINT	Endpoint URL for Ollama
LMSTUDIO_ENDPOINT	Endpoint URL for LM Studio

| LITELLM_API_KEY | API key for the LiteLLM provider | | LITELLM_BASE_URL | Base URL for the LiteLLM provider | | PORTKEY_API_KEY | API key for the Portkey provider (a Portkey API key for hosted, or the upstream’s key for a self-hosted gateway) | | PORTKEY_BASE_URL | Base URL for the Portkey provider (required) |