五小时额度像流水：两个调法

五小时额度掉得像流水这事，官方工程师给了解法，毛病出在默认策略太激进。

误解先澄清。社区此前吐槽它根本没做上下文压缩、暗地里狂塞 token，这话其实冤枉了它。auto-compact 每次触发都是动真格做摘要的，一按就把此前的全部往来压成几行梗概，历史原文并不留在窗口里。

真正的账目在别处。一百万档的窗口，默认要攒到九十六万七千 token 才肯动手收一次；收之前的那段长对话里，你敲的每个字身后都跟着七八十万甚至逼近百万的重包袱。多数请求能命中提示缓存、单价也确实便宜，可乘数这么大，每聊一轮照样在啃那五小时。

至于"一压就换前缀、缓存全废、重写亏本"的顾虑，答案是不成立。摘要那步走的多半是热读，真过期时只为新梗概付一笔很小的写费，换回的是后面每一轮的基数直接砍半，细账怎么算都值。

两处改动照录。终端里直接敲 /autocompact 400k，或者在 ~/.claude/settings.json 里配好 autoCompactWindow，逼它提前压缩，别让上下文滚到九百多 K。

另外个人订阅的缓存保活默认一小时，后台子代理只有五分钟，写代码停顿久了缓存冷掉重写确实心疼。想省心就在配置里改 promptCacheTtl 和 subagentPromptCacheTtl，主会话跑 Opus 的话，把打杂的子代理换成更轻量的模型，额度立马耐用很多。

"憋到 967K 才压"这半句是全场重心。前面试错不心疼讲的是把预算花得大方，这条讲的是把预算从漏点上堵回来。跟前面五分钟六美分呼应，那条在省单价，这条在省基数，两头都在提醒同一件事，代理时代的开销大头不在单价，在身后的包袱。

我留意的是缓存保活那处一小时对五分钟的落差，主与仆的时间差看着不起眼，停顿久了却直接折算成额度。

我留的疑问有三处。967K 这个阈值会不会随版本改没说；摘要质量对后续任务的影响没测；子代理换轻量模型后的任务完成度也没数。

这周按两个调整各跑一轮，把五小时额度的实际曲线记下来对比。