思考 token 算不算钱：GLM、Kimi、Grok、Gemini 计费口径对照

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

结论先放这儿：思考内容一律要算钱，没有哪家把它当赠品。但各家写清楚的程度差别极大——xAI 在文档里用表格明写「推理 token 按完整的补全 token 价计费」，Kimi 在常见问题里直接回答「会计入输入/输出 token 消耗」，Gemini 干脆把它写进定价页表头「输出价格（包括思考 token）」，而 GLM 只在注意事项里提了一句「思考过程会消耗额外的 Token」，MiniMax 与阶跃星辰的官方文档里我没有找到单列思维链计价的条款，只能从 usage 字段结构去看。比起比较单价，更该先搞清楚的是三件事：思考能不能关、强度档位怎么定、多轮对话要不要把历史思考带回去。

先把问题拆对：「算不算钱」其实是三个问题

很多人问「思考 token 算不算钱」，心里想的其实是一件事：我这个月的账单为什么比预估高。但要答清楚，得拆成三问：

第一，思考内容算不算进 token 用量统计。第二，如果算，算在输入侧还是输出侧——各家的定价页普遍是把输入与输出分成两栏分别列价的（阶跃星辰的价格明细页甚至把输入栏再拆成缓存命中与未命中两列），思考 token 落在哪一栏，就按哪一栏的口径走，具体数字见各家官方定价页。第三，我能不能不让它思考。

这三问不是并列关系，而是递进的：第一问决定要不要把它算进成本模型，第二问决定往模型的哪一项里填，第三问决定这项还能不能被压掉。很多人直接跳到第三问，结果发现目标型号根本关不了，前两问又没算过，账单就成了黑箱。

这三问的答案在这六家平台上并不整齐。下面按「官方写得最明确」到「官方基本没写」的顺序来看。

xAI：唯一把口径做成表格的一家

xAI 的文档里有一张 token 类型与计费方式的对照表，逐行写明：非缓存的 prompt token 按完整的 prompt token 价，缓存命中的 prompt token 按更低的缓存价，补全 token 按完整的补全 token 价，而 推理 token（Reasoning tokens）同样按完整的补全 token 价 计费。官方在推理能力页的末尾还补了一句更直白的话：使用推理模型时，推理 token 会作为总消耗的一部分被计费。具体单价见官方定价页。

有三处细节值得单独拎出来：

• 多智能体请求会成倍放大这笔钱。xAI 说明，多智能体模式下主导 agent 与各个子 agent 消耗的全部 token 都要计费，输入、输出、推理 token 都算在内；任何一个 agent 发起的服务端工具调用也都计入工具用量并计费。官方明确提示：多个 agent 可能并行运行、各自独立调用工具，因此一次多智能体请求消耗的 token 与工具调用次数可能远高于普通的单 agent 请求。
• Batch 的优惠覆盖推理 token。官方说明批量接口的低价适用于所有 token 类型，输入、输出、缓存与推理 token 都在内；但并不是所有模型都有批量优惠，不在官方列表里的模型按标准价，具体适用范围与比例见定价页。
• 对账有现成字段。每次推理响应的 usage 对象里都带 cost_in_usd_ticks，表示这一次请求实际被扣的费用，官方说明这是应用了包括缓存优惠在内的全部减免之后的实际计费金额，并且包含服务端工具调用的费用。它以「tick」这种整数单位表示，是为了避免浮点舍入误差，换算关系见官方文档。xAI SDK 另外提供了一个换算好的便捷属性。

Kimi：常见问题里给了正面回答

Moonshot 的思考模型文档结尾有一条问答，问的正是「reasoning_content 会消耗额外的 token 吗」，官方回答是：是的，reasoning_content 会计入输入/输出 token 消耗，具体计费方式参考产品定价页。

比这句话更值钱的是文档里另外两处约束：

一是 reasoning_content 里包含的 token 也受 max_tokens 参数控制，官方写明 reasoning_content 的 token 数加上 content 的 token 数应小于等于 max_tokens。这意味着 max_tokens 不是「回答长度上限」，而是「思考加回答的总长度上限」——设小了模型可能思考完就没配额输出正文了。官方在多步工具调用的配置建议里也提醒要把 max_tokens 设得足够大，以免无法输出完整的 reasoning_content 和 content。

