文档

Oh My Pi

Oh My Pi 将提供商配置集中放在一个 YAML 文件中。在你选择的名称下添加三行——baseUrl、api、apiKey——omp 就会通过一个密钥路由到 Claude 和 GPT，模型列表则会自动获取，无需手动输入。

在 ~/.omp/agent/models.yml 中添加提供商配置块 — baseUrl、api、apiKey — 将 Oh My Pi 指向 Kunavo，发现功能会通过 GET /v1/models 填充模型列表。

~/.omp/agent/models.yml

providers:
  kunavo:
    baseUrl: https://api.kunavo.com/v1
    api: openai-completions
    apiKey: KUNAVO_API_KEY       # an env-var name; literal text also works
    discovery:
      type: openai-models-list   # reads GET /v1/models

# Prefer a fixed list to a discovered one? Drop the discovery block and
# declare ids instead. Omitted metadata defaults to a 128,000-token context
# window and a 16,384-token output limit, so set the real numbers from
# /models when they differ.
#
#     models:
#       - id: claude-sonnet-5
#         name: Claude Sonnet 5
#         contextWindow: ...
#         maxTokens: ...

Base URL 需要保留 /v1。 omp 将 baseUrl 记录为“端点根路径”，将 openai-completions 记录为“OpenAI 兼容的聊天补全”，其 404 故障排查条目写道：“通用 OpenAI 兼容 Base URL 通常以 /v1 结尾。”两个页面上的所有自定义提供商示例也都以相同方式结尾。“通常”是他们使用的保留说法，并非保证——但 Kunavo 提供 /v1/chat/completions，因此 https://api.kunavo.com/v1 是能生成该端点的根路径。这与 Anthropic 风格的客户端正好相反，后者需要不带路径的源站地址。

此路由不要添加 authHeader。omp 说明该字段用于网关“明确要求将 Authorization: Bearer 作为普通标头注入”的情况，并指出“标准提供商客户端已采用其常规身份验证方案”——OpenAI 兼容客户端采用的正是这种方案，Kunavo 也接受。只有当 curl 无法复现下方情况，而你遇到 401 时，才添加它。

本配置依据下方日期时 omp 自己的文档整理。Kunavo 尚未使用 omp 调用其端点——没有会话、没有流式对话轮次、没有工具往返调用，也没有路由检查。发布配置页面不等于测试，本页内容也不应被理解为测试结果。下方的 curl 是你可以在十秒内自行确认的部分；其余情况取决于你与 omp 的实际使用。

Kunavo 不提供嵌入、文本转语音或语音转文本模型，因此此提供商只处理聊天。配置中用于转录音频或构建向量索引的任何功能，都应继续使用已有的提供商密钥。

还没有密钥？创建 Kunavo 账户，创建一个密钥（以 sk-kn- 开头），并充值 $10 起——调用费用从该余额中扣除，失败的调用不会收费。随后，控制台会打开 Oh My Pi 设置页面。

分步操作

在 /app/keys 创建密钥并复制——它只会显示一次。
在启动 omp 的 shell 中，将其导出为 KUNAVO_API_KEY。omp 会先将 apiKey 解析为环境变量名，若找不到则将文本本身作为密钥，因此变量名拼写错误时会悄然加载，并在首次请求时失败。以 ! 开头的值会被作为 shell 命令运行——这是 1Password 风格的配置方式。
将上面的代码块放入 ~/.omp/agent/models.yml。提供商 id——此处为 kunavo——由你自行选择，并会成为每个选择器的前半部分。
运行 omp models kunavo 加载文件，并仅列出此提供商。YAML 或 schema 出现问题时，会打印 models.yml validation failed 以及出错字段；omp models refresh kunavo 会强制重新执行发现请求，而不是使用缓存目录。
使用精确选择器进行测试：omp -p --model kunavo/claude-sonnet-5 "Reply with only OK"。然后启动 omp，输入 /model，并将所需 id 设为默认——模型中心会在打开时重新加载 models.yml。/switch 只会更改当前会话。

已于 2026年9月21日对照 omp 的“提供商”页面检查。第三方设置会发生变化；如果这里的字段名称不再与你看到的内容一致，应以该页面为准，而不是本页。

这是简要版本。完整教程——包括模型选择、真实会话成本和失败模式——见 Oh My Pi 与 OpenCode 对比。

调试客户端前先验证

一个请求即可确定故障来自端点、密钥还是配置文件。如果返回 JSON，则相同的基础 URL 和密钥可以在 Oh My 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 的美元，格式为输入 / 输出。

模型 ID	Kunavo 输入 / 输出	它在 Oh My Pi 中的位置
`claude-sonnet-5`	$1.40 / $7.00	默认角色——大多数会话实际运行的模型
`claude-opus-5`	$3.50 / $17.50	计划角色，错误的计划所造成的代价高于 token 费用
`claude-haiku-4-5`	$0.70 / $3.50	smol 角色：分流、摘要，以及永无止境的调用
`gpt-5-6-sol`	$2.00 / $12.00	使用同一个提供商配置，获得来自另一模型系列的第二意见

