Open Interpreter 接入统一 API

先说结论:api_base 加 openai/ 模型前缀

Open Interpreter 在两种界面里都记录了自定义端点的路径。命令行下,传 --api_base 填端点,--model 填一个带 openai/ 前缀的 ID。Python 里,在调用 chat() 之前设置 interpreter.llm.api_base、interpreter.llm.api_key、interpreter.llm.model。 这个前缀不是装饰。Open Interpreter 跑在 litellm 上,litellm 靠模型字符串决定用哪个供应商客户端,这正是 openai/ 前缀这么关键的原因:openai/claude-sonnet-4-6 的意思是"按 api_base 指定的地址,用 chat-completions 协议说话,模型字段填 claude-sonnet-4-6"。丢掉前缀,litellm 会按裸名字推断供应商,把一个 claude-* 的 ID 推去 Anthropic 的客户端,忽略你配置的端点。

export OPENAI_API_KEY=sk-你的kkaiapi密钥

interpreter \
  --api_base https://api.kkaiapi.com/v1 \
  --model openai/claude-sonnet-4-6

Open Interpreter 拿模型做什么

Open Interpreter(GitHub 上的 openinterpreter,约 6.6 万星标)给一个语言模型配了个能在你机器上跑的代码解释器:你用自然语言说一个目标,模型写 Python 或 shell,Open Interpreter 在本地执行,输出结果反馈回对话,进入下一步。这个循环让它和聊天客户端本质不同。模型产出的不是文字,而是以你用户的权限运行的代码,它是对着你真实系统的真实报错去迭代的。 这带来两个和路由相关的结果。第一,模型质量直接等同于安全和正确性属性:一个瞎编参数或读错报错栈的模型会产生另一轮失败的往返,自动执行模式下更是一轮你没审阅过的失败。第二,这个循环以一种特定方式吃 token:每一轮都会重发不断增长的对话、代码和捕获的输出,长时间的调试会话会很快把上下文撑起来。 api_base 设置把整个循环挪到一个端点上。因为模型字段在加了 openai/ 前缀之后按纯字符串传递,一个 Claude ID、一个 GPT ID、一个 DeepSeek ID 是一个参数就能换的选择,不是各自独立的供应商配置。

完整配置:Python API 与 profile

Python 路径在 interpreter.llm 上设同样三个值,再加上 litellm 没法替一个自定义 ID 推断出来的两个设置:context_window 和 max_tokens。Open Interpreter 用 context_window 决定保留多少对话历史再开始裁剪,不设置或用默认值放在一个 200k 模型上,裁剪的时机会比该发生的时候早得多;把模型真实支持的数值声明出来。 对一份持久化的配置,同样的键可以放进一份 profile YAML,写在 llm: 块下(用 interpreter --profiles 打开 profile 目录)。profile 能把端点、模型、窗口这些设置留在你的 shell 历史之外,在不同机器上也能复用同一份配置,Key 仍然由环境变量提供。

import os
from interpreter import interpreter

interpreter.llm.api_base = "https://api.kkaiapi.com/v1"
interpreter.llm.api_key = os.environ["KKAIAPI_KEY"]
interpreter.llm.model = "openai/claude-sonnet-4-6"

# litellm 没法替一个自定义 ID 推断这些值,需要显式声明:
interpreter.llm.context_window = 200000
interpreter.llm.max_tokens = 8192
interpreter.llm.supports_functions = True

interpreter.chat("读一下 data.csv,按营收画出前十行的图")

给写代码的模型选型

模型比较在这里格外具体:给两个模型同一个任务,数到跑出可用结果需要几个往返。按 Key 的用量视图会加上每次会话的 token 成本,和往返次数一起就是完整的比较。经一个端点,每个候选只是一个参数。

