Every agent harness handles a full context window the same way: summarise the history, keep the summary, drop the rest. The differences are how big the window is and what it costs to fill it.
| Harness | Window | At the limit | One call with a full window |
|---|---|---|---|
| Claude Code | Up to 1M, varies by model | Compacts the transcript into a summary | $4.00 on Opus 5.5, $0.10 on Haiku 5.5 |
| Codex | 1,050,000 | Automatic compaction | $10.50 on GPT-6 Astra, $0.11 on GPT-6 Luna |
| Gemini CLI | 1M on Gemini 3 | Compaction in the CLI | $2.00 on Gemini 4 Carbon at its launch price |
The cost column is the price per million input tokens at the top model, which is what one call with a full window costs before any output.
The window is not free
A million-token prompt is not a bigger conversation, it is a bill. At Opus 5.5's $4 per million input tokens, one call that reads the whole window costs $4. At GPT-6 Astra's $10, it costs $10.50. Ten of those in a session is $40, and the model has not written a word yet.
Cheap models change this. Haiku 5.5 at $0.10 per million makes a full window cost ten cents, which is why "use the small model for the summarising" is standard advice rather than a compromise.
Compaction loses the same things everywhere
A summary keeps decisions and drops detail. The file path you discussed twenty turns ago, the exact error message, the reason you rejected the first approach — those go first. Every harness has this failure mode, because every harness is compressing the same kind of history.
What to do about it
Write the decisions to a file the agent can re-read, rather than trusting the transcript to survive. A short notes file costs a few hundred tokens to load and replaces a summary that may have lost the point.
Then check the window before the task, not after. Anthropic's context engineering post makes the point that the budget should be spent deliberately; the harness will spend it for you otherwise.