一次大模型调用要预留多少 Token？输入、工具结果与输出预算

团队觉得一条请求“远小于模型的百万 Token 窗口”，因为用户提问只有几句话。实际发送时，还带上系统规则、工具定义、此前对话、一份检索到的 PDF，以及账户查询的返回；模型也必须留下生成回答的空间。真正要核对的是：这一次完整调用能放进去多少，生成第一个字前必须留出多少？

上下文图回答哪些材料该进入模型、各自从哪里来。本页把即将发送的请求计数，对照确切模型和接口的上限，决定发送、缩减或改道。长对话压缩检查点处理运行中怎样保住旧决定；即使是首次调用，也需要这份容量预算。下方工作表每次只记录一次调用，工具返回后再做一行。

先记三种上限，再分配 Token

针对模型具体版本和接口，分别查上下文窗口、模型或接口明确列出的单独最大输入（如有），以及最大生成输出，再记本次实际设置的生成上限。这些不一定是同一个数。模型资料页可能列出窗口与最大输出，却没有另列输入上限；不能从窗口推断出单独的输入上限，也不能把窗口当作可见回答的长度。

可用一条保守验收式做发送前的关卡：

已计数的本次完整输入 I + 本次设置的全部生成上限 G + 余量 H ≤ 上下文窗口 W

若模型或接口明确列出单独输入上限，还要检查 I + H ≤ 最大输入；同时检查 G ≤ 最大输出。这里的 G 覆盖模型可能生成的一切：可见文本、工具调用结构、推理或思考，以及不可见的格式 Token。依据实测的完整生成用量，包括较长的合格案例，设置 G。H 用于输入计数误差以及计数后、发送前的输入增长，因此单独输入关卡也要计入它；依据可信的输入变化和实测计数偏差说明余量来源，不套跨提供商的固定百分比。

这是一项自定的保守放行规则，不意味着每家 API 都会按这条式子提前报错。Anthropic 文档说明，输入本身超过窗口会报错；较新的 Claude 模型可能接受“输入加 max_tokens 超出窗口”的请求，直到生成触及窗口才停止。设计时要保证完整答案有空间，不能把晚停当成正常交付。

给即将发送的完整请求计数

先组装真实候选请求：系统与开发指令、用户消息、保留的历史、示例、工具名称和参数结构、检索段落、图片与文件、输出结构，以及已经收到的工具返回。针对将要使用的模型计数。只数用户文字，会漏掉消息边界、工具结构和多模态处理的用量。应用侧客户端工具的返回会进入下一次模型调用。工具运行前，用续接需要保留的输入、工具结果上界和续接结构估算下次输入，再用预计 I + H 核对明示的输入上限，用预计 I + G + H 核对 W；收到结果后，重组实际请求重新计数。提供商托管的服务端工具可能在同一次 interaction 内返回并继续，因此要限制调用次数和返回规模，并查看实际 usage，不能一概假设会另起一次请求。

三家计数接口与用量字段不可互换：

核对的接口	发送前能得到什么	完成后怎样读
OpenAI Responses	input_tokens.count 接收与 Responses 相同结构的文本、工具、图片、文件和会话；计数包含角色、消息边界等表示开销。尚未产生的工具返回仍无法预知。	usage.input_tokens 包含作为子项的缓存输入；usage.output_tokens 包含可见文本以外的生成 Token。
Anthropic Messages	count_tokens 支持 system、客户端工具、图片与 PDF，但结果是估计，实际用量可能略有差异。多数服务端工具、MCP 连接器及 URL/file 来源块会使该计数接口报错，须看实际响应的 usage。	开启缓存时，总输入为 input_tokens + cache_read_input_tokens + cache_creation_input_tokens，不能只看 input_tokens。
Gemini 当前 Interactions 文档	count_tokens 预先返回的只是输入计数。实际 interaction 的 usage 分列输入、输出、thought、缓存和工具使用；仍需核对模型明确列出的限额。	total_output_tokens 与 total_thought_tokens 分列；评估完整生成至少把两者相加，工具用量另看。缓存命中是输入的分类，不能再额外加一次。

Prompt 缓存可以改变处理费用和等待时间，却不会扩大窗口。Anthropic 明确说缓存读取与写入都占上下文；OpenAI 把 cached_tokens 列在总输入中。容量栏保留完整输入，缓存命中另列成本栏；命中是否真实发生可用缓存命中试验验证。

为全部生成留空间，而非只数可见回答

