--- layout: post.njk source: https://yage.ai/share/codex-gpt56-context-budget-20260721.html speaker: yage.ai title: GPT-5.6 的上下文到底是 1.05M、500K，还是 400K？ date: '2026-07-22' summary: 文章详细解析了GPT-5.6模型在不同使用场景（API vs Codex）下的上下文窗口限制的复杂性。它区分了官方API规格上限与实际产品额度，解释了输入预算和最大输出限制如何通过不同的版本配置（如v0.144.5到v0.144.6）导致总上下文容量从约500K降至400K的机制，并强调了客户端本地配置与云端实际资源分配之间的差异。 area: tech-engineering category: ai-application tags: - context-window - model-budget - api-specification - compaction people: [] companies_orgs: - OpenAI products_models: - GPT-5.6 media_books: [] draft: true status: evergreen --- GPT-5.6 的上下文窗口，其实并不像看上去那么明确。官方 API 页面写的是 1.05M，但平时使用 Codex，几乎不可能把会话推到这个数字。最近的一次调整又让问题更复杂：Codex 中原本约 500K 的窗口变成了 400K；查看不同版本的配置，还会看到打包输入预算有时是 372K，有时是 272K，旁边又列着 128K 的最大输出限制。把输入与输出相加，还会得到 500K、400K 两种产品总额度；网上甚至有人报告运行时只显示约 258K。1.05M、500K、400K、372K、272K、258K 和 128K 到底分别是什么？下面逐个拆开来看。 GPT-5.6 从 API 模型窗口到 Codex 实际工作预算的逐层变化 ## 先给答案：API 仍是 1.05M，Codex 约从 500K 回到 400K 面对同一个模型，开发者在不同场景下会遇到看似冲突的限制。要理清这些数字，需要将模型的底层规格与产品的默认封装额度区分开来。 底层的 API 模型规格非常明确且保持稳定。根据 GPT-5.6 Sol API 页面 与 GPT-5.5 API 页面，两款模型在 API 渠道的 context window 上限均为 1,050,000 token，最大输出限制为 128K。这是模型总容量上限，而非单纯的输入额度。 而一旦模型通过 ChatGPT subscription 路由接入 Codex 客户端，其适用的产品额度约定就发生了变化。这种拆分在 GPT-5.5 时代就已存在：OpenAI 在介绍 GPT-5.5 的文章中宣布，Codex 内的 GPT-5.5 拥有 400K 上下文空间。其默认配置将这一空间拆分为 272K 输入预算与 128K 最大输出限制，二者在算术上相加刚好为 400K。 在 GPT-5.6 时代，这套产品额度经历了一次波动。在稍早的 Codex v0.144.5 版本中，打包的输入预算设为 372K。加上 128K 的输出限制，在算术上得出了 500K 的总空间，但这并非官方独立宣传的产品承诺。随后，Codex CLI v0.144.6 的发布日志将 GPT-5.6 的限制纠正为 272K。根据 修改记录中的 PR #34009，此改动仅涉及 bundled model metadata（本地打包的提示词模板及 context_window 与 max_context_window 等元数据）。该 PR 仅能证明本地元数据的改动，不能用来推断官方调整的底层意图，也无法证明云端所有的服务行为都因此发生了改变。另外，Codex 虽依靠这些打包配置来规划会话预算，但云端服务器下发的配置同样可能覆盖本地默认值。 更新客户端这一动作，并不意味着该限制只存在于客户端。事实上，客户端需要准确的元数据，以便在将会话发送到云端前及时启动 compaction，防止因请求超额而被后端拒收。同时，Codex 后端能够动态下发最新的模型目录来覆盖本地打包的默认配置。根据 GitHub 上的运行报告 (issue #32806)，至少已有运行报告显示，使用 v0.144.6 之前旧版本客户端 0.144.3 的用户，也已收到了云端下发的 272K 限制。因此，无论是锁定 v0.144.5 版本还是手动修改本地数值，都无法可靠地保留 372K 的原有行为。这些改动虽然会改变客户端本地规划 compaction 的时机，却无法强求云端后端接受超出配额的请求。 在实际运行中，部分开发者还会看到第四个数字。根据上述运行报告，特定运行环境下 model_context_window 可能会报告约 258,400 token 的有效额度。这一数值仅是单一开发者在特定会话中观察到的 95% 有效窗口表现，并不是一个固定的压缩触发阈值，实际的 compaction 触发仍取决于账号对应的具体路由。 渠道与配置版本 API 规格上限 默认输入预算 最大输出限制 产品总额度说明 GPT-5.5 API 1,050,000 按请求分配 128K - GPT-5.5 Codex 1,050,000 272K 128K 约 400K (272K 输入 + 128K 输出) GPT-5.6 初始 Codex (v0.144.5) 1,050,000 372K 128K 约 500K (372K 输入 + 128K 输出) GPT-5.6 修复后 Codex (v0.144.6) 1,050,000 272K 128K 降回约 400K (272K 输入 + 128K 输出) ## 500K 与 400K 的算法：默认输入预算从 372K 纠正为 272K 上述两个组合额度均由默认输入预算与最大输出限制相加得到。 在 v0.144.5 版本中，Codex 为 GPT-5.6 分配了 372K 输入预算。加上 128K 的输出限制，在算术上得出了约 500K 的产品总额度，使本地客户端以此为目标规划长会话。在最新的 v0.144.6 版本中，Codex 将输入预算重新修正为 272K，在相同的 128K 最大输出限制下，产品总额度随之降回约 400K。 这说明 Codex 中的 GPT-5.6 重新回到了与 GPT-5.5 相同的额度标准。开发者能使用的默认输入额度再次统一为 272K，而底层的 API 模型规格并未下调。 ## 减少的 100K 预算怎样影响账单与长任务 输入预算从 372K 降回 272K（即 Codex 总额从约 500K 降回 400K），对长任务的直接后果是更早触发 compaction。当会话累积的 token 达到预算上限时，Codex 将在后台自动压缩历史会话。输入预算缩减了 100K，在上述 95% 有效窗口表现下，两者的有效预算差额为 95K token；但实际的 compaction 触发点仍受账号、路由和运行时的影响，并非固定提前 95K。 对于使用 API key 的独立调用，272K 是一个关键的计费边界。根据 API 官方文档，一旦单次请求的输入 token 超过 272K，该请求的输入和输出费率将分别按 2 倍与 1.5 倍计费。虽然这仅针对该笔请求的费率进行调整、不等于整个账单翻倍，但也显著抬高了长会话的调用成本。 若使用 ChatGPT subscription 渠道，用户虽不直接为超额付费，但这同样会带来服务端资源和容量规划的压力，且 272K 刚好与计费边界重合。在 issue #19464 讨论中，工程贡献者 Eric Traut 曾提到，在客户端支持 1M 级上下文需要服务端实现和容量规划。这体现了后台资源的考量，但不能作为此次版本调整动机的官方解释。 同时，客户端的本地配置修改并不能在云端可靠地解锁更大窗口，大上下文仍需要云端服务配合。因此，使用 API key 的独立调用与通过 ChatGPT subscription 的 Codex 客户端会话，并不共享相同的上下文额度约定。 防范长任务中的上下文超支或过早压缩，不能只看模型规格。开发者需要建立一套清晰的检查规则：先读取当前活跃运行时的 model_context_window，再观察当前账号路由下实际的 compaction 行为，并在相同路由下测试长任务。模型规格、产品通道、运行时窗口和实际压缩行为四者结合，才构成了会话真正可用的上下文边界。