二是保留式思考对成本的影响被写在了明面上：开启保留式思考后，历史轮次的思考内容会持续占用上下文长度并计费。Kimi 用 thinking.keep 控制这件事，取值 null 或不传时忽略历史轮次的 reasoning_content，官方对这一档的描述就是「上下文更短、成本更低」；取值 "all" 时完整保留。更细的用法可以看Kimi 思考模型的调用方式。

Gemini：写在定价页表头里

Gemini 的做法最省事——定价页的输出价格那一列，表头直接写的是「输出价格（包括思考 token）」。也就是说思考 token 不单列一档价，它就在输出价里。

官方 FAQ 另外给出了计费依据的四项：输入 token 数、输出 token 数、缓存的 token 数，以及缓存 token 的存储时长。注意最后这一项——它是一个跟调用次数无关的计费维度：缓存放在那里不动，时间本身也在计。做长上下文成本估算时，如果只按「命中多少次、每次省多少」来算，这一项就整个漏掉了。别家是不是也这么算，得逐家去看它自己的定价页，本文不做跨厂商的一般性概括。

GLM 与两家国产平台：得从字段结构去推

GLM 在深度思考页的注意事项里写了「Token 消耗：思考过程会消耗额外的 Token，请合理规划使用」，这是官方对思考消耗 token 的明确表态，但文档没有把思考 token 单列成一档计价。另一处旁证在 clear_thinking 参数的说明里：该参数默认为 true，官方描述是在本次请求中忽略或移除历史轮次的 reasoning_content，仅使用非推理内容作为上下文输入，「可降低上下文长度与成本」——反过来说，保留历史思考就是要花钱的。

还有一个容易踩的差异：GLM 对话补全接口文档里列出的 usage 字段是 prompt_tokens、completion_tokens、total_tokens 以及 prompt_tokens_details.cached_tokens，并没有单独的推理 token 计数；而问答 Agent 对话接口的 usage 里是有 completion_tokens_details.reasoning_tokens（官方描述为「推理 Token 数」）的。想在对话补全这条链路上单独统计思考 token 花了多少，官方文档里没有找到对应字段。GLM 侧的计费细节可以对照GLM 思考模式的计费口径。

MiniMax 的 Responses API 在 usage 里给了 output_tokens_details.reasoning_tokens，官方描述是「思维链消耗的 token 数（仅开启推理时计入）」——从字段位置看它是输出 token 的一个明细项。更有意思的是 OpenAI 兼容接口上的 reasoning_split 参数：官方说明它不开启也不关闭 thinking，只控制思考内容怎么返回。为 true 时思考通过 reasoning_content 和 reasoning_details 返回；为 false 时，原生 Chat Completions 响应会把 thinking 保留在 content 字段中的 <think>...</think> 标签里。也就是说不开这个开关，思考内容物理上就是 content 的一部分，你连从响应里把它剥出来单独统计都做不到。至于是否单独定价，官方定价页上我没有找到思维链单列的条目。

阶跃星辰 的推理模型在流式返回里用 reasoning 字段承载思考过程（如果既有代码用的是 reasoning_content，可以在请求里传 reasoning_format="deepseek-style" 切换字段名，用 OpenAI SDK 时通过 extra_body 传）。官方给出的示例输出里，带 reasoning 分片的那些 chunk，completion_tokens 是在逐个累加的。至于思维链是否按单独价目计费，官方文档里没有找到相关说明。

能不能关掉：这一层的差别比单价更要命

这是本文最该记住的一节。能不能关，是逐个型号定的，不是逐家定的——同一家旗下既有官方明写「无法禁用」的型号，也有能整档关掉的型号。各家官方原文如下（关注点放在型号名上，不要按厂商记结论）：

