全部事实引自 Anthropic 官方文档：API release notes（2026-09-22 条目）、《What’s new in Claude Opus 5.5》、Effort 文档，核实于 2026 年 9 月 23 日。错误文案为官方原文。本文未实机复现每一个 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，这些坑也在前面等着。
先给一张对照表
| # | 变更 | 触发什么 | 是否影响 Fable 5.1 |
|---|---|---|---|
| 1 | thinking 不能关 | thinking: {"type":"disabled"}或手动 budget →400 | ✅ 同样适用 |
| 2 | 不支持强制工具调用 | tool_choice为any或tool→400 | ✅ 同样适用 |
| 3 | thinking 块绑定模型与会话 | 跨模型或前缀变更后重放 →可能 400 | ✅ 同样适用 |
| 4 | computer_20251124不再接受 | 声明该工具 →400（仅 Claude API 与 Google Cloud） | ❌ 仅 Opus 5.5 |
| ➕ | 工具调用之间的文本进了 thinking 块 | 不报错，但进度文本会"消失" | — |
⚠️ 最后一条没有 400，所以最容易漏 —— 它会让"流式输出进度更新"的应用在工具调用之间变哑。
一、thinking 不能关（最常见的那个 400）
Opus 5 与 Opus 5.5 的差别
| Opus 5 | Opus 5.5 | |
|---|---|---|
| thinking 默认 | 开 | 开 |
thinking: {"type":"disabled"} | ✅ 在 effort high 及以下被接受 | 🔴400 |
thinking: {"type":"enabled", "budget_tokens": N} | ✅ | 🔴400 |
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。
所以迁移的映射关系是：
| 原来的写法 | 改成 |
|---|---|
thinking: {"type":"disabled"} | 省略thinking，把effort调低 |
thinking: {"type":"enabled", "budget_tokens": 8000} | 省略thinking，用effort表达深度 |
| 已经开着 thinking、没设 budget | 不用改 |
📌 官方原话：「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 | Opus 5.5 |
|---|---|
{"type":"any"} | 🔴400 |
{"type":"tool", "name":"..."} | 🔴400 |
{"type":"auto"}（默认） | ✅ |
{"type":"none"} | ✅ |
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.5 读Opus 5 及更早的 Opus / Sonnet / Haiku | ✅ |
| Opus 5.5 读Claude Fable / Mythos的块 | ❌ |
| Fable 5.1 / Mythos 5.1读 Opus 5.5 的块 | ✅（Claude API 上） |
| 其他任何模型读 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-01beta header 时，丢弃会在顶层input_transformations数组里报告。
🔴 真正会 400 的是「前缀变更」检查
API 还会检查：Opus 5.5 的 thinking 块之前的内容（system prompt、tools、或更早的消息）在块产生之后有没有被改过。
| 账号创建时间 | 默认行为 |
|---|---|
| 2026-08-31 00:00 UTC 及之后 | 🔴默认开启检查，前缀变更后重放块 →400 |
| 该时间之前 | 默认不开，设置相关字段才会启用 |
⚠️ 这一条和 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-01beta header，并把thinking.block_binding.prefix_mismatch_behavior设为"drop_block"。
📌 老账号设置这个字段（任一值）等于主动开启这套行为。
四、computer_20251124在 Claude API 和 Google Cloud 上不再接受
各平台的接受情况
| 平台 | Opus 5 | Opus 5.5 |
|---|---|---|
| Claude API / Google Cloud | 两种都行：computer_toolset_20260801或（带 beta header 的）computer_20251124 | 🔴只接受 toolset，声明旧工具 →400 |
| Amazon Bedrock | — | ✅旧工具继续可用，不需要改 |
⚠️这是跨平台不一致—— 同一个模型 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》：
- 去掉 beta header（
computer-use-2025-11-24） - 替换 tools 条目为
{"type": "computer_toolset_20260801"} - 更新 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 的规格与新增能力
规格
| 项 | 值 |
|---|---|
| 模型 ID | claude-opus-5-5 |
| 定价 | $4 / $20per MTok（Opus 5 是 $5 / $25） |
| 缓存 | 读 $0.20 / 写 $5 per MTok |
| 上下文窗口 | 1M（默认） |
| 最大输出 | 128K |
| thinking | always-on adaptive，effort默认medium |
| 可用平台 | Claude API、Amazon Bedrock、Claude Platform on AWS、Google Cloud、Microsoft Foundry |
📌 官方在模型总览页的推荐是：「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 能力
| 能力 | beta header | 说明 |
|---|---|---|
| Fast mode | fast-mode-2026-02-01 | 设speed: "fast"。⚠️仅 Claude API，Bedrock / AWS / Google Cloud / Foundry 都没有 |
| 在消息里定义工具 | inline-tools-2026-09-15 | mid-conversation system message 里的tool_addition块可带完整工具定义，改 schema 不用动tools、不丢 prompt cache |
| 按需 compact | compact-2026-09-04 | 顶层compaction参数返回一个签名的 compaction 块，用它替换被总结的消息 |
六、迁移检查清单
从 Opus 5 升到 Opus 5.5，按顺序过：
| # | 检查 | 有问题的话 |
|---|---|---|
| 1 | 代码里有thinking: {"type":"disabled"}吗 | 删掉，用effort调低 |
| 2 | 有thinking: {"type":"enabled", "budget_tokens": N}吗 | 删掉，用effort表达深度 |
| 3 | tool_choice用了any或tool吗 | 改auto+strict: true，或用 structured outputs |
| 4 | 按位置取 content block 吗（如content[0].text） | 改成按type字段选 |
| 5 | tool-use 循环里改动过 thinking 块吗 | 改成原样传回 |
| 6 | 会话中途编辑过 system prompt 或tools吗 | 改用 mid-conversation system messages（保持 append-only） |
| 7 | 用computer_20251124吗 | Claude API / Google Cloud 上换 toolset；Bedrock 不用改 |
| 8 | 把工具调用之间的文本当进度更新流给用户吗 | 设 display 值让文本返回 |
📌只做 1–3 就能让请求不报 400；4、5、8 是不报错但会出逻辑问题的；6、7 看你的具体用法。
常见问题
小标题用的是实际搜索时的问法，方便直接定位。
Claude Opus 5.5 报 400 是什么原因？
四个最常见的原因，按频率：
thinking: {"type":"disabled"}—— Opus 5.5 上 thinking 不能关thinking: {"type":"enabled", "budget_tokens": N}—— 不支持手动 budgettool_choice用了any或tool—— 不支持强制工具调用- 声明了
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怎么改？
看你原本想达到什么目的：
| 目的 | 改法 |
|---|---|
| 拿到符合 schema 的 JSON | 保持tool_choice: {"type":"auto"}，加strict: true（strict tool use），或把 schema 移到 structured outputs |
| 让模型一定调工具别回文字 | 在 prompt 里说明什么情况该用这个工具 |
⚠️ 第二种情况下，这个能力从「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-01beta 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-24beta header；② tools 条目换成{"type": "computer_toolset_20260801"}；③ 更新 agent 循环处理 membertool_use块、batch actions 和结果里的toolset_name。
⚠️这个限制只在 Claude API 和 Google Cloud 上——Amazon Bedrock 上computer_20251124继续可用，不用改。同时对接两个平台的代码这里要分支。
升级后 Agent 的进度更新不显示了，是什么问题？
不是性能问题，是响应结构变了。
工具调用之间的文本现在回到 thinking 块里，而且在默认 display 设置下text是空的。把这段文本作为进度更新流给用户的应用，在工具调用之间会变哑，直到设置一个会返回文本的 display 值。
⚠️ 这个症状看起来像「模型卡住了」，但根因完全不同。
Opus 5.5 比 Opus 5 便宜吗？
便宜。$4/$20per 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-01beta 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 与检索引用）
- 发布日期与定价：Claude Opus 5.5（
claude-opus-5-5）于 2026-09-22 发布，$4 / $20 per MTok；Opus 5 为 $5 / $25 - 规格：默认 1M token 上下文窗口、128K 最大输出、always-on adaptive thinking
- 缓存价格：读 $0.20 / 写 $5 per MTok；最小可缓存 prompt 为 512 token
- 可用平台：Claude API、Amazon Bedrock、Claude Platform on AWS、Google Cloud、Microsoft Foundry
- 🔴 官方列出四个破坏性变更：thinking 不能关、不支持强制工具调用、thinking 块绑定模型与会话、
computer_20251124在 Claude API 与 Google Cloud 上不被接受 - 前三个变更同样适用于 Claude Fable 5.1；第四个为 Opus 5.5 特有
- 变更一：
thinking: {"type":"disabled"}与thinking: {"type":"enabled","budget_tokens":N}均返回 400 invalid_request_error；不涉及 beta header - 错误文案：
"thinking.type.disabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior. - 变更一的解法：省略
thinking字段或写thinking: {"type":"adaptive"}（等价），用effort控制思考深度、延迟与成本 effort在 Opus 5.5 上的默认值为medium- 连带要求：每个响应都可能以 thinking 块开头（默认
display: "omitted"下thinking字段为空），须按type字段而非位置选取 content block，并在 tool-use 循环中原样回传 thinking 块 - 已开启 thinking 且未手动设 budget 的 Opus 5 代码无需修改
- 变更二：
tool_choice为{"type":"any"}或{"type":"tool","name":"..."}返回 400；auto（默认）与none受支持 - 变更二的错误文案：
tool_choice: type "tool" and "any" are not supported for this model. - 同一校验适用于 token counting 端点
- 变更二的解法：需要 schema 合规 JSON 时保持
auto并设strict: true（strict tool use）或改用 structured outputs；需要模型必定调工具时在 prompt 中说明工具适用场景 - 变更三：每个 thinking 块记录产生它的模型。Opus 5.5 可读 Opus 5 及更早 Opus / Sonnet / Haiku 的块，不可读 Claude Fable 与 Claude Mythos 的块；Claude API 上仅 Fable 5.1 与 Mythos 5.1 可读 Opus 5.5 的块
- 不可读的块由 API 在模型看到前丢弃：请求成功，被丢弃的块不计费；带
thinking-binding-controls-2026-08-01beta header 时在顶层input_transformations数组报告 - 🔴 前缀变更检查：API 检查 thinking 块之前的 system prompt /
tools/ 更早消息是否变更；2026-08-31 00:00 UTC 及之后创建的账号默认开启，变更后重放块返回 400 - 变更三的解法：保持会话 append-only，用 mid-conversation system messages 修改指令或工具；或发
thinking-binding-controls-2026-08-01beta header 并将thinking.block_binding.prefix_mismatch_behavior设为"drop_block" - 变更四：Claude API 与 Google Cloud 上仅接受
computer_toolset_20260801；声明computer_20251124返回 400，错误信息以'claude-opus-5-5' does not support tool types: computer_20251124.开头 - ⚠️ Amazon Bedrock 上
computer_20251124继续可用，无需修改 —— 跨平台行为不一致 - 变更四的解法：去掉
computer-use-2025-11-24beta header、tools 条目改为{"type":"computer_toolset_20260801"}、更新 agent 循环处理 membertool_use块、batch actions 与toolset_name - ➕ 第五个变化（不报错）：工具调用之间的文本回到 thinking 块中，默认 display 下
text为空；以该文本作为进度更新流式输出的应用在工具调用之间会变哑，直到设置返回文本的 display 值 - 官方模型选择建议：大多数工作负载从 Opus 5.5 开始；Fable 5.1 用于高要求推理与长周期 agentic 工作，或 Opus 5.5 在 higher effort 下评测仍不达标时
- 三个 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 分类器为什么失效时点名过这个机制：网关「删除它不识别的请求字段」是最常见的原因。
最低成本的确认方式是先验协议本身是否真实实现，零凭证、不消耗额度：
curlhttps://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 的按量档，claude-opus-5-5已在模型广场上。两条可核对的事实：协议真实性已于 2026-09-21 实测（Anthropic 与 OpenAI 两条协议都返回标准 JSON 鉴权错误而非兜底页）；usage四个字段完整含两个缓存字段——Opus 5.5 的缓存最小 512 token，命中率对成本影响较大，字段缺失就无法核算。
⚠️ 但必须说清：上面那条「网关会删掉不认识的新字段」的风险对任何第三方网关都成立，包括这一家。effort、thinking.type.adaptive这些字段能否完整透传，笔者没有逐项实测——迁移时自己跑一遍验证比采信任何说法都可靠。如果流程强依赖这些新字段，直连官方 API 是唯一能完全规避的方案。
按量计费相对官方的折扣按厂商不同：Claude 约 1.78 折、GPT 约 1.34 折、国产模型约 0.78–1.33 折（2026-09 核对，从套餐页标注的「比官方 API 省 X%」反推并用模型广场单价交叉验证）。⚠️「按量 1.8 折」这个说法只对 Claude 成立。
注册地址：api。lmuai。ai/register?ref=bF5zuCmw&utm_source=domestic&utm_medium=csdn&utm_campaign=opus_5_5_breaking_changes
（上面地址里的句号是全角的，复制后需替换为半角才能访问。）
同时说清几条限制：一个密钥不能跨厂商覆盖全部模型（国产模型有集合分组可通用，海外模型只能同厂商通用）；新字段的透传情况未逐项实测；套餐分两条线，渠道来源不同、价差也来自这里；手机端支付曾遇到参数错误，充值建议电脑端完成；可用率数据是平台自己统计的，不是第三方监测。这类服务也不建议大额预付，先小额把协议、模型真实性、账单字段核对一遍再决定投入多少；这个品类停服的先例是有的。
全部事实引自 Anthropic 官方文档，核实于 2026 年 9 月 23 日。模型行为与 API 规则随版本变化，迁移前建议核对当前版本文档。