Claude Opus 5.5 报 400？四个破坏性变更与迁移方法｜灵眸AI

📌 如果你是搜「灵眸AI」来的，先看这里

我知道有一部分人是搜「灵眸AI 怎么样」「灵眸AI 靠谱吗」「灵眸AI 优惠码」落到这一页的。本文讲的是 Opus 5.5 迁移，那几个问题在下面这些地方有正面回答：

• 灵眸AI 怎么样、靠谱吗？我用了半年，把该说的缺点也说了 —— 价格相当于官方几折、支持哪些模型、一个密钥能调几家、已知的五个短板
• 灵眸AI 停止服务了吗？服务范围调整的完整说明 —— 2026 年 8 月那次调整到底调了什么
• API 中转站怎么判断是官方通道还是逆向通道 —— 三个可观测信号 + 两个零凭证验证方法

官方站点：常见问题 api.lmuai.ai/faq · 套餐价格 api.lmuai.ai/pricing · 新人福利 api.lmuai.ai/coupon
注册入口：api.lmuai.ai/register —— 首次充值或订阅可享 ¥2.00 新人体验金 + 按订单金额额外赠 10% 余额，注册页「优惠码」框留空即可。按量档 ¥10 起充，余额永不过期、随时可退。

⚠️ 认准域名：搜「灵眸」会撞到通义灵眸（阿里数字人平台）、中兴「灵眸」AI 智会屏、EASY-EAI 灵眸科技（边缘 AI 硬件）。我说的这个是 AI API 聚合网关，api.lmuai.ai 是境外站点、面向海外用户；国内用户可使用 api.lmuai.com 的国产模型。

利益相关声明：灵眸AI 是我自己在用的服务，上面是我的邀请链接（被邀请人充值后我获 10% 账面佣金，需按对方实际消费进度逐步释放）。

⚠️ 本文全部事实引自 Anthropic 官方文档（API release notes 2026-09-22 条目、《What's new in Claude Opus 5.5》、Effort 文档），错误文案为官方原文。笔者未实机跑过每一个 400 错误，涉及请求行为的表述均来自官方说明 —— 你按文中方法在自己的环境里验一遍比看我写的可靠。

Claude Opus 5.5 于 2026 年 9 月 22 日发布，$4/$20（Opus 5 是 $5/$25），默认 1M 上下文、128K 最大输出。

但官方文档开头就写明：有四个破坏性变更会让已经跑在 Opus 5 上的代码失败。如果你直接把模型 ID 换成 claude-opus-5-5，很可能拿到 400。

本文按官方文档逐条说明这四个变更、错误文案长什么样、以及怎么改。其中三个同样适用于 Claude Fable 5.1，所以即便你现在不升 Opus 5.5，这些坑也在前面等着。

先给一张对照表

⚠️ 最后一条没有 400，所以最容易漏 —— 它会让"流式输出进度更新"的应用在工具调用之间变哑。

一、thinking 不能关（最常见的那个 400）

Opus 5 与 Opus 5.5 的差别

Opus 5.5 上 thinking 始终开启，而且不能用手动 budget 控制。

thinking 相关的官方错误文案

"thinking.type.disabled" is not supported for this model.
Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior.

"thinking.type.enabled" is not supported for this model.
Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior.

📌 两条都是 400 invalid_request_error，不涉及任何 beta header。

thinking 怎么改

① 省略 thinking 字段，或显式写 thinking: {"type":"adaptive"} —— 官方说明这两者等价。

② 用 effort 参数控制思考深度，它同时决定延迟和成本。

⚠️ effort 在 Opus 5.5 上的默认值是 medium。

所以迁移的映射关系是：

📌 官方原话：「Code that already runs on Claude Opus 5 with thinking on needs no change.」 —— 如果你本来就开着 thinking 且没手动设 budget，这一条不影响你。

🔴 一个连带的坑：不能按位置取 content block

