GLM 的思考 token 算不算钱：怎么把它控制住

数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。

结论先说：思考过程要花钱。智谱在深度思考文档的「注意事项」里写得很直白——思考过程会消耗额外的 Token；而费用 FAQ 里的计费口径是「根据您的模型输入和输出的总 token 数进行计费」，并没有为思维链单开一个免费科目。所以问题不是「算不算钱」，而是「能压到什么程度」。官方给了三个层级的控制手段：thinking.type 决定思不思考，reasoning_effort 决定思考到什么深度，clear_thinking 决定历史轮次的思维链要不要继续被塞进上下文重复付输入费。最容易被忽略的是第三个——它影响的不是这一轮的输出，而是后面每一轮的输入。

先搞清楚思考内容出现在响应的哪个位置

深度思考开启后，思维链不会混在正文里。按对话补全接口的字段说明，思维链内容放在 reasoning_content 字段，非流式时挂在 choices[].message.reasoning_content，流式时通过 delta.reasoning_content 逐块推送——官方 Python 示例里就是靠 hasattr(delta, 'reasoning_content') 来判断当前推的是思考还是正文，从而在终端上把「思考中」和「回答」分成两段打印。

再看 usage。接口文档列出的字段是 prompt_tokens（用户输入的 Token 数量）、completion_tokens（输出的 Token 数量）、prompt_tokens_details.cached_tokens（命中的缓存 Token 数量）和 total_tokens。注意这里没有任何一个字段叫「reasoning tokens」。

这就带出一个现实问题：思考消耗的 token 具体被计进了 completion_tokens 的哪一部分、能不能在对话补全接口里单独拆出来看，官方文档里没有找到相关说明。 深度思考页给的响应示例里 usage 也只有上面那几个字段。

这里要补一个容易被搞混的限定：分项字段并非全线都没有，只是不在对话补全这一侧。 问答 Agent 对话（流式）接口的用量对象里除了 prompt_tokens、completion_tokens、total_tokens，还多出 total_calls（工具调用总次数）、prompt_tokens_details.cached_tokens（缓存命中 Token 数），以及 completion_tokens_details.reasoning_tokens，字段说明就是「推理 Token 数」。文档同时注明这份用量信息仅在 done 事件里给出。所以如果你的应用跑在智能体那条链路上，推理 token 是能直接读到分项的。

但这属于另一个端点、另一套用量结构，不能反推回对话补全。也就是说，你在对话补全上想做「思考占比」这类精细归因，目前只能自己在客户端把 reasoning_content 的长度记下来另行统计。这一点在做成本看板时要提前设计好：两条链路的用量字段不是同一套，指标模型如果按其中一条设计，接另一条时要么字段读不到、要么白丢掉现成的分项，上线后再补埋点很麻烦。

第一个开关：thinking.type 决定思不思考

thinking 是一个对象参数，核心参数页给的默认值是 {"type": "enabled"}，支持模型为 GLM-4.5 及以上。取值只有两个：

• enabled：开启思维链
• disabled：关闭思维链，直接给出回答

但「开启」并不等于「每次都会长篇思考」。官方把模型分成了两类行为：GLM-5.2、GLM-5.1、GLM-5、GLM-5-Turbo、GLM-5v-Turbo、GLM-4.6、GLM-4.6V、GLM-4.5 是由模型自动判断是否思考；而 GLM-5.3、GLM-4.7、GLM-4.5V 是强制思考。这个区别对成本的影响很直接：前一类你把参数开着，简单问题模型可能自己就跳过了；后一类你开着就是真的每次都在思考。这份模型清单同样以官方文档当前版本为准，新模型上架或行为调整时会变动，别把它写死在代码注释里当长期依据。

还有一条迁移期的坑，文档里用醒目提示单独标了出来：GLM-5.3 不再支持关闭思考，API 请求中 thinking.type 传 disabled 会直接报错。GLM-5.3 的模型页也给了对应的迁移提示——如果你的应用当前用的是 thinking.type: "disabled"，在把模型 ID 换成 glm-5.3 之前必须先改成 enabled，并把 reasoning_effort 设为 low，否则请求会失败。换句话说，「换个更新的模型顺手降本」这个想法在这里不成立，你只能换成「用最轻的思考档位」。

思考模式页还提到，GLM-5.3、GLM-5.2、GLM-5.1、GLM-5、GLM-4.7 系列默认就是开启 Thinking 的，这一点不同于 GLM-4.6 的默认「混合 thinking（自动开启）」。所以从 GLM-4.6 往上升级时，账单结构发生变化是可以预期的，不是计费出了问题。

第二个开关：reasoning_effort 决定思考多深

