900K！Hermes一天两次解锁GPT-5.6上下文限制，但要小心这行小字

今天上午我又被 Hermes 的更新速度整不会了。

早上 6 点多，我刚看到 Teknium 把 ChatGPT / Codex OAuth 下的 GPT-5.6 上下文从 272K 提到 350K。当时 Nous Research 还专门往真实 Codex 后端硬塞了 36 万、37 万、38 万 Token，最后测出：37 万左右能过，38 万开始 context_length_exceeded。

结果不到 3 个小时，情况又变了。

OpenAI 把原来主要面向 API Key 的 GPT-5.6 百万上下文能力，放到了 ChatGPT Subscription 的 Codex 使用路径上。Teknium 随即重新压测，然后又合了一个 PR：

272K350K900K

一天之内，两次解锁。

而且这次不是“配置文件里大胆填个 900000 试试看”，而是 Nous 真把 90 万、91 万甚至接近 93 万 Token 一点点塞进了 OpenAI 后端。

900K 真的跑通了。

但我翻完 OpenAI 官方 GPT-5.6 文档后，注意到下面还有一行特别不起眼的小字。

它可能比“900K”这三个数字更值得普通用户知道。

一、早上还是 350K，中午已经变成 900K

先把这几个小时发生的事情捋一下。

北京时间 8 月 17 日 06:43 左右，Hermes 合并 #87981。

当时 Codex /models 给 GPT-5.6 返回的 Context 仍然是：

272,000

Nous 觉得这个数字可能已经不准，于是直接测试 ChatGPT Subscription 使用的 Codex OAuth 后端。

结果是：

约 360K✅ 成功约 371K✅ 成功约 382K+❌ context_length_exceeded

于是 Hermes 没有顶着 372K 使用，而是比较保守地设成：

350K

给服务端留大约 22K 缓冲。

如果事情停在这里，350K 已经比以前的 272K 多了将近三成。

但几个小时以后，OpenAI 服务端变了。

Hermes 又重新测试。

这次结果直接变成：

500K900K911,276约 925K+❌ context_length_exceeded

所以北京时间 09:31 左右，#88056 正式合并。

Hermes 对 GPT-5.6 Sol、Terra、Luna，以及 GPT-5.4 的 Codex OAuth Context Override，从：

350K

再次提高到：

900K

GPT-5.5 和 GPT-5.4-mini 则没有跟着变化，目前依旧维持 272K。

一天连改两次，不是 Hermes 前一次测错了。

而是中间 OpenAI 真把后端开关翻了。

二、为什么官方说 1M，Hermes 最后只敢给 900K？

这里有一个很容易让人困惑的数字。

OpenAI 官方 GPT-5.6 Sol 页面现在明确写的是：

Context Window：1,050,000 tokensMax Output：128,000 tokens

Terra、Luna 也是 1.05M Context。

既然是 105 万，Hermes 为什么不干脆写：

1050000

而是只有 900K？

因为 Context Window 并不等于“可以塞进去 105 万输入，然后再让模型额外输出 12.8 万”。

模型还得给输出、Reasoning 以及请求内部处理留空间。

这次 Nous 的真实测试其实已经很说明问题：

911K还能跑925K 左右开始撞墙

所以 Hermes 最后取：

900K

相当于在真实测试边界前留了一截安全带。

而且 Hermes 也不是等会话真的涨到 900K 才处理。

按照当前大约 85% 的自动 Compression 触发策略：

900K × 85%≈ 765K

也就是说，一场特别长的任务跑到大约 76 万 Token 级别时，就已经会准备整理上下文。

这个设计明显不是在追求：

“看，我能塞满 100 万！”

而是：

“模型给了我一个百万级房间，我真正长期工作时留点过道。”

三、真正应该注意的，是 OpenAI 文档下面这行小字

我专门去看了 OpenAI 官方 GPT-5.6 Sol、Terra、Luna 的模型页面。

在 1.05M Context、Input Price、Output Price 下面，都有一句很容易扫过去的说明：

当 Prompt 输入超过 272K Token 时，整个请求按 2 倍 Input、1.5 倍 Output 定价。

关键不是：

“272K 以后的部分更贵。”

而是官方写的是：

for the full request

也就是整次请求。

拿 GPT-5.6 Sol 的 API 定价举个最直观的例子。

普通价格是：

Input：$5 / 1M tokensOutput：$30 / 1M tokens

如果一次请求的 Input 跨过 272K，按照官方现在的长上下文规则，相当于该请求的普通 Input 费率进入 2 倍档，Output 进入 1.5 倍档。

所以：

271K

和：

273K

看起来只差 2K Token。

在长上下文计价规则上，却跨过了一条线。

这就是标题里我说的：

“要小心这行小字。”

900K 是一个非常爽的能力上限。

但它绝对不是“免费的额外内存”。

四、那我用 ChatGPT Pro，不走 API，也会翻倍扣额度吗？

这个问题反而要说得谨慎一点。

因为 API 和 ChatGPT Subscription 不能混成一套规则。

OpenAI 的 Codex Rate Card 现在已经明确改成按照实际 Token 使用量折算 Credits，不再简单按照“一条消息大约算多少次”来估算。

例如 GPT-5.6 Sol：

每 100 万 TokenInput：125 CreditsCached Input：12.5 CreditsOutput：750 Credits

