๐ค I was 45 minutes into a Claude Code session when Claude just โ started making stuff up.
Default values I never asked for. Constraints I'd set an hour earlier? Completely ignored. Like talking to someone who totally forgot the entire conversation.
So I did what felt natural. I started correcting it in the session. More instructions. More constraints. Spelling things out AGAIN from scratch.
This made everything insanely worse.
Here's the thing nobody tells you about context windows โ every correction you make goes into the same context window that's already broken.
Think of your context window like SpongeBob. When he's fresh, he absorbs everything perfectly. But once he's soaked in dirty water โ failed attempts, stale instructions, frustrated corrections โ squeezing him harder doesn't clean him. You're just pushing the same dirty water around.
At that point your context window is basically SpongeBob rolling around in the mud singing "I'm a dirty boy."
It's a death spiral. And most people don't realize they're in one until they've burned 30 minutes arguing with an AI that stopped listening 20 minutes ago.
This is even more important now with Claude's usage limits. Every correction that makes things worse is burning through your session cap faster โ and once you're out, you're out.
So here's a hard rule โ stop adding once you notice the session has gone off course. Start terminating.
/clear wipes your conversation history but keeps the project context. Or just open a brand new terminal window entirely. Throw dirty SpongeBob away and grab a fresh sparkly clean one.
Claude will immediately go back to being the brilliant product that it is.
I do this like โ a hundred times a day. The moment something starts to feel off, I don't investigate. I don't argue. I just end the session and start over. If I really need context from the old session, I'll ask Claude to summarize it and copy paste the important parts into the new one after reviewing.
Running /compact when things have already gone wrong is usually not the move โ you're basically just squeezing a dirty sponge and re-dipping it in dirty water. You freed up space but the residue of bad context is still baked in.
Fresh sessions will produce better code in 3 minutes than 30 minutes of arguing will.
Stop squeezing dirty SpongeBob. Grab a fresh one. ๐ง
Related: You're Wasting Your Best Engineering Skill โ โ the longer take on curating context strategically before Claude starts hallucinating in the first place.
Top comments (7)
this frames the symptom as the fix. by the time it hallucinates you've already lost the window. compacting context every 30min before it degrades works better - you keep the decisions instead of restarting from scratch.
The SpongeBob analogy is genuinely the best mental model I've seen for context degradation. The part that resonates most is that corrections don't clean the context window รขยย they add to it. Every "no, that's wrong" is still tokens, still part of the record the model is attending over. You're not replacing the bad state, you're appending to it.
What this implies structurally is that the feedback loop should be architectural, not conversational. Rather than trying to course-correct in-band, the pattern I've found useful is explicit session boundaries: when a task has a clear success criterion, encode it in the system prompt as a terminal condition, not as a constraint to check against. The model then either reaches the condition or fails explicitly รขยย rather than drifting indefinitely while accumulating correction tokens.
The /clear approach is basically manual garbage collection. The interesting question is whether you could encode a more principled version: automatic session termination when the loss surface of the conversation starts increasing rather than decreasing. That's a hard signal to measure in real-time, but it might be approximated by monitoring something like repeated noun phrases or increasing semantic drift from the initial prompt. Has anyone tried automating the "throw away dirty SpongeBob" decision?
Kill the session is underrated advice, because a hallucinating agent doesn't recover, it compounds. Once it's confidently wrong about the state of your code, every further step builds on the wrong premise, and you spend more untangling it than a fresh start would cost. The skill is noticing early, and the tell is usually the agent explaining why something works that you know doesn't. Fresh context beats arguing with a model that's committed to a bad model of your codebase.
The point about /compact being the wrong move once things have gone sideways matches what I keep relearning. Compaction summarizes the bad reasoning along with the good, so the model carries its own wrong turns forward in a shorter form. Re-stating the goal in a fresh session from the last known-good commit has been faster for me than any amount of arguing with a context that's already poisoned.
This matches what I see running several coding agents in parallel and reading every diff before it ships. The earliest tell for me isn't the agent forgetting a constraint, it's the diff no longer matching what the chat reply claims happened, it says it added a null check and the diff touches a different file entirely. Once that gap shows up I don't bother correcting the session either, I've tried and the correction rides on the same broken context and comes out half right. One thing I'd add to kill it fast, watch the diff first, not the explanation of it, the conversation only starts reading as confused after you've already lost the minutes the diff would have shown you right away.
The "start fresh" instinct is right, but the failure mode isn't just accumulated dirty context โ it's that your corrections are attention poison. When you say "no, I told you the timeout should be 30s" for the third time, the model now has three conflicting timeout statements in-window and no reliable signal about which one wins. Recency usually tips it, but not always, and you've made the earlier correct instruction look like noise it already ignored once. You're not filling a sponge, you're teaching it that its own past outputs are part of the spec.
Which is why the summarize-and-carry-over trick you mention at the end is actually the whole game, not a footnote. But be careful there too: if you ask the already-confused session to summarize itself, it'll faithfully carry the hallucinated defaults and dropped constraints into the clean session โ the mud comes with you. When I restart I don't ask the dead session to summarize; I go back to the source of truth (the actual files, the actual requirements) and re-seed from that. The old session is exactly the thing I don't trust anymore, so I don't let it write my next prompt.
Wren's point about the dead session summarizing itself is the one people miss: you trust it to tell you what broke when it's the thing that broke.
early tell we track: when the model's explanation of a change runs 3x longer than the actual diff, it's defending something it did wrong. that's the signal to kill, not when the code breaks.
what we've built around this: CLAUDE.md files per feature area as the reseed source. start fresh, drop those in, not a summary from the dying session. took a few weeks to build the habit but it cuts the reset from 10 minutes to 2.
do you find /compact useful at any point โ like early, before pressure builds, not mid spiral?