reasoning_effort 用来控制开启思维链之后的推理程度，官方明确写了仅 GLM-5.2 及以上支持。低于这个版本的模型你传了也没用，属于白写。

这个参数的取值和映射规则有点绕，而且是分模型、分端点的，值得照着文档核一遍：

• 针对 GLM-5.3：仅支持 max、high、low，其余输入将报错。文档给的档位含义是 low 轻量推理、high 增强推理、max 深度推理，默认 max。
• 针对 GLM-5.2：支持 max、xhigh、high、medium、low、minimal、none。其中 none 或 minimal 代表模型放弃思考；low / medium 会被映射为 high；xhigh 会被映射为 max。
• 在 Coding Plan 请求里，映射规则又不一样：GLM-5.3 下 none、minimal、low 映射为 low，medium、high 映射为 high，xhigh、max 映射为 max。

这里有个反直觉的地方值得单独说：在 GLM-5.2 上，你写 low 想省点思考开销，实际上会被映射成 high。也就是说「我传了个更低的档位所以应该更省」这个推断是不成立的，真正能让 GLM-5.2 放弃思考的取值是 none 或 minimal。这类映射关系在别的地方基本看不到，但直接决定了你的降本操作有没有生效。以上枚举与映射请以官方文档当前版本为准，档位随模型迭代会调整。

第三个开关：clear_thinking 决定历史思维链要不要重复付费

这是最容易被漏掉的一个，因为它不影响单轮输出，只影响多轮对话的输入长度。

先说清楚它挂在哪：clear_thinking 不是顶层参数，而是 thinking 对象的一个属性，和 type 平级。官方示例里的写法是 "thinking": {"type": "enabled", "clear_thinking": False}，前面那两个开关也在同一个对象里。写调用封装时把这个字段的路径固定下来，别照着「第三个开关」这种叙述顺序当成三个并列的顶层参数去传。

对话补全接口对 clear_thinking 的说明是：默认为 True，用于控制是否清除历史对话轮次（previous turns）中的 reasoning_content。文档还单独加了一条注意：该参数只影响跨 turn 的历史 thinking blocks，不改变模型在当前 turn 内是否产生、输出 thinking。这条界线很关键——想让模型这一轮少思考得去动 thinking.type 和 reasoning_effort，clear_thinking 管不着当前轮。

• true（默认）：本次请求会忽略／移除历史 turns 的 reasoning_content，仅用非推理内容（用户/助手可见文本、工具调用与结果等）作为上下文输入。文档说这适用于普通对话与轻量任务，可降低上下文长度与成本。
• false：保留历史 turns 的 reasoning_content 并随上下文一起给模型，也就是官方说的「保留式思考（Preserved Thinking）」。

方向要看明白：默认行为是省钱的，你主动把它关掉才会开始为历史思维链重复付输入费。思考模式页也交代了端点差异——保留式思考在 Coding Plan 端点默认开启、标准 API 端点默认关闭。所以同一段代码从编程套餐端点搬到标准 API 端点，多轮成本结构会变，这不是 bug。

那什么时候值得开？官方给的理由是：保留 reasoning content 有助于保持推理连续性与对话完整性、提升模型表现，并提高缓存命中率，在真实任务中节省更多 tokens。这就绕回了缓存这条线——上下文缓存文档写明缓存命中的 Token 按更低价格计费（具体比例见官方定价页），响应里通过 usage.prompt_tokens_details.cached_tokens 透明显示命中量。换句话说，保留式思考是拿「上下文变长」去换「更高的缓存命中比例」，是不是划算取决于你的对话轮次和前缀稳定性，得看 cached_tokens 的实际变化来判断。想搞清楚命中条件的可以先看 GLM 上下文缓存怎么才能命中 和跨厂商的 API 缓存计费机制。

开启保留式思考有硬性要求，文档用了很强的措辞：必须把完整、未修改的 reasoning content 传回 API，所有连续的 reasoning content 必须与模型在原始请求期间生成的序列完全一致，不要重新排序或修改，否则会降低效果并影响缓存命中。缺失、裁剪、改写或重排都会导致效果下降或无法生效。这里的代价是双份的——既没拿到质量收益，又白付了额外输入费。

工具调用场景：思考 token 会成倍出现

交错式思考（Interleaved thinking）从 GLM-4.5 开始就默认支持，模型可以在工具调用之间、以及收到工具结果之后继续思考，把多次工具调用与推理步骤串联起来。GLM-4.7 的模型页把它描述为「每次回答/工具调用前都会思考」。

