Why Claude Code gets worse in long sessions
I buried a chat rule under 513K tokens to see if Claude would forget it. It didn't. I still start fresh for every ticket.
4 min read · Nov 5, 2026
I wanted to see how far I could push a single Claude Code session before it started forgetting things, so I set up a test. Early on, only in chat, I gave it one rule: every commit message ends with "Checked-by: coach." Then I kept working in that same session the way I would on a long day, through tickets, refactors, a nine thousand line log, a few corrections and a merge, until the session was sitting at 513 thousand tokens.
It never forgot. Every commit ran the tests first and every commit ended with my line. At one point, without being told, it handed that giant log off to a background subagent rather than reading it into my session. So the obvious question is why I still start a fresh session for every ticket, and the answer has more to do with what a long session costs than with anything it forgets.
What's sitting in the window
Every time you send a message, Claude rereads the entire conversation: your newest line, every line before it, and every file it opened along the way. Even a brand new session of mine starts at around 35 thousand tokens before I've typed anything, because the system instructions, my CLAUDE.md, the tools and a line for each of my skills are already loaded. I think of it like a desk where the things you always need are laid out before you sit down.
Then the work starts piling up. I asked it to fix one small bug in a roster importer, and it read the ticket, searched the code, made the fix and ran the tests. In my terminal each of those steps was a line or two, but Claude receives every line of output, so the messages section of /context went from 10 tokens to over 10 thousand. My prompt had been a single sentence.
What all that history costs
The model I use has a million token window, so running out isn't really the issue. A bigger desk just takes longer to fill. The problem is that the old work stays on it, competing with whatever you're doing now, and Claude Code sends the whole thing again with every message, which eats into your usage as well. /context even pointed this out, suggesting that close to 200 thousand tokens of my session were old file reads it could have done without.
When a session does get close to full, Claude Code cleans up after itself. It clears out old tool output first, and if that isn't enough it replaces the conversation with a summary. Your CLAUDE.md gets reread from disk and the last few files you touched come back. When I ran /compact myself, the session dropped from 513 thousand tokens to about 52 thousand. The files I'd been editing came back, but the nine thousand line log came back as nothing more than its file name. That's fine as long as the summary keeps what you need, but you don't get a say in what it keeps unless you do it yourself.
How I work around it
The habit that matters most is giving every ticket its own session, even for a small tweak. I name the session after the ticket, so coming back to it later is just claude --resume RST-51 and everything we did is still there. If it's been a while, or Claude asks whether I really want to resume something that old, I start fresh instead and give it a short handoff with the ticket, what's done, what's next and anything it's likely to trip on. A handful of lines like that beats half a million tokens of history. I do the same thing when Claude keeps getting something wrong. After two corrections I stop, because a third one only adds another failed attempt for it to reread, and a fresh session with one better prompt usually gets there faster.
When I'm in the middle of a feature and want to keep going, I compact on purpose instead of waiting for the automatic one. I pick a natural break and tell it what to focus on, which is how that 513 thousand token session came down to 52 thousand while keeping the parts I cared about.
For anything noisy, like a big log, I let a subagent read it in its own window. Mine got through all nine thousand lines using around 38 thousand tokens of its own, and my session only ever saw the answer. It doesn't make the answer any smarter and it costs some extra tokens, but it keeps the mess off my desk.
The last habit is putting rules in files. My chat rule only held because I never left that session. When I put the same rule into the handoff for a fresh session, Claude pushed back and pointed out that it wasn't in CLAUDE.md or my commit skill, so if I wanted it followed, that's where it needed to go. If a rule matters, it belongs somewhere Claude rereads. The catch is that changes to CLAUDE.md made in the middle of a session don't load until the next /clear or /compact. Skills have a similar wrinkle: if a long skill gets trimmed after a compact, it's the bottom that goes, so the rules that matter most belong at the top.
The same task, both ways
To see the difference for myself, I gave the same next task to two sessions. The stale one carried 508 thousand tokens and took 42 seconds to come back with a plan. The fresh one, with a five line handoff, used 47 thousand tokens and took 28 seconds, and it came back with the same plan. That's a tenth of the tokens on that message and on every message after it, for the same result.
The full episode shows all of this on screen.
Written by
Derek AubieFull-stack developer, 15+ years. I make Prompt & Commit: how a working developer actually uses AI. No hype, just what works.