Pi

在 ~/.pi/agent/models.json 中添加自定义提供商配置块 — baseUrl、api 和模型 ID — 让 Earendil 的 Pi 终端编程代理通过一个密钥使用 Claude 与 GPT。

{
  "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
        }
      ]
    }
  }
}

分步操作

1. 在 /app/keys 创建密钥并复制——它只会显示一次。
2. 将其设置为环境变量 KUNAVO_API_KEY。Pi 会在 apiKey 字段中解析 "$NAME" 或 "${NAME}"，也可以解析字面值或开头为 !command 的值。如果变量名后面还有字面文本，请使用带大括号的形式。
3. 创建或编辑 ~/.pi/agent/models.json，并粘贴上方的代码块。非内置提供商必须设置 baseUrl，且在提供商级别或模型级别提供 api 值——Pi 的源代码要求这些值，否则不会加载模型；其他设置均为可选。打开 /model 即可重新加载文件。
4. 运行 pi，执行 /model，然后选择一个你已声明的 ID。如果列表中没有它，请检查 JSON 前面的密钥——参见上方的解析顺序说明。
5. 给它一个需要读取和编辑真实文件的任务。Pi 几乎所有操作都依赖工具调用，因此首次运行时接触文件系统，比打个招呼能让你了解得更多——而且这次运行可以暴露流式传输或工具架构不匹配的问题；这正是 Kunavo 尚未替你测试过的问题类型。

已于 2026年10月1日 对照 Pi 的选择模型文档 检查。第三方设置会发生变化；如果这里的字段名称不再与你看到的内容一致，应以该页面为准，而不是本页。

调试客户端前先验证

一个请求即可确定故障来自端点、密钥还是配置文件。如果返回 JSON，则相同的基础 URL 和密钥可以在 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-..."

字段中应填写哪个模型 ID

每个文本模型都可通过模型 ID 访问——实时列表见 GET /v1/models，包含价格的目录见模型页面。费率单位为每 1M token 的美元，格式为输入 / 输出。

另一种方式：anthropic-messages

在 2026 年 9 月 22 日文档更新之前，Pi 为自定义提供商的 api 记录了四个值——openai-completions、openai-responses、anthropic-messages 和 google-generative-ai。更新后的模型页面没有列出任何值：一个示例中显示 openai-completions，并将该情况描述为“兼容 OpenAI、Anthropic 或 Google 的端点”。Pi v0.99.2 的源代码将该字段定义为自由字符串，并将其分发给与之匹配的十种内置实现之一——前四种加上 openai-codex-responses、azure-openai-responses、google-vertex、mistral-conversations、bedrock-converse-stream 和 pi-messages。自定义提供商曾有文档说明的只有前四种，此处未测试其余六种中的任何一种；本页没有任何内容表明其中任何一种可用于第三方端点。

anthropic-messages 是有文档记录的四种取值之一，而 Kunavo 除了兼容 OpenAI 的接口，也支持 Anthropic Messages 接口。因此，这条路由可以用配置表达。本页不会在供你粘贴的配置块中为它填写 base URL：Pi 的文档从未明确规定此 api 的 base URL 字段应填写什么值。在 9 月 22 日之前，文档以两种方式展示它——一个示例中是 https://proxy.example.com/v1，另一个示例中是不带路径后缀的 https://proxy.example.com；当天的文档更新删除了两者，没有做出选择。如果你选择这条路由，可以先试一种；如果首次调用返回的是 404 而不是 401，就需要修改那一行。

在 Pi 的该 API 的 compat 架构中，有三个字段值得你在使用前了解（源代码版本为 v0.99.2）。文档对这三个字段有一条规则，值得先引用：“兼容性设置应描述端点请求或响应行为中已验证的差异。不要仅因为端点宣称兼容 OpenAI 或 Anthropic 就启用这些设置。”

1. compat.supportsEagerToolInputStreaming — 适用于会拒绝按工具即时流式传输输入的后端。
2. compat.supportsStrictTools — 端点是否接受严格的 JSON 架构工具定义；自定义模型不会继承内置 Anthropic 模型声明的设置。
3. compat.supportsMidConvoEffort — 在对话中途更改推理强度。此端点是否符合条件，需要在运行时确认；Kunavo 尚未通过实际运行作出判断。

本页顶部的 openai-completions 配置块避开了这三个问题。这就是建议从这里开始的真实原因，并非声称它性能更好。