• GLM：用 thinking.type 控制，取值 enabled 与 disabled。但官方特别加了注：GLM-5.3 不再支持关闭思考，API 请求中传 disabled 将会报错。文档还区分了两种「enabled」——部分型号是模型自动判断是否思考，另一部分是强制思考。
• Kimi：K3 始终进行推理，不支持 thinking 参数；面向代码场景的 K2.7 Code 始终开启思考，且保留式思考始终开启、无法关闭，传入 "all" 以外的非法 thinking.keep 值会报错；K2.6 默认开启思考、可按需关闭。
• xAI：推理能力页写的是 grok-4.6 与 grok-4.5 支持 reasoning_effort 参数，并明写推理无法禁用（该页的模型对照表在这两行后面也各跟了一句 cannot be disabled）。但同一份文档的 REST API 参考里，POST /v1/chat/completions 的请求体说明写的是 reasoning_effort 仅 grok-4.3 支持，取值含 none，官方对 none 的解释是完全禁用推理。两处的作用域是不同型号，别把「xAI 不能关思考」当成全线结论，以官方文档当前版本为准。另有一条连带限制：presencePenalty、frequencyPenalty 和 stop 不能与推理模型一起使用，请求里带上这些参数会返回错误。
• Gemini：兼容层上 2.5 系列可以把 reasoning_effort 设为 "none" 来关闭思考，但官方明文写着 Gemini 2.5 Pro 与 Gemini 3 系列无法关闭推理。这一条的展开见Gemini 关不掉思考的那些型号。
• MiniMax：M3 可以用 thinking: {"type": "disabled"} 跳过思考直接回答；但 M2.x 系列的 thinking 无法关闭，官方写明即使传入 disabled，thinking 仍会保持开启。
• 阶跃星辰：文档给出的是推理强度档位（且档数按型号区分，见下一节），关闭思考的开关，官方文档里没有找到相关说明。

所以「用便宜档模型 + 关掉思考来省钱」这条路，在上面这几个官方明写不可禁用的旗舰型号上是走不通的。选型时先拿型号名去查它能不能关，比比较单价重要得多。

强度档位不是同一把尺

各家都提供了推理强度参数，但取值和默认档并不一致，跨平台迁移时直接照搬字符串会出问题：

• xAI 的 reasoning_effort 有 low、medium、high、xhigh 四档，官方说明未指定时默认为 high（以官方文档当前版本为准），且 xhigh 只在部分型号上可用，不支持的型号会按 high 处理。另外多智能体型号上这个参数的含义完全不同——它控制的是有多少个 agent 协作，而不是推理深度。
• Kimi K3 通过请求顶层的 reasoning_effort 配置，支持 low、high、max 三档，官方说明默认为 max（以官方文档当前版本为准）。从 K2.x 迁到 K3 时官方建议移除 K2.x 的 thinking 配置，改用顶层字段。
• GLM 的 reasoning_effort 仅 GLM-5.2 及以上支持，且不同型号的合法取值不同：官方写明针对 GLM-5.3 仅支持 max、high、low，其余输入将报错；GLM-5.2 支持的取值更多，其中若干档位之间存在映射关系。★ 这里有个极易读漏的限定：GLM 文档把映射规则分成了「在 API 请求中」与「在 Coding Plan 请求中」两套，同一个取值在两条链路上的落点并不一样，抄规则时务必连着场景一起抄。
• Gemini 的兼容层是做映射：OpenAI 的 reasoning_effort 映射到 Gemini 的 thinking_level（Gemini 3.x）或 thinking_budget（Gemini 2.5），档位为 minimal、low、medium、high。官方特别说明 reasoning_effort 与 thinking_level/thinking_budget 功能重叠，不能同时使用；不指定时走模型的默认级别或默认预算。
• 阶跃星辰 的档位是按型号分的，这一点官方写得很克制、极容易读漏：接口文档的原话是「支持三档推理强度的模型可选值为 low、medium、high」——注意主语是「支持三档推理强度的模型」，不是「阶跃的模型」；紧跟着的下半句就写明 step-3.5-flash-2603 兼容 low、high 两档。也就是说 medium 并不是全线通用的取值，往两档型号上传 medium 之前得先确认。官方在三档模型的强度对照表里把 medium 描述为默认推荐、适合一般推理和多步骤任务，这句同样只对三档型号成立。还有个接口差异：Chat Completion API 用 reasoning_effort，Messages API 用 output_config.effort，字段名不通用。

