截至 2026 年 7 月 10 日，GPT‑5.6 Sol 的公开 API 规格是 1,050,000 tokens；但在 Codex CLI 0.144.1 的隔离探针中，Codex 模型目录把产品会话原始窗口封顶在 372,000，客户端再按 95% 报告 353,400 的有效输入窗口，并在活动上下文累计涨到 334,800（原始窗口的 90%）时自动触发压缩——是“用量往上顶到这条线”就压，不是“低于它才压”。一个最小新会话在用户几乎什么都没说时已经消耗 12,446 tokens，因此从这里到第一次压缩、还能继续塞进去的空间约为 32.2 万（334,800 − 12,446 ≈ 322,354）。这不是“模型缩水”，而是模型能力、产品预算、内部开销与压缩策略四套口径叠加后的结果。
这是带版本号与日期的产品快照，不代表所有账号、套餐、地区或未来 Codex 版本永久固定为同一数值。
先把“一兆”说清楚：同一句上下文，至少四种口径
模型能吃下一兆，不等于 Codex 产品会把这一兆全部交给一个会话。
“上下文窗口”是模型生成下一步时能够参考的工作记忆：系统指令、用户消息、文件、工具定义、工具返回、历史回复和即将生成的输出都可能占位。它不是训练数据量，也不是“用户可以粘贴的纯文本额度”。OpenAI 的模型页把 GPT‑5.6 Sol 定义为 1,050,000 tokens 总上下文，其中最大输入 922,000、最大输出 128,000。[1]
GPT‑5.6 Sol API 总上下文
Codex 0.144.1 原始窗口
session telemetry 报告值
默认自动 compact 线
模型能力上限
API 模型页描述的是一次请求的理论总池。直接调用 API 时，应用开发者负责组织消息、工具和压缩策略。
产品会话预算
Codex 作为 Agent 产品，可以为同一底层模型设定更小的目录窗口、预留余量和自动压缩线。
准确表达不是“GPT‑5.6 Sol 只有 35 万上下文”，而是：GPT‑5.6 Sol API 有 105 万模型窗口；在本次 Codex 0.144.1 产品快照中，会话按 37.2 万目录窗口、35.34 万有效输入窗口运行。
窗口账本：372K、353.4K、334.8K 为什么同时成立
这三个数字不是互相矛盾，而是同一套产品策略的不同刻度。
Codex 协议把 effective_context_window_percent 的默认值设为 95%，源码注释明确说这是为系统提示、工具开销和模型输出留出余量。[3] 另一个函数把自动压缩上限默认设为原始窗口的 90%，即便用户显式配置更高，也会取更小值。[4]
5% headroom 是产品层统一预留；12,446 是已经进入有效输入预算的实际启动 payload。它们是两层不同概念，不能把“5%”误读成“系统提示词恰好占 5%”，也不能把二者混成一笔账。
这条线的方向最容易被读反：自动压缩不是“用量低于 334,800 就压缩”，而是活动上下文从下往上增长，一旦累计占用顶到约 334,800（原始窗口的 90%）就触发——90% 是 Codex 服务端的硬顶，本地把 auto_compact_token_limit 配得再高也会被压回 90%。[4]触发后 Codex 把较早的历史压成摘要、活动占用回落，再带着摘要继续往下做。它落在 95% 有效输入线之前，正是为“压缩这一步本身 + 后续输出”预留余量。所以从最小新会话（启动已占 12,446）到第一次压缩，你还能再写入约 334,800 − 12,446 ≈ 322,354（≈32.2 万） token；这才是“首次压缩前可继续增长的空间”那句话的完整算法。
上下文解剖：到底什么在占空间
一个 Agent 会话从来不是“用户问题 + 模型回答”这么简单。它更像一张持续滚动的项目账本。
- 模型基础指令：Codex 的工作方式、沟通方式与行为边界。
- 工具 schemas：命令、补丁、搜索、浏览器、MCP 等工具的名字、描述和参数。
- 系统与开发者规则：权限、沙箱、插件、App 与 Agent 调度规则。
- Skills / 插件 / MCP：目录说明与按需加载的能力定义。
- 项目规则：如
AGENTS.md、工作区说明和约束。 - 运行环境：cwd、日期、时区、操作系统、网络与文件权限。
- 用户与助手历史——每一轮需求、澄清、决策和回答。
- 文件与检索结果——源码片段、文档、网页、图片与附件。
- 工具调用与返回值——终端日志、测试失败、构建输出、搜索结果，常常是增长最快的一项。
- 压缩摘要与推理工件——为了延续任务而保留的结构化状态。
一个最小隔离样本：用户只说“回复 OK”，为什么已经有 12,446 tokens？
研究使用空临时目录、忽略用户配置与规则、只读沙箱和低推理强度发出最小请求。用户提示只占十余个 tokens，但服务端报告首轮输入为 12,446。再使用 OpenAI 官方 Token Counting API 对模型基础指令单独计数，可得到以下账本：
MEASURED SAMPLE · Codex CLI 0.144.1 · 2026-07-10。9,177 是总量上的精确差值，但 Codex 没有继续返回每个工具 schema 的逐项账单，因此不能伪装成更细的“工具精确分解”。
扩展环境为什么会更大
一旦启用更多 Skills、插件、MCP、项目规则和多 Agent 调度，启动负载会继续增加。在一个功能较多的匿名化对照样本里，Skills 目录约增加 1,976 tokens，项目规则约增加 395，环境描述约增加 102。它们说明“几千到一万多的初始开销”是合理量级，但不是所有用户都固定相同。
系统提示通常是稳定底噪；长期会话里更危险的是重复的工具输出、全量日志、整文件读取与不断累积的历史。它们会让有用决策淹没在噪声里，形成 context pollution。
证据链：一套可复现的窗口审计
最可靠的结论，不来自 UI 上的一条进度条，而来自模型目录、源码、独立请求和服务端 token 计数的交叉验证。
- 01 · VERSION固定日期、CLI 版本、模型名与登录方式。
- 02 · CATALOG读取
context_window与max_context_window。 - 03 · PROBE在空目录发出最小请求，并故意配置 1.05M。
- 04 · TELEMETRY读取
task_started与当轮token_count。 - 05 · COUNT用官方 Count input tokens API 做差分归因。
- 官方规格API 模型页确认 1,050,000
这回答“底层模型能做什么”。
- 产品目录Codex 0.144.1 模型目录给出 372,000
这回答“当前 Codex 给会话分配多少”。
- 源码钳制配置值会与 max_context_window 取最小值
这回答“手动写 1.05M 为什么没有生效”。
- 服务端回报独立请求最终 telemetry 为 353,400
这回答“真实运行时到底按什么数工作”。
- 精确计数官方 token-counting endpoint 计算消息、指令和工具
这回答“哪些结构消耗了输入预算”。
- 固定版本、日期、模型与配置
- 读当轮
last_token_usage - 对同一 payload 做差分计数
- 把事实、样本与推断分栏
- 只看 UI 百分比
- 把累计 token 当当前占用
- 用字符数除以四冒充精确分词
- 塞几十万垃圾文本做昂贵压力测试
压力测试在这里反而不是最强证据：Codex 会在接近上限前主动压缩，单纯塞入几十万 tokens 很难区分“模型拒绝”“客户端压缩”和“历史截断”。目录、源码与 telemetry 的交叉验证更直接。
会话如何长大：缓存、累计值与自动压缩
Agent 每调用一次工具，往往就会形成下一次模型请求；同一段历史会被一轮轮重新带上。
last_token_usage.input_tokens 更接近当前这一轮实际送给模型的活动输入。
total_token_usage 是多轮请求累计值，完全可以超过百万甚至千万，并不表示单轮窗口越界。
cached_input_tokens 是 input_tokens 的子集。缓存可以降低重复计算的成本和延迟，但缓存内容依然是模型这轮可参考的上下文，不能从窗口占用里扣掉。[9]
Codex 的模型目录还可以限制单个工具输出写入历史的预算；本次 Sol 快照使用 tokens/10,000 的截断策略。这不是“每个工具固定占一万”，而是避免单次巨型日志把整条会话迅速挤满。真正长期有效的做法仍是让工具只返回相关片段。
Codex 与 Claude Code：必须用同一把尺子比较
Claude Code 的优势不是“它没有内部提示词”，而是它当前为符合条件的会话开放了更大的产品池。
产品目录原始池
用量涨到 334.8K（90%）即压缩
支持模型的扩展池
约接近 95% 时自动压缩
| 维度 | GPT‑5.6 Sol API | Codex + GPT‑5.6 Sol | Claude Code 1M 模式 |
|---|---|---|---|
| 模型级总窗口 | 1.05M | 底层模型相同 | 支持模型为 1M |
| 产品会话公开池 | 应用自行管理 | 本次快照 372K | 符合模型/套餐条件时接近 1M |
| 系统提示占空间 | 是 | 是 | 是 |
| 项目规则占空间 | 应用自行注入 | AGENTS.md 等 | CLAUDE.md、memory 等 |
| 工具 / MCP 占空间 | 是 | 是 | 是 |
| 自动压缩 | 由应用策略决定 | 默认 90% raw window | 默认约接近 95% |
| 用户独占整个数字 | 否 | 否 | 否 |
| 可用性条件 | API 权限与价格 | 版本、账号与远程目录 | 模型、套餐、提供商与开关 |
Anthropic 当前文档明确提供 opus[1m] 与 sonnet[1m] 选择；部分当前模型原生就是 1M，具体是否自动包含取决于模型、套餐与提供商。[10] Claude Code 也会在用户输入前加载系统提示、CLAUDE.md、记忆、工具名和 Skill 描述，并在长会话中自动清理旧工具输出、总结历史。[11]
Codex 与 Claude Code 都要从总池里支付内部开销。 差异不在“谁没有系统提示词”，而在产品当前愿意向一个会话暴露多大的总池、何时压缩，以及哪些套餐承担长上下文的成本。
如何把有限窗口花在真正有价值的内容上
上下文工程不是“塞得越多越好”，而是让每一轮都保留最值得模型继续参考的证据。
- 目标、验收标准和不可违反的约束
- 已确认决策、变更文件和未完成事项
- 与当前问题直接相关的代码和日志片段
- 可验证的测试结果与关键来源
- 完整构建日志和重复报错
- 与任务无关的整个代码库或大文件
- 没有使用到的 MCP 与工具 schemas
- 子 Agent 的全部过程性噪声
- 让工具精准返回——先搜索，再读取命中的函数或行段，不要默认整文件回灌。
- 让规则短而稳定——把真正长期有效的约束写进根级项目说明，避免长篇背景故事常驻。
- 把探索交给子 Agent——主线程只接收结论、证据和需要决策的分歧。
- 阶段性保存状态——在压缩前沉淀“决定了什么、改了什么、还差什么”。
- 切换任务就开新线程——无关历史会在之后的每一轮持续消耗输入预算。
- 看活动输入，不看累计账单——缓存能省成本，但不能腾空窗口。
任务可增长空间 ≈ 自动压缩线 − 固定启动负载 − 项目规则 − 已保留历史。 对本次最小样本，它约为 334,800 − 12,446 = 322,354；对工具更多、规则更长的环境则会更少。
能证明限制存在，但不能替厂商证明动机
严谨的报告不仅要给答案，也要标出答案停在哪里。
- GPT‑5.6 Sol API 规格为 1.05M
- Codex 0.144.1 目录窗口为 372K
- 运行时有效窗口报告为 353.4K
- 用户配置会被 max_context_window 钳制
- 默认自动压缩线为 raw window 的 90%
- 控制长上下文的服务成本与延迟
- 避免工具日志造成上下文污染
- 用压缩、检索与子 Agent 换取稳定性
- 保持订阅产品的资源预算可预测
OpenAI 没有公开解释“为什么具体选择 372K”。可以观察到的是，GPT‑5.6 Sol 的 API 请求一旦超过 272K 输入，官方模型页注明整个请求会进入更高的长上下文费率：输入 2 倍、输出 1.5 倍。[1] 这能说明长上下文存在真实成本，却不能单独证明 Codex 产品限制的全部动机。
同样，长窗口也不自动等于更高质量。OpenAI 的 Codex 文档把无关日志造成的可靠性下降描述为 context pollution / context rot，并建议用子 Agent 把过程噪声留在独立窗口。[8] 这是工程上的合理取舍，但仍应与“厂商官方解释”分开书写。
远程模型目录可以随版本、账号、套餐、地区与灰度发布变化。复查时应重新运行 codex debug models 和最小探针，而不是把本报告的 372K 当作永久常数。
真正该记住的，不是一个数字，而是一串口径
模型规格写的是能力上限，产品会话交付的是上下文预算。 对这次带版本号的 Codex GPT‑5.6 Sol 快照，准确答案是一串数字：1.05M 模型规格、372K 产品原始窗口、353.4K 有效 telemetry、334.8K 默认压缩线，以及约 322K 的最小样本任务增长空间。
Claude Code 1M 模式的产品池更大，但它同样要支付系统提示、工具、项目规则、历史与输出成本。上下文工程的成熟标志，不是执着于“能不能塞满”，而是知道什么值得留下，什么应该在进入窗口之前就被过滤。
更大的窗口给你余地；更干净的上下文，才真正给模型判断力。
来源与方法
研究方法：先以官方模型页确认底层规格，再固定 Codex CLI 0.144.1，通过模型目录、固定版本源码、空目录最小请求、session telemetry 和 OpenAI Token Counting API 进行交叉核验。Claude Code 部分仅采用 Anthropic 官方产品与平台文档。所有实测数字均标明版本与日期；厂商未公开解释的动机单独列为推断。
- GPT‑5.6 Sol Model — OpenAI API Docs · 1.05M 上下文、最大输入/输出与长上下文计价说明。
- Codex 0.144.1 Model Catalog — OpenAI Codex 源码 · 372K 目录窗口与工具输出截断策略。
- Codex ModelInfo 协议 — OpenAI Codex 源码 · 95% 有效窗口的默认值与 headroom 说明。
- Codex 自动压缩阈值 — OpenAI Codex 源码 · 默认 raw window 的 90%。
- Codex 配置钳制逻辑 — OpenAI Codex 源码 · 配置窗口与 max_context_window 取最小值。
- Codex 请求结构 — OpenAI Codex 源码 · input、tools、base_instructions 与 output_schema。
- Counting tokens — OpenAI API Docs · 对消息、指令、文件与工具 schemas 进行模型级精确计数。
- Why subagent workflows help — OpenAI Codex Docs · context pollution、context rot 与子 Agent 隔离。
- Prompt caching — OpenAI API Docs · 缓存输入的计数与使用方式。
- Claude Code extended context — Anthropic Claude Code Docs ·
opus[1m]、sonnet[1m]与可用条件。 - Explore the context window — Anthropic Claude Code Docs · CLAUDE.md、记忆、工具、Skills 与压缩后保留规则。
- How Claude Code works — Anthropic Claude Code Docs · 旧工具输出清理与自动摘要机制。
- Context windows — Anthropic Platform Docs · 1M 总窗口的定义、计入项与支持模型。
视觉系统：松墨纸 · Pinemark。图表为本报告基于公开数据绘制的内联信息图。
本报告由 Will 收集整理，仅供学习研究；易变数字与产品可用性请以一手来源和实测为准。