Claude Code 400 thinking type should be enabled or disabled 解决

API Error: 400 thinking type should be enabled or disabled 的意思是：Claude Code 在请求里带了 "thinking": {"type": "adaptive"}，而 ANTHROPIC_BASE_URL 指向的接口（硅基流动、阿里云百炼这类第三方 Anthropic 兼容接口）只接受 enabled 和 disabled 两个值。Key、额度和模型本身都不是原因；升级 Claude Code 或换了模型名之后才开始报错，也是这个原因。

最快的恢复办法：在 ~/.claude/settings.json 的 env 里加上 "CLAUDE_CODE_DISABLE_THINKING": "1"，然后重启 Claude Code。请求从此不再带 thinking 字段，不管模型名是 GLM、DeepSeek、Qwen 还是 Claude 都有效。流传最广的 CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 只对 Opus 4.6 和 Sonnet 4.6 这两个模型名生效；模型名是 Pro/zai-org/GLM-5 这类厂商 ID 时，请求里仍是 adaptive，照样 400。

要分清的一点是：“不发送 thinking 字段”不等于“关闭思考”。字段省略后模型还会不会思考，由厂商接口的默认行为决定。想明确保留思考，就得让请求改发 {"type": "enabled", "budget_tokens": N}，后面单独讲做法。

thinking type should be enabled or disabled：接口拒收的是 adaptive

这句报错来自接口，不是 Claude Code 自己的提示。Claude Code 按模型名决定 thinking 字段怎么写：

• 它认得的新 Claude 型号（Sonnet 4.6、Opus 5.5、Haiku 5.5 等），以及它不认识的模型名（GLM、DeepSeek、Qwen 等厂商 ID），默认发送自适应推理："thinking": {"type": "adaptive"}，另带 "output_config": {"effort": "high"} 一类的 effort 参数。
• Sonnet 4.5、Haiku 4.5 这类只支持固定预算的旧型号，发送 {"type": "enabled", "budget_tokens": 31999}。

在 Claude Code 2.1.306 上把模型名设成 Pro/zai-org/GLM-5，发出的请求体里是这样一段：

{
  "model": "Pro/zai-org/GLM-5",
  "thinking": { "type": "adaptive", "display": "omitted" },
  "output_config": { "effort": "high" },
  "max_tokens": 32000
}

同时终端会先打印一行 Claude Code doesn't recognize the model "Pro/zai-org/GLM-5", so it assumes a context window of 200k tokens.，说明它没把这个名字当成任何已知型号。接口回 400 后，Claude Code 会再重试一次，两次都失败才显示 API Error: 400 thinking type should be enabled or disabled。

接口那一侧并不是“不支持思考”。硅基流动的 Anthropic 格式 Messages 接口文档给 thinking.type 列出的值只有 disabled（关闭思维链）和 enabled（必须同时给 budget_tokens），没有 adaptive。阿里云百炼 Coding Plan 的报错写得更直白：Only 'enabled' and 'disabled' are supported for thinking; 'adaptive' is not supported.（见 cc-switch 的 #1173 号 issue，2026 年 2 月 28 日）。所以这些接口支持思考，只是不认 adaptive 这个值。

Claude Code 从哪个版本开始给这类模型名发 adaptive，社区说法不一：#1173 里的用户说 v2.1.62 正常、v2.1.63 开始报错；cc-switch 的 #1489 号 issue 里有人说 2.1.150 正常、2.1.153 出问题。可以确定的是，2026 年 2 月底起，阿里云百炼、硅基流动、商汤等接口的用户陆续报告同一类错误，而当前的 2.1.306 默认仍然这样发送。

先恢复使用：设置 CLAUDE_CODE_DISABLE_THINKING=1

Claude Code 环境变量文档对这个变量的说明是：设为 1 时，请求里完全省略 thinking 参数，这是给拒收该参数的代理和网关准备的兼容选项。

把它写进 ~/.claude/settings.json 已有的 env 对象里。下面的示例里只有最后一行是新增的，其余三项是你原来接第三方接口时就该有的配置；如果文件里已经有 env，不要再写第二个，把这一行并进去：

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.siliconflow.cn",
    "ANTHROPIC_AUTH_TOKEN": "你的 API Key",
    "ANTHROPIC_MODEL": "Pro/zai-org/GLM-5",
    "CLAUDE_CODE_DISABLE_THINKING": "1"
  }
}