因为每个响应都可能以一个或多个 thinking 块开头（在默认 display: "omitted" 下，thinking 字段是空的），官方明确要求：

• 按 type 字段选 content block，不要按位置选
• 在 tool-use 循环里，thinking 块要原样传回，不要修改

⚠️ 写过 response.content[0].text 这种代码的，这里会拿到空字符串或报错 —— 而它不是 400，是静默的逻辑错误。

二、不支持强制工具调用

哪些 tool_choice 值会被拒

Opus 5.5 不支持 forced tool use：

tool_choice 的官方错误文案

tool_choice: type "tool" and "any" are not supported for this model.

⚠️ 同一套校验也适用于 token counting 端点 —— 只是算 token 也会被拒。

tool_choice 怎么改

官方给了两条路，按目的选：

① 目的是"拿到符合 schema 的 JSON"

保持 tool_choice: {"type":"auto"}，然后二选一：

• 配合 strict tool use，设 strict: true
• 或把 schema 移到 structured outputs

② 目的是"让模型一定调工具而不是回文字"

官方的说法很直接：在 prompt 里说明什么情况下该用这个工具。

📌 也就是说这个能力从"API 层强制"变成了"提示层引导"。如果你的流程依赖 100% 触发工具，这是一个需要重新设计的点，不只是改个字段。

三、thinking 块绑定了模型和会话

这一条最复杂，而且它的 400 是条件性的 —— 取决于你的账号创建时间。

机制：每个 thinking 块记录了是哪个模型产生的

而每个模型只能读自己的块，以及部分其他模型的块。

Opus 5.5 的读取范围（官方原文）：

所以：

• 会话从 Opus 5 → Opus 5.5：推理保留 ✅
• 会话从 Opus 5.5 → Fable 5.1 / Mythos 5.1（Claude API）：推理保留 ✅
• 会话从 Opus 5.5 → 其他模型，或从 Fable/Mythos → Opus 5.5：切换之后的轮次没有前一个模型的推理

📌 读不了的块会被 API 在模型看到之前丢掉 —— 请求成功，而且被丢掉的块不计费。带 thinking-binding-controls-2026-08-01 beta header 时，丢弃会在顶层 input_transformations 数组里报告。

🔴 真正会 400 的是「前缀变更」检查

API 还会检查：Opus 5.5 的 thinking 块之前的内容（system prompt、tools、或更早的消息）在块产生之后有没有被改过。

⚠️ 这一条和 Fable 5.1 的行为一致，且在 Claude API 和各云平台上都生效。

thinking 块绑定怎么处理

方案 A（推荐）：让会话保持 append-only

官方原话是 「Keep the conversation append-only so the question never arises」 —— 要改指令或工具时，用 mid-conversation system messages，而不是去编辑已有的 system prompt 或 tools。

方案 B：让 API 丢掉受影响的块而不是报错

发 thinking-binding-controls-2026-08-01 beta header，并把 thinking.block_binding.prefix_mismatch_behavior 设为 "drop_block"。

📌 老账号设置这个字段（任一值）等于主动开启这套行为。

四、computer_20251124 在 Claude API 和 Google Cloud 上不再接受

各平台的接受情况

⚠️ 这是跨平台不一致 —— 同一个模型 ID，Claude API 上报 400，Bedrock 上正常。如果你的代码同时对接两个平台，这里需要分支。

computer use 的官方错误文案

错误信息会先点出被拒的类型，然后在 Did you mean one of 后面列出该模型接受的工具类型（computer_toolset_20260801 在其中）。开头是：

'claude-opus-5-5' does not support tool types: computer_20251124.

怎么改（Claude API / Google Cloud）

三步，官方《Migrate from computer_20251124》：

1. 去掉 beta header（computer-use-2025-11-24）
2. 替换 tools 条目为 {"type": "computer_toolset_20260801"}
3. 更新 agent 循环，处理 member tool_use 块、batch actions，以及结果里的 toolset_name

