300k

general · First seen 2026-07-27 · Last seen 2026-10-20 · 14 mentions

Overview

300k 指的是约 30 万 token 的模型上下文窗口长度,在 AI 编程工具圈正成为一个常见的“默认档位”——它决定了 agent 一次能读多少代码、多久触发一次自动压缩,直接影响成本和体验。随着 Codex、Claude Code 等工具把可用上下文推到这一量级以上,如何在长上下文与费用之间取舍,成为社区讨论的焦点。

300k 上下文的近期进展

  • Codex 就是 300K 左右的上下文:宝玉指出 OpenAI 的 Codex 实际工作上下文大约在 300K token 附近,这一说法被用来解释其会话长度和压缩行为的表现。
  • Codex 默认上下文从 200k-300k 提升到 500k,最大可到 1M:Codex 的默认上下文由此前约 200k 到 300k 之间提升至 500k,最大可支持 1M,压缩频率因此明显降低,长任务的中断感减少。
  • 宝玉建议 Claude Code 用 /autocompact 限制上下文到 300-400K:针对 Claude Code,宝玉建议通过 /autocompact 命令把自动压缩阈值设在 300-400K,以控制上下文增长带来的成本。
  • Agentic AI 缓存失效导致 1 美元一次的"hi":在 agent 场景中,上下文越长,缓存失效时的重复计费越贵,一次简单输入也可能产生约 1 美元成本,凸显了长上下文的费用风险。
  • 当前焦点与观察点

    300k 之所以被反复提及,是因为它是许多 agent 工具实际运行时的典型窗口量级。围绕它有两个争议点:一是厂商宣传的最大上下文(如 1M)与默认可用上下文(约 300k 或 500k)之间的差距,用户需要弄清自己真正用的是哪一档;二是成本问题——上下文越长,token 计费和缓存失效带来的开销越大,社区因此流行用 /autocompact 这类手段主动压缩、或用 SubAgent 编排把重活分给更便宜的模型。后续值得观察的方向是:默认上下文是否会普遍向 500k 迈进、压缩策略能否做到对用户无感,以及长上下文的单位成本能否随模型迭代继续下降。

    Coverage

    10 on file