pi-provider-litellm

LiteLLM proxy provider extension for Pi.

Discovers models from self-hosted LiteLLM proxies and registers them under Pi providers. The default provider is litellm; optional aliases can register additional LiteLLM providers with separate credentials. Supports /login litellm, /litellm-refresh, LiteLLM MCP tools, LiteLLM Skills Gateway prompt injection, and Google ADC token auth. Tries /model/info first (admin endpoint with rich metadata), falls back to /v1/models (OpenAI-compatible) on 401/403/404, then tries /health plus per-endpoint /model/info for older LiteLLM proxies.

Install

pi install npm:pi-provider-litellm

Pi fetches the package from npm and registers it. Add -l to install into project settings (.pi/settings.json) instead of global.

To try it without installing (one-off, current run only):

pi -e npm:pi-provider-litellm

git clone https://github.com/balcsida/pi-provider-litellm.git ~/.pi/agent/extensions/pi-provider-litellm
cd ~/.pi/agent/extensions/pi-provider-litellm
npm ci
npm run clean && npm run build

Configure

Option A — interactive login

Inside pi:

/login litellm

You can also run /login, select Use a subscription, then select LiteLLM.

You'll be prompted for the base URL and API key. Credentials are persisted to ~/.pi/agent/auth.json.

Enterprise SSO login

If your LiteLLM proxy requires SSO/OAuth authentication (enterprise deployments), you can authenticate via a browser SSO flow and optionally pair the resulting JWT with a stable virtual key:

