输入令牌
输入令牌表示一次请求中提供的内容。这可以包括系统指令和开发者指令、最新的用户消息、较早的对话轮次、检索到的文档、工具定义、工具结果，以及模型支持时经过编码的图像或音频。
“输入”描述的是数据流向，而不是内容的编写者。用户可能只输入一句简短的话，但应用程序在后台发送的完整请求可能要大得多。
缓存的输入仍然是输入。缓存可以改变其价格或在用量报告中的显示方式，但不会把这些内容变成输出，也不会将其从模型的工作上下文中移除。
输出令牌
输出令牌是在响应期间生成的。可见的文字和代码属于输出，工具调用等生成的结构也属于输出。根据提供商使用的术语，报告中的输出总量还可能包括内部推理以及其他不可见的生成令牌。
因此，屏幕上显示的文字并不是可靠的令牌计数器。响应可能只显示 180 个令牌的文字，但用量记录报告的生成总量却大得多。
推理令牌
推理令牌有时也称为思考令牌，是推理模型在规划、检查或完成任务时内部生成的令牌。它们不是额外的提示内容，也不一定会显示给你。, sometimes called thinking tokens, are generated internally while a reasoning model plans, checks, or works through a task. They are not extra prompt content, and they are not necessarily shown to you.
提供商可能会隐藏推理内容、省略推理内容，或返回摘要。摘要只是对这一过程的呈现，并不能证明你收到了每一个内部推理令牌。当前的 OpenAI、Anthropic 和 Google 文档都说明，即使完整文本没有返回，也会对完整的内部工作量进行计量。
并非每个模型或 API 都会公开推理令牌计数。有些模型会生成答案，但不会单独报告推理阶段。另一些模型支持影响推理投入程度的控制项，但除非提供商明确说明，否则这些控制项并不保证确切的思考量。
真正的区别
这三个标签回答的是不同的问题：
| Token type | Defining question | Typical contents | Usually visible? | Accounting relationship |
|---|---|---|---|---|
| Input | What did this request send to the model? | Instructions, messages, context, tools, files | Mostly, though applications can add content | A top-level request category; cached input may be a priced subset |
| Output | What did the model generate? | Answer text, code, tool calls, and sometimes internal generated work | Partly | Can be an inclusive total or an answer-only field, depending on the API |
| Reasoning | What internal generated work helped produce the answer? | Planning, intermediate work, checks | Often hidden or summarized | Commonly a subset of generated output for billing, but sometimes reported beside output |
输入和生成的输出是一次请求的两个相反方向。推理则是一种生成活动。因此，推理并不是与输入和输出并列的、普遍适用的第三个类别。
在比较不同提供商的控制面板时，这一区别很重要。OpenAI 将推理记录为包含在总输出计数中的一项明细。Anthropic 同样将思考令牌描述为其权威输出总量的一部分。Google 则分别公开候选输出和思考计数，并说明响应定价会将二者合并。字段名称虽然不同，但三者都将推理视为生成的工作量。
一个用量示例
考虑下面这个简化请求：
- 指令、用户消息、历史记录和附加上下文合计 1,200 个输入令牌。
- 模型生成 620 个推理令牌。
- 随后生成一个包含 180 个令牌的可见答案。
某个 API 可能报告：
input_tokens: 1200
output_tokens: 800
output_details.reasoning_tokens: 620这里的 output_tokens 是包含推理令牌的总量。不要再次加上 620。180 个令牌的答案是 800 个生成令牌中不属于推理的部分。
另一个 API 可能报告：
input_tokens: 1200
output_tokens: 180
thought_tokens: 620
total_tokens: 2000这里，答案输出和思考令牌是分开的字段。在评估生成用量时，必须将二者都纳入。两份报告描述的是同一个简化流程：
1,200 input + 620 reasoning + 180 visible answer = 2,000 total tokens如果所有生成令牌都采用提供商的输出费率，简化后的成本计算为：
(1,200 × input rate) + (800 × output rate)实际账单还可能为缓存输入、缓存写入、批处理、工具或其他功能设置单独的费率。应依据 API 的用量架构和定价规则，而不是假设每个字段都可以相加。
每类令牌何时重要
当请求携带大量上下文时，输入令牌很重要。较长的历史记录、文档、工具定义和重复的指令，即使最新的用户消息很短，也可能占据主要用量。输入计数还可以告诉你上下文窗口中还剩多少空间。
当响应很长或被反复生成时，输出令牌很重要。生成是逐步进行的，因此输出通常在性能和定价特征上都与输入不同。将文档分类为一个标签的工作流，与起草一份报告的工作流，其用量形态就不同。
当任务需要内部工作时，推理令牌很重要。简短的最终答案可能是在很长的推理轨迹之后生成的。这会增加成本、延迟可见答案，并消耗生成令牌容量，却不会让显示出来的响应变长。
对于推理模型，输出上限可能同时涵盖内部推理和可见响应。如果推理先耗尽了配额，模型可能只能返回简短或不完整的答案。在将输出上限视为承诺的答案长度之前，请查阅对应端点的文档。
常见混淆
推理令牌不是额外的输入
模型会在生成过程中创建推理令牌。如果应用程序将保留的思考内容发回，那么这些内容可能在后续轮次中成为输入；但那是一次新的请求，也有一个新的计量边界。
推理令牌并不总是与输出令牌分开
如果用量对象说明推理是输出中的一项明细，那么将这两个字段相加就会重复计算。如果报告将思考令牌与答案输出并列为不同字段，那么忽略思考字段就会少算。进行算术计算前，请先阅读架构定义。
输出令牌并不总是可见的文字
令牌并不等同于文字，生成用量也不局限于显示出来的文字。工具调用参数、隐藏的推理以及提供商管理的格式化内容，都可能扩大你看到的内容与计量记录之间的差距。
答案简短并不一定意味着成本低
可见长度只是用量的一部分。一次请求可能包含大量输入、可观的内部推理，或二者兼有。与渲染后答案的大小相比，响应的用量记录是更可靠的计量依据。
接下来阅读
阅读 什么是输入令牌？了解应用程序会将哪些内容放入请求。阅读 什么是输出令牌？了解生成的响应和限制。阅读 什么是推理令牌？了解依赖提供商的思考层。