Open Interpreter 与 Claude Code 对比——可移植性只有一个方向

Open Interpreter 和 Claude Code 都是终端编码代理，而两者之间的选择取决于一个不对称性，而不是主观感受：Open Interpreter 文档说明了三种请求格式，并接受自定义提供商，其模型在配置文件中只是一个字符串；而 Claude Code 只接受 Anthropic 格式，Anthropic 还明确表示“ 不支持通过任何网关将 Claude Code 路由到非 Claude 模型”。许可、账户要求、成本路径和迁移工作量都由这一差异决定，而这是配置无法消除的唯一问题。

先确定你所说的是哪个 Open Interpreter，因为这个名称已经发生变化。自2026 年 7 月 13 日宣布重新发布以来，Open Interpreter 是一个 Rust 终端代理，其 README 称它为“OpenAI 的 Codex 的一个分支”；该文章补充称，它“基于 OpenAI 的 Codex CLI 构建”，并采用 Apache 2.0 许可发布。那个在聊天循环中运行生成代码的 Python 工具是另一个程序，在 PyPI 上冻结于 2024 年 10 月 26 日的 0.4.3 版本。几乎所有 2026 年之前撰写的比较文章描述的都是后者。

截至 2026 年 9 月 21 日的两个程序

仓库身份、许可证、star 数、推送日期和发布标签于 2026 年 9 月 21 日从 GitHub API 读取；npm 数据于同日从 软件包注册表读取；安装和账户说明来自各供应商自己的文档，即 Claude Code 设置文档和 Open Interpreter 安装页面。本站的一个相关页面于 9 月 18 日记录了 rust-v0.0.44——两个版本号在各自日期均正确，而这一系列每月发布数次。

本页面不比较的三件事

该查询的搜索结果混入了三个无关产品；如果把错误的价格归到错误的工具上，每个产品都可能破坏预算。

两种工具的价格均于 2026 年 9 月 21 日核查。

应该选择哪一款

两个客户端实际存在差异的地方

