2026/09/07

GPT-6 Astra 上下文窗口：为什么 Codex 可能显示 258K

理解 GPT-6 Astra 的 1.05M API 上下文窗口、为什么 Codex 会显示更小的预算、如何测量压缩而无需猜测。

GPT-6 Astra 的 1,050,000 token 上下文窗口是 API 模型限制，不是对每个 Codex 会话都能显示 1.05M 可用 token 的承诺。 如果 Codex 在你的会话中显示约 258K，之后进行压缩，把这些数字当作会话级产品行为。OpenAI 没有将 258K 作为官方 Astra 规格发布，也没有在这里引用的来源中披露确切的分配公式。^[1]

有用的回应是区分模型合同、产品的工作预算、已占用的量和压缩阈值。它们是不同的数字。测量你实际使用的会话和客户端版本；不要从四舍五入的计数器推断隐藏的分配公式。

快速回答

Astra API 模型文档化 1.05M token 上下文窗口 和 128K 最大 output。^[1]
Codex 计数器是产品工作预算，而不是 API 模型限制。如果它显示约 258K，将其当作会话观察，而不是官方规格。
指令、工具、输出余量、对话状态和压缩都可以减少可见的工作集；OpenAI 不发布确切的分割。
通过 API 测量 API 容量，通过将需求、决策和测试结果保存在 chat 之外，使长 Codex 任务幸存压缩。

人们混在一起的三个数字

短语"上下文窗口"在产品讨论中用得很宽松。在调试之前，命名你看到的数字。

数字	含义	不能证明什么
1,050,000	OpenAI `gpt-6-astra` API 模型合同中的上下文窗口值	Codex 客户端给一个回合或会话整个量
128,000	模型页面的最大输出值	每个请求保留或生成 128,000 token
约 258K	你当前 Codex 会话可能显示的值	文档化的、永久的 Astra 限制或确切的内部公式

还有两个数字很重要：剩余预算 和 压缩触发器，其中产品在硬故障前总结或外部化之前的工作。

模型页面最大值和产品的剩余计数器都可以正确。它们回答不同的问题：

模型合同： API 模型在其文档合同下能支持多少总 context。
运行时工作预算： 当前产品为此会话选择或能够保持活跃的量。
剩余预算： 当前指令、历史、工具材料和 output 余量后剩余的量。
压缩阈值： 产品何时开始以更紧凑形式保存任务。

不要从 1.05M 减去 128K 并声称余额是 Codex 预算。如果会话显示 258K，不要除以假设的安全百分比并声称结果是隐藏的 cap。这些计算可能产生整数，但引用的 OpenAI 材料没有文档化该分配。

实用的预算模型，而不是内部规格

规划时，使用概念不等式很有帮助：

active instructions
+ retained conversation
+ tool schemas
+ tool inputs and outputs
+ files or excerpts supplied to the model
+ output headroom
<= current runtime working budget

这是记账模型，而不是 Codex 的反向工程描述。OpenAI 没有在这里引用的来源中发布每个组件的确切大小或 258K 显示背后的规则。该方程的价值在于左侧的每一项都可以在测试期间观察或控制。

这个区别也防止了常见的 API 错误。128,000 最大输出不意味着 API 总是会留那么多空，设置更小的 output cap 也不会增加模型的发布上下文窗口。它只是为该响应设置边界。改用 endpoint 返回的使用情况，而不是从文档字符或 UI 进度条估计。

对于当前模型 ID、支持的模式和路由特定行为，使用 GPT-6 Astra API 参考。模型页面有当前 reAPI 费率卡。这些页面描述该路由；它们不定义 Codex 应用的会话预算。

压缩在 Codex 中为 Astra 改变什么

压缩存在是因为长工具驱动的工作最终填满其活跃工作 context。历史上，OpenAI 说，Codex 总结了累积的工作，这可能遗漏细节，如为什么修复失败或组件如何表现。使用 Astra，OpenAI 推出了实验性 Codex 机制，可以跨 context 窗口保留笔记。较早的窗口保持可搜索，因此模型可以检索过去的需求或测试结果，即使它没有在这些笔记中被捕获。^[2]

这给长会话三种不同形式的内存：

活跃 context： 当前回合立即出现的材料。
跨窗口笔记： 活跃 context 转过时保留的选定事实。
可搜索较早的窗口： 当相关时可检索的较旧消息和工具结果。

活跃 context 是我们期望 live"tokens remaining"指示器描述的部分。OpenAI 的文章没有解释 Codex 计数器如何处理笔记或可搜索窗口。这两种形式可以帮助代理恢复信息，而无需保持每个字节活跃。可搜索历史与每个先前工具结果占据模型当前 context 一次不同。

OpenAI 说新机制可以在 Codex 配置中启用，预期在发布后的几周内成为 Astra 默认值。^[2] 因为该状态是时间敏感的，请检查当前 Codex 文档和你安装的版本，而不是复制未验证的配置片段。本文故意不规定未文档化的 context-window override。