• 主循环需要一个能写出可运行代码、能一遍读懂报错栈的模型;claude-sonnet-4-6 和 gpt-5.5 是可靠的中间档,一个更好的模型避免掉的每一次失败往返,都是省下的 token 和实际时间
• deepseek-v4-pro 是代码密集会话里值得一试的候选,经一个端点,在你自己的任务上试一遍只是改一次 --model
• 快速的一次性任务(改文件名、一次性转换、格式转换)不需要旗舰推理,claude-haiku-4-5-20251001 或 glm-5.2 能让它们又快又便宜
• 自动执行模式(-y)去掉了代码生成和执行之间的人工审阅环节。如果要用它,只用在你正在跑的最强模型上,而且要在沙箱或容器里,绝不用在还在评估的模型上

主力模型价格

价格按 kkaiapi 中文区实时价格计算,单位 ¥/1M tokens(输入/输出)。

Open Interpreter 专属的翻车点

裸模型 ID 会绕开你的端点。没有 openai/ 前缀,litellm 会按名字推断供应商:claude-* 的 ID 会跑向 Anthropic 的客户端,结果是对着一个你从没配置过的主机报鉴权或路由错误。如果报错提到的是某个厂商 SDK 而不是你的网关,说明前缀漏了。 默认的上下文假设会裁剪你的会话。对一个 litellm 不认识的 ID,没有任何东西会替它填上下文窗口;Open Interpreter 会退回保守行为,提早裁剪历史。显式声明 context_window,因为一个代码调试会话丢掉早期尝试,会重蹈同样的错误。 会话越长,账单越涨。每一轮都会重发对话加代码加捕获的输出。一个把很大的 dataframe 或很长的日志粘进循环的会话,会在后续每一次请求里都带着它。优先让模型写代码去检查文件,而不是把文件内容粘进聊天,任务变了就开一个新会话。 函数调用不匹配。Open Interpreter 在支持的地方会用结构化函数调用;supports_functions 这个开关就是给检测猜错的 ID 用的。如果代码块在一个你知道能力足够的模型上出得乱七八糟,显式设成 True;如果一个模型确实不支持工具,设成 False 让回退路径生效。 执行这一侧是你自己的责任。api_base 只是挪动了模型流量,生成的代码仍然以你的权限在本地运行。网关不会给任何东西加沙箱,所以自动执行模式要限定在容器里,其它地方都保留安全审阅这一环。

哪些人会把 Open Interpreter 接到一个网关上

• 把 Open Interpreter 当日常自动化工具的开发者,想要 Claude 级别的代码生成、GPT 的多样性、快速 ID 处理一次性任务,全在一个 Key 下
• 跑探索性分析循环的数据从业者,一个会话可能意外吃掉不少上下文,按 Key 用量能把每个笔记本级任务的成本看清楚
• 在"跑到可用结果的往返次数"这个最诚实的指标上比较写代码模型的工程师,每个候选一个 --model 参数
• 跑定时或容器化 interpreter 任务的爱好者,一个环境变量端点加一个密钥,比一套按厂商的凭证更省事
• 手头没有某家厂商官方支付渠道的开发者,充值即用不需要海外卡

验证接入与排查首次会话

先列出网关的模型;openai/ 后面的 ID 必须和提供的某个 ID 精确匹配,版本后缀也算。 首次会话的失败很有规律。报错提到 anthropic 或别的厂商 SDK,说明漏了 openai/ 前缀,litellm 按名字做了路由。401 意味着启动 interpreter 的 shell 看不到 Key,或者设成了别的变量;有了前缀,OPENAI_API_KEY 或显式的 api_key 都能用。模型不存在的报错是 ID 拼错了。连接错误通常意味着 api_base 漏了 /v1 后缀;客户端会在你给的 base 后面拼接 /chat/completions。 循环跑起来之后,kkaiapi 控制台会显示每次请求的模型、token 数和花费。interpreter 会话是那种感觉小、账单却是中等的典型负载,用量视图能看清到底是哪些会话真正扛走了 token。

curl -s https://api.kkaiapi.com/v1/models \
  -H "Authorization: Bearer $KKAIAPI_KEY" | head -50

常见问题