Opus 4.7: auto-compaction at 200k tokens makes it unusable for long sessions

Describe the bug / feedback

Opus 4.7 auto-compacts at around 200k tokens, making it functionally a 200k-context model despite being advertised as 1M context. After compaction, the model spends ~150k tokens reconstructing its context from the compressed summary, only to recompact again almost immediately. In practice this means the model can barely complete a real implementation task before losing the thread.

What makes this worse than Opus 4.6

Opus 4.6 had its own issues but at least accumulated context across the full session. Tasks got done. With 4.7, the constant recompaction means every long session degrades into repeated context-reconstruction cycles. The model behaves like Sonnet 3.5 mid-task — lightweight and forgetful — which defeats the purpose of running the most capable model.

Concrete failure mode (reproducible)

1. Start a session that requires reading a large codebase (e.g., 180-file project ingest)
2. The model hits 200k tokens mid-work
3. Compaction fires. 150k tokens consumed summarizing what just happened
4. The model has barely recovered when it hits 200k again
5. Second compaction. The session is now stuck in a loop
6. Nothing gets built

Expected behavior

Either:

• (a) the advertised 1M context is actually usable before compaction fires, or
• (b) compaction fires much later (e.g., 800k), or
• (c) there's a user-configurable threshold so power users can choose to pay the cache-miss cost and keep a longer context

Suggested fix

Expose a configurable compaction threshold in settings (or ~/.claude/settings.json). The current behavior feels like it optimizes for cost at the expense of capability — which is the opposite of what Opus 4.7 users signed up for.

If the 1M context window is not actually available end-to-end in Claude Code sessions, that should be documented clearly rather than implied.