OpenAI API context window 是什么？

更新于 2026-10-30 · runapi.cfd

简答：OpenAI API 的 context window（上下文窗口）是一次请求能够处理的最大 token 容量，不是模型的永久记忆。先用“当前输入 token + 计划输出 token ≤ 模型上下文窗口”做初步检查；如果是推理模型，还要按官方 usage 规则确认 reasoning token，它通常是 output_tokens 的明细，不应再次重复相加。最稳妥的流程是：核对具体模型限制、用 Tokenizer 估算输入、设置合理的 max_output_tokens，再根据响应的 usage 和 incomplete 状态排查。

定义：Context window 是模型在一次生成请求中能够处理的 token 总容量，通常涉及输入 token、输出 token，以及部分模型输出中的 reasoning token。

30 秒判断卡：先用数字判断请求是否可能超限

假设某模型的 context window 为 W = 128000，当前输入占用 I = 90000，你希望最多生成 O = 12000 个输出 token。初步检查是：I + O = 102000，没有超过 128000，因此从总量角度看仍有约 26000 token 的余量。

这里的 12000 是输出上限，不是模型一定会生成的数量；如果模型属于推理模型，还要根据该模型的官方规则和最终 usage 核对 reasoning token。不要把 reasoning_tokens 再额外加到已经包含它的 output_tokens 上。

先检查什么	怎么判断	超出或异常时怎么做
模型 context window	查看具体模型详情页，不套用其他模型数字	更换适合的模型，或缩短输入
当前输入 token	统计消息、历史、工具、文件等实际输入	删除无关历史、工具结果和重复说明
max_output_tokens	它是本轮输出上限，不是总上下文大小	根据剩余空间设置，不要把它当作扩容参数
reasoning token	部分推理模型会在 output_tokens_details 中提供明细	按 usage 结构读取，避免重复计数
响应状态	检查是否出现 incomplete 或输出截断	缩短输入、降低输出预留并重新测试

OpenAI 官方将 context window 定义为单次请求中输入和输出可使用的最大 token 数，部分模型还会涉及 reasoning token；模型详情页则分别列出 context window 与 max output。OpenAI 对话状态文档 OpenAI 模型文档

Context window、输入输出 token 与 reasoning token 的关系

可以把一次请求理解为一个有限容量的容器。输入侧可能包括系统或开发者指令、用户问题、历史消息、工具定义、工具返回内容、文件和图片等；输出侧包括模型生成的结果，部分推理模型还会在输出用量中记录 reasoning token。

需要特别区分三个概念：

可见输出 token：用户通常能在响应文本中看到的内容。
总 output tokens：API usage 中用于表示模型输出消耗的总量，可能包含 reasoning token。
reasoning tokens：部分推理模型的输出明细，用于说明总输出中的推理部分。

因此，排查时不要简单套用“输入 + 可见输出 + reasoning token”并重复相加。更安全的做法是先读取当前响应的 usage 字段，再按照具体模型文档解释字段层级。OpenAI 的官方响应示例把 reasoning_tokens 放在 output_tokens_details 下，说明它是 output_tokens 的明细，而不是必然独立于 output_tokens 的第三个总量。OpenAI Responses Compact API 参考

Context window 和 max_output_tokens 有什么区别？

Context window回答“这一轮请求总共能容纳多少 token”；max_output_tokens回答“这一轮最多允许模型生成多少输出 token”。前者是总容量，后者是输出侧的上限。

继续使用上面的假设：模型上下文窗口为 128000，输入为 90000，设置 max_output_tokens=12000，则初步总量为 102000。若将输出上限设置为 50000，初步总量将变成 140000，已经超过假设的上下文窗口。此时调低 max_output_tokens 可能帮助请求满足总量限制，但它不会扩大 context window，也不能修复已经过大的输入。

如果输入本身已经超过模型可接受范围，例如输入达到 140000，而模型窗口只有 128000，那么即使把 max_output_tokens 设置为 1，也应先缩短输入。反过来，如果输入很小但输出总是过早停止，则应检查 max_output_tokens、响应状态和停止原因，而不是只看 context window。

最小可运行请求：设置输出上限并读取 usage

下面是一个 Responses API 的最小请求示例。模型 ID 和密钥都是占位符，必须替换为当前账户可用的值；不要把真实密钥写入代码仓库、Shell 历史、日志或前端代码。示例使用 max_output_tokens 预留最多 12000 个输出 token：

curl https://api.openai.com/v1/responses -H "Content-Type: application/json" -H "Authorization: Bearer $OPENAI_API_KEY" -d '{"model":"替换为可用模型ID","input":"用三句话解释 context window","max_output_tokens":12000}'

先确认模型 ID、context window 和 max output 来自同一个具体模型页面。
估算输入规模，不能只统计用户问题，还要考虑历史消息、工具定义和附件。
设置一个低于剩余容量的 max_output_tokens，先验证请求能否完成。
检查 HTTP 状态、输出文本、响应状态和 usage，不要只根据是否返回 200 判断成功。
若出现不完整响应，区分是输入过大、输出上限过小，还是模型在上下文限制下被截断。

OpenAI 官方文档说明，Responses API 可以使用会话状态和 previous_response_id 管理多轮对话，但历史输入 token 仍可能计入 API 用量；保存会话并不意味着上下文窗口无限扩大。OpenAI 对话状态文档

