作者注：Codex 和 WorkBuddy 都不是专为 Claude 设计的客户端，报错几乎都出在接入层。本文按「端点、工具往返、思考块」三类，把报错原文和修法一一对上。
我们自己就踩过这个坑。最开始图省事，用 OpenAI 兼容协议调 Claude，也就是把它当成一个 OpenAI 模型来用。简单对话没有问题，但只要开始调用工具就报错，重试也没用。后来把协议换回 Anthropic 原生的 /v1/messages，才跑顺。
先判断你有没有中招：Codex 一启动就报 wire_api 相关错误，或者 WorkBuddy 能正常聊天、一调用工具就 400，又或者回复内容莫名其妙是空的，那基本就是本文说的情况。
- 模型本身没坏，问题出在 接入层有三处对不上：端点、工具往返、思考块。
- 最好修的是第 3 类（思考块与输出预算），只需要在客户端改读取方式和
max_tokens。 - 难度居中的是第 2 类（工具往返），主要靠翻译层或网关来修正。
- 最费劲的是第 1 类（端点），只能换客户端，或者加一层翻译网关。
全文的结论顺序是：原生 Anthropic 协议 > 网关翻译成 anthropic > OpenAI 兼容 chat。今天可以先做一件事：用下文的对照表确认报错属于哪一类。
Codex、WorkBuddy 用 Claude 报错的 3 类原因核心要点
先解释几个术语。Responses、Messages、Chat Completions 可以理解为三种点菜方式：后厨做的菜一样，只是菜单格式不同。Codex 只会用 Responses 点菜，Claude 只接 Messages 和 Chat Completions。thinking 块相当于模型的草稿纸，Anthropic 会校验这张草稿有没有被人改过。
| 类别 | 一句话机制 | 主要由谁修 | 修复难度 |
|---|---|---|---|
| 第 1 类 端点对不上 | Codex 只发 Responses，Claude 不接这种格式 | 换工具或网关 | 最费劲 |
| 第 2 类 工具往返对不上 | 翻译过程中 id、内容块或思考块被改动 | 网关为主 | 中等 |
| 第 3 类 思考块与预算对不上 | 模型每次都会思考，客户端仍按老方式读结果 | 客户端 | 最省力 |
第 1 类：Codex 调用 Claude 时端点对不上
报错长什么样：Error loading config.toml: wire_api = "chat" is no longer supported. How to fix: set wire_api = "responses".
这段话的意思是：配置里 wire_api = "chat" 这种写法已经不再支持，需要改成 responses。
为什么：按 Codex 官方配置参考，wire_api 现在只有 responses 一个取值。过去「把 wire_api 改成 chat 兜底」的做法已经失效，新版 Codex 会在加载配置时直接报错。哪怕这个 provider 根本没被用到，也会连带 codex login status 一起跑不起来。另一边，API易 apiyi.com 上的 Claude 型号只开放 anthropic 和 openai 两种端点，不提供 /v1/responses。两头格式对不上，中间又没有翻译，报错就是必然的。
怎么修：
1. 客户端：打开 ~/.codex/config.toml，按报错提示删除残留的 chat 写法，先让 Codex 能正常启动。
2. 换工具：如果只是想用 Claude 写代码，直接改用 Claude Code，它走的就是原生 Messages。
3. 网关：如果必须留在 Codex，就加一层能把 Responses 翻译成 Messages 的网关。供应商地址优先填 Anthropic 原生端点。
验收标准：codex login status 能正常执行；走网关时，下发一条需要读文件的指令，Codex 能完整完成一次工具调用。
第 2 类：Claude 工具调用往返对不上
报错长什么样：
– tool_use ids were found without tool_result blocks immediately after
– An assistant message with 'tool_calls' must be followed by tool messages...
– thinking or redacted_thinking blocks in the latest assistant message cannot be modified
– Invalid signature in thinking block. The block is bound to a different conversation.
第一条表示有 tool_use 没有紧跟对应的 tool_result。第二条是 Chat 格式下的同类问题。第三条表示上一轮的思考块被改动过。第四条表示思考块签名和当前会话对不上。
为什么：兼容层要把 Claude 的 text、tool_use、tool_result、thinking 这些内容块逐块翻译成 tool_calls 和 role: tool，之后再翻译回来。这个过程中只要 id 对错、内容块被合并、thinking 块被挪动，就会返回 400。Responses 里有 developer 角色，而 Messages 里没有，需要并入 system。另外，claude-opus-5-5 不接受以下老写法：强制 tool_choice（any 或指定工具）、预填 assistant 消息（prefill）、temperature / top_p / top_k。
怎么修：
1. 网关：每个 tool_use 后面紧跟同 id 的 tool_result，并且 tool_result 要放在 user 消息内容块的最前面。
2. 网关：上一轮的 assistant 消息原样回传，thinking 字段为空的块也要带上；developer 内容并入 system。
3. 客户端：tool_choice 只保留 auto 或 none，删掉 prefill 和采样参数。
4. 客户端：如果已经出现签名错误，直接新开会话。按 API易 官方 FAQ 的说明，这类报错有时会被包装成 Request rejected (429)，但它并不是限流，退避重试也没用。
5. 换工具：如果 harness 把强制 tool_choice 写死了，自己改不了，那就换客户端。
同类 400 的排查思路可以参考 Claude Code 报错 400 tool use concurrency，这篇讲的是 tool_use 与 tool_result 配对失败时如何逐条定位。
验收标准：连续多轮工具调用（读文件、改文件、再读文件）不再出现 400，同一会话里也不再出现签名错误。
第 3 类：Claude 思考块与输出预算对不上
报错长什么样："thinking.type.enabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior. 也可能是 "thinking.type.disabled" is not supported for this model. 还有一种情况不报错，但回复是空的或被截断。
为什么：claude-opus-5-5 每次请求都会思考，响应可能以 thinking 块开头。客户端如果按位置读取 content[0].text，就会读到空值。思考 token 按输出计费，也会占用 max_tokens。从这一代开始，工具调用之间的旁白也放进了 thinking 块，而默认 display 是 omitted，所以看起来是空的。
怎么修：
1. 客户端：thinking 参数要么省略，要么写 thinking: {"type": "adaptive"}，并删掉 budget_tokens。
2. 客户端：思考深度改用 output_config.effort 控制，可选 low / medium / high / xhigh / max，默认 medium。
3. 客户端：读取回复时按 type 找 text 块，不要按位置取。
4. 客户端：max_tokens 要同时覆盖思考和正文；想看到旁白内容，就把 thinking.display 设为 summarized。
想彻底理解这套新机制，可以看 解读 Adaptive Thinking 自适应思考，它说明了 budget_tokens 应该怎么迁移到 effort 档位。
验收标准：同一条提示连续发送几次，正文都不为空，也不再出现 thinking.type 相关报错。
Claude 报错原文速查对照表
| 报错原文关键词 | 属于哪类 | 5 分钟自检动作 | 修完还报看哪篇 |
|---|---|---|---|
wire_api = "chat" is no longer supported |
第 1 类 | 检查 config.toml 里有没有残留的 chat 写法 | Magpie 教程 |
tool_use ids were found without tool_result |
第 2 类 | 检查 tool_result 的 id 和位置 | Claude Code 报错 400 tool use concurrency |
must be followed by tool messages |
第 2 类 | 确认是否经过 Chat 兼容层 | Claude Code 报错 400 tool use concurrency |
Invalid signature in thinking block |
第 2 类 | 新开会话再试 | 解读 Adaptive Thinking 自适应思考 |
thinking.type.enabled / 回复为空 |
第 3 类 | 删除 budget_tokens，改为按 type 读取 | 解读 Adaptive Thinking 自适应思考 |
| 简单对话能通，一调用工具就报错 | 第 2 类 | 检查 WorkBuddy 接入协议 | Workbuddy 支持 Claude 原生格式调用吗 |
修复 Codex、WorkBuddy 调用 Claude 报错的两条路线
| 路线 | 适合谁 | 协议优先级 |
|---|---|---|
| A 回到原生客户端 | 只想用 Claude 写代码 | 最高，没有翻译损耗 |
| B 加一层翻译网关 | 必须留在 Codex 或 WorkBuddy | 其次，供应商地址填 anthropic |
| 长期停在 chat 兼容 | 不推荐 | 最低，工具调用和思考块容易出问题 |
路线 A：在 Codex 里想用 Claude，就改用 Claude Code。WorkBuddy 官方的模型配置只有 /chat/completions 和「自定义协议」开关，没有 Anthropic 原生入口，所以在 WorkBuddy 里别指望拿到原生 thinking。具体可以看 Workbuddy 支持 Claude 原生格式调用吗，这篇解释了为什么「对话能通、工具报错」以及能怎么绕过去。
WorkBuddy 直连的配置方法：进入「设置 → 模型 → 自定义」，Base URL 填 https://api.apiyi.com/v1，模型名填 claude-opus-5-5，Key 使用 API易 apiyi.com 令牌页创建的那一把。URL 只写到 /v1，不要自己拼上 /chat/completions。
图注：重点看 URL 是否只写到 /v1、模型名是否为 claude-opus-5-5、「自定义协议」开关是否保持关闭。
路线 B：给 Codex 加网关时，Codex 这边保持 wire_api = "responses" 不变，由网关把请求翻译成 Messages 后转发。WorkBuddy 的自定义模型 URL 指向本地网关，Claude 型号的供应商地址填 Anthropic 原生端点 https://api.apiyi.com。
🎯 技术建议：一个 Key 就能同时验证原生 Messages 和兼容 chat 两种端点。建议先在 API易 apiyi.com 用测试额度对比两种协议下的工具调用效果，再决定走哪条路线。
用 Magpie 给 Codex、WorkBuddy 接 Claude
Magpie 是一个 MIT 协议的社区开源工具，它在本地 127.0.0.1:3425 起一个网关，能在 OpenAI Chat、Responses、Anthropic Messages 之间互相转换，正好补上第 1 类的缺口。除了手动配置，也可以直接可视化在 Magpie 里配置。图形界面填好 API Key 和 Base URL，Codex、WorkBuddy 一起接到同一个网关，不用手改配置文件。完整步骤见 Magpie 教程，里面讲了如何用一个网关统一多个 Agent 的模型来源。
- 供应商页：添加 Key。API易 在「中转」分组里，也可以点「+ 自定义供应商」手动填写。
- Agent 页：Codex、WorkBuddy 分别选择 claude-opus-5-5。
- 新开一个会话，不要沿用旧会话的历史。
图注：重点看供应商是否在「中转」组里显示为可用、Base URL 是否为 Anthropic 原生地址、Agent 页两个开关是否都已打开。
Claude 调用价格与缓存成本
以下价格单位为美元 / 百万 tokens，查于 2026-10-28，型号与价格以平台型号列表为准：
| 型号 | 输入 | 输出 | 缓存读 | 可用平台 |
|---|---|---|---|---|
| claude-opus-5-5 | $4 | $20 | $0.2 | API易 apiyi.com |
| claude-sonnet-5-5 | $2 | $10 | $0.1 | API易 apiyi.com |
| claude-haiku-5-5 | $0.1 | $0.5 | $0.01 | API易 apiyi.com |
Agent 每一轮都会重发完整历史，所以 claude-opus-5-5 的思考 token 按输出价计费。翻译层一旦把 system、tools 或前缀的顺序打乱，cache_control 断点就会失效，成本和延迟会同时上升。如果命中率异常，可以看 Claude 缓存命中率掉到 0（diagnostics），这篇讲了如何定位断点失效的原因。
风险与封号自负
Magpie 等网关属于社区开源工具，不是 API易 的官方组件，我们不做背书，也不提供技术支持。通过这类工具转发请求，可能会被目标服务限流甚至封号，相关后果由使用者自行承担。建议先用测试账号把整条链路跑通，确认没问题后再考虑放到正式账号上。
这几种情况别折腾
如果你只是偶尔在 Codex 里用一次 Claude，或者公司环境不允许安装额外软件，又或者你本来就只需要跑 Claude，那就没必要搭网关。直接换客户端（改用 Claude Code），或者在 Codex 里换成原生支持 Responses 的模型，会省事得多。
常见问题 FAQ
Q1：Codex 官方支持 Claude 吗？
不支持。Codex 只走 Responses，Claude 不提供这种端点，必须经过翻译层才能用。
Q2：在 API易 上的 Claude 能走 /v1/responses 吗？
不能。API易 apiyi.com 上的 Claude 型号只开放 anthropic 和 openai 两种端点。
Q3：报 429 是不是被限流了？
如果报错内容里带 `Invalid signature in thinking block`，那不是限流，而是思考块签名校验失败，新开会话即可。
Q4：WorkBuddy 能用 Anthropic 原生协议吗？
官方配置里没有 Anthropic 原生入口，只能走 OpenAI 兼容路线，或者经过网关转换。
Q5：怎么快速验证修好了？
用 API易 apiyi.com 的测试额度新开一个会话，连续跑几轮工具调用，同时确认正文不为空。
Codex、WorkBuddy 用 Claude 报错自查清单
- Codex 配置里已经没有任何 chat 写法。
- Claude 请求走的是原生协议或翻译成 anthropic 的网关，而不是 chat 兼容。
- 每个 tool_use 都有同 id 的 tool_result 紧随其后。
- 上一轮的 thinking 块原样回传，没有被改动。
- 没有使用强制 tool_choice、prefill 或采样参数。
- 回复按 type 读取，并且
max_tokens已为思考预留空间。
总结
Codex、WorkBuddy 用 Claude 报错，基本都能归入端点、工具往返、思考块这三类。修复顺序是：先改客户端读取方式，再修翻译层，最后考虑换客户端或加网关。协议选择上，能用原生 Anthropic 就用原生，用不了再让网关翻译成 anthropic，不要长期停留在 chat 兼容上。推荐通过 API易 apiyi.com 用同一个 Key 对比不同协议的效果。
📚 参考资料
- Codex 配置参考：wire_api 的取值说明
- 链接：
developers.openai.com/codex/config-reference - 说明：确认 wire_api 当前只支持 responses
- Codex 配置加载报错实例
- 链接：
github.com/openai/codex/issues/41816 - 说明：wire_api 报错的原文出处
- Claude Opus 5.5 迁移指南
- 链接：
platform.claude.com/docs/en/models/opus-5-5/migration-guide - 说明：thinking、tool_choice、采样参数的硬性限制
- Anthropic 工具调用排障
- 链接：
platform.claude.com/docs/en/agents-and-tools/tool-use/troubleshooting-tool-use - 说明：tool_use 与 tool_result 的配对规则
- WorkBuddy 模型配置
- 链接：
www.workbuddy.ai/docs/zh/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Model - 说明：自定义模型入口与自定义协议开关
- Magpie 仓库
- 链接：
github.com/yetone/magpie - 说明：社区开源网关，使用前请自行评估风险
作者：APIYI 技术团队
技术交流：欢迎在 API易 apiyi.com 首页联系我们，更多资料可访问 docs.apiyi.com 文档中心
