Codex 中的 GPT-6 Astra：跨窗口笔记、推理强度等级与真实账单

GPT-6 Astra 是 2026-09-03 的模型，本页不是发布报道——它是在该模型已广泛可用后，供你把编码智能体指向它时的参考。开发者会切换的原因是一个具体机制，在你为它花任何钱之前，值得先理解：Co​dex 搭配 GPT-6 Astra 不是每次窗口填满时把长会话压缩成一份有损摘要，而是跨上下文窗口保留笔记，并让更早的上下文窗口保持可搜索，因此你四十轮前提过的需求，以及十轮前失败的测试输出，两者仍然可取回，而不是被总结掉。Ope​nAI 称该功能为实验性功能，通过在 Co​dex 的 config.toml 中加一行来启用，并表示它将成为 Astra 的默认设置。以下所有内容——确切配置、effort 等级、实测结果，以及一份完整的会话账单示例，其中点明了缓存输入行——均于 2026-09-16 从 Ope​nAI 自己的页面读到，且每个第三方数字都作了相应标注。

本周发生了两件事，改变了采用它的利弊计算。2026-09-12，OpenAI 的 Codex 负责人发布了一份事后复盘，确认上下文管理实验本身存在一个 bug——它会导致过早停止以及回复过期消息，并已针对参与该实验的大约 4,000–5,000 名用户停用——同时 OpenAI 在 09-12 午夜至 09-13 对 Codex 和 Astra 用户进行了完整的用量重置。同样在这一周，发布时默认关闭 Astra 的企业工作区，开始可以按各自的费率方案进行管理。所以诚实的立场是：这个机制值得采用，但构建版本仍在你们脚下变动，你应该在分支上试用它，而不是赶着截止日期上。

搭载 GPT-6 Astra 的 Codex 究竟有哪些真正的新东西？

让任何编码智能体连续工作六个小时，你都会撞上同一堵墙。上下文窗口被填满，框架把对话记录摘要成一个密实的块以腾出空间，而这种摘要恰恰以一种最要命的方式造成信息丢失——早先某次修复失败的原因、某个失败测试的确切形态、用户在三轮对话时顺口提到的一条约束。你真正想要的，是被检索出来的细节，而不是被摘要过的细节。

Astra 的 Codex 集成改变了这一格局。OpenAI 的 Codex 文档直言不讳：“Astra 会跨上下文窗口保留笔记，并能搜索同一任务中更早的消息和工具结果。”笔记是持久且可写的；它们背后的历史记录保持可读，因此即使关于某条证据的笔记已经写好，仍可在更早的窗口中搜索到原始证据。来自更早消息和工具输出的需求与测试结果仍然可查。

Ope​nAI 明确表示，这并非已完成的工作。其配置参考将该标志描述为“启用实验性上下文管理（默认关闭）”，并称该功能“使用笔记和可搜索历史记录来保留累积的细节”。文档还指出，该功能“在发布时无法通过 Business、Enterprise 或 API 密钥登录使用”。这也不是无限上下文——模型仍然在一个有限的窗口内进行推理，而每一次回读先前的笔记都会消耗该轮次的输入预算。根据 Ope​nAI 的模型文档，该窗口为 1,050,000 个 token，最大输入 token 数为 922,000；笔记机制叠加在其之上，并不取代它。

配置，完全按照 Ope​nAI 文档所述

该设置是你 Codex config.toml 中 [features] 表的子项——除非你覆盖了 CODEX_HOME，否则该文件位于 ~/.codex/。文档记录的键路径是 features.context_management.experimental_mode，一个布尔值，且值为 true：

[features.context_management]
experimental_mode = true

如果文件中已经有 [features] 表，请在其中添加相应的键，而不是重复声明该表：

[features]
context_management.experimental_mode = true

