Auto-compaction should not scale with the context window

We've had CLAUDE_CODE_AUTO_COMPACT_WINDOW pinned at 300000 since April and I've never wanted to raise it. Every time I look at what a long session actually costs, the big window is working against me.

Every request re-reads the whole prefix, so a session sitting near a million tokens pays roughly three times per turn what the same work costs at three hundred thousand. Caching lowers the price per token but it doesn't touch that ratio. On a subscription it shows up as the weekly limit draining faster, and nothing in the UI connects the two, so you hit the limit sooner without knowing why.

The quality side is worse. By the time a session is that long the part that matters is a small slice of what gets re-read every turn, and attention to the middle of a long context measurably degrades (Lost in the Middle, https://arxiv.org/abs/2307.03172). So you pay three times as much for output that's harder to steer, and the fix is the one thing a big window removes the pressure to do, which is compact.

Two things I'd want:

Auto-compaction firing well before the window does, whatever the window happens to be. If the trigger scales with the context size, then every model with a bigger window makes sessions more expensive by default and nobody chose that.

Something in the UI showing what the session costs per turn while it's running. Knowing how much context is left is a different question from knowing what each turn pays to re-read, and only the second one tells you when to compact.

The big window earns its keep when you're reading one huge file or a whole repo in a single pass, and compaction can't do that. So this is about the default, not the capability. Mine are almost all the other kind of session, and those are the ones paying for it.