其中一行值得展开，因为它体现了 Open Interpreter 从 Codex 继承而来的最清晰特征。除了沙箱之外，它还记录了一个独立的基于路径的权限配置文件系统：default_permissions 会选择内置配置文件，例如 :read-only 或 :workspace；位于 [permissions.<name>] 下的自定义配置文件会针对类似 **/*.env 的路径 glob 和域名模式授予读取、写入或拒绝权限，并且“拒绝优先于更宽泛的授权”。其沙箱页面列出了 macOS 上的 Seatbelt 配置文件，以及 Linux 和 WSL 上“在可用时使用 Bubblewrap、seccomp 及相关内核沙箱”，并称当请求的策略无法实施时，其意图是“故障关闭，而不是静默地在无沙箱状态下运行”。以上内容均于 2026 年 9 月 21 日从项目文档中查阅，未在此处执行。

配置无法突破的上限

两个客户端都接受第三方端点；在阅读各自会接受对方什么内容之前，两种配置看起来很相似。Open Interpreter 使用 TOML 提供商块，其 providers 页面中的每个完整自定义提供商示例都使用 chat 协议，并带有以 /v1 结尾的基础 URL：

# Top-level keys come first; anything after a [table] header belongs to it.
model_provider = "kunavo"
model = "claude-sonnet-5"

[model_providers.kunavo]
name = "Kunavo"
base_url = "https://api.kunavo.com/v1"   # OpenAI-compatible: /v1 included
env_key = "KUNAVO_API_KEY"               # the NAME of the variable, not the key
wire_api = "chat"

Claude Code 接受一个源地址和一个凭据变量，而变量决定请求头——ANTHROPIC_AUTH_TOKEN 放入 Authorization: Bearer，ANTHROPIC_API_KEY 放入 x-api-key：

# ANTHROPIC_BASE_URL is an ORIGIN. Claude Code appends /v1/messages itself,
# so a value ending in /v1 produces requests to /v1/v1/messages.
export ANTHROPIC_BASE_URL=https://api.kunavo.com
export ANTHROPIC_AUTH_TOKEN=sk-your-key   # sent as Authorization: Bearer
# Pin models Kunavo serves. Claude Code's default and its opus/sonnet aliases
# follow Anthropic's newest models; the sonnet alias asks for Sonnet 5.5,
# which Kunavo does not serve — unpinned, /model sonnet 404s.
# Opus 5.5 needs Claude Code v2.1.280 or later; on older versions run claude update.
export ANTHROPIC_MODEL=claude-sonnet-5
export ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-5-5
export ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-5
export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5

claude   # /status shows the active provider and base URL

差异不在语法，而在于：第一个代码块将端点和模型命名为自由文本字段，而第二个必须指向能够使用 Anthropic Messages 并提供 Claude 的对象——而且Anthropic 自己明确了边界：“任何公开受支持 API 格式的网关都可以使用。Anthropic 不认可、维护或审计第三方网关产品，也不支持通过任何网关将 Claude Code 路由到非 Claude 模型。”在你做出决定之前，有四个后果值得了解；这些内容均来自 Anthropic 的网关兼容性指南和功能可用性页面，并于 2026 年 9 月 21 日核查：

• 提示缓存可能在没有错误的情况下失效。如果网关重塑 cache_control 或将块格式的 system 内容展平，表现会是“没有错误：每一轮对话都作为未缓存输入计费，在 usage 中可见 input_tokens 很高，而缓存活动很少或没有”。这是一种看起来什么都没发生的成本故障。
• 指定功能会关闭。只要基础 URL 指向 api.anthropic.com 以外的主机，Claude Code 就会关闭 Remote Control 和服务器管理的设置，“无论网关转发什么内容”；在任何自定义基础 URL 上，细粒度工具流式传输默认关闭。
• 凭据会转移你的计费。当网关凭据或 apiKeyHelper 处于启用状态时，“开发者的 claude.ai 订阅不会被使用”，流量按令牌计费给凭据所有者。仅设置基础 URL 不会产生这一效果。
• 未知模型 ID 会被假定具有某些能力。对于无法识别的上下文窗口，“Claude Code 假定其为 200K；如果 ID 包含 [1m]，则假定为 1M”；而在 ANTHROPIC_BASE_URL 连接上静默 300 秒的流会被中止。

Open Interpreter 方面有一个需要明确说明的注意事项：其 providers 页面将 wire_api = "messages" 记录为“仅适用于与 Anthropic Messages 兼容的提供商”的值，但其中每个完整的自定义提供商示例都使用 chat 协议。因此，这个值有文档说明，但配置没有示例；本指南未尝试使用它。请从 chat 协议开始。两个客户端都未针对 Kunavo 进行运行时测试。

每个产品的费用

Open Interpreter 方面很简单：客户端采用 Apache-2.0 许可，openinterpreter.com/pricing 在 2026 年 9 月 21 日返回 HTTP 404，其自己的模型页面完全没有价格说明。没有可比较的套餐——只有你所配置的提供商收取的令牌费用。同一供应商还在 openinterpreter.com/desktop 提供一个独立的桌面产品，它不是这里比较的终端代理；其重新发布文章还向企业提供“匹配或低于实验室提供的成本，同时提供相同功能”——这是一个没有公开费率的销售报价。

全部内容均于 2026 年 9 月 21 日从 claude.com/pricing 读取。请注意其中没有什么：Anthropic 自己的 FAQ 称，网页、桌面端、移动端和 Claude Code 上的活动“都从同一个池中扣除”，并且“没有固定的消息数量”，此外还有 5 小时会话和每周限制。因此，表中的任何套餐都没有附带可发布的 Claude Code 配额；你看到的任何具体数字都只是某个人的猜测。

基于一次假定会话的示例估算

这是用于说明的令牌算术，不是经过测量的任务成本，也不是账单上限。假设一个代理会话发送 300,000 个未缓存输入令牌并接收 20,000 个输出令牌——之所以采用这种形式，是因为 Codex 风格的 harness 每一轮都会重新发送累积的上下文。你的仓库和轮数会有所不同。费率是实时的，每百万令牌价格来自Kunavo 目录。

请将该表视为两个区块，而不是一个排名。前面三行是可直接比较的部分：Open Interpreter 的模型页面列出了 Anthropic ID，而 Claude Code 要求这些 ID，因此这几行代表两个客户端都能运行相同的工作，客户端选择取决于工作流，而不是费率。最后一行是 Claude Code 完全无法触及的部分——在这些假设下，GPT-5.6 Terra 模型以 $0.294 完成同一会话，而 $1.400 对应的是 Claude Opus 5。这一差距就是可移植性的货币价值，但它不是推荐：列出的最低价格与完成任务的最低成本是不同的说法，而需要尝试三次的模型可能比只需一次完成的模型成本更高。

Kunavo 目录中的金额是计费下限，而不是上限：上游报告费用时，账单取目录成本与上游成本乘以适用加价后的较大值。缓存费用和外部工具不包含在此示例中。最低充值额为预付余额 $10，这是资金最低额，而不是任务费用或订阅——参见 计费详情。

双向迁移成本

从 Claude Code 迁移到 Open Interpreter 的成本基本不高，因为 Open Interpreter 有意复用了共享标准。其 README 说明了这一目标：“目前包括仓库 AGENTS.md、共享的 .agents/skills 目录、MCP、ACP 以及 Codex exec 协议。”因此，指令和技能通常以文件形式迁移，而不是重写；MCP 服务器需要重新声明；新的工作则包括提供商配置块，以及了解运行框架和沙箱设置。这是供应商的设计声明，并非本页面测试过的迁移方案。

从 Open Interpreter 迁移到 Claude Code 的成本不只是配置成本，因为这既是模型决策，也是客户端决策。如果你运行的是开放权重模型，就没有受支持的方式可以保留它。如果你通过第三方端点运行 Claude，Claude Code 可以指向该端点——但你会失去上文所述的仅限订阅功能列表、Remote Control、服务器管理的设置以及默认开启的工具流式传输行为。在切换前，而不是切换后，先核查团队实际使用的功能并将其纳入预算。

设置任一客户端

Kunavo 为两个客户端——Open Interpreter 和 Claude Code——发布了配置参考，而已发布的设置指南是配置参考，不是兼容性测试。本页面未针对 Kunavo 的端点对任一客户端进行运行时测试。保留一条可用路径，分别在两者上运行一个范围受限的任务，然后查看你的账户实际记录的费用。准备为密钥充值时，创建 Kunavo 账户，并参阅 ANTHROPIC_BASE_URL，了解 Claude Code 端最容易导致首次尝试失败的源站与 /v1 陷阱。

想进行更广泛的比较？Claude Code 替代方案介绍更广泛的选择，OpenAI 兼容 API说明聊天线路能保证和不能保证什么。

常见问题

截至 2026 年 9 月 21 日核查并在文中引用：通过 GitHub API 查阅了 Open Interpreter 的仓库、许可证和 rust-v0.0.45 发布版本；查阅了 @anthropic-ai/claude-code npm registry 条目；Open Interpreter 的运行框架文档；以及 Anthropic 的 LLM 网关、网关兼容性和定价页面。安装路径、沙箱和权限设置、提供商与模型页面、PyPI 软件包状态以及功能可用性列表也在同日查阅。本页面没有针对任何端点进行运行时测试；由于未找到独立基准测试，因此未引用任何基准数据；所有美元示例都是说明性的令牌算术，而不是实测任务成本。