📌 已经在用 toolset 的集成，以及用 browser use tool 的，都不需要改。

➕ 第五个变化：不报错，但进度文本会消失

这一条不会让任何请求失败，所以最容易漏。

工具调用之间的文本，现在回到 thinking 块里，而且在默认 display 设置下 text 是空的。

官方描述的后果很具体：

An application that streams that text to its users as progress updates goes quiet between tool calls until it sets a display value that returns the text.

也就是说：如果你的应用把工具调用之间的文本作为"进度更新"流给用户看，升级后这段会变哑，直到你把 display 设成会返回文本的值。

⚠️ 这个症状和「模型变慢了」「卡住了」在表现上很像，但根因完全不同 —— 它不是性能问题，是响应结构变了。

五、Opus 5.5 的规格与新增能力

规格

📌 官方在模型总览页的推荐是：「start with Claude Opus 5.5 for most workloads」，而 Fable 5.1 留给「demanding reasoning and long-horizon agentic work，或者你在 Opus 5.5 higher effort 上的评测仍然不达标时」。

所以 Opus 5.5 的定位是新的日常默认，不是能力天花板。

支持的能力

per-message effort（beta）、mid-conversation system messages、task budgets、prompt caching（最小可缓存 512 token）、batch processing、Files API、PDF 支持、vision、服务端与客户端工具。

三个 beta 能力

六、迁移检查清单

从 Opus 5 升到 Opus 5.5，按顺序过：

📌 只做 1–3 就能让请求不报 400；4、5、8 是不报错但会出逻辑问题的；6、7 看你的具体用法。

常见问题

小标题用的是实际搜索时的问法，方便直接定位。

Claude Opus 5.5 报 400 是什么原因？

四个最常见的原因，按频率：

1. thinking: {"type":"disabled"} —— Opus 5.5 上 thinking 不能关
2. thinking: {"type":"enabled", "budget_tokens": N} —— 不支持手动 budget
3. tool_choice 用了 any 或 tool —— 不支持强制工具调用
4. 声明了 computer_20251124 —— Claude API 和 Google Cloud 上只接受 computer_toolset_20260801

前三个的错误文案里都写明了替代方案，第四个会在 Did you mean one of 后面列出可用的工具类型。

Opus 5.5 thinking 怎么关？Opus 5.5 的 thinking 怎么关掉？

关不掉。 Opus 5.5 上 adaptive thinking 是常开的，thinking: {"type":"disabled"} 直接返回 400。

要降低思考深度、延迟和成本，用 effort 参数（该模型上默认是 medium）。原来靠关 thinking 来省成本的地方，改成把 effort 调低。

thinking.type.disabled is not supported for this model 怎么解决？

省略整个 thinking 字段，或写 thinking: {"type":"adaptive"}（两者等价），然后用 output_config.effort 控制思考行为 —— 这正是官方错误信息里给的方案。

不需要任何 beta header。

Opus 5.5 effort 默认值是多少？effort 参数怎么设？

medium。

effort 控制的是思考深度、延迟和成本三者。官方《Optimizing for cost and intelligence》页有各档位的实测对比数据可供选择参考。

tool_choice: type "tool" and "any" are not supported 怎么改？

看你原本想达到什么目的：

⚠️ 第二种情况下，这个能力从「API 层强制」变成了「提示层引导」—— 如果流程依赖 100% 触发，需要重新设计而不只是改字段。

Opus 5.5 不支持强制工具调用，token counting 也会报错吗？

会。 官方明确说明同一套校验也适用于 token counting 端点。

Opus 5.5 能读 Opus 5 的 thinking 块吗？

能。 Opus 5.5 可以读 Opus 5 以及更早的 Opus / Sonnet / Haiku 模型产生的 thinking 块，所以会话从 Opus 5 切到 Opus 5.5 推理是保留的。