计费方式是从预付余额中按 token 扣费，无月费——参见计费。对于重复上下文——这正是编辑器或聊天客户端发送内容的大部分——提示缓存对账单的影响大于模型选择。

发现：使用哪种类型，以及哪些模型会出现在选择器中

omp 提供六种 discovery.type 值，其中两种看起来适用于网关，但只有一种适用。proxy 的文档说明它适用于“模型条目通过 supported_endpoint_types 声明模型类型的 OpenAI/Anthropic 混合代理”，并根据该字段推导每个模型的线路格式。Kunavo 的 GET /v1/models 不会发布该字段，因此在 proxy 下，每个条目都会回退到提供商级别的 api；如果未设置，则会被丢弃。文档将 openai-models-list 描述为“通用 OpenAI 兼容 GET /v1/models 端点”，应使用这一项，这也是上方配置块保留 api: openai-completions 的原因：omp 的规则是“除 proxy 外，发现功能都需要提供商级别的 api”。

打开模型选择器之前，有一点值得了解。Kunavo 的模型列表包含整个已启用目录，因此发现后会在聊天模型之外一并显示图像、视频和音乐 id，而聊天传输无法调用这些模型。Kunavo 会在聊天模型条目上发布 context_length——根据其模型文档，这是 omp 的通用发现功能在 max_model_len 之后读取的字段——但媒体模型条目没有此字段，因此 omp 会为它们采用默认值 128,000 token，而非真实数值。如果你希望选择器简洁且准确，请移除发现配置块，改为手动声明实际使用的三四个 id。

omp 也支持 anthropic-messages，而 Kunavo 会响应 /v1/messages。本页没有为这一组合提供配置块：此处引用的两个页面只确定了 OpenAI 兼容路由的基础 URL 格式，并未说明 Anthropic 兼容路由如何处理末尾的 /v1；配置块的意义在于读者可以直接复制粘贴。如果你选择这种方式，disableStrictTools: true 是文档中针对 Anthropic 兼容端点上工具调用因 400 错误失败时给出的解决方案。

常见问题

如何向 Oh My Pi 添加自定义 API 提供商？

所有配置都在 ~/.omp/agent/models.yml 中完成。在 `providers:` 下添加一个键——名称由你选择，并成为选择器中代表提供商的部分——然后填写 baseUrl、api 和 apiKey；这是 omp 自己的“添加自定义提供商”示例所采用的顺序。你可以在 `models:` 下手动列出模型，也可以添加 `discovery:` 配置块，让 omp 自动获取模型。然后运行 `omp models <your-provider-id>` 确认文件已加载，并通过 `omp --model <provider>/<model-id>` 或会话内的 /model hub 选择模型。

Oh My Pi 的 baseUrl 末尾需要加 /v1 吗？

对于 OpenAI 兼容端点，需要。omp 将 baseUrl 称为端点根路径，并会根据你声明的 api 系列追加路由，因此 `api: openai-completions` 表示它会在你提供的根路径下请求 chat completions。omp 自己的 404 故障排查说明指出，通用 OpenAI 兼容基础 URL 通常以 /v1 结尾，其文档中的每个自定义提供商示例也都带有该后缀。Kunavo 提供 /v1/chat/completions，因此应填写 https://api.kunavo.com/v1——缺少 /v1 会返回 404 或“端点不受支持”，而不是身份验证错误。

Oh My Pi 在哪里查找 API 密钥？多个来源冲突时以哪个为准？

models.yml 中的 apiKey 会按三个步骤解析：如果值以 ! 开头，就运行 shell 命令并使用其去除首尾空白后的标准输出；否则，omp 会查找名称完全相同的环境变量；如果不存在，则将该文本本身作为密钥。最后一种回退方式容易导致问题——变量名拼写错误时不会报错，直到首次请求才会失败。在更广泛的优先级顺序中，models.yml 中的密钥优先于已存储的 OAuth；omp 说明这是有意设计的，因此为网关提供的密钥不会被上游登录凭据覆盖。

网关在 omp 中应该使用哪种发现类型？

应使用 openai-models-list，而非 proxy；除非网关在每个模型条目上都声明 supported_endpoint_types 字段。proxy 会读取此字段，以判断模型应路由到 /v1/messages 还是 /v1/chat/completions；如果缺少该字段，模型就会回退到提供商级 api，或被丢弃。Kunavo 的 /v1/models 不会发布该字段，因此通用 OpenAI 列表才是正确类型；除 proxy 外，omp 要求所有发现类型都设置提供商级 api。运行 `omp models refresh <provider>` 可强制重新获取，而不是使用缓存目录。

Kunavo 是否已经使用 Oh My Pi 对其端点进行过测试？

没有。2026 年 9 月 21 日检查的是 omp 自己的文档——字段名称、顺序、密钥解析规则和发现类型均引自该文档；另有两项细节是通过 Kunavo 自己的 /v1/models 路由核对的，而非基于假设。此处没有使用 omp 会话调用 api.kunavo.com，也没有对流式响应、工具往返调用或客户端内部的模型路由作出任何声明。唯一可以单独确认的是端点和密钥能否正常工作，本页中的 curl 命令可以完成这项检查。