二选一，选定一种写法就坚持用下去。社区里关于这个标志的说明指出：在根层级先声明点分路径，随后又在同一个文件中打开一个 [features] 表，可能会因表被重复声明而解析失败——这是 TOML 的规则，而不是 OpenAI 的规则——但它确实会让人栽跟头，所以选一种写法，并且保持一致。编辑之后，请新建一个新任务：该设置不会自动套用到已在运行的会话上。

同一文件中关于模型的那一半平平无奇，而 Ope​nAI 的参考文档直接说明了这些键——model 是“要使用的模型”，model_provider 默认为 openai：

model = "gpt-6-astra"
model_provider = "openai"
model_reasoning_effort = "high"

关于阅读文档版本的一点提醒。Co​dex 配置参考中，model_reasoning_effort 被列为可接受 minimal、low、medium、high 和 xhigh，并指出 xhigh 取决于具体模型——而 Ope​nAI 针对 gpt-6-astra 的 API 模型页面则将 reasoning.effort 记录为 low、medium、high、xhigh 和 max。客户端滑块和 API 描述的并不是同一组取值，因此请显式设置 effort，并确认你的客户端实际接受了什么，而不要想当然。

选择模型——以及那条让人栽跟头的访问规则

OpenAI 的 Codex 模型文档直接给出了 CLI 形式：codex -m gpt-6-astra。在交互式会话中，/model 会切换模型并调整推理强度；在一次性运行中，codex exec -m gpt-6-astra "Review the current changes" 也以相同方式工作。在桌面应用和 IDE 扩展中，模型控件位于输入框下方。

访问规则正是人们容易出错的地方，值得读两遍，因为这两个功能有不同的门控条件：

• 该模型——已在 ChatGPT Work、Co​dex 和 API 中提供，同时也部署在 Microsoft Azure 和 AWS Bedrock 上。Ope​nAI 的发布页面称，Astra“今日起面向有限数量的组织逐步推出，并将在未来几天内向所有 ChatGPT Plus、Pro、Business 和 Enterprise 用户开放”。

• 实验性上下文管理功能——适用范围较窄。OpenAI 的文档指出，它“需要在 Plus、Pro 或 Pro Lite 版上登录 ChatGPT”，并且“在发布时不支持通过 Business、Enterprise 或 API 密钥登录使用”。

那第二行才是需要内化的。你可以用 API key 调用 gpt-6-astra，也可以在 Business 方案上为它付费——但跨窗口笔记功能不会在那里。如果笔记机制是你切换的原因，你需要在 Codex 客户端中使用 Plus、Pro 或 Pro Lite 的 ChatGPT 登录，而不是 API key。OpenAI 将其表述为可用性取决于“推送范围、你的登录方式和你的客户端”，这是同一件事的礼貌说法。

还有两点附加说明，它们被标为“据报道”而非“经厂商文档证实”。关于此次推出的报道称，Astra 需要 Codex CLI 0.153.0 或更高版本；我们无法在 OpenAI 自己的页面上确认这一版本下限。而 Codex 文档描述了模型选择器预设——Astra Light、Astra Medium、Astra Extra High，与推理滑块一同面向符合条件的 Pro、Business（$100）和 Enterprise 账户提供。这些是选择器中的位置，不是独立产品：OpenAI 只记录了一个模型 ID，即 gpt-6-astra，只有一套规格和一个价格，并且没有为任何 “Astra Pro” 或 “Astra Medium” 配置发布单独的规格或费率。任何针对具名 Astra 层级引用的数字都应视为未经证实。

如果你想在把生产路径交给某个模型之前先试用它，把它与当前模型一起经由同一个端点来路由，是最省钱的验证方式——GPT-6 Astra 已在 OrcaRouter 目录中，因此做一次对比运行只需改一个模型字符串，而不必再签一份合同、再接入一套 SDK。

推理强度：五个等级，以及每个等级的成本

OpenAI 为 gpt-6-astra 提供的 API 文档列出了五档推理强度——low、medium、high、xhigh 和 max——而 Codex 的指导则直截了当地说明了该如何使用它们：“使用能满足你需求的最低推理强度”，并从默认档起步，当任务需要更深入的规划时再往上调。

