Pi

Pi is a terminal coding agent (@earendil-works/pi-coding-agent). Its provider configuration is very similar to OpenClaw, which is built on the same agent stack.

Its custom provider supports four APIs, and Amux implements all four protocols natively.

Recommended: let CC Switch do it#

CC Switch supports Pi, so you can add a provider there without editing JSON manually. Start a new session after switching.

The manual route is below.

1. Install#

npm i -g @earendil-works/pi-coding-agent

The CLI is pi. Check pi.dev for the current install instructions.

2. Create an Amux key#

Create one on the keys page in the console. The key remains viewable there after creation, so you do not need to rotate it just to retrieve it again.

export AMUX_API_KEY=your Amux key

Put it in ~/.zshrc or ~/.bashrc.

3. Configure#

Edit ~/.pi/agent/models.json:

~/.pi/agent/models.json

{
  "providers": {
    "amux": {
      "baseUrl": "https://gateway.amux.ai/v1",
      "api": "openai-completions",
      "apiKey": "$AMUX_API_KEY",
      "models": [
        {
          "id": "anthropic/claude-opus-5",
          "name": "Claude Opus 5"
        },
        {
          "id": "openai/gpt-5.6",
          "name": "GPT-5.6"
        },
        {
          "id": "deepseek/deepseek-v3.2",
          "name": "DeepSeek V3.2"
        }
      ]
    }
  }
}

The address for each API#

api and baseUrl have to match. Mismatching them produces a connection or auth error, which points in entirely the wrong direction:

If you want a general default, start with openai-completions. It is the most broadly compatible option and works well for most setups.

4. Pick a model#

/model

The file is re-read every time you open /model, so edits usually apply without restarting the session.

To see what is currently available:

pi --list-models

Pinning a provider or choosing a strategy#

The id can carry a suffix directly: anthropic/claude-opus-5:anthropic pins one provider, and :@price or :@reliability chooses the ordering. See the API reference.

Pi relies heavily on tool calls, so :@reliability is often a good choice for longer runs.

Troubleshooting#

Amux models do not appear under /model#

Pi only lists models that have working auth. Check the variable is actually exported:

echo $AMUX_API_KEY

If it is empty, Pi loads the configuration but marks the models unavailable, so they do not appear in the list.

Authentication failure#

First check that api and baseUrl match (see the table above). Picking the wrong protocol also surfaces as an auth-style error, and people go looking at the key. Then check the key is still enabled in the console and the workspace has balance.

The JSON is broken#

One stray comma in models.json invalidates the whole file, and the only symptom is that the models never appear. Run it through any JSON validator.

The model reports as unsupported#

Not every model supports every protocol. With api: "openai-responses" you need a model whose upstream serves Responses; the same goes for anthropic-messages. Each model's page lists the protocols actually available for it — change the model or the api.

The system prompt seems to be ignored#

Some OpenAI-compatible servers do not understand the developer role. Amux supports it, so no additional setting is required here. If the same file also configures a local server such as Ollama or vLLM, add this to that provider:

"compat": { "supportsDeveloperRole": false }