生成上限不是最终段落的字符上限。OpenAI 的推理 Token 原文不通过 API 显示，却占窗口、计入输出；输出用量还可能包含不可见的格式 Token，因此有时一个可见字都没生成就耗尽上限。Anthropic 的 thinking 计入 max_tokens 和窗口；不同模型在后续轮次保留或丢弃旧 thinking 块的规则不同。Gemini 当前 Interactions 的 thinking 文档说明，max_output_tokens 含 thought；若在思考阶段触顶，可见输出可能为空或被截断。细节各异，但都说明不能拿最终字数代替完整生成预算。

先写完整交付需求：必备字段、是否有两种语言、引用、模型可能需要产生的工具调用。用多条有代表性的案例，特别是最长但仍合格的一条，记录全部生成的真实用量；把 G 设到足以完成任务且不超过模型输出上限。若装不下，删减明确可选的字段，把结果拆成能分别验收的阶段，或选限额合适的模型。不能悄悄截去 JSON 必填字段，也不应为了凑短输出而把推理空间压到不可用。

调用后检查提供商状态、停止或未完成原因、实际用量和下游验收。回答前几句流畅，不代表已触顶的结果可以交付。结构化输出必须完整解析并通过输出协议检查。用实测的完整生成需求调整 G，用输入计数偏差和发送前增长调整 H；缓存命中本身不证明请求变短了。

案例：保修检索遇到账户工具返回暴涨

一位虚构的服务助手依据获批的保修条款回答设备问题。示例模型的窗口是 64,000 Token，另有明确列出的 56,000 输入上限和 8,000 输出上限。首次完整请求计数为 24,000；团队为全部生成设 6,000 上限，依据之前的输入计数偏差留 2,000 余量。输入关卡为 24,000 + 2,000 = 26,000 ≤ 56,000，输出关卡为 6,000 ≤ 8,000，窗口关卡为 24,000 + 6,000 + 2,000 = 32,000 ≤ 64,000。以上都是案例假设，并非厂商默认值。

随后助手调用应用侧的账户工具。运行前，团队估算续接需保留 23,000 输入 Token、工具结果上界 25,000，以及 1,000 的续接结构，得出预计 I = 49,000；计入余量后，通过输入关卡 49,000 + 2,000 = 51,000 ≤ 56,000 和窗口关卡 49,000 + 6,000 + 2,000 = 57,000 ≤ 64,000。实际工具范围过宽，返回冗长事件历史，超出预估上界。把真实结果及续接消息组装后，下一次完整请求计数为 61,000：计入余量后超过单独的输入关卡 61,000 + 2,000 = 63,000 > 56,000，而且 61,000 + 6,000 + 2,000 = 69,000 也越过团队的窗口关卡。不能照旧发送，也不能把之前的预检当成放行。工具负责人把结果收窄为已获准的保修相关字段和事件定位码；重新组装后计数为 27,000，并验证答案仍能引用正确的条款与账户事实。这里需要修的是工具返回范围，不是删掉关键保修条件。

案例：双语事故简报的 JSON 还没写完

一支运维团队要求把英文和中文事故简报放进同一个严格 JSON 对象。虚构测试模型的窗口是 40,000 Token，输入上限 32,000，输出上限 8,000。完整输入只有 17,000，输入空间充足。团队却因之前看到的最终文案很短，把本次生成上限设为 1,600。一个较难案例在写完两个语言字段之前就花掉了思考和格式 Token，响应状态显示未完成，JSON 无法解析。

团队不按字符和 Token 的固定比例猜，而是用多条获批的合成案例实测，加入最长但仍合格的双语简报，记录全部生成用量。随后把完整生成上限调到 4,000，并保留有依据的 2,000 输入余量：输入关卡为 17,000 + 2,000 = 19,000 ≤ 32,000，输出关卡为 4,000 ≤ 8,000，窗口关卡为 17,000 + 4,000 + 2,000 = 23,000 ≤ 40,000。复测检查完成状态、JSON 解析、两种语言字段与事实一致性。如果真实案例所需输出超过该模型的上限，就共享一份已核验的事故事实记录，分两次生成并分别验收，而不接收残缺对象。

不适用边界

这张表只规划一次模型调用；每次工具返回或请求材料变化后重做。它不决定哪份资料应该进入上下文、旧历史如何压缩、缓存有没有真正命中，也不核算整条工作流的价格；这些由相邻页面处理。案例里的模型上限都是为了演算虚构的数字。本站工作表会保存在当前浏览器，只填合成案例编号和汇总 Token 数；私密 Prompt、文档、工具结果与 API 日志应留在获准的系统中。