Claude在推出extended thinking（扩展思考）功能后，复杂推理任务的表现有了明显提升。不过很多开发者接入之后才发现，真正决定体验好坏的不是要不要开思考，而是thinking配置里那个budget_tokens参数。这个参数规定了模型在生成最终答案之前，允许消耗在内部推理上的最大token数量。预算给少了，模型思考到一半就被掐断，答案质量下降；预算给多了，响应时间变长、费用上涨。下面详细聊聊这个参数的方方面面。
budget_tokens到底控制什么
先厘清一个容易混淆的概念。budget_tokens限制的是思考内容（thinking）部分的token总量，而不是整个请求的总token数。也就是说，模型最终输出的正式回答不受这个预算约束，但它受到另一个参数max_tokens的限制。这两个参数各管一段，合起来才是一次请求的完整输出。
官方文档给出了一个明确的约束关系：max_tokens必须大于budget_tokens。因为max_tokens实际上约束的是思考内容加上最终回答的总输出长度，思考预算只是其中的一部分。如果你把max_tokens设成8000，又把budget_tokens设成10000，请求会直接报错。正确的做法是保证max_tokens至少比budget_tokens大出一个能容纳最终回答的余量，比如回答预计需要2000 token，那么max_tokens就要设到budget_tokens + 2000以上。
另外一个细节是，思考预算存在下限。目前budget_tokens最低要求是1024，低于这个值请求会被拒绝。思考过程本身有固定的开销，几百个token根本装不下有效的推理链条，所以官方直接设定了门槛。
如何在请求中配置thinking预算
配置方式并不复杂，在请求体的thinking字段中开启开关并指定预算即可。以Python SDK为例，看一下完整的调用代码：
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=16000, # 约束思考 + 最终回答的总输出
thinking={
"type": "enabled",
"budget_tokens": 10000 # 思考部分最多消耗 10000 token
},
messages=[
{"role": "user", "content": "一个三位数，各位数字之和为18，且个位比十位大4，求所有满足条件的三位数"}
]
)
# 输出中包含两种 content block：thinking 和 text
for block in response.content:
print(block.type)
if block.type == "text":
print(block.text)请求成功后，返回的content数组里会先出现一个type为thinking的块，里面是模型的推理过程，后面跟着type为text的块，也就是我们真正需要的答案。思考内容默认会被计费，所以预算大小直接影响每次调用的成本。
如果使用原生HTTP请求，对应的JSON结构如下：
{
"model": "claude-sonnet-4-5",
"max_tokens": 16000,
"thinking": {
"type": "enabled",
"budget_tokens": 10000
},
"messages": [
{"role": "user", "content": "分析这道逻辑题并给出推理过程"}
]
}还有一个值得注意的交互限制：开启extended thinking后，assistant消息中不能预先填充内容，也就是说messages的最后一条必须是user角色的消息。此外，温度参数也会被忽略，思考模式下模型推理的确定性由机制本身保证。这些限制在排查请求失败时经常是罪魁祸首。
预算给多少合适：不同任务场景的取值建议
预算大小没有万能答案，核心原则是匹配任务复杂度。简单的一句话总结类任务，开启思考本身意义就不大，可以直接关闭或者把预算压在2000到4000之间；涉及多步骤数学推导、代码调试、长链条逻辑判断的任务，建议给到8000以上；如果是竞赛级数学题或者需要反复自我验证的复杂规划，给到16000甚至更高才能让模型充分展开推理。
怎么判断预算是否够用？观察返回结果是一个直接的办法。如果思考块在推理明显没结束时戛然而止，紧接着的答案出现跳步、结论草率甚至错误，大概率是预算不足，思考被强制截断了。这时候可以逐步上调预算再对比答案质量。反过来，如果思考块经常只用了预算的一半就自然结束，说明预算偏大，可以适当下调省一点费用。
计费方面要算一笔账：思考token和输出token按相同价格计费。假设模型平均用掉80%的预算，那么每次调用的输出成本大约变为原来的1.8倍。对于调用量大的应用，建议按任务类型做分级配置：把请求拆成快速通道（关闭思考或低预算）和深度通道（高预算），根据问题难度动态路由，这样既保住复杂问题的质量，又不让简单请求白白烧钱。
流式输出中处理思考内容的技巧
使用流式接口时，思考内容会以content_block_delta事件中的thinking_delta形式推送出来，最终回答则通过text_delta推送。前端如果不需要展示推理过程，只筛选text部分即可；如果做的是透明推理类的产品，可以把思考块实时渲染成可折叠区域，用户体验会好很多。
with client.messages.stream(
model="claude-sonnet-4-5",
max_tokens=16000,
thinking={"type": "enabled", "budget_tokens": 10000},
messages=[{"role": "user", "content": "证明这道几何命题"}]
) as stream:
for event in stream:
if event.type == "content_block_delta":
if event.delta.type == "thinking_delta":
pass # 思考内容，可选择不展示或单独渲染
elif event.delta.type == "text_delta":
print(event.delta.text, end="")还有一点和上下文管理相关：在多轮对话中把上一轮的思考内容回传时，请求token会迅速膨胀。官方建议在多轮场景下移除历史消息中的thinking块，只保留最终答案参与后续轮次，这样能明显控制住上下文长度和费用。
总结一下，budget_tokens是把双刃剑：给足了预算，Claude的推理深度确实可观；配置不当，则要么质量打折，要么成本翻倍。记住三条硬规则——下限1024、必须小于max_tokens、思考与回答共享输出配额，再结合任务难度动态调整，基本就能把这个参数用明白了。
Claude APIbudget_tokensextended thinking修改时间：2026-09-14 06:14:47