文档
Open Interpreter
Open Interpreter 通过 TOML 表配置提供商,与其 Codex 前身类似;但它保留了上游 Codex 已弃用的 Chat Completions 传输方式。只需添加一个 [model_providers.kunavo] 配置块,代理就能使用该密钥可访问的任意模型。
在 ~/.openinterpreter/config.toml 中添加一个 [model_providers.kunavo] 表 — base_url、env_key、wire_api = "chat" — Rust 终端代理即可运行密钥可访问的任意模型。
model_provider = "kunavo"
model = "claude-sonnet-5"
[model_providers.kunavo]
name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
env_key = "KUNAVO_API_KEY" # the NAME of the variable, not the key
wire_api = "chat"chat 传输上,基础 URL 保留 /v1 后缀。Open Interpreter 的文档是通过示例而非明确规则说明这一点的:提供商页面上的自定义提供商配置块使用 base_url = "https://api.example.com/v1",配置页面使用 "https://api.acme.example/v1",文档中点名的托管网关使用 "https://app.nz/v1"。省略此后缀会导致 404,而不是身份验证错误。0.4.3 的 Python 软件包通过 --api_base、--api_key 和 --model openai/<id> 配置,也可以在 Python 中通过 interpreter.llm 配置。这些选项在当前终端代理中都不存在;它只读取上面的 TOML 表。在编辑任何内容之前先运行 interpreter --version——旧教程中的 pip install open-interpreter 可能会让另一个二进制文件以相同名称与之竞争。claude-code harness——其文档说明,默认情况下,只要满足“Anthropic、Claude 模型 ID、Anthropic base URL 或任何 messages 提供商”之一,就会选择它。这里这种搭配是有效的:路由表列明 claude-code 与 wire_api = "chat" 兼容。若要改用其他选项,请显式设置 harness;显式值始终优先。无法识别的值会回退到 chat,且不使用内置请求构造器,而不会直接报错退出。sk-kn- 开头),并充值 $10 起——调用费用从该余额中扣除,失败的调用不会收费。随后,控制台会打开 Open Interpreter 设置页面。分步操作
- 在
/app/keys创建密钥并复制——它只会显示一次。 - 将它导出为你即将写入
env_key的名称:export KUNAVO_API_KEY=sk-kn-...。该字段存放的是变量名,而不是变量值——文档列出的env_key是“从环境变量读取 bearer token”的来源。 - 将上面的配置块放入
~/.openinterpreter/config.toml;如果希望它只对某个仓库生效,也可以放入可信项目中的.openinterpreter/config.toml。项目配置优先于用户配置;本次运行中,-c key=value标志的优先级高于两者。 - 启动
interpreter并运行/model。模型选择器会先查询当前提供商的 models 路由,Kunavo 会返回GET /v1/models,因此列表会自动填充。 - 如果生效的值不对,请运行
/debug-config。它会打印最终生效的配置以及每个值的来源;与重新阅读 TOML 相比,这更容易确认是否用了过期配置文件或项目文件。
已于 2026年9月21日 对照 Open Interpreter 的模型提供商页面 检查。第三方设置会发生变化;如果这里的字段名称不再与你看到的内容一致,应以该页面为准,而不是本页。
调试客户端前先验证
一个请求即可确定故障来自端点、密钥还是配置文件。如果返回 JSON,则相同的基础 URL 和密钥可以在 Open Interpreter 中使用。
# 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 输入 / 输出 | 它在 Open Interpreter 中的位置 |
|---|---|---|
claude-sonnet-5 | $1.40 / $7.00 | 编辑并运行循环中的默认工作模型 |
claude-opus-5 | $3.50 / $17.50 | 规划大型重构时使用,错误的计划代价很高 |
claude-haiku-4-5 | $0.70 / $3.50 | 回合数占主导的 shell 密集型会话 |
gpt-5-6-sol | $2.00 / $12.00 | 来自不同模型系列的第二意见,共用同一密钥 |
常见问题
如何为 Open Interpreter 配置自定义 API 提供商?
在 ~/.openinterpreter/config.toml 中添加一个 [model_providers.<id>] 表,填写 name、base_url、env_key 和 wire_api,然后通过顶层的 model_provider 键选择它,并用 model 指定模型。对于兼容 OpenAI 的端点,使用 wire_api = "chat",并将 base URL 设为以 /v1 结尾的地址——这是 Open Interpreter 自己的提供商页面为自定义提供商和其按名称记录的托管网关展示的格式。env_key 存放的是环境变量名,因此应导出密钥,而不要将密钥直接粘贴到文件中。
Open Interpreter 的 base_url 末尾需要加 /v1 吗?
对于 chat wire,是的。文档没有用文字说明路径构造规则,但列出的每个自定义提供商示例都带有该后缀:提供商页面上的 https://api.example.com/v1、配置页面上的 https://api.acme.example/v1,以及它所列网关的 https://app.nz/v1。messages wire 的行为不同——客户端自带的 Anthropic 风格提供商使用的 API 根地址不带 /v1——因此,/v1 这一答案仅适用于 wire_api = "chat" 和 wire_api = "responses"。
旧的 --api_base 和 --model openai/... 标志还有效吗?
不再有效。它们属于冻结在 0.4.3 版本的 Python 包,该包通过 LiteLLM 路由,因此需要 openai/ 前缀。当前的终端代理是 Codex 的 Rust 分支,既不支持这些标志,也不采用此前缀约定:它从 ~/.openinterpreter/config.toml 或项目级 .openinterpreter/config.toml 读取 TOML 提供商表,并通过 model_provider 和 model 选择提供商及模型。配置需要从头编写;docs.openinterpreter.com 会重定向到 Rust 文档,所以旧教程的链接仍然有效,但描述的是你并未安装的程序。
为什么 /model 选择器不显示自定义提供商的上下文窗口?
因为这些元数据来自客户端内置的目录;该目录根据 models.dev 和少数实时提供商端点生成,并且只有在提供商与目录条目按 Anthropic 身份、base URL、提供商名称或认证环境变量匹配时才会填入。Kunavo 不在这个生成的目录中——根据 2026 年 9 月 21 日检查的仓库文件确认——因此,手动编写的提供商会从端点自己的 models 路由获取模型列表,仅此而已。模型仍然可以运行;只是选择器中可在模型旁显示的信息较少。
没有 Anthropic 账号,Open Interpreter 也能调用 Claude 模型吗?
可以,因为 wire_api 指定的是传输方式,而不是供应商。使用 wire_api = "chat" 时,模型 ID 会原样传递到你配置的 base_url,并在那里解析,因此你持有的凭证属于该端点。Open Interpreter 仍会根据 Claude 模型 ID 自动选择 claude-code harness,而该 harness 被列为兼容 chat wire,因此这属于文档记载的搭配,而不是变通方案。