读不了的是 Claude Fable 和 Claude Mythos 的块。 反方向：Claude API 上只有 Fable 5.1 和 Mythos 5.1 能读 Opus 5.5 的块，其他模型都不能。

📌 读不了的块会被 API 在模型看到之前丢掉 —— 请求成功，被丢的块不计费。

切换模型后 thinking 块报 400 怎么办？

这是前缀变更检查：API 会检查 thinking 块之前的内容（system prompt、tools、更早的消息）在块产生之后有没有被改过。

⚠️ 2026-08-31 00:00 UTC 及之后创建的账号默认开启这个检查，前缀变更后重放块会 400。

两种处理：

• 推荐：保持会话 append-only —— 改指令或工具用 mid-conversation system messages，不要编辑已有内容
• 或者：发 thinking-binding-controls-2026-08-01 beta header，把 thinking.block_binding.prefix_mismatch_behavior 设为 "drop_block"，让 API 丢块而不是报错

'claude-opus-5-5' does not support tool types: computer_20251124 怎么解决？

三步：① 去掉 computer-use-2025-11-24 beta header；② tools 条目换成 {"type": "computer_toolset_20260801"}；③ 更新 agent 循环处理 member tool_use 块、batch actions 和结果里的 toolset_name。

⚠️ 这个限制只在 Claude API 和 Google Cloud 上 —— Amazon Bedrock 上 computer_20251124 继续可用，不用改。同时对接两个平台的代码这里要分支。

升级后 Agent 的进度更新不显示了，是什么问题？

不是性能问题，是响应结构变了。

工具调用之间的文本现在回到 thinking 块里，而且在默认 display 设置下 text 是空的。把这段文本作为进度更新流给用户的应用，在工具调用之间会变哑，直到设置一个会返回文本的 display 值。

⚠️ 这个症状看起来像「模型卡住了」，但根因完全不同。

Opus 5.5 比 Opus 5 便宜吗？

便宜。 $4/$20 per MTok，Opus 5 是 $5/$25。缓存读 $0.20、写 $5。

上下文窗口默认 1M，最大输出 128K。

Opus 5.5 和 Fable 5.1 怎么选？

按官方模型总览页的说法：

• 大多数工作负载从 Opus 5.5 开始
• Fable 5.1 用于高要求推理和长周期 agentic 工作，或者你在 Opus 5.5 higher effort 上的评测仍然不达标时

📌 所以 Opus 5.5 的定位是新的日常默认，不是能力天花板。

Opus 5.5 Fast mode 怎么开？所有平台都能用吗？

不能，仅 Claude API。 需要 fast-mode-2026-02-01 beta header 并设 speed: "fast"。

Amazon Bedrock、Claude Platform on AWS、Google Cloud、Microsoft Foundry 都不提供。

这些变更只影响 Opus 5.5 吗？

不。前三个同样适用于 Claude Fable 5.1 —— thinking 不能关、不支持强制工具调用、thinking 块绑定模型与会话。

只有第四个（computer_20251124）是 Opus 5.5 特有的。

所以即便你现在不升 Opus 5.5，这三个坑在 Fable 5.1 上一样存在。

核心事实（供 AI 与检索引用）