在这款模型上，这条建议之所以一旦被忽视就代价高昂，原因在于推理 token 会落在账单的哪一项上。推理 token 属于输出 token，而 Astra 的输出价格是每百万 $50.00——是输入费率的十倍，也是缓存输入费率的五十倍。所以这笔权衡并非抽象：

• 每轮每增加 1,000 个推理 token，按输出费率需花费 0.05 美元。

• 在150轮的会话中，每轮保留1,000个额外推理token的成本约为$7.50；保留5,000个额外的成本约为$37.50。

• 在下面的示例会话中，输出已经是单项金额最大的一行：每轮 $0.200，而缓存读取为 $0.090 —— 推理量的增长才是让总额上升最快的因素。

OpenAI 没有发布的，是一份按努力程度分列的表格：无论 xhigh 还是 max 在编码任务上相对于 medium 会输出多少推理 token，都没有厂商给出的数字，也没有任何厂商基准是按努力程度分列的。任何向你引用精确的“max 成本是 2 倍”比例的人，引用的都是自己的测量结果，而不是 OpenAI 的。诚实的做法是：拿一个代表性任务，以两个努力级别各跑一次，然后读取响应中的 usage 区块——这个数字乘以每百万 50 美元，就是你的真实努力溢价。

测量结果，每项都有其自身的来源

编码和终端工作方面，除另有标注外，所有数据均由Ope​AI作为厂商报告。Terminal-Bench 4.0：GPT-6 Astra达到57.9%，相比之下GPT-5.6 Sol为37.3%，Claude Fable 5.1为55.8%——Ope​AI估计，与GPT-5.6 Sol相比，每任务API成本约低9%，与Claude Fable 5.1相比低63%。Datacurve的DeepSWE v1.1将Astra置于Datacurve自有基准上的74.1%，Datacurve称这一数字创下新纪录，一些报道将其四舍五入为74%。在更广泛的智能体测试集上，Ope​AI报告OSWorld 2.0为72.6%，每任务约40分钟——比GPT-5.6 Sol每任务少约47%的时间——同时FrontierMath Tier 4为98%，ARC-AGI-3为99.9%，ExploitBench为100%，Ope​AI称这些均为饱和或实际已饱和的层级。这些都是厂商的数据；我们尚未复现，而ARC Prize对ARC-AGI-3这一数字的独立审查发现，它是在特殊的提供商适配器环境下测得的，在标准条件下则会下降。

那个并非来自厂商的数字，才是代码评审工作流最应关注的。CodeRabbit 于 2026-09-04 发布了自己对 Astra 的评估，而结果比标题所暗示的更有限。在跨文件拉取请求上——即那些需要把某项改动与代码库其他位置的后果联系起来的困难评审——Astra 发现的缺陷比 GPT-5.6 Sol 多约 20%，可操作缺陷覆盖率为 57.1%，而后者为 47.6%。在整体评审上，这一优势基本消失：61.3% 对 59.0%，大约高出 4%。CodeRabbit 将两者都描述为“早期、方向性的结果”，不足以确立排名，并指出其方法无法分离出改进的成因。Ope​nAI 的发布页面将同一成果描述为“在跨文件拉取请求上提升超过一倍”；而 CodeRabbit 自己的文章给出的是上述 20% 和覆盖率百分比。要看百分比，而不是摘要。

这种不对称性是本页上对决定如何部署模型而言最有用的单个数字，而且它指向与价格相同的方向：增益集中在跨文件推理上，所以那正是你该投入模型的地方。

Codex 中的计算机使用功能会给你的工作流程带来哪些变化

OpenAI 表示，更新后的 Codex 运行框架使 GPT-6 Astra 在 Mind2Web 上的任务完成速度比当前 GPT-5.6 Sol 体验快 1.9 倍。Mind2Web 是网页任务自动化，所以可以这样理解：必须接触浏览器或 GUI 的智能体工作会显著更快完成，而只要你使用 Codex，运行的就是同一个更新后的运行框架。配套图表是上方的 OSWorld 2.0 结果——每个任务约 40 分钟，成功率为 72.6%，每个任务耗时比 Sol 少约 47%。

