Your session is a budget, not a chat
Codex, Claude Code and Gemini CLI all rot the same way and recover differently. Here is the session discipline that keeps long agent runs usable.
When Anthropic published their guide to getting more out of Claude Code sessions, the top comment on Hacker News was not a thank you. It was closer to a complaint. The product should be doing this. Why am I hand-tuning a token budget like it's 2009 and I'm managing heap.
That complaint is correct. It is also useless to you today.
The tooling is not there yet. Until it is, the session is a resource you own, and if you don't budget it you will spend your afternoon watching an agent confidently undo work it did an hour ago. This post is about how to budget it. Across all three CLIs, because they fail differently and most of what's written only covers one.
A session is not a conversation
This is the mental model that costs people the most.
A chat is something you have. A session is something you spend. It has a fixed size, it fills whether or not you're getting value, and everything in it competes for the model's attention. Tool output you'll never read again sits in there taking up room next to the one instruction that actually mattered.
Chroma tested 18 frontier models on long-context performance. Every single one degraded as input grew. Not "some, under adversarial conditions." All of them. A model with a 200K window can show meaningful degradation by 50K tokens, which means the number on the box is a ceiling, not a working range.
So the question is never "will it fit." It's "what is the smallest context that can still do this job." Those are different questions and only one of them is useful.
Three tools, three session models
Everyone writes about Claude Code. Fine, it's the loudest. But if you run more than one of these you need to know that they persist and recover in genuinely different ways, and the habits do not transfer cleanly.
Claude Code compacts. When you approach the limit it summarizes the conversation so far and continues from the summary. Persistent instructions live in CLAUDE.md.
Codex CLI resumes. Sessions are stored on disk, codex resume --last or codex resume <SESSION_ID> picks one back up. It auto-checkpoints on an interval measured in tool calls, and AGENTS.md merges over your global config so the persistent layer costs almost nothing in-window.
Gemini CLI checkpoints your files. Each session gets an id and is written to disk, and checkpointing takes a shadow-git snapshot of the working directory. Instructions live in GEMINI.md.
Read that again, because the important part is easy to skim past.
Claude summarizes your conversation. Gemini snapshots your files. Codex sits between them, persisting the transcript with periodic checkpoints.
That is not a feature-chart difference. It's a difference in what you can get back after something goes wrong. If an agent mangles ten files, Gemini's checkpoint is the thing that saves you and a conversation summary is worthless. If an agent forgets the constraint you gave it forty minutes ago, a file snapshot doesn't help at all and the transcript is what you need. Knowing which tool protects which asset tells you where to keep your own safety net.
What actually breaks
Compaction is the obvious failure and the most misunderstood one. A summary is lossy by construction. The question is what it drops first, and the answer is annoyingly consistent: negative instructions.
"Do not touch the migration files." "Never commit directly to main." "This service is not idempotent, do not retry."
Those are the first things to go. They are short, they read like asides, and a summarizer optimizing for narrative flow throws them out. Your positive instructions mostly survive. Your guardrails mostly don't. So the agent comes back from compaction cheerful, capable, and no longer aware of the one rule that was keeping it out of trouble.
There's an open issue on the Claude Code repo (#32691) where people report compaction firing three to five times in a two to three hour session, taking 30 to 60 seconds each time, and losing rules that Claude itself had written to memory files. Whatever you think about the severity, note the shape: the failure is not that the agent gets dumber. It's that it gets amnesiac about constraints while staying fluent.
Three more worth naming, because naming them makes them easy to spot:
Poisoning. A wrong fact enters the context and then reproduces at every subsequent step. The agent isn't hallucinating repeatedly. It hallucinated once, and now it's building on it faithfully. This is the expensive one, because the output stays internally consistent while being wrong from the root.
Distraction. As history grows the model leans on the transcript instead of its actual knowledge. It starts pattern-matching against what it already did rather than reasoning about what to do. You see this as an agent that keeps proposing variations of an approach that already failed.
Confusion. Irrelevant material in the window degrades the answer because the model tries to use what it was given. That 4000-line log you pasted in to debug one line is still in there, still being weighed.
All three share a root cause. Stuff accumulated that nobody removed.
The discipline
Not tips. Rules, with reasons, in the order I'd adopt them.
Scope a session like a git commit. One coherent unit of work, a clear start, a clear end state. When the work changes, the session ends. The instinct to keep one long session running all day because "it knows the project now" is exactly backwards. It knows the project and also every dead end you walked into since breakfast.
Compact at 60 percent, not 95. Compaction quality depends on how much has to be thrown away. Summarizing a half-full window is a haircut. Summarizing a nearly-full one is an amputation. If you wait until the tool forces it, you have chosen the worst possible moment to compress.
Re-state your constraints after every compaction. This is the highest-value habit in the post and it takes ten seconds. Assume your guardrails did not survive. Say them again. If you find that tedious, that tedium is the actual product gap the HN thread was complaining about, and you should feel free to be annoyed about it while you keep doing it.
Put persistent rules in the file, not the conversation. CLAUDE.md, AGENTS.md, GEMINI.md. Anything you'd have to repeat after a compaction belongs on disk. Conversation is volatile storage. The instruction file is durable storage. Treat them accordingly.
Clear between unrelated tasks. Not compact. Clear. Compaction preserves a summary of work that has nothing to do with what you're about to do. That's not context, that's residue.
Write a handoff before you stop. A short file that captures where things stand and what's next. Then start clean next time instead of resuming a session whose first half is irrelevant. On the HN thread this was the single most upvoted practical suggestion, and the people doing it reported better results from short sessions plus handoffs than from long continuous ones. That matches what I see.
Keep noisy output out of the window. Long test runs, verbose builds, large file dumps. Quiet flags, or push them into a subagent that reports back a summary. A build log you skimmed once should not be paying rent for the next two hours.
What not to do
Short list, all of these are common and all of them cost real time.
Don't paste large files in "for context" when the agent can read the specific part it needs. Don't keep a session alive across a break long enough for the cache to expire, you get the cost of the long context with none of the speed. Don't switch model or effort mid-session casually, it busts the cache and you pay to rebuild it. Don't treat the context window size as the working budget. Don't assume a rule you gave once is still in effect after the tool told you it compacted.
And don't build an elaborate personal framework for this before you've done the boring version. Someone posted a Show HN about solving context drift with a structured set of markdown files. Four points, three comments. Not because the idea was bad, the idea was reasonable. Because a system that manages your context is only worth building after simple discipline has provably failed you, and for most people it hasn't been tried yet.
Where this is heading
Worth saying plainly: some of this is temporary.
Context editing that strips stale tool results automatically is already shipping, and the numbers are not small. Anthropic reports a 29 percent improvement from context editing alone on agentic search, 39 percent when combined with a memory tool, and in a 100-turn evaluation it cut token consumption by 84 percent while completing runs that otherwise failed outright.
So the manual parts of this post have a shelf life. Good. That's the correct direction and I'd rather the tools absorbed this work.
What won't expire is the model underneath. Context is a budget. Attention is finite and degrades with volume. Summaries lose constraints before they lose narrative. Whatever the tooling automates next, those stay true, and the operator who understands them will get more out of the automation than the one who just turned it on.
— d.