周二早上，你打开 ChatGPT 的用量页面，发现额度已经烧掉了 87%——可你明明这周没怎么用 agent：没有通宵跑任务，也没有上传大文件，只是正常聊了一下午。如果你用 Hermes 连的是 ChatGPT Codex OAuth（gpt-5.4 / gpt-5.6 系列），那么元凶很可能是一个被悄悄调大、远超官方宣传的上下文窗口。窗口越大，每次请求塞进去的 token 就越多，订阅额度就烧得越快。好消息是，Hermes 已经在 8 月 23 日修正了默认行为：基础模型回到厂商公布的 272K，想要大窗口就显式选择 -900k 变体。这篇文章讲清楚背后的机制，以及你能怎么控制它。

为什么更大的上下文窗口反而更费钱

先解释一个概念：上下文窗口（context window）是模型一次请求里最多能读到的 token 数量，包括系统提示词、历史对话和工具输出。窗口大，意味着 agent 能“记住”更多东西——但代价是每一轮对话都要把当前窗口里的内容重新发送一遍，这些输入 token 全部计入你的用量。

对于按 token 计费的 API 还好说，用多少付多少；但对于 ChatGPT 订阅（Plus / Pro）通过 Codex OAuth 接入的情况，额度是按月给的。窗口从 272K 悄悄涨到 900K，意味着每轮请求的输入量最多膨胀到三倍多——如果你再开着历史很长的会话，额度几小时烧光是完全可能的。这正是 8 月中旬社区在 Discord 上反馈的现象：明明没怎么用，订阅用量却飞快见底。

Hermes 8 月 16 日曾把 Codex 模型的上下文自动抬到 900K（当时认为“实测能用就用满”），结果让所有 Codex OAuth 会话都默默用上了大窗口。8 月 23 日合并的 PR #92797 纠正了这一点：基础 slug 一律回到厂商公布的 272K 默认值，900K 变成严格的选择加入（opt-in）。

-900k 变体：想要大窗口就显式选

现在，在 /model 选择器里，Codex 系列的基础模型旁边会多出带 -900k 后缀的选项：

• gpt-5.6-sol-900k
• gpt-5.6-terra-900k
• gpt-5.6-luna-900k
• gpt-5.4-900k

这些是 Hermes 侧的别名：选 gpt-5.6-sol-900k 后，实际发给后端的模型 id 会被去掉后缀（还是 gpt-5.6-sol），用量计费也按基础模型算——你只是显式声明“我要用那个实测可达 ~911K 的大窗口”。之所以敢这么干，是因为 Hermes 在 8 月对 ChatGPT 订阅账号做了实测：Codex 后端对外公布 272K，但对订阅账号实际能接收约 911K 的输入。

有一点要注意：不是所有 Codex 模型都有 -900k 变体。像 gpt-5.5 和 gpt-5.4-mini 这类后端真的只给 272K 的模型，加后缀也没用，所以压根不提供变体。Hermes 判断一个 slug 是否“实测 900K”，靠的是 agent/model_metadata.py 里维护的实测清单（_CODEX_900K_ELIGIBLE_BASES），只有清单内的模型才合成变体。

压缩阈值跟着窗口走

上下文窗口不光决定你能塞多少内容，还决定 Hermes 什么时候帮你压缩（compaction）历史——也就是把旧对话总结成摘要，腾出空间继续聊。压缩的触发点是 compression.threshold，默认是窗口的 50%。

这里有个微妙的联动：如果 272K 的窗口也按 50% 触发，那会话才用到约 136K 就压缩了，白白浪费一半窗口。所以 Hermes 对 Codex OAuth 路由下的 gpt-5.4 / 5.5 / 5.6 基础 slug 会自动把阈值抬到 85%（约 231K 才压缩），这就是所谓的 autoraise。

而 -900k 变体正好相反——900K 的窗口按 50% 触发（约 450K），已经非常宽松，不需要 autoraise。8 月 23 日同日合并的 PR #92848 就是做这件事：-900k 变体一律走全局 compression.threshold，基础 slug 保留 85% autoraise。用一句话记：压缩阈值永远跟着你选的窗口走。

想自己掌控？这些配置项给你

如果你不喜欢默认行为，以下配置都能改：

# 关掉 Codex 272K 基础模型的 85% autoraise（恢复全局阈值）
hermes config set compression.codex_gpt55_autoraise false

# 保留 autoraise，但关掉那条一次性提示横幅
hermes config set compression.codex_gpt55_autoraise_notice false

注意：codex_gpt55_autoraise 是历史遗留的键名，实际作用范围包括 gpt-5.4 / 5.5 / 5.6 系列，不只是 gpt-5.5。

其他常用项：

• compression.threshold：全局压缩阈值（默认 0.50，即窗口的 50%）。
• compression.model_thresholds：按模型单独设置阈值，键名做子串匹配、最长匹配优先。比如 1M 窗口的模型可以晚点压缩（"glm-5.2-1M": 0.25），128K 的模型早点压（"claude-sonnet": 0.35）。
• 小窗口地板：上下文低于 512K 的模型，阈值会被抬到 0.75 打底（只升不降），避免窗口还有一半空闲就压缩。
• compression.proactive_prune_tokens：大窗口模型默认 50% 阈值很少触发，旧的工具输出会一直躺在历史里每轮重发。设一个值（比如 48000）可以提前把工具结果清理掉，省 token。
• 想要完全手动指定某个模型的窗口大小，用 model_overrides 的 context_window 字段——我们之前写过一篇完整的配置指南。

小结

上下文窗口不是越大越好，它是一笔每轮都在付的账单。这次 Codex 事件的教训是：默认值应该保守，大窗口留给真正需要长文档、长历史的人显式开启。对你来说，实用建议有三条：第一，日常会话用基础 slug（272K）就够，别盲目追大；第二，只有处理长文档或超长会话时，才在 /model 里选 -900k 变体；第三，用上面的配置项把压缩阈值调成符合你习惯的节奏。另外提醒一句：这些改动目前都在 main 分支上（8 月 23 日合并，晚于 v0.20.5 的发布标签），升级后即可用 hermes update 获取——/model 选择器的模糊过滤是近期 CLI 打磨的一部分，配合 -900k 变体使用更顺手。想知道更多省 token 的日常技巧，可以再看看我们的效率技巧合集。