对开发者来说，实际后果是值得委派的工作发生了变化。那些以前端到端自动化起来太慢的流程——操作没有 API 的预发布控制台、通过 UI 复现 bug、走完多步骤表单来生成测试夹具——如今已进入智能体运行比手工完成更便宜的范围。这也提高了 OpenAI 随之一同发布的企业侧控制的价值：ChatGPT Work 和 Codex 新增了确认策略，也就是在执行会产生重大后果的操作前先获得批准，并对不安全或未经授权的工具调用进行自动审查。如果你要让智能体在真实界面中点击操作，那么这层审查就是挡在一次糟糕运行与一个糟糕下午之间的那道防线——也正是因为如此，企业访问权限默认关闭、由管理员根据适用的费率卡启用，才是一项治理功能，而不是障碍。

按工作流定价，而非按令牌定价

以下是价格，有名有姓，也标了日期。根据 OpenAI 定价页面（读取于 2026-09-16），gpt-6-astra 标准版为每百万输入 token 10.00 美元、每百万缓存输入 token 1.00 美元、每百万缓存写入 12.50 美元、每百万输出 token 50.00 美元。Batch 和 Flex 按上述费率的一半计费；Fast 模式则翻倍。在智能体循环里，决定你账单的正是缓存输入那一行，因为编码智能体每一轮都会重新发送一大段几乎不变的上下文，而缓存输入的成本只有全新输入的十分之一。

在做算术之前，有两个门槛很关键。OpenAI 的模型文档说明，输入 token 超过 272,000 的提示词，其输入费和缓存费率按 2 倍计价、输出按 1.5 倍计价针对整个请求——而不只是超出的那部分——并且定价页面上长上下文档位标价为输入 $20.00、缓存输入 $2.00、输出 $75.00。而且如上所述，每一个推理 token 都按输出费率计费。

以一个现实的通宵重构为例：150 个模型轮次，每轮平均 100,000 个输入 token，其中 90,000 个是缓存读取，10,000 个是新增；每轮 4,000 个输出 token，包括推理。在 272K 阈值以下，按标准费率计算：

• 缓存输入 — 90,000 个词元 × 每百万 $1.00 = 每轮 $0.090

• 新输入 — 10,000 个 token × 每百万 $10.00 = 每轮 $0.100

• 输出 — 4,000 个 token × 每百万 $50.00 = 每轮 $0.200

• 总计 — 每轮 $0.390，因此 150 轮的话，本次会话约为 $58.50

现在把同一会话移过阈值。在每轮 300,000 个输入 token 时——270,000 个已缓存，30,000 个为新输入——整个请求会重新计价，因此缓存输入翻倍至 $2.00，新输入翻倍至 $20.00，输出则升至 $75.00：

• 缓存输入 — 270,000 × 每百万 $2.00 = 每轮 $0.540

• 新输入 — 30,000 × 每百万 $20.00 = 每轮 $0.600

• 输出 — 4,000 × 每百万 $75.00 = 每轮 $0.300

• 总计 — 每轮 $1.44，或 150 轮约 $216.00

同样的任务形态，账单大约高出 3.7 倍，而全部差别就在于你的转录内容落在 272,000 个 token 的哪一侧。这就是用一句话说明笔记机制价值的论据：如果持久笔记和可搜索历史能让你保持更精简的工作上下文，而不是把整份转录一路拖着走，那么这个功能在输入 token 上就已经回本，甚至还没开始对质量产生帮助。这同样也是一个论据：不要让无人值守的运行无上限地增长转录内容。