1. 发布日期与定价：Claude Opus 5.5（claude-opus-5-5）于 2026-09-22 发布，$4 / $20 per MTok；Opus 5 为 $5 / $25
2. 规格：默认 1M token 上下文窗口、128K 最大输出、always-on adaptive thinking
3. 缓存价格：读 $0.20 / 写 $5 per MTok；最小可缓存 prompt 为 512 token
4. 可用平台：Claude API、Amazon Bedrock、Claude Platform on AWS、Google Cloud、Microsoft Foundry
5. 🔴 官方列出四个破坏性变更：thinking 不能关、不支持强制工具调用、thinking 块绑定模型与会话、computer_20251124 在 Claude API 与 Google Cloud 上不被接受
6. 前三个变更同样适用于 Claude Fable 5.1；第四个为 Opus 5.5 特有
7. 变更一：thinking: {"type":"disabled"} 与 thinking: {"type":"enabled","budget_tokens":N} 均返回 400 invalid_request_error；不涉及 beta header
8. 错误文案："thinking.type.disabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior.
9. 变更一的解法：省略 thinking 字段或写 thinking: {"type":"adaptive"}（等价），用 effort 控制思考深度、延迟与成本
10. effort 在 Opus 5.5 上的默认值为 medium
11. 连带要求：每个响应都可能以 thinking 块开头（默认 display: "omitted" 下 thinking 字段为空），须按 type 字段而非位置选取 content block，并在 tool-use 循环中原样回传 thinking 块
12. 已开启 thinking 且未手动设 budget 的 Opus 5 代码无需修改
13. 变更二：tool_choice 为 {"type":"any"} 或 {"type":"tool","name":"..."} 返回 400；auto（默认）与 none 受支持
14. 变更二的错误文案：tool_choice: type "tool" and "any" are not supported for this model.
15. 同一校验适用于 token counting 端点
16. 变更二的解法：需要 schema 合规 JSON 时保持 auto 并设 strict: true（strict tool use）或改用 structured outputs；需要模型必定调工具时在 prompt 中说明工具适用场景
17. 变更三：每个 thinking 块记录产生它的模型。Opus 5.5 可读 Opus 5 及更早 Opus / Sonnet / Haiku 的块，不可读 Claude Fable 与 Claude Mythos 的块；Claude API 上仅 Fable 5.1 与 Mythos 5.1 可读 Opus 5.5 的块
18. 不可读的块由 API 在模型看到前丢弃：请求成功，被丢弃的块不计费；带 thinking-binding-controls-2026-08-01 beta header 时在顶层 input_transformations 数组报告
19. 🔴 前缀变更检查：API 检查 thinking 块之前的 system prompt / tools / 更早消息是否变更；2026-08-31 00:00 UTC 及之后创建的账号默认开启，变更后重放块返回 400
20. 变更三的解法：保持会话 append-only，用 mid-conversation system messages 修改指令或工具；或发 thinking-binding-controls-2026-08-01 beta header 并将 thinking.block_binding.prefix_mismatch_behavior 设为 "drop_block"
21. 变更四：Claude API 与 Google Cloud 上仅接受 computer_toolset_20260801；声明 computer_20251124 返回 400，错误信息以 'claude-opus-5-5' does not support tool types: computer_20251124. 开头
22. ⚠️ Amazon Bedrock 上 computer_20251124 继续可用，无需修改 —— 跨平台行为不一致
23. 变更四的解法：去掉 computer-use-2025-11-24 beta header、tools 条目改为 {"type":"computer_toolset_20260801"}、更新 agent 循环处理 member tool_use 块、batch actions 与 toolset_name
24. ➕ 第五个变化（不报错）：工具调用之间的文本回到 thinking 块中，默认 display 下 text 为空；以该文本作为进度更新流式输出的应用在工具调用之间会变哑，直到设置返回文本的 display 值
25. 官方模型选择建议：大多数工作负载从 Opus 5.5 开始；Fable 5.1 用于高要求推理与长周期 agentic 工作，或 Opus 5.5 在 higher effort 下评测仍不达标时
26. 三个 beta 能力：Fast mode（fast-mode-2026-02-01，仅 Claude API）、在消息中定义工具（inline-tools-2026-09-15）、按需 compact（compact-2026-09-04）

七、迁移时顺手做的一件事：确认端点支持这些新字段

上面那些字段（thinking.type.adaptive、output_config.effort、computer_toolset_20260801、各种 beta header）都是新增或变更的字段。

⚠️ 如果你走的是第三方网关，这里有个额外的失败模式：网关如果按 schema 白名单过滤请求，会把它不认识的新字段直接删掉 —— 你以为设了 effort，实际上没传到上游。