值写成字符串 "1"。用 cc-switch 这类工具切换供应商的，把这一项加到该供应商配置的 env 里，否则切换时可能被覆盖。临时试一下也可以在终端里先 export CLAUDE_CODE_DISABLE_THINKING=1 再启动 claude。ANTHROPIC_BASE_URL、Key 和模型名怎么配，见Claude Code API 配置：先选路由，再设置 Key、模型和网关。

改完后完全退出 Claude Code 再重新打开，发一句简单的话。不再出现这条 400 就说明请求已经不带 adaptive 了。如果报错换成了别的内容，说明 thinking 这一关已经过了，要按新的报错原文排查：请求里仍带着 output_config.effort，个别接口可能对这个字段另有限制。

MAX_THINKING_TOKENS=0 在第三方接口上也会省略 thinking，模型名是 GLM 时效果一样。但模型名是 claude-opus-5-5 这类关不掉思考的型号时，0 不起作用，测试里请求仍是 adaptive。所以通用的写法是 CLAUDE_CODE_DISABLE_THINKING=1。

实测矩阵：Claude Code 2.1.306 在各模型名下发出的 thinking

下表来自 2026 年 10 月 21 日的一组测试，共 31 个用例。测试条件：macOS 上的 Claude Code 2.1.306，用 claude -p 非交互运行，每个用例使用独立的配置目录（CLAUDE_CONFIG_DIR），ANTHROPIC_BASE_URL 指向本机一个模拟的 Anthropic 接口。这个模拟接口记录每次请求的 model、thinking 和 output_config，只要 thinking.type 不是 enabled 或 disabled 就返回这条 400，其余请求一律返回正常回复。

它不是硅基流动、阿里云或任何真实厂商的接口。表里的“请求里的 thinking”一列说明的是 Claude Code 实际发出了什么；“结果”一列只代表这个模拟接口的规则，真实厂商对其他字段可能另有限制。

从这张表能读出三条规则：

1. 决定请求怎么写的是模型名，不是厂商。同一个接口，模型名换成 claude-sonnet-4-5 就发 enabled，换成厂商 ID 就发 adaptive。
2. 对厂商模型名，开关类设置只能把 thinking 去掉。CLAUDE_CODE_DISABLE_THINKING=1、MAX_THINKING_TOKENS=0、alwaysThinkingEnabled: false 都是让请求不带这个字段；在这组测试里，能让厂商 ID 带上 enabled 的只有 modelOverrides 映射。
3. CLAUDE_CODE_DISABLE_THINKING=1 优先级最高。它和 alwaysThinkingEnabled: true 同时存在时，请求里仍不带 thinking；模型名是关不掉思考的 Opus 5.5 时它也照样生效。

想在自己的环境里复现，思路很简单：用任意语言起一个本地 HTTP 服务，把收到的 /v1/messages 请求体写进日志，按上面的规则回 400 或正常回复；再用独立的 CLAUDE_CONFIG_DIR、把 ANTHROPIC_BASE_URL 指向 http://localhost:端口，逐个设置变量运行 claude -p "Reply with OK"，看日志里的 thinking 字段。Claude Code 的处理方式会随版本变化，换了大版本值得重跑一遍。

CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING 为什么对 GLM、DeepSeek 无效

官方文档写明了它的适用范围：这个变量只在 Opus 4.6 和 Sonnet 4.6 上关闭自适应推理，退回由 MAX_THINKING_TOKENS 控制的固定思考预算；对 Fable、Sonnet 5 及以后、Haiku 5.5、Opus 4.7 及以后的型号无效，它们始终使用自适应推理（Claude Code 环境变量文档）。

文档没提厂商模型名，但上面的测试给出了答案：Claude Code 把不认识的名字当作“默认用自适应推理”的模型处理，这个变量对它们不生效。这个变量在社区讨论里被当作首选办法推荐过，它在较早版本上是否有效，测试没有覆盖；在 2.1.306 上，它只在模型名就是 claude-sonnet-4-6 或 claude-opus-4-6 时把请求改成 enabled。

另一个看起来对路的办法是用 ANTHROPIC_DEFAULT_SONNET_MODEL_SUPPORTED_CAPABILITIES 声明模型能力，比如只写 thinking、不写 adaptive_thinking。Claude Code 模型配置文档说明，这类 _SUPPORTED_CAPABILITIES 变量在 Amazon Bedrock、Google Cloud Agent Platform、Microsoft Foundry 上生效；ANTHROPIC_BASE_URL 指向网关时，只有 _NAME 和 _DESCRIPTION 生效。测试里三种写法都没有改变请求，与文档一致。

Alt+T、/config 关掉思考为什么也能消掉报错