也就是说，ChatGPT Plus / Pro 通过 Codex 做长任务时，Context 越大，实际输入 Token 越多，额度消耗自然也可能越高。

不过这里有个边界一定要讲清楚：

OpenAI API 模型页明确写出了：

>272KInput ×2Output ×1.5

但我目前在官方 Codex Subscription Rate Card 里，没有看到一句同样明确的话，说明 ChatGPT 订阅 Credits 也一定机械套用这组 2× / 1.5× 长上下文倍率。

所以不能直接写成：

ChatGPT Pro超过 272K额度一定翻倍

至少现在官方文档还不足以支持这么绝对的说法。

能确定的是：

更大的 Context更多可能参与请求的 Token长任务更容易消耗更多 Credits

至于订阅额度是否完整复用 API 的长上下文倍率，我宁愿等 OpenAI Rate Card 把这条写得更明确。

这比看到 “same warning applies” 几个字就直接替官方补完计费公式稳妥得多。

五、但也别看到 900K 就害怕：90 万窗口不等于每轮烧 90 万新 Token

另一个极端也不对。

有人看到：

900K Context

会马上理解成：

“以后我发一句‘继续’，是不是又得重新花 90 万 Token？”

没有这么简单。

Agent Loop 最大的优化之一就是 Prompt Cache。

OpenAI 官方自己的 GPT-5.6 工程文章专门解释过：Codex 一次任务可能连续进行很多轮模型请求，每轮都重复携带 System Prompt、Conversation History、Tool Definition 和早期 Tool Result。

如果每次都重新计算，成本会非常夸张。

所以 Harness 会尽量保持前面的 Prompt Prefix 完全一致，让这些已经计算过的内容命中 Prompt Cache。OpenAI 也明确说，大量 Context Bloat 会增加成本、干扰模型并产生不必要的 Reasoning，因此 Codex 会限制 Tool Output，并尽量减少无意义的上下文膨胀。

Codex Rate Card 里的差价也很明显。

GPT-5.6 Sol：

普通 Input：125 Credits / 1MCached Input：12.5 Credits / 1M

正好相差 10 倍。

所以真正影响额度的不是一个简单的：

Context Window = 900K

而是一整组东西：

当前 Context 到底用了多少其中多少命中 Cache这一轮新增了多少内容Tool 又塞回来多少输出Subagent 返回了多少东西模型输出和 Reasoning 有多长

900K 只是仓库最大能放多少。

不是每次都必须把仓库塞满。

六、900K 真正改变的，是 Hermes 能接什么级别的长任务

所以我并不觉得这次更新只是“参数从 350K 改成 900K”。

对短聊天来说：

30K → 900K

几乎没区别。

你根本用不到。

真正受益的是那些以前很容易撞 Compression 的任务。

比如：

大型代码仓库；

连续几个小时的 Debug；

几十次 Tool Call；

长时间 Deep Research；

多个 Subagent 不断返回结果；

一个 Session 持续处理大量文件；

Bot 长期接管一个复杂项目。

以前 272K 时，Hermes 很快就要开始：

压缩总结丢掉部分原始历史

350K 能多撑一点。

现在 900K 则完全进入了另一档。

尤其 Hermes 最近又在同时做 Replay Economy、Lean Compression、Session Search Recovery，这些东西和大 Context 其实并不矛盾。

正确方向反而是：

Context Window 越来越大不要为了有 900K就必须塞满 900K

OpenAI 官方自己也在强调 Avoid Context Bloat。

强模型时代，Harness 真正重要的能力开始变成：

知道什么应该一直带着；

什么可以缓存；

什么可以压缩；

什么可以先丢掉，需要时再 Search 回来。

七、附干货：这次普通 Hermes 用户其实不用自己改 900000

如果你走的是 ChatGPT Subscription / Codex OAuth，我不建议看到这个消息以后就跑去 config.yaml 手工硬塞：

context_length: 900000

Hermes 最新 Main 已经做了自动处理。

正常：

hermes update

即可。

而且这次 Override 设计还有一个细节很好。

当前 Codex /models Catalog 据 Nous 的实测仍然可能给这些模型返回过时的：

272000

Hermes 只有看到这个已知过时值时，才替它改成：

900000

如果哪天 OpenAI 正式把 Catalog 改成：

1000000

或者：

1050000

Hermes 会相信新的 Live Value，不会继续强行卡死 900K。

目前受益的主要是：

gpt-5.6-solgpt-5.6-terragpt-5.6-lunagpt-5.4

GPT-5.5 和 GPT-5.4-mini 当前仍然是 272K。

所以这次我自己的态度非常简单：

900K，当然应该欢迎。

这是 Hermes 长任务能力一次非常实在的扩容。

但我不会因为有了 900K，就故意让每场任务都长到 800K。

就像电脑从 16GB 内存换到 64GB，我们高兴的是以前放不下的大工程终于能跑，不是为了证明内存买得值，每天开 300 个 Chrome 标签页。

Hermes 一天之内：

272K350K900K

这个速度确实很夸张。

但比 900K 更值得记住的，还是 OpenAI 官方文档下面那行不起眼的小字：

大上下文给你的是更高的能力上限。

不是一张“从此 Token 随便烧”的免费通行证。