Pi

A custom provider block in ~/.pi/agent/models.json — baseUrl, api and the model ids — puts Earendil's Pi terminal coding agent on Claude and GPT through one key.

{
  "providers": {
    "kunavo": {
      "baseUrl": "https://api.kunavo.com/v1",
      "api": "openai-completions",
      "apiKey": "$KUNAVO_API_KEY",
      "models": [
        {
          "id": "claude-sonnet-5",
          "name": "Claude Sonnet 5",
          "reasoning": true,
          "input": ["text", "image"],
          "contextWindow": 1000000,
          "maxTokens": 128000
        },
        {
          "id": "claude-haiku-4-5",
          "name": "Claude Haiku 4.5",
          "input": ["text", "image"],
          "contextWindow": 200000,
          "maxTokens": 64000
        }
      ]
    }
  }
}

Step by step

1. Create a key at /app/keys and copy it — it is shown once.
2. Put it in the environment as KUNAVO_API_KEY. Pi resolves "$NAME" or "${NAME}" in the apiKey field, as well as a literal value or a leading !command. Use the braced form when literal text follows the variable name.
3. Create or edit ~/.pi/agent/models.json and paste the block above. A non-built-in provider needs baseUrl and an api value at either provider or model level — Pi's source refuses to load the model without them — and everything else is optional. Opening /model reloads the file.
4. Start pi, run /model and pick one of the ids you declared. If they are not listed, check the key before the JSON — see the resolution-order note above.
5. Give it a task that reads and edits a real file. Pi leans on tool calling for nearly everything it does, so a first run that touches the filesystem tells you much more than a greeting does — and it is the run that would surface a streaming or tool-schema mismatch, which is exactly the class of thing Kunavo has not tested for you.

Checked against Pi's Choose a Model documentation on October 1, 2026. Third-party settings move; if a field name here no longer matches what you see, that page is the authority, not this one.

Verify before you debug the client

One request settles whether a failure is the endpoint, the key, or the configuration file. If this returns JSON, the same base URL and key work in Pi.

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

Which model id to put in the field

Every text model is reachable as a model id — the live list is GET /v1/models, and the catalog with prices is on the models page. Rates are USD per 1M tokens, input / output.

The other route: anthropic-messages

Until its September 22, 2026 docs refresh, Pi documented four values for a custom provider's api — openai-completions, openai-responses, anthropic-messages and google-generative-ai. The refreshed models page lists none: it shows openai-completions in one example and describes the case as “An OpenAI-, Anthropic-, or Google-compatible endpoint”. Pi's source at v0.99.2 types the field as a free string and dispatches it to whichever of ten built-in implementations matches — the four plus openai-codex-responses, azure-openai-responses, google-vertex, mistral-conversations, bedrock-converse-stream and pi-messages. Only the four were ever documented for a custom provider, and none of the other six was tested here; nothing on this page says any of them works against a third-party endpoint.

anthropic-messages is one of the documented four, and Kunavo answers the Anthropic Messages surface as well as the OpenAI-compatible one. So the route is expressible. What this page will not do is write a base URL for it into a block you would paste: Pi's documentation has never settled that field for this api. Until September 22 it showed it two ways — https://proxy.example.com/v1 in one example, a bare https://proxy.example.com in another — and the docs refresh that day removed both rather than choosing. If you take this route, try one, and if the first call comes back 404 rather than 401, that line is the one to change.

Three fields in Pi's compat schema for this api are worth knowing before you get there (source, v0.99.2), and the docs' one rule about all of them is worth quoting first: compatibility settings “should describe verified differences in the endpoint's request or response behavior. Do not enable them based only on an endpoint advertising OpenAI or Anthropic compatibility.”

1. compat.supportsEagerToolInputStreaming — for a backend that rejects per-tool eager input streaming.
2. compat.supportsStrictTools — whether the endpoint accepts strict JSON-schema tool definitions; a custom model does not inherit what a built-in Anthropic model declares.
3. compat.supportsMidConvoEffort — changing reasoning effort mid-conversation. Whether this endpoint qualifies is a runtime question, and Kunavo has not answered it by running anything.

The openai-completions block at the top of this page avoids all three, which is the honest reason to start there rather than a claim that it performs better.