我把 OpenRouter 换成了 ofox：0 加价 + 双协议 + Claude Code 直连实测（2026）

上个月我们团队的 API 月账单突破 $400，我拉了一下 OpenRouter 的消费明细，发现光 5.5% 的平台手续费就吃掉了 $22。一开始是拒绝折腾的——OpenRouter 用了快一年，模型切换确实方便。但 $22 一个月、一年 $264，这钱花得有点冤。

TL;DR：同等调用量下，迁移后月账单降了约 $18-22（即省下那笔手续费），Claude Code 通过 Anthropic 原生协议直连bailian/qwen3.8-max的体验比预期好很多，P95 延迟稳定在 280ms 左右（测试环境：香港节点，样本量约 200 次请求，测试时间段为 2026 年 6 月工作日高峰期）。迁移成本？改两行环境变量，十分钟搞定。

发布背景

本文写于 2026 年 6 月。彼时 OpenRouter 依然是最成熟的 LLM 聚合网关——模型覆盖广、社区活跃、文档清晰。但它有两个让我越来越难受的点：

1. 5.5% 手续费：官方明确收取，模型越贵扣得越多。用anthropic/claude-opus-4.8这种旗舰模型时，输出 $75/M 的 5.5% 就是 $4.125/M 的隐性成本
2. 只支持 OpenAI 兼容协议：Claude Code 原生走 Anthropic Messages API，接 OpenRouter 需要套一层转换，extended_thinking、tool_use等参数存在被中间层忽略或转换失真的风险（具体范围因版本而异，建议实测验证）

这两个痛点叠在一起，让我开始认真看替代方案。

核心参数对比表

Benchmark 与能力对比（厂商自报，未经第三方验证）

这张表不是评测 ofox 本身——而是对比我在两个平台上高频使用的模型：

⚠️ 注意：上表中的模型 ID 均为 ofox 平台的写法（provider/model-name格式），以 ofox 后台实际展示为准。其中bailian/qwen3.8-max对应qwen3.8-max，moonshotai/kimi-k3对应kimi-k3，deepseek/deepseek-v4-flash对应deepseek-v4-flash——这些均为平台自定义路由 ID，与各厂商官方文档的命名体系可能存在差异，建议使用前在 ofox 模型列表中确认。

这些 benchmark 分数厂商各报各的，我更看重实际写代码时的手感。

定价分析与成本测算

先看公式：

月账单 = Σ(input_tokens × 输入单价 + output_tokens × 输出单价) × (1 + 平台费率)

OpenRouter 的费率是 1.055，ofox 是 1.0。

我团队 6 月实际用量换算（按公开信息整理）：

⚠️claude-opus-4.8定价（input $15/M、output $75/M）来自 Anthropic 官网公开单价，计算式为 $15×8M + $75×3M = $120 + $225 = $345.0，OpenRouter 含手续费约 $363.98。gpt-5.6-sol和deepseek-v4-flash的单价按各自官方公开信息整理，具体数字请以 ofox 后台和各厂商官方定价页为准。qwen3.8-max的 OpenRouter 报价未找到公开来源，该行仅作定性参考。

换算成人民币大概每月省 ¥130-160（按约 7.2 汇率：$18×7.2≈¥130，$22×7.2≈¥158）。不算多，但一年下来就是 ¥1500+，够续好几个月服务器了。

API 调用实战代码

迁移前（OpenRouter）

from openai import OpenAI client = OpenAI( api_key="sk-or-v1-xxxx", base_url="https://openrouter.ai/api/v1" )

resp = client.chat.completions.create( model="claude-opus-4.8", messages=[{"role": "user", "content": "重构这段代码"}] )

迁移后（ofox，OpenAI 协议）

