Hold the context
Anything important that lives only in the chat is at risk, because a long conversation gets compacted as it grows and a summary blurs the precise things, the amounts, the dates and the decisions. Over a long session or a big codebase there is a second drift too, the answers start going generic, reaching for what a project like this usually looks like instead of what was actually found. Holding the context means keeping the real findings in a durable place outside the chat, so the next turn and the next session both start with them already in hand rather than with a guess.
Say it another way
Context here means everything the AI is currently holding in mind about your work. In a long session it gets squeezed into a summary as it fills up, and the precise bits, the amounts, dates and decisions, can blur. So you write the important things down somewhere solid rather than trusting the chat to remember.
Doing this with Claude Code: Hold the context
Keep the decisions and the hard facts where you and Claude can both find them, in a place that survives the conversation. A CLAUDE.md and project memory, a rolling STATUS file, sessions you can name and resume. The chat itself is not that place: as it grows long Claude compacts it, dropping bulky tool output first and then summarising the older history. A summary blurs exactly the precise things you needed kept, the amounts, the dates and the decisions.
Holding the context earns its keep in six ways: keep the facts outside the chat, put what matters where it is read, trim the noise, hand facts cleanly between agents, keep a long exploration sharp and write down what you ruled out.
Keep the facts outside the chat. Put the amounts, dates, IDs and decisions in CLAUDE.md, project memory or a STATUS file, not only in the conversation. Memory reloads at the start of every session and CLAUDE.md sits outside the history, so compaction cannot round them off, like a master recipe pinned to the wall rather than cooked from memory of what was said earlier.
Put what matters where it is read. Claude leans on the start and end of a long input and is least reliable through the middle, so lead with the key facts and signpost them with headers rather than burying a make-or-break detail in the middle of a wall of text.
Trim the tool output. A command that hands back forty fields when five matter quietly fills the window and pushes the real facts toward the lossy middle. Ask for only the fields you need, or filter the output, so the noise never lands in the context in the first place.
Hand facts cleanly between agents. When a subagent does a piece of work, have it return the distilled facts with where, when and how it got them, not the whole verbose haul, so the main session can trust and combine them without drowning in detail.
Keep a long exploration sharp. Over a long session the model drifts to generic typical-pattern answers as it loses grip on the specifics. Counter it the same way: keep a scratchpad of what you actually found and refer back to it, push verbose discovery into a subagent so the main thread stays clean, then reach for /compact when the context fills. Each pass then stays grounded in this codebase rather than a generic one.
Write down what you ruled out. A scratchpad naturally fills with what you found and loses what you eliminated, so keep a short table of what was attempted and what it ruled out beside it. Eliminations are the most expensive thing to re-derive and the easiest thing to omit, which is why the same wrong theory comes back round on Monday.
Common questions
- Why does a long session start giving generic answers?
Claude reads the whole input, every word of it, but what sits at the beginning and the end lands with the most clarity. Over a long session it drifts toward what a project like this usually looks like, rather than what was actually found. - Can I prompt my way out of that drift?
No. Where the beginning and the end land hardest is just how the AI works, not a fault you can argue it out of. You work with it by putting what matters where it gets read. - What is the rule for working around it?
Be strategic and work in layers. Plan in layers and do the work in layers, because you cannot solve everything in one pass. Work in discrete blocks you know will fit, so a block does not need the history to make sense. - One big document or many small ones?
One file to a fact, found by its description line. That gives you a queryable layer rather than a single monster document, so the right piece can be pulled without carrying everything around it. - What does almost nobody write down?
What was ruled out. The record usually holds what was found, the amounts, the dates and the decisions, and it drops the dead ends: the theory that did not hold, the file that was irrelevant, the config that was fine all along. - Why do the dead ends matter so much?
Eliminations are expensive to derive and leave no trace, which makes them the one part of the work that gets done twice. A fresh session will cheerfully propose the thing you disproved on Tuesday. - What stops that rework?
A short table of what was attempted and what it ruled out, kept beside the notes on what you found. Without it, the same wrong theory comes back round on Monday. - I have a session from yesterday. Resume it or start fresh?
Check whether it is still true before you weigh what it cost. Validity has to come before cost, because you cannot plan with out of date information. Settle whether the old picture still stands, and only then ask whether re-deriving it is worth the time. - Does it matter how far into the work I already am?
How much you have invested changes what starting again costs you. It does not change whether what you are holding is still true. Run it the other way round and being a long way in becomes the reason to keep building on something wrong. - Which mistake is worse?
A stale resume is confidently wrong, where an unnecessary fresh start is only slower. The two cost different amounts, which is why leaning toward starting fresh is a sensible default under uncertainty rather than a law. - How do I find out what actually changed?
Ask what moved before deciding anything. Commit often and the set of changes since the AI last looked is small and nameable. Let it drift and nobody can say what moved, which leaves the AI reasoning from a copy of the files that no longer exists.
Back to For developers. The craft around it is Working with AI.