因为在第三方接口上，关闭思考的效果就是不发送 thinking 字段，和 CLAUDE_CODE_DISABLE_THINKING=1 殊途同归。Claude Code 模型配置文档里的三个开关：

• 当前会话：macOS 按 Option+T，Windows 和 Linux 按 Alt+T。
• 全局默认：运行 /config 切换 thinking mode，保存为 ~/.claude/settings.json 里的 alwaysThinkingEnabled。社区里问“think mode 是哪个字段”，答案就是它。
• 环境变量：MAX_THINKING_TOKENS=0。

测试里 alwaysThinkingEnabled: false 确实让 GLM 模型名的请求不再带 thinking。Option+T/Alt+T 是交互快捷键，非交互测试里没有按过，效果按官方文档描述。

有一个例外。模型名是 Opus 5.5、Sonnet 5.5、Haiku 5.5 或 Fable 时，官方文档写明思考关不掉：开关处显示 Thinking can't be turned off，保存的 alwaysThinkingEnabled: false 和 MAX_THINKING_TOKENS=0 都不起作用。测试里 claude-opus-5-5 在这两种设置下仍发送 adaptive。这对“网关把 sonnet、haiku 映射到旧版 Claude”的用户尤其要注意：2.1.306 里别名 sonnet 解析为 claude-sonnet-5-5，haiku 解析为 claude-haiku-5-5，按快捷键关不掉，只有 CLAUDE_CODE_DISABLE_THINKING=1 能去掉字段。

cc-switch 的 #1489 号 issue 里还有人说“alt+t 关闭再开启好像就可以了”。按官方说明，重新开启后请求会再带上 thinking，这个说法也没有其他报告佐证，不建议当成修法。

想保留思考：让请求改发 enabled 的几种办法

去掉字段能让请求通过，但思考是否还在要看厂商默认。#1489 里有人报告，硅基流动的 Anthropic 接口不传 thinking 时默认开启思考，仍会返回思维链；这是单个用户的观察，其他厂商、其他模型未必如此。如果你需要明确开启思考，按模型名选做法：

用 modelOverrides 让厂商模型名按 Sonnet 4.5 处理

modelOverrides 是 Claude Code 的设置项，作用是把 Anthropic 模型 ID 换成发给接口的另一个字符串；官方文档写明它也作用于 ANTHROPIC_MODEL 传入的 ID（Claude Code 模型配置文档）。Claude Code 判断能力时看的是映射前的 Claude ID，于是会按 Sonnet 4.5 的方式发 enabled，而接口收到的 model 是厂商 ID：

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.siliconflow.cn",
    "ANTHROPIC_AUTH_TOKEN": "你的 API Key",
    "ANTHROPIC_MODEL": "claude-sonnet-4-5-20250929",
    "MAX_THINKING_TOKENS": "8000"
  },
  "modelOverrides": {
    "claude-sonnet-4-5-20250929": "Pro/zai-org/GLM-5"
  }
}

测试里这份配置发出的请求是 "model": "Pro/zai-org/GLM-5"、"thinking": {"type": "enabled", "budget_tokens": 8000}，不带 output_config，也不再打印“不认识模型”的提示。用之前要清楚这几点：

• 映射的键要写带日期的完整 ID。测试里只写 claude-sonnet-4-5 时映射没有生效，发出的 model 仍是 claude-sonnet-4-5。claude-haiku-4-5-20251001 同样可用。
• 映射目标必须是 Claude Code 按 enabled 处理的旧型号。映射到 claude-sonnet-5-5 时，请求照样是 adaptive。
• Claude Code 会把这个模型当成 Sonnet 4.5：请求里不再带 effort 参数，上下文窗口等也按 Sonnet 4.5 处理。
• 不设 MAX_THINKING_TOKENS 时预算是 31999、max_tokens 是 32000。厂商对这两个值有上限时，用 MAX_THINKING_TOKENS 调小预算。DeepSeek 的 Anthropic 接口文档说它支持 thinking，但忽略 budget_tokens（DeepSeek Anthropic API 文档）。
• 这只是用模拟接口验证了 Claude Code 发出的请求，没有在真实厂商接口上跑过；Claude Code 以后若调整对旧型号的处理，这个办法可能失效。

网关改写与降级

cc-switch 的 discussion #5864 里有回复提到，开启它的整流选项后，“此后的请求会把 thinking 强制改写为 enabled”。这是社区报告，测试没有覆盖；用之前看一眼网关日志，确认转发出去的请求里确实是 enabled。