对成本的含义很明确：一次 Agent 任务如果调了多次工具，思考就不止发生一次。而思考模式页还有一条强制要求——使用「交错思考 + 工具」时，必须显式保留 Reasoning content，并在返回工具结果时一并返回。官方示例里的做法是把这一轮流式收集到的 reasoning 拼好，连同 content 和 tool_calls 一起 append 进 assistant 消息，再 append tool 消息。也就是说，这个场景下你没有「靠丢弃思维链来省输入费」的选项，它是功能正确性的前提。

真要在这类场景降开销，官方给的路子是 GLM-4.7 引入的轮级思考（Turn-level Thinking）：在同一调用会话中，每一轮请求都可以独立选择开启/关闭思考。文档给的用法是——「问个事实/改个措辞」这类轻量轮次关掉思考追求快速响应，「复杂规划/多约束推理/代码调试」这类重任务轮次再开启；在需要快速执行的工具轮次降低推理开销，在需要综合工具结果做决策的轮次开启深度思考。延迟优化的最佳实践页也是同一个思路：简单分类、固定格式抽取、短文本改写可以关闭或减少不必要的深度思考。

输出长度这条闸门要单独设

max_tokens 限制的是单次调用生成的最大 token 数量，核心参数页特别注明「限制的是生成内容的长度，不包括输入」。各模型的默认值和最大值官方在核心参数页给了一张对照表，用之前回去查当前版本，别照抄任何二手数字。

需要留意的是：max_tokens 是否把 reasoning_content 一并计入，官方文档里没有找到相关说明。 在这个问题明确之前，稳妥的做法是把这个上限当成一道兜底闸门用，而不是当成精确的成本控制刻度。

配合着看 finish_reason，接口文档列的取值里有几个和长度直接相关：length 表示达到 token 长度限制，model_context_window_exceeded 表示超出模型上下文窗口，stop 是自然结束或触发 stop 词。如果你发现账单涨了但业务结果没变好，先去统计一下 length 的占比——被截断的输出照样是已经生成出来的 token。

账单异常时的排查顺序

计费 FAQ 里有几条和思考成本排查直接相关的机制，按这个顺序查效率比较高：

先看消费明细。 官方给的入口是财务总览页面（可看今日消费情况与近几个月的消费统计，具体覆盖范围以页面当前显示为准）、费用账单页面（详细使用记录），需要下载则在导出记录页面点击下载汇总账单。先确认是哪个模型、哪个时间段涨的，再谈参数。

再确认扣减顺序有没有误导你。 平台支持费用扣减和资源包扣减两种方式，扣除时优先扣资源包账户，再扣现金余额账户；存在多个相同适用场景的资源包时，优先扣除最快过期的那个。所以「现金余额没怎么动」不代表没花钱，资源包那头可能已经在掉了。另外欠费状态下仍然可以使用有效期内的资源包，资源包过期后不支持延期、续费、重新激活。

然后查模型版本有没有被人换过。 结合前面说的默认行为差异：从自动判断思考的模型换到强制思考的模型（比如 GLM-4.7、GLM-5.3），即使代码一个字没改，思考 token 的量级也会变。这是升级模型时最常见的账单跳变原因。

最后查是不是把 clear_thinking 关了。 有人为了提升多轮效果把它设成 false，但没同步确认缓存命中是不是真的上去了。判断依据就是 cached_tokens——它没涨而 prompt_tokens 涨了，那就是纯亏。

另外还有一条容易被误解的：API Key 被删除后，该 Key 将无法再次成功调用接口，也不会产生扣费。所以怀疑 Key 泄露导致账单异常时，删除是能立刻止血的。系统性的成本盯盘方法可以参考 API 成本监控怎么做，GLM 侧的整体计费口径见 GLM API 计费说明。

最容易栽的坑

按官方文档梳理下来，真正会让人吃亏的不是「忘了关思考」，而是这三个：

一是以为传了更低的 effort 档位就一定更省。GLM-5.2 上 low 和 medium 都会被映射为 high，你的降本操作在参数层面就没生效。

二是以为 GLM-5.3 也能关思考。它不能，传 disabled 直接报错，只能靠 reasoning_effort 调档。官方迁移提示写得很清楚：不先把这行改掉，请求会失败——升级前没人改，上线就是全量报错。

三是开了保留式思考却没验证缓存命中。这个功能的收益完全建立在缓存命中率提升上，而命中又要求 reasoning content 原样、按序、不裁剪地传回。中间任何一个环节被你的消息压缩逻辑动过，收益归零、成本照付。

下一步建议做一件很具体的事：在你的调用封装里加一行，把每次响应的 reasoning_content 长度和 usage 里的四个字段一起落日志。等哪天账单跳了，你手里有的就不只是「感觉是思考变多了」，而是能拿出对比数据的记录。