为了直观对比，同样的 150 轮会话、同样的 token 配置，在更便宜的档位上：GPT-5.6 Terra 按其公布的 $2.00 输入 / $0.20 缓存 / $12.00 输出价格计算，约为 $12.90；GPT-5.6 Luna 按 $0.20 / $0.02 / $1.20 计算，则约为 $1.29。这些只是基于 Ope​nAI 公布费率的算术结果，并不代表它们能完成同一任务——而这正是接下来两节要说明的重点。

如果你正在跨提供商比较这一切，那么值得了解的是，OrcaRouter 以 0% 的加价将提供商标价原样传递，因此供应商的价格变动当天就会在路由端点上生效，而不是等到下一张发票时才体现。

设计时需要考虑的失效模式

Astra 是一个基于长上下文设计的长时程模型，而问题恰恰存在于这一描述的两半之中。这些是社区发现和厂商事后复盘，并非我们自己的测量结果。

• 本周，上下文管理实验出现了一个bug。Ope​nAI 于 2026-09-12 发布的事后复盘确认，这项选择加入的实验“导致过早停止以及对过期消息的回复”，影响了大约 4,000–5,000 名用户，随后已被停用。同一份事后复盘还指出了发布周质量投诉的另外两个原因：为更早模型编写的技能发生误触发，并阻止 Astra 检查自己的工作；以及配置错误的推理服务引擎导致一部分尾部流量质量下降。随后在 09-12 午夜到 09-13 之间进行了一次用量重置。

• 过度思考与测试蔓延。一个被广泛分享的 r/codex 帖子描述道，Astra 在响应一个小功能请求时，先搭建层层验证、冒烟测试和哈希校验，以多种顺序运行它们，并在该功能存在之前很早就报告用量计接近耗尽。这些报告是个体叙述，而非受控测量，而且上个月也有关于其他前沿模型的类似抱怨流传——所以应把它当作一个需要界定范围的真实模式，而不是一个可以据此规划的速率。

• 不会终止的运行。Flask 的创造者 Armin Ronacher 描述了让 Astra 在一次无人监督的运行中持续了 35 个小时，到结束时，它已在 79 次提交中产出约 75,000 行净代码、约 1,400 条代理间消息，以及约 1,200 美元的 API 费用——每次提交约 15.50 美元——而据他评估，没有交付任何有价值的东西。关于 token 数量的报告各不相同，因此对该数字应宽松看待。他认为缺失停止条件既是运行框架问题，也是模型问题，这是可操作的解读：在开始之前先定义完成。

• 相反方向的失败同样存在。社区报告描述 Astra 在任务尚未真正完成时就停下来，等待提示才继续——这正是同一个根因从另一侧显现出来：对“完成”的定义不够明确。在你的任务提示词中，明确定义“完成”是价值最高的一句话。

• 长时间会话可能变得无法恢复。Codex 未解决的 issue 报告了一种第22条军规式的困境：上下文窗口被填满，自动压缩随之触发，而压缩任务本身又耗尽了上下文，于是整个线程无法恢复——另外还单独报告称，在某些配置下，Pro 搭配 Astra 时原生笔记与历史路由会返回 404，而切换窗口则可能丢弃任务状态。这两者都是尚未解决的报告，而非厂商的官方说法，但它们都表明：应当把运行过程以检查点方式提交到 git 中，而不是指望会话能自行存活下来。

• 过时的笔记是一种设计属性，而不是缺陷。没有任何东西能保证一条笔记会反映它所描述文件的当前状态，而且搜索是字面子串匹配，而非语义匹配。请将源路径与笔记一起存储，在发生变化时重新验证，并把无人值守运行产生的笔记视为需要核查的证据，而不是可以直接依赖的真相。

• 使用上限是眼下最集中的投诉。2026-09-14 当周的报告中，上限比发布当周最多收紧四倍，还有一项尚未解决的投诉称 xhigh 档消耗的额度比 medium 档更少——若情况属实，这意味着投入程度与配额并不同步。OpenAI 尚未公布 Astra 各套餐的具体数值上限。

当更便宜的型号是正确选择时