调查 258K 显示而不将其当作通用的

有用的测试比较会话，不是内存。从空任务开始并在添加材料前写下条件。

要记录的字段	为什么重要
日期和时间	推出和默认值可以改变
Codex 应用或 CLI 版本	旧和新客户端可能会携带不同的目录或行为
账户和工作区类型	产品访问和工作区控制可能不同
选定的模型标签	会话可能不使用你想要的模型
新或已恢复会话	已恢复的线程已经包含保留的工作
显示的总预算和剩余预算	这些是正在调查的值
启用的工具或集成	模式和结果将材料添加到会话
压缩事件和时间	显示产品动作的位置，而不仅是计量开始位置
压缩后的结果	揭示哪些需求和测试事实幸存

然后运行控制序列：

打开新会话，选择 Astra 并在附加文件或运行工具前捕获模型标签和显示的预算。
给它一个有界的只读存储库任务。记录读取哪些文件以及命令是否产生短或长 output。
请求第二个新会话中的同样交付物，但从源过滤搜索和 cap 日志。比较显示预算的变化。
如果压缩发生，要求原始接受标准、修改的文件、失败的方法和最新测试结果。对照存储库检查每一项，而不是接受流利的总结。
在客户端更新后重复。不要比较已恢复的旧会话与新会话，并将每个差异归属于模型。

这个测试不会揭示私人实现细节。它会回答操作问题：哪些输入消耗你看到的预算、此客户端何时压缩以及哪些信息必须写在某处持久。

如果你的界面显示 258K，保留完整的测试条件：客户端版本、运行时目录、账户、会话年龄、启用的工具和最近的输入。没有这些变量和官方 OpenAI 规格，该数字不能被提升到一般 Codex 限制。

工具输出可以消耗比请求本身更多的空间

编码任务可能从两句 prompt 开始，仍然变得很大。递归文件列表、生成的 lockfiles、缩小的 bundles、冗长的测试报告、数据库转储和重复的 diffs 可以超过原始请求。模型可能只需要五个相关的错误行，而工具返回五千。

在它进入对话前减少该材料：

在打开整个目录前搜索符号或错误字符串；
请求相关行范围而不是整个生成文件；
显示聚焦的 diff，然后只在需要时打开未改变的 context；
在完整套件前运行狭窄的失败测试；
cap 重复堆栈跟踪并将完整日志作为文件保留；
用计数汇总大数据结果，然后检查异常行；
避免在多个回合中粘贴相同的构建输出。

这不仅仅是推迟压缩的方法。更小、更有针对性的工具结果使区分当前错误与陈旧失败变得容易。它们还留出更多空间用于需求、决策和验证。

在 chat 之外保留完整的工件并记录它们的路径。代理可以在需要时重新打开相关的。路径加简洁的发现通常比转录复制三次更有用。

设计长任务以使压缩可幸存

一百万 token 模型不是项目状态的替代品。对于可能跨越多个 context 窗口的存储库变化，在工作区或任务系统中保持紧凑的账本：

Goal:
Non-negotiable constraints:
Files intentionally changed:
Decisions and evidence:
Failed approach and why:
Checks run and exact result:
Remaining work:
Rollback point:

在决策改变时更新它，而不是在每个命令后。账本有两个工作：它让压缩会话恢复重要事实，它让人工审计代理的总结是否与实际 worktree 匹配。

使用显式接受标准。"完成重构"很脆弱，因为压缩后会话可能重新解释"完成"。"解析器接受这三个 fixtures，旧 endpoint 保持在交换机后面，没有无关文件改变"幸存压缩好得多。

对于 API 迁移，GPT-6 Astra 迁移指南提供了发现、canary 和回滚序列。对于产品访问问题，使用 GPT-6 Astra 访问矩阵分离 Codex 与 Chat、Work 和 API。

何时 1.05M API 合同是重要的数字

当需求是向 gpt-6-astra 故意组装大 context 时使用 API 测试。用 /v1/models 确认模型，构建代表性 fixture，设置有界的 output 限制并存储响应的使用字段。远低于上限开始，仅在任务实际受益时增加。

OpenAI 的 Astra 模型指南在 API 中列出压缩作为可用能力。^[3] 这是单独的 API 机制；它不文档化 Codex 使用的阈值或会计。

OpenAI 的模型页面也指出超过 272,000 input token 的请求使用更高的 long-context 费率，在发布的定价规则下应用于整个请求。^[1] 该 272K 定价阈值不是证明 Codex 必须公开 272K 或 258K 的证据。定价档、模型容量和应用的工作预算是独立的政策。

API 实验应该回答产品问题，而不是证明可以接受大有效负载。紧凑的评估可能比较：

retention score = required facts recovered correctly / required facts queried

accepted cost = total settled cost / responses that pass every required check

在 fixture 的开始、中间和结尾放置已知事实。要求可以精确检查的答案。记录 latency、token 使用和失败。不要仅因为请求成功返回就声称模型"使用了完整窗口"。