中文、英文和代码怎样估算 token？

字符数、字数和 token 数不是同一个概念。中文、英文、标点、空格、数字和代码会按照目标模型使用的编码方式切分，因此不能写死“一个汉字等于一个 token”或“固定多少字等于一个 token”。

可以用下面这段 Python 对纯文本做可复核估算。它不会模拟完整聊天消息包装、工具 Schema、图片或文件处理，所以结果只能作为输入预警；完整请求仍应以当前端点支持的计数方法和 API 返回的 usage 为准：

pip install tiktoken

import tiktoken; model = "替换为目标模型ID"; text = "请把这段中文摘要成三句话，并保留 API、JSON 和 max_output_tokens 这些代码标记。"; enc = tiktoken.encoding_for_model(model); ids = enc.encode(text); print("字符数:", len(text)); print("token数:", len(ids))

这段示例的关键不是背下某个固定数字，而是让本地编码器按照目标模型返回实际结果。官方 tiktoken 项目提供了 encoding_for_model()，但如果模型名称未被库识别，应按目标模型文档选择对应编码或改用官方支持的计数方式。OpenAI tiktoken 项目

对于聊天消息、工具定义、图片和文件，计数规则取决于具体端点和模型，不能把纯文本编码结果直接当成完整请求 token 数。遇到临界长度时，应保留安全余量，并用实际响应的 usage 复核。

上下文超限和输出变短：按顺序排查

先查模型：确认模型 ID、context window 和 max output 是否匹配，不要把旧模型或其他模型的数字套过来。
再查输入：统计历史消息、系统指令、工具描述、工具返回、文件和图片，优先删除重复或不再需要的内容。
区分输出问题：输入过大时要缩短输入；输出上限过小才调整 max_output_tokens；仅仅降低输出上限不能修复超大的输入。
检查响应：查看是否有 incomplete、截断原因或 usage 明细，确认是容量限制还是业务逻辑提前结束。
最后处理长对话：将任务拆成阶段，保留目标、约束、已确认事实和未解决问题，删除重复闲聊与过期工具结果。

上下文超限不适合盲目重试，因为请求内容没有变化。应先减少输入，再发送一个最小请求确认端点和模型本身可用。

长对话如何管理：手动摘要、previous_response_id 与 compaction

Chat Completions 通常需要应用自行维护并重新发送历史消息；Responses API 则提供 Conversations、previous_response_id 和 compaction 等上下文管理方式。无论使用哪种方式，模型仍然受具体 context window 限制。

对于长时间运行的 Responses API 流程，可以使用服务端 compaction：在请求中配置 context_management 和 compact_threshold，当渲染后的 token 数达到阈值时由服务端压缩上下文。也可以调用 /responses/compact 获取压缩后的上下文窗口，并将返回结果原样传给下一次请求。

官方文档特别提醒，压缩结果是供模型继续工作的机器状态，不应当当作普通人工摘要随意编辑。若使用 previous_response_id，按文档继续传入新的用户消息；若自行维护输入数组，则应保留压缩返回的完整结果。OpenAI Compaction 文档 OpenAI Compact API 参考

什么时候应该查模型文档，而不是套用网上数字？

context window、最大输出 token、推理行为、输入类型和 usage 字段都可能因模型及模型快照不同而变化。本文的 128000 仅用于演示计算方法，不是 OpenAI API 的统一上限。实际调用前，应打开具体模型详情页核对当前限制。

如果你通过兼容接口、API Router 或其他供应商调用，还要额外确认路由层是否修改了模型 ID、参数名、输出上限或上下文限制。OpenAI 官方模型页面只能证明对应官方端的能力，不能自动证明其他网关的行为。

常见问题

OpenAI API 的 context window 是模型记忆吗？

不是。它是单次请求能够处理的 token 容量。多轮对话要保留历史，应用仍需传入相关消息、使用会话状态或采用官方支持的上下文管理方式；context window 本身不是永久记忆。

输入 token、输出 token 和 reasoning token 会不会重复计算？

不能简单把三者无条件相加。部分响应中 reasoning_tokens 位于 output_tokens_details 下，是 output_tokens 的明细。应先查看当前模型和响应 usage 的字段层级，再决定如何解释。

为什么 max_output_tokens 设置很大，回答仍然不完整？

max_output_tokens 只是输出上限，不会扩大 context window。如果输入历史、工具定义或附件已经占用大量空间，模型可用空间仍然有限；应先缩短输入并检查响应状态。

中文文本怎样准确计算 token？

不能按固定字数换算。可使用与目标模型匹配的 Tokenizer 或 tiktoken 对纯文本估算；聊天包装、工具、图片和文件的完整计数取决于端点和模型，最终应以 API usage 或当前官方文档为准。

previous_response_id 会让历史输入不再计费吗？

不会简单等同于免费复用。OpenAI 文档说明，响应链中的历史输入 token 仍可能作为输入 token 计入用量；应结合 usage、缓存机制和当前模型文档核对。

context window 超限时应该重试多少次？

不要盲目重试。先缩短历史、删除无关工具结果、拆分任务，或在适用的 Responses API 流程中使用 compaction，再发送最小请求验证。

Run API