同样写 "high"，在上面这几家不是同一件事；同样不写这个参数，落到的默认档也不同。把一份 prompt 从一家搬到另一家，成本变化往往来自这里，而不是单价表。

多轮对话才是账单放大器

单轮请求里思考 token 的量还算可控，真正的放大发生在多轮：如果你把历史轮次的思考内容一起回传，它每一轮都要作为输入被重新计费一次。

各家对这件事的处理都给了开关和硬约束。GLM 的保留式思考在 Coding Plan 端点默认开启、标准 API 端点默认关闭，想在标准 API 上开启要传 clear_thinking: false，并且必须把完整、未修改的 reasoning_content 按原始顺序传回——官方警告，缺失、裁剪、改写或重排都会降低效果并影响缓存命中。缓存命中率一掉，省下的思考 token 又从输入侧还回去了。Kimi 那边的 thinking.keep 前面已经说过。xAI 的做法是加密：推理内容由平台加密，在 Responses API 里传 include: ["reasoning.encrypted_content"] 就能拿到，再把加密内容回传即可为后续对话提供上下文。Gemini 3 则是在 chat completions 接口上支持兼容形式的思考签名，官方错误码表里还专门有一个 missing_thought_signature，表示响应缺少必需的签名。

一句话：多轮场景下要么老老实实原样回传换取推理连贯性与缓存命中，要么明确关掉历史思考换取更短的上下文，最怕的是传了一半——效果没拿到，钱照付。

别忘了限流这一侧

思考 token 影响的不只是账单，还有你的速率配额。xAI 的文档写得最清楚：一次请求消耗的所有 token 都计入该模型的 TPM 限制，其中明确列出了推理模型上的 reasoning token；顺带一提，缓存命中的 prompt token 虽然按更低的价格计费，但仍然照常计入 TPM。

这意味着把 reasoning_effort 调高，除了账单变化，你的每分钟可用请求数也会实质性下降——同样的 TPM 额度被更长的思考吃掉了。排查「明明没加量却开始撞限流」的时候，先看看是不是最近把推理强度调高了。限流维度本身的通用机制可以看RPM 与 TPM 到底限的是什么。

最容易栽的三个坑

第一，把一家的口径套到另一家。 「思考 token 都是按输出价算」这句话在 xAI 和 Gemini 的文档里能找到依据，但 MiniMax 和阶跃星辰的官方文档并没有相应的单列条款，你得自己去看它们的定价页。跨平台做成本模型时，逐家回官网核，别用一句通则盖住所有平台。

第二，把限定条件丢掉。 前面提到的 GLM 强度映射规则分 API 请求与 Coding Plan 请求两套，就是典型例子。类似的还有 Kimi 的保留式思考在不同型号上是可选还是强制、MiniMax 的 thinking 开关在 M3 与 M2.x 上行为不同、阶跃的三档取值只对「支持三档推理强度的模型」成立、xAI 的「无法禁用」与「none 可完全禁用」分别落在不同型号上。这些条件一丢，结论就从「在某种情况下成立」变成了「一定成立」，而后者是错的。

第三，以为把思考关掉就能省钱。 一是有一批旗舰型号官方明写不给关；二是关掉思考后模型在复杂任务上可能需要更多轮次才能做对，多出来的轮次未必比那点思考 token 便宜。更稳的做法是按轮次分档——轻量轮次用低档或（在允许关闭的型号上）关闭，需要综合判断的轮次再放开。这些参数本来就是逐次请求传的：GLM 的 thinking.type 与 reasoning_effort、xAI 的 reasoning_effort、阶跃的 reasoning_effort 都写在单次请求体里，你完全可以让同一条链路的不同轮次走不同档位，前提仍然是先确认目标型号的合法取值。

下一步建议做两件具体的事：先去你在用的那家的 usage 响应里确认有没有推理 token 的独立计数字段，没有的话就用「输出 token 减去可见正文长度」做粗估；然后拿一个真实业务 prompt，在最低档和默认档各跑一批，把两组的 usage 存下来对比。比起读定价页，这份自己的数据更能告诉你思考这件事在你的场景里到底值不值。