OpenAI 改变了什么
该公告很简短，其中的每个细节都很有用。
对于 Codex 和 Work 中的 GPT-6.1 Sol，新的默认值是 500k，高于之前的 272k。这并不是上限。帖子中写道："我们未来还会提高，" 并给出了该模型的最大值："GPT-6.1 Sol 的最大上下文长度为 1M。" 它还将 500k 框定为一种精心选择的平衡，而不是限制："它经过了仔细测试，是大多数用户的新契合点。"
默认值是可以更改的。帖子中写道："您仍然可以覆盖它，" 无论往哪个方向。
订阅者的定价也随之改变。第二条帖子指出，当使用量来自订阅时，不会对 GPT-6.1 Sol 收取长上下文费用。
在撰写本文时，这些帖子中描述了这一变化。Codex 变更日志的最新条目是 10 月 8 日发布的 GPT-6.1 Sol 的 Ultrafast 模式，而 Codex 模型页面并未列出其上下文长度。如果您需要书面数字来进行团队决策，请在下一周再次查看这两个页面。
Codex 中的压缩是什么
每个 Codex 对话都有一个上下文窗口：模型可以同时考虑的对话量、工具输出和指令量。Codex 的配置参考清楚地定义了该设置。model_context_window 是 "活动模型可用的上下文窗口 Token。"
当对话接近该限制时，Codex 会对其进行压缩。较早的变更日志条目描述了这种行为："当接近上下文窗口限制时，上下文压缩会自动总结会话。" 发生这种情况的时间点有其自身的设置。model_auto_compact_token_limit 是 "触发自动历史记录压缩的 Token 阈值（未设置则使用模型默认值）。"
您也可以自己触发它。斜杠命令参考列出了 /compact，其描述为 "总结可见对话以释放 Token。" 并表示在您确认后，"Codex 会用简明扼要的总结替换较早的轮次，在保留关键细节的同时释放上下文。"
最后这句话就是权衡所在。总结保留了压缩步骤判定为关键的内容。较早轮次中的其他所有内容都会从对话的工作上下文中消失。
压缩何时仍会触发
500k 窗口有很大的空间，但长期的 Codex 工作会很快填满空间。
长期运行的目标。 Codex 的长期运行工作指南鼓励您将相关工作保持在同一个对话中，以便模型可以使用相同的上下文来选择下一步。这个建议是合理的，但这也是对话增长超出任何阈值的原因。
大型工具输出。 测试运行、日志和文件读取都会进入上下文。一个漫长的调试会话从工具输出中添加的内容可能比您自己的消息还要多。
手动压缩。 /compact 的工作方式与以前相同。如果您或您的团队成员经常使用它来保持会话精简，总结步骤仍然会发生，只是按照您的时间表进行。
您自己的阈值。 如果在您的配置中的任何位置设置了 model_auto_compact_token_limit，压缩将从该数字开始，而不是从新默认值派生的点开始。
压缩也有您可以挂钩的可观察边缘。Codex 的钩子（hooks）文档描述了两个事件。PreCompact "在 Codex 压缩对话之前运行。" PostCompact "在 Codex 压缩对话之后运行。" 两者都会报告触发是手动还是自动。因此，您不必猜测长会话是否被压缩了。您可以确切知道。
哪些旧设置会覆盖它
对于读到公告并期望明天就能获得更长会话的人来说，这部分最有可能让他们感到意外。
Codex 从多个层级读取配置，其配置指南列出了"优先级最高优先"的顺序：
- CLI 标志和
--config覆盖 - 项目配置文件，从项目根目录一直到您的工作目录
- 使用
--profile选择的配置文件 ~/.codex/config.toml中的用户配置- 云端托管默认值（当为您的工作区交付时）
- 系统配置
- 内置默认值
新的 500k 是一个默认值。默认值位于该列表的底部。上层中相同设置的任何值都会胜出。
这很重要，因为在 272k 作为默认值时流传着一些建议。GPT-5.6 和 GPT-6 Sol 的指南引导人们手动设置 model_context_window 和 model_auto_compact_token_limit，要么是为了突破旧的默认值，要么是为了更早、更便宜地进行压缩。如果您遵循了其中之一，这些行可能仍保留在您的配置文件中。示例配置描述了默认值：对于 model_context_window，它说 "default: auto for model"，对于 model_auto_compact_token_limit，它说 "unset uses model defaults"。设置它们后，模型默认值将不再适用。
需要检查的几个具体情况：
- 固定的窗口。 如果您的用户配置将
model_context_window设置为 272k 时代的值，那么这就是您获得的窗口。 - 固定的压缩阈值。 如果设置了
model_auto_compact_token_limit，即使窗口更大，压缩也会在您的数字处触发。 - 团队共享的项目文件。 仓库中的
.codex/config.toml优先级高于您的用户配置，因此某人几个月前添加的值适用于信任该项目的所有人。 - 配置文件。 如果您使用配置文件启动，其值的优先级高于您的用户配置。
- 托管默认值。 如果您的工作区交付了云端托管配置，管理员可能已为您设置了这些值。
还有一个值得了解的范围设置。model_auto_compact_token_limit_scope "控制自动压缩阈值是计算完整的活动上下文（total，默认值），还是仅计算携带的压缩窗口前缀之后的增长（body_after_prefix）。" 如果您更改了它，压缩时机将遵循您的选择。
这些都不是错误。对于较小的默认值，它们是合理的选择。它们只是不会自行更新。
更大的窗口让哪些内容保持原样
更大的上下文窗口改变了单个对话在压缩前可以运行多长时间。它不会改变上下文在对话之间的移动方式，Codex 文档在多处划定了这一界限。
指令在开始时加载。 "Codex 在启动时构建指令链（每次运行一次；在 TUI 中，这通常意味着每个启动的会话一次）。" 该链是您的 AGENTS.md 文件，并且它是有上限的：一旦合并大小达到 project_doc_max_bytes（默认 32 KiB）定义的限制，Codex 就会停止添加文件。更大的窗口不会提高该上限。如果规则似乎消失了，我们关于 Codex 跳过 AGENTS.md 规则的指南涵盖了常见原因。
新对话从指令开始，而不是旧的转录记录。 指令链是在 Codex 启动时构建的。如果您开启了本地记忆，它们会在后台从符合条件的较早对话中生成，这与向前携带对话的完整上下文不同。
记忆是分开的。 OpenAI 的记忆页面指出 "ChatGPT 网页端使用 ChatGPT 记忆，而本地 Codex 客户端使用独立的本地记忆存储和控制。" 它还给出了一个明确的经验法则："将记忆视为有用的召回层，而不是必须始终适用的规则的唯一来源。" 本地记忆也不会在任务中途形成，因为 Codex "会跳过活动或短暂的会话。" 我们关于开启 Codex 本地记忆的演练解释了这些控制。
Work 遵循其自身的设置。 对于记忆，OpenAI 表示 ChatGPT Work "使用适用于您的帐户和工作区的记忆设置；它不使用本地 Codex 记忆存储或本地记忆控制。" 您的本地 config.toml 管理读取它的 Codex 客户端。
人们尝试的其他方法
将窗口设置为 1M 并忘记压缩。 在模型的最大限制内，您可以这样做，但足够长的任务仍然会达到适用的任何阈值。
保留旧的阈值。 为 272k 选择的压缩限制会使压缩保持在该点触发。
期望下一个对话能够记住。 更大的窗口与单个对话共存亡。
信任包含确切规则的总结。 压缩保留了它判定为关键的内容。必须遵守的规则属于 AGENTS.md，它们在开始时加载。
假设团队中的每个人都有相同的设置。 配置文件、项目文件和托管默认值可能会让两个人在同一个仓库上拥有不同的窗口。
解决方法：检查什么覆盖了默认值，决定压缩必须保留什么，然后事后将其放回
步骤 1：审计您的配置以查找固定的上下文设置
打开 ~/.codex/config.toml 并查找 model_context_window、model_auto_compact_token_limit 和 model_auto_compact_token_limit_scope。在您的仓库中的任何 .codex/config.toml 以及您使用的配置文件中执行相同的操作。
对于找到的每个值，决定您是否仍然需要它。如果您设置它只是为了解决旧的 272k 默认值问题，请将其删除并让模型默认值生效。如果您是有意设置的（出于成本或速度考虑），请保留它并写下原因，以免下一个人不小心将其删除。如果您处于托管工作区中，请询问管理 Codex 配置的人员为您设置了什么。
步骤 2：告诉压缩必须保留什么
Codex 允许您替换压缩提示词。配置参考将 compact_prompt 描述为 "历史记录压缩提示词的内联覆盖。" 还有一个标记为实验性的基于文件的选项。
请谨慎使用。一个好的压缩提示词应该指明必须保留的类别：当前目标、在此对话中做出的决定、更改的文件以及未解决的问题。保持其简短并针对您的工作方式。有关另一个工具中的类似方法，请参阅我们的 Claude Code 自动压缩设置指南。
步骤 3：在压缩后将基本要素放回
某些上下文应该被重申，而不是被总结。Codex 的钩子文档描述了 SessionStart 钩子，它可以匹配由压缩引起的会话启动，并在下一次模型请求之前运行，添加模型视为额外开发者上下文的上下文。这是重申长任务无法承受丢失的少数事实的文档化方法。
然后将持久知识移出对话。规则放入 AGENTS.md。值得在对话之间重用的决定应该放在比任何单个会话寿命更长的地方。
在 MemoryLake 中进行设置
更大的上下文窗口可以将更多单个对话保留在视野中。您下周需要的决定仍然需要一个不是对话的归宿。MemoryLake 是一个记忆层，用于将这些决定保存在您维护的一个列表中，供 Codex 和其他助手使用。
您自己用自己的话编写条目。不会从您的 Codex 配置、您的本地 Codex 记忆、您的 ChatGPT 帐户或任何供应商的存储中读取、写入或删除任何内容。如果您在托管工作区中工作，请检查您组织关于将项目详细信息复制到其他地方的政策。
步骤 1：创建 API 密钥
登录并从控制面板生成密钥。该密钥属于您的 MemoryLake 工作区，与您的 OpenAI 帐户是分开的。
步骤 2：上传您的第一批记忆
从压缩总结最容易模糊的内容开始：架构决策及其原因、尚未写入 AGENTS.md 的规范以及已知陷阱。每个条目一个决定，并注明日期。
步骤 3：连接您的 AI 和代理
连接 Codex 和您使用的其他助手。然后，每个新对话都可以利用相同的决定，而不管上一个对话的窗口有多大或何时进行了压缩。
这在实践中改变了什么
第一个区别是您知道自己实际获得了哪个窗口。在审计之后，新的默认值要么适用，要么您已选择不使用它。
第二个区别是长会话中的意外更少。有了钩子，压缩就成了一个您可以观察到的事件，并且基本要素会在事后恢复。
第三个区别是更清晰的工作分工。上下文窗口保存当前任务。AGENTS.md 保存规则。独立的记忆保存决定。当您更换模型时，同样的分工也适用，正如我们关于切换到 GPT-6 Astra 的指南所描述的那样。
第四个区别是减少了对模型脑子里保留内容的依赖。OpenAI 本身也写过关于洞察模型推理局限性的文章，这在我们对随着该窗口变窄需要写下什么的探讨中有所涵盖。写下决定是可靠的一半。Kiro 用户也面临同样的问题，这在决定在 Kiro 的压缩中保留什么中有所涵盖。
500k 默认值的最佳实践
在假设之前先进行审计。 任何配置层中固定的值都会覆盖新的默认值。
保持有意设置的文档化。 固定值旁边的注释可以省去下一个人的猜测。
检查项目文件。 共享的 .codex/config.toml 适用于信任该项目的所有人。
留意压缩。 钩子会告诉您它何时发生以及是什么触发了它。
在压缩后重申基本要素。 不要依赖总结来获取规则。
将规则保留在 AGENTS.md 中。 它在每个会话开始时加载。
在对话之外写下决定。 任何窗口大小都无法将它们带到下一个对话中。
结论
OpenAI 于 2026 年 10 月 11 日将 Codex 和 Work 中 GPT-6.1 Sol 的默认上下文长度从 272k 提高到 500k，以减少压缩，并停止对订阅使用收取长上下文费用。该模型的最大值为 1M，默认值可以被覆盖。
当长任务达到适用于您的阈值时，压缩仍然会发生。而且该阈值可能根本不是新的默认值：CLI 标志、项目文件、配置文件、您的用户配置或托管默认值中的值都高于它。
检查您的配置，决定压缩必须保留什么，并在其运行后重申基本要素。然后，将超出单个对话范围的重要决定保存在更大的窗口永远无法触及的地方。