Providers

Most hosted providers support one or both of these authentication methods:

• Sign in through a browser or device flow backed by OAuth.
• Provide an API key.

Use /login [provider] to see the methods supported by a provider. Amazon Bedrock and Google Vertex AI can also use ambient cloud credentials.

Run /login and select a provider. Pi guides you through its OAuth or API-key flow and saves the resulting credential in auth.json.

On a remote or headless machine, an OAuth callback may not reach the local process. When prompted, paste the final redirect URL or authorization code back into Pi.

Run /logout and select a provider to remove its stored credential. This does not unset environment variables, remove authentication from models.json, or revoke the credential at the provider.

auth.json can contain API keys and OAuth tokens. Keep it private and do not commit it.

Environment variables are useful in CI and anywhere Pi should not store the key. Set the variable before starting Pi:

export ANTHROPIC_API_KEY=sk-ant-...
pi

This table covers providers with a single primary API-key variable. Providers that need additional configuration or support ambient credentials are covered under Provider Specific Config.

Anthropic also recognizes ANTHROPIC_OAUTH_TOKEN as an API credential and ANTHROPIC_AUTH_TOKEN as bearer authentication.

With no key or token set, Anthropic uses workload identity federation when ANTHROPIC_FEDERATION_RULE_ID, ANTHROPIC_ORGANIZATION_ID and ANTHROPIC_IDENTITY_TOKEN_FILE are set: the Anthropic SDK exchanges the identity token for a short-lived access token and refreshes it itself (re-reading the identity token file, so keep that file fresh for long sessions). ANTHROPIC_SERVICE_ACCOUNT_ID and ANTHROPIC_WORKSPACE_ID are passed through when set.

To use a secret manager without writing the resolved key to disk, set a provider's key in auth.json to a command prefixed with !:

{
  "anthropic": {
    "type": "api_key",
    "key": "!security find-generic-password -ws 'anthropic'"
  }
}

Pi runs the command when the key is first needed and caches its standard output for the process lifetime. Empty output, a timeout, or a nonzero exit leaves the key unresolved until Pi restarts.

The providers below have additional setup, need additional settings, or can use credentials supplied by their platform.

A stored API-key credential can include an env object. Its values take priority over the process environment for that provider:

{
  "cloudflare-workers-ai": {
    "type": "api_key",
    "key": "...",
    "env": {
      "CLOUDFLARE_ACCOUNT_ID": "account-id"
    }
  }
}

Radius is a service crafted for Pi by the builders of Pi, Earendil Works. It provides a customizable AI gateway with organization-level controls and analytics built in, and artifacts for sharing what you create with Pi.

To get started, run /login radius in Pi. This adds Radius as a provider, and its models appear in /model like any other provider's.

Radius also has an MCP server, so Pi can manage Radius for you.

Radius is currently in early alpha and evolving quickly. See radius.earendil.com for more.

Radius authentication uses its gateway catalog and caches refreshed model metadata for later offline startup. A custom Radius gateway configured in models.json uses its own catalog rather than inheriting the public radius.pi.dev catalog.

Authenticate with /login openrouter or OPENROUTER_API_KEY.

With a key, Pi lists only the OpenRouter chat models that key may use, with the key's context size, max output, and prices. These come from OpenRouter's /models/user endpoint and reflect guardrails and provider restrictions set in OpenRouter. Image and classifier models are not filtered.

Pi refreshes the list in the background at startup in interactive mode, when /model opens, after /login, and on pi update --models. The last list is saved and used offline and in pi -p and RPC mode. After switching keys outside /login, the previous key's list stays until the next refresh.

Regional endpoints filter models to their region. To use one, set the base URL in models.json:

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

If the base URL rejects the key at /models/user or does not have that endpoint, for example a proxy configured as the OpenRouter base URL, Pi lists every OpenRouter model.

The provider ID is azure (formerly azure-openai-responses). Use it as the key in auth.json, models.json, and settings.json, and in model references such as --model azure/gpt-5.4.

The azure provider serves OpenAI models through the Responses API and Microsoft Foundry models through Chat Completions, such as azure/deepseek-v4-pro.

Set an API key plus either a base URL or resource name:

export AZURE_OPENAI_API_KEY=...
export AZURE_OPENAI_BASE_URL=https://your-resource.ai.azure.com
# Or:
export AZURE_OPENAI_RESOURCE_NAME=your-resource

Resource root URLs under ai.azure.com, cognitiveservices.azure.com, and openai.azure.com are normalized to the OpenAI API path.

Pi sends the model ID as the deployment name. If a deployment has a different name, map it with AZURE_OPENAI_DEPLOYMENT_NAME_MAP:

export AZURE_OPENAI_DEPLOYMENT_NAME_MAP=gpt-5.4=my-gpt-deployment,deepseek-v4-pro=my-deepseek

AZURE_OPENAI_API_VERSION overrides the API version for OpenAI models (default v1).

To use a Foundry model that Pi does not include, add it under azure in models.json with api: "openai-completions". Custom models require a baseUrl; AZURE_OPENAI_BASE_URL and AZURE_OPENAI_RESOURCE_NAME take priority over it when set:

{
  "providers": {
    "azure": {
      "baseUrl": "https://your-resource.services.ai.azure.com",
      "models": [
        { "id": "your-deployment", "api": "openai-completions" }
      ]
    }
  }
}

Bedrock can use a bearer token or an ambient AWS credential source:

# Named profile
export AWS_PROFILE=your-profile

# IAM keys
export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...
# Required for temporary credentials
export AWS_SESSION_TOKEN=...

# Bedrock bearer token
export AWS_BEARER_TOKEN_BEDROCK=...

# Region, when not supplied by the profile or AWS SDK configuration
export AWS_REGION=us-west-2
# AWS_DEFAULT_REGION is also supported

Pi also supports ECS task credentials and IRSA through the standard AWS_CONTAINER_CREDENTIALS_* and AWS_WEB_IDENTITY_TOKEN_FILE variables.

The gateway requires a token, account ID, and gateway ID:

export CLOUDFLARE_API_KEY=...
export CLOUDFLARE_ACCOUNT_ID=...
export CLOUDFLARE_GATEWAY_ID=...

The account and gateway IDs can come from the process environment or the credential's env object in auth.json.

CLOUDFLARE_API_KEY authenticates Pi to the gateway. Upstream access can use Cloudflare unified billing, credentials stored in the gateway, or an Authorization header configured for the provider in models.json.

Workers AI requires a token and account ID:

export CLOUDFLARE_API_KEY=...
export CLOUDFLARE_ACCOUNT_ID=...

The account ID can also be stored in the credential's env object.

Use a Google Cloud API key:

export GOOGLE_CLOUD_API_KEY=...

To use Application Default Credentials, configure a project and location:

export GOOGLE_CLOUD_PROJECT=your-project
# GCLOUD_PROJECT is also supported
export GOOGLE_CLOUD_LOCATION=us-central1

Then authenticate:

gcloud auth application-default login

To use a service-account key file instead, set GOOGLE_APPLICATION_CREDENTIALS along with the project and location.