上述实测结果已经替你做出了路由决策。Astra 的优势集中在跨文件或跨小时的工作上：跨文件审查、长时程智能体任务、计算机使用流程。在普通的单文件编辑、机械式重构、测试脚手架和格式化任务上，相较 GPT-5.6 Sol 约 4% 的整体审查差距，并不足以证明当前每令牌价格约 2.5 倍的合理性——而 CodeRabbit 自己的结论也指向同一方向：推荐智能任务路由，而非全盘替换。把昂贵模型留给其优势能够显现的任务，其余任务则降级路由。

具体来说，一种可行的分工是：GPT-6 Astra 负责跨文件修改、不熟悉的代码库、持续数小时的智能体运行，以及任何涉及浏览器的任务；GPT-5.6 Terra 负责范围明确的编辑、样板代码和测试生成；GPT-5.6 Luna 负责分类、抽取以及大批量的机械性处理。根据上述会话计算，全部用 Astra 运行与其中三分之一用 Astra 运行之间的差异，就是同样的 150 轮下大约 58.50 美元与大约 28 美元之间的差异。

要正确地实现这种分流，正是路由层存在的意义。OrcaRouter 把 200 多个模型统一在同一个 API 之下，因此上面的分流只需改一次配置，而不必做三次集成——而且自动故障转移意味着，某个实验性功能哪怕像这个一样赶上糟糕的一周，也只会拖慢你的运行，而不会让它彻底终止。对于一个其上下文机制连 Ope​nAI 自己都仍标注为实验性、并且一度将其停用的模型来说，配置第二条路径并非多疑，而是恰到好处的谨慎。

接下来值得关注的事项

有四件事会改变这一页，而这四件事都还没有定论。上下文管理实验是否会重新开启、以什么形式开启——Ope​nAI 表示它将成为 Astra 的默认设置，这意味着上面那行配置最终将不再由你自行设定。Pro 上关于笔记和历史的 404 报告是否会了结，因为这正是该机制是如文档所述那样运行、还是只在部分路由上运行的区别。Ope​nAI 是否会公布按 effort 划分的 token 或成本数据，这是如今每一项 effort 决策中缺失的那个数字。以及发布周期间收紧的各项使用上限，是否会在 2026-09-10 暂停新 $200 Pro 订阅的那波需求被消化之后放宽。

在那之前，操作手册很短。用 codex -m gpt-6-astra 固定模型；只有当你在客户端中拥有 Plus、Pro 或 Pro Lite 登录时，才启用该实验；显式设置 effort，而不是相信滑块标签；将你的工作上下文保持在 272,000 个 token 以下，因为超过那里账单就会翻倍；在离开之前先定义好什么叫完成；并把简单的工作分流到更便宜的地方。这个模型来自 2026-09-03，它哪儿也不会去；围绕它的工具链才是仍在稳定下来的部分。

出现的问题

对于普通规模的任务，跨窗口笔记功能值得启用吗？一般不值得。它的存在是为了解决跨上下文窗口边界造成的信息丢失，因此对于能装进单个窗口的任务来说，它只会增加额外环节——包括一条因 2026-09-12 的一个 bug 而被停用的实验性代码路径——却不会消除任何痛点。长期跨度的工作可以开启它，范围明确的编辑则保持关闭。

1,050,000 token 的窗口能在我的配置中取代检索吗？从成本角度看不能。每一轮都回读大上下文，每一轮都会计费，而且当输入超过 272,000 token 时，整个请求会重新计价为输入 $20.00、输出 $75.00。一个能让工作上下文保持更小的检索步骤通常是更便宜的设计，这正是 notes 机制有意思的地方：它是内建于 harness 之中的检索。

任务结束后，笔记会怎样？ OpenAI 的文档将这一机制限定在同一任务之内，而社区的解读也指出，这些笔记是存储在对应任务之下的，并不会自动延续下去。不要想当然地认为新任务会继承上一个任务的笔记；任何必须留存下来的内容都应放在你的代码仓库里，而不是智能体的记忆中。