把 Claude Code 降回旧版本也能避开 adaptive，但开始变化的版本号说法不一，降级还会丢掉之后的修复，只适合作为短期应急。

用 curl 确认接口是否接受 adaptive

想确认是不是接口不认 adaptive，而不是 Key、模型名或别的问题，用同一个模型名各发一次 adaptive 和 enabled：

BASE="https://api.siliconflow.cn"   # 与 ANTHROPIC_BASE_URL 相同
KEY="你的 API Key"
MODEL="Pro/zai-org/GLM-5"

# 1. adaptive
curl -s "$BASE/v1/messages" \
  -H "Authorization: Bearer $KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"'"$MODEL"'","max_tokens":2048,"thinking":{"type":"adaptive"},"messages":[{"role":"user","content":"hi"}]}'

# 2. enabled + budget_tokens
curl -s "$BASE/v1/messages" \
  -H "Authorization: Bearer $KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"'"$MODEL"'","max_tokens":2048,"thinking":{"type":"enabled","budget_tokens":1024},"messages":[{"role":"user","content":"hi"}]}'

有的接口用 x-api-key: $KEY 而不是 Authorization: Bearer，按厂商文档换掉 Authorization 那一行。budget_tokens 要小于 max_tokens。

结果这样看：

• 第一条返回这条 400、第二条正常：确认是接口不接受 adaptive，按前面的办法改客户端或网关。
• 两条都正常：接口已经接受 adaptive，问题可能在 Claude Code 和接口之间的路由或代理，检查它们是否改动了请求。
• 两条都报错：先看报错原文，多半是 Key、模型名或地址的问题，与 thinking 无关。

这两条命令是检查方法，没有在真实厂商接口上执行过，返回内容以你的接口为准。

同一类报错的其他写法，以及另一类 thinking 400

下面这些写法和 thinking type should be enabled or disabled 是同一回事：接口或底层模型只认 enabled/disabled，Claude Code 发了 adaptive。处理办法相同。

这些是历史报告，不代表这些厂商今天仍会这样回应。

下面几种也是 thinking 相关的 400，但原因不同，不能套用上面的办法：

• "thinking.type.enabled" is not supported for this model. Use "thinking.type.adaptive"...：方向正好相反，是旧客户端或旧参数撞上了只认 adaptive 的新型号。Bedrock 上的情况见AWS Claude 报 400 怎么办：按报错原文逐条排查。
• 思考块不能被修改、content block is not a thinking block 一类：问题出在对话历史里的思考块，常在压缩或续写时出现，见Claude Code 压缩失败：Error compacting conversation 原因与恢复。
• DeepSeek 的 content[].thinking ... must be passed back：要求把上一轮的思考内容回传，和 thinking.type 的取值无关。DeepSeek 的接入方式见Claude Code 连接 OpenRouter 和 DeepSeek：路线选择、配置与首错排查。DeepSeek 的 Anthropic 接口文档写明支持 thinking 参数（忽略 budget_tokens）。
• 新型号拒收旧采样参数的 400，见Claude Code 报 top_p deprecated？别先换渠道，先按 Opus 4.7 的新请求规则排。

关于 thinking 400 的几个问题

硅基流动是不是不支持思考模式？

支持。它的 Anthropic 格式接口文档列出了 enabled，要求同时给 budget_tokens；它不支持的是 adaptive 这个值。把报错理解成“厂商不支持思考”，会让人误以为只能放弃思考。

设了 CLAUDE_CODE_DISABLE_THINKING 之后还有思维链吗？

不一定。这个变量只是让 Claude Code 不发送 thinking 字段，模型是否思考由厂商默认决定。官方文档也提醒，在默认会思考的模型上，省略参数后模型仍可能思考。要明确开启，用前面 modelOverrides 的办法让请求发 enabled。

关闭思考模式以后，工具调用还是 400 怎么办？

先看新的报错原文。还是 thinking type should be enabled or disabled，说明设置没生效：检查变量是否写进了实际使用的 settings.json、是否被切换工具覆盖、是否重启过。换成了别的文字，就是另一个兼容问题，比如思考块或某个字段不被接受，按那条报错单独排查。

降级到旧版 Claude Code 能解决吗？

能避开，但不推荐长期这样用。开始发送 adaptive 的版本号社区说法不一，从 v2.1.63 到 2.1.153 都有人报告；降级还会丢掉之后的修复和新功能。CLAUDE_CODE_DISABLE_THINKING=1 或 modelOverrides 都能在当前版本上解决，代价更小。