1. Run /login litellm inside pi
2. Enter the proxy URL
3. At the login method prompt, enter 2 for SSO / Enterprise JWT
4. Your default browser opens the LiteLLM SSO login URL (e.g. https://litellm.your-domain.com/sso/key/generate) automatically — the URL is also displayed in case it can't be opened. Authenticate via SSO
5. Copy your token from the LiteLLM UI and paste it at the prompt (copying a full Bearer ... header value is fine — the prefix is stripped automatically)
6. When prompted to generate a virtual key, press Enter to accept (recommended) or enter n to use the JWT directly

When you generate a virtual key, the resulting sk-... key is stored as your credential and used for all API requests. If the proxy's key policy attaches an expiry to the generated key, Pi will prompt you to re-authenticate when it nears expiry; otherwise the key is treated as permanent until revoked in LiteLLM.

When using a JWT directly, the extension reads its exp claim and Pi will prompt you to re-authenticate when the token nears expiry. Run /login litellm again to refresh.

Option B — environment variables

export LITELLM_BASE_URL="https://litellm.your-domain.com"
export LITELLM_API_KEY="sk-..."

Stored pi credentials for litellm take precedence over LITELLM_API_KEY; the environment key is used when no saved credential exists. LITELLM_BASE_URL is used when no saved login base URL exists.

Multiple LiteLLM provider aliases

Add alias providers in ~/.pi/agent/settings.json under litellm.providers. Each alias is registered as a separate Pi provider name, so models appear as litellm/model-id and litellm-anthropic/model-id.

{
  "litellm": {
    "providers": {
      "litellm-anthropic": {
        "baseUrl": "https://litellm.your-domain.com",
        "apiKey": "$LITELLM_CLAUDE_KEY",
        "headers": "$LITELLM_HEADERS"
      }
    }
  }
}

You can also override the default provider through the same shape:

{
  "litellm": {
    "providers": {
      "litellm": {
        "baseUrl": "https://litellm.your-domain.com",
        "apiKey": "$LITELLM_API_KEY",
        "headers": "$LITELLM_HEADERS"
      },
      "litellm-anthropic": {
        "baseUrl": "https://litellm.your-domain.com",
        "apiKey": "$LITELLM_CLAUDE_KEY",
        "headers": "$LITELLM_HEADERS"
      }
    }
  }
}

Provider fields:

| Field | Default | Effect | |---|---|---| | baseUrl | LITELLM_BASE_URL for litellm; required for aliases | LiteLLM proxy URL, with or without /v1 | | apiKey | LITELLM_API_KEY_HELPER/LITELLM_API_KEY for litellm; required for aliases | Pi config value for this provider's key. Use $ENV_VAR, ${ENV_VAR}, !command, or a literal key. Escape a literal $ as $$. | | headers | $LITELLM_HEADERS for litellm; unset for aliases | JSON string env reference or inline object of request headers | | displayName | provider name | Label shown in Pi UI | | enabled | true | Set false to skip an alias |

/login litellm and Google ADC token auth remain scoped to the default litellm provider. Aliases use their configured apiKey or manually stored auth entries matching the alias name.

Use

/model

Optional environment variables

| Variable | Default | Effect | |---|---|---| | LITELLM_API_KEY_HELPER | unset | Command that prints a fresh LiteLLM bearer token. Takes precedence over LITELLM_API_KEY. Registered as a !command provider key; Pi re-runs it on every request (the per-request auth path is uncached), so rotating/short-lived tokens stay fresh. | | LITELLM_HEADERS | unset | JSON object of extra headers sent to LiteLLM provider, discovery, MCP, and Skills Gateway requests. Provider aliases can use it with "headers": "$LITELLM_HEADERS". | | LITELLM_GCLOUD_TOKEN_AUTH | unset | If set to a non-empty value other than 0, use Google Application Default Credentials as the LiteLLM bearer token source. This takes precedence over LITELLM_API_KEY_HELPER and LITELLM_API_KEY when no stored /login litellm credential exists. | | GOOGLE_APPLICATION_CREDENTIALS | Google default ADC path | Optional path to an ADC JSON file used by LITELLM_GCLOUD_TOKEN_AUTH. If unset, the extension checks the default gcloud ADC locations. | | LITELLM_OFFLINE | unset | If 1, skip discovery on this start; use cache only | | LITELLM_DISCOVERY_TIMEOUT_MS | 5000 | Discovery fetch timeout in ms; 0 to skip discovery |

LITELLM_DISCOVERY_TIMEOUT_MS=0 only disables startup and refresh model discovery. It does not replace the base URL or API key settings required to send requests when you are not using /login litellm.

Google ADC token auth

When your LiteLLM proxy accepts Google OAuth access tokens, you can let the extension refresh tokens from Application Default Credentials:

gcloud auth application-default login
export LITELLM_BASE_URL="https://litellm.your-domain.com"
export LITELLM_GCLOUD_TOKEN_AUTH=1

Only authorized_user ADC files are supported. Service account JSON files are rejected with a warning. Tokens are cached in memory for 50 minutes and the registered provider key is a Pi !command, so request-time auth resolves a fresh token when Pi sends model requests.

LiteLLM MCP tools

If your LiteLLM proxy exposes MCP REST endpoints, this extension discovers tools from:

• GET /mcp-rest/tools/list
• POST /mcp-rest/tools/call

Each discovered tool is registered as a native Pi tool named mcp_<server>_<tool>, with simple JSON Schema parameters mapped to Pi/TypeBox parameters. Complex schemas fall back to a single args object. MCP discovery runs after successful live model discovery, /login litellm, or /litellm-refresh; it does not force network or helper-token access when a fresh model cache is used. MCP tools run in Pi's parallel tool mode and retry transient failures once.

LiteLLM Skill Hub

If your LiteLLM proxy exposes /claude-code/marketplace.json, enabled skills are fetched before each agent turn and appended to the system prompt as a litellm_skills section. The extension falls back to the legacy /v1/skills Skills Gateway path when Skill Hub is unavailable. It also registers Pi tools for basic skill management:

• litellm_skill_list
• litellm_skill_create
• litellm_skill_delete

Mocked LiteLLM smoke workflow

The LiteLLM Smoke GitHub Actions workflow starts VidaiMock and a real LiteLLM proxy on the runner. LiteLLM exposes OpenAI-compatible and Anthropic routes whose upstreams are served by VidaiMock, then this extension's smoke runner discovers those models through LiteLLM and sends /v1/chat/completions requests through the proxy.

This keeps the LiteLLM integration path under test but does not call real LLM APIs. No provider API keys or GitHub Models permission are required. The smoke runner also asserts that discovery came from /model/info (LITELLM_SMOKE_EXPECT_SOURCE) so a silent fallback to /v1/models fails the run. The workflow also runs auth checks plus optional Postgres-backed auth checks when LITELLM_LICENSE is configured for virtual-key and admin-route behavior, then runs a non-interactive Pi CLI smoke with --list-models and -p against both the OpenAI-compatible and Anthropic-backed routes, so extension loading, model discovery, and real completion paths are covered without opening the TUI.

Development

This package requires Node.js >=22.19.0. CI currently uses Node 24.16.0.

npm ci
npm run check
npm run clean && npm run build

npm run check runs Biome, type checking, and the Vitest suite. Runtime changes must be built before local Pi smoke checks because the extension entrypoint is ./dist/index.js.

Before changing package contents or dependency policy, also run:

npm run supply-chain:guard
npm pack --dry-run

The published npm package should contain only dist, README.md, and LICENSE.

Release

Releases are driven by semver tags named v*.*.*. The GitHub release workflow installs from the lockfile, runs the checks, builds dist, verifies the package tarball, publishes to npm with provenance, and creates a GitHub release.

Before tagging a release, keep package.json and package-lock.json versions in sync and verify the dry-run package contents.

Slash commands

• /litellm-refresh — force re-fetch the model list for all configured LiteLLM providers, ignoring cache
• /litellm-refresh <provider> — refresh one configured provider alias, for example /litellm-refresh litellm-anthropic

Cache

The default provider model list is cached at ~/.pi/agent/litellm-models.json with a keyed fingerprint of the base URL + API key. Alias provider caches use ~/.pi/agent/litellm-models-<provider>.json. Changing the base URL or key invalidates that provider's cache automatically.

If the cache is older than 24 hours, the extension refreshes it in the background on session start (non-blocking). Failures are silent — the cached models remain in use. Run /litellm-refresh to force an immediate refresh.

Troubleshooting

| Symptom | Likely cause | |---|---| | "no credentials" warning at startup | Env vars not set and no OAuth credential — run /login litellm | | "discovered no models" | Proxy returned an empty list — check pi's startup log and verify /model/info, /v1/models, or /health responds | | /model/info returning 401/403/404 | Expected behavior with virtual keys — extension falls back to /v1/models | | Discovery times out | Increase LITELLM_DISCOVERY_TIMEOUT_MS or set LITELLM_OFFLINE=1 to fall back on cached models | | 401 Token expired | Set LITELLM_API_KEY_HELPER. | | No models with gcloud auth | Verify gcloud auth application-default login has been run or set GOOGLE_APPLICATION_CREDENTIALS to an authorized_user ADC file | | Enterprise SSO login shows "virtual key generation failed" | The LiteLLM instance may lack a database (/key/generate requires one), your user account may lack key-generation permission, or the request timed out; the JWT is used directly as a fallback | | Enterprise SSO token prompt fails with "SSO token is required" | The token field was left empty — paste the token copied from the LiteLLM UI | | MCP tools not showing | Verify the proxy exposes /mcp-rest/tools/list and run /litellm-refresh after fixing the proxy | | Skills not affecting prompts | Verify the proxy exposes /claude-code/marketplace.json or /v1/skills and returns enabled skills |

License

MIT — see LICENSE.