from openai import OpenAI client = OpenAI( api_key="sk-ofox-xxxx", base_url="https://api.ofox.io/v1" # 如遇连接问题请以 ofox 官方文档最新地址为准 )

⚠️ 注意：https://api.ofox.io/v1为文章写作时 ofox 的 API 端点，如遇连接问题请以 ofox 官方文档中的最新地址为准。

resp = client.chat.completions.create( model="claude-opus-4.8", messages=[{"role": "user", "content": "重构这段代码"}] )

就改了api_key和base_url。模型名格式一样是provider/model-name，零学习成本。

Claude Code 走 Anthropic 原生协议

Claude Code 原生用的是 Anthropic Messages API，不是 OpenAI 格式。在 OpenRouter 上需要绕一层，extended_thinking参数存在被中间层忽略或转换失真的风险。

目标平台支持 Anthropic 原生协议直连，配置方式：

export ANTHROPIC_BASE_URL="https://api.ofox.io" export ANTHROPIC_API_KEY="sk-ofox-xxxx"

然后 Claude Code 里直接用claude-opus-4.8，thinking块完整返回，不再被中间层截断。

还可以用 Anthropic 协议调bailian/qwen3.8-max：

import anthropic client = anthropic.Anthropic( api_key="sk-ofox-xxxx", base_url="https://api.ofox.io" # 如遇连接问题请以 ofox 官方文档最新地址为准 )

msg = client.messages.create( model="qwen3.8-max", max_tokens=4096, messages=[{"role": "user", "content": "用中文解释这段 Rust 代码"}] )

跑通了。一把 Key 同时调 Claude 和 Qwen，协议还能选 Anthropic 原生——这在 OpenRouter 上做不到。

迁移流程图

graph TD A[现有 OpenRouter 代码] --> B{改 base_url} B --> C[api.ofox.io/v1] C --> D{改 api_key} D --> E[sk-ofox-xxxx] E --> F{选协议} F -->|OpenAI 兼容| G[model 字段不变] F -->|Anthropic 原生| H[Claude Code / Cline 直连] F -->|Gemini 原生| I[Gemini SDK 直连] G --> J[完成迁移] H --> J I --> J

整个过程十分钟。最花时间的其实是去目标平台注册账号、生成 Key——代码改动本身不到 2 分钟。

自动 Fallback 实测

6 月 28 号晚上deepseek/deepseek-v4-flash限流了，日志里出现了这个：

HTTP 429: {"error":{"message":"Rate limit exceeded","code":429}}

在 OpenRouter 上碰到这种情况，以前的做法是自己写 retry + fallback 逻辑：

models = ["deepseek/deepseek-v4-flash", "bailian/qwen3.5-flash"] for m in models: try: resp = client.chat.completions.create(model=m, messages=[...]) break except Exception: continue

不过这个 fallback 的具体策略（切到哪个备用通道、是否跨厂商）没有找到公开文档详细说明，属于黑盒。如果对路由策略有强要求，LiteLLM 自托管可能更透明。

竞品横向对比

客观说：OpenRouter 在模型丰富度和社区生态上仍然是第一梯队。如果你只用 OpenAI 协议、不在乎那 5.5%、不需要团队级审计——没必要迁移。不同平台各有侧重，选适合自己场景的就好。

团队成本审计

这是让团队 leader 拍板迁移的真正原因。之前用 OpenRouter，月底对账就是一个总数，分不清哪个同事、哪个项目、哪个模型花了多少。

目标平台的管理后台能按 Model / User / API Key 三个维度拆用量和费用。上月有个同事的 RAG pipeline 误用了claude-opus-4.8跑批量摘要（应该用deepseek-v4-flash），后台直接看到那条 Key 的日消费从 $2 跳到 $15——两分钟定位问题，改了 model 字段就回来了。

OpenRouter 免费版不支持按模型和 Key 拆分费用明细；Portkey 支持类似功能，但需要额外付费。这个对比是我们选择迁移的直接原因之一。

FAQ

Q: 从 OpenRouter 迁移过来要改多少代码？
A: 如果你用的是 OpenAI SDK，改base_url和api_key两个变量就行。模型名格式provider/model-name保持一致。

Q: OpenRouter 的sk-or-v1-格式 Key 能直接用吗？
A: 不能。需要在 ofox 后台重新生成 Key，格式不一样。

Q: Claude Code 配置 Anthropic 协议后，能调非 Anthropic 模型吗？
A: 能。实测用 Anthropic SDK 调了bailian/qwen3.8-max，基础文本对话正常返回。ofox 网关做了协议适配，但thinking、tool_use等 Anthropic 特有字段在跨模型场景下的行为建议实测验证。

Q: 自动 fallback 会切到我不想用的模型吗？
A: 按观察推测，fallback 是同模型多通道切换，不是跨模型切换。但具体策略官方文档没有详细说明，属于黑盒，不能完全确认所有情况都如此。如果对路由策略有强要求，建议选择 LiteLLM 自托管以获得完全可控的路由配置。

Q: OpenRouter 上的HTTP-Referer和X-Title头还需要吗？
A: 不需要了。那是 OpenRouter 特有的追踪字段，ofox.io 不要求这些。

Q: 迁移后遇到 401 报错怎么办？
A: 大概率是 Key 没换。检查环境变量是不是还指向sk-or-v1-开头的旧 Key，换成 ofox 后台生成的新 Key 即可。

Q: 有免费额度吗？
A: ofox 有 Free 套餐和若干免费模型可用，具体额度建议查官方最新页面，数字可能随时调整。

Q: 延迟表现怎么样？
A: 测试环境是香港节点，样本量约 200 次请求，测试时间段为 2026 年 6 月工作日高峰期。claude-opus-4.8P95 首 token 延迟在 280ms 左右，与直连 Anthropic 官方差距在 20-40ms 内，日常使用感知不明显。具体取决于网络环境。

总结

核心操作就两步：把base_url从openrouter.ai/api/v1改成api.ofox.io/v1（以官方文档最新地址为准），把 Key 换掉。

省下的钱不多（每月 ¥130-160），但双协议支持让 Claude Code 的体验好了一截，团队审计让月底对账不再是黑盒。OpenRouter 没有卸载——偶尔要试一些冷门模型（比如meta-llama系列的最新版）还是会回去用，毕竟它模型数量确实最多。

适合迁移的场景：高频调用、在意 5.5% 手续费、需要 Anthropic 原生协议、团队多人共用 Key。如果只是个人偶尔调用，OpenRouter 依然是最省心的选择。