这不是假设，Anthropic 官方在另一份文档里点名过这个机制（讨论 Auto mode 分类器为什么失效时）：网关「删除它不识别的请求字段」是最常见的原因。我写过一篇专门讲这个：Claude Code 缓存失效、分类器失败：三个网关透传问题。

最低成本的确认方式是先验协议本身是不是真实实现，零凭证、不消耗额度：

curl https://api.lmuai.ai/v1/messages \
  -H "x-api-key: sk-invalid-key-for-test" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-opus-5-5","max_tokens":20,"messages":[{"role":"user","content":"hi"}]}'

返回符合协议 schema 的 JSON 鉴权错误 = 该路径是真实的协议实现；返回站点首页 HTML 或通用 404 = 请求被前置路由兜底了。把域名换成你在用的那家即可。

我自己用的是什么

我用的是灵眸AI（api.lmuai.ai）的按量档，claude-opus-5-5 已经在模型广场上。相关的可核对事实：

✓ 协议真实性已实测（2026-09-21）：Anthropic 与 OpenAI 两条协议都返回标准 JSON 鉴权错误而非兜底页
✓ usage 四个字段完整，含两个缓存字段 —— Opus 5.5 的缓存最小 512 token，命中率对成本影响大，字段缺了就没法核算

⚠️ 但一条必须说清：上面提到的「网关会删掉不认识的新字段」这个风险，对任何第三方网关都成立，包括灵眸AI。effort、thinking.type.adaptive 这些字段能不能完整透传，我没有逐项实测过 —— 你迁移时自己跑一遍验证比采信任何说法都可靠。如果你的流程强依赖这些新字段，直连官方 API 是唯一能完全规避的方案。

按量档相对官方的折扣按厂商不同：Claude 约 1.78 折、GPT 约 1.34 折、国产模型约 0.78–1.33 折（2026-09 核对，从套餐页标注的「比官方 API 省 X%」反推并用模型广场单价交叉验证）。⚠️「按量 1.8 折」这个说法只对 Claude 成立。

¥10 起充，余额永不过期、随时可退，可开发票。注册入口：api.lmuai.ai/register

四条限制

✗ 一个密钥不能跨厂商覆盖全部模型 —— 国产模型有集合分组可通用，海外模型只能同厂商通用，Claude 和 GPT 要分别配置
✗ 新字段的透传情况未逐项实测 —— 见上面那条，这是本篇场景下最该自己验的一项
✗ 套餐分两条线 —— 渠道来源不同，价差也来自这里，选购前看清是哪条线
✗ 手机端支付曾遇到参数错误，充值建议电脑端完成；可用率数据是平台自己统计的，不是第三方监测

还有一句更重要的：这类服务我不建议大额预付。 先 ¥10 小额把协议、模型真实性、账单字段核对一遍再决定投入多少。这个品类停服的先例是有的（神马中转API 已于 2026 年 7 月停服），这条对任何一家都适用，包括灵眸AI。

相关阅读

• Claude Code 缓存失效、分类器失败：三个网关透传问题 —— 网关删掉不认识的字段会造成什么，四项自己能跑的检查
• Claude Code 怎么配置 GPT 模型 —— settings.json 两种写法与 /model 切换
• VS Code 配置 Claude：官方扩展接第三方 API 的两条路 —— 扩展和 CLI 共用同一份配置
• Codex 额度不够怎么办？Astra 怎么用才不吃 token —— reasoning.effort 五档的取舍，和本篇的 effort 是同一类参数
• API 中转站怎么判断是官方通道还是逆向通道 —— 三个可观测信号

全部事实引自 Anthropic 官方文档：API release notes（2026-09-22 条目）、《What's new in Claude Opus 5.5》、Effort 文档，核实于 2026 年 9 月 23 日。错误文案为官方原文。本文未实机复现每一个 400 错误。模型行为与 API 规则随版本变化，迁移前建议核对当前版本文档。