--- title: "Manage Context in Claude Code as a PM" description: "Long Claude Code sessions degrade because old decisions pile up. The habits that keep output usable: watch the meter, clear between tasks, compact with intent." canonical_url: "https://builderscamp.com/guides/tools/claude-code-context-management-for-pms" date_published: "2026-09-18" date_modified: "2026-09-18" author: "Andre Albuquerque, Inês Lourenço" publisher: "Builders Camp" guide_class: "tools" --- # How to manage context in Claude Code when you are a product manager **TL;DR:** A Claude Code session degrades once the transcript fills with superseded decisions, and the fix is four habits: check /context before you trust an answer, /clear between unrelated tasks, /compact with an explicit instruction when you are mid-task, and keep durable facts in files rather than in chat. The cost is that you have to write things down as you go, which is also the point. ## Why does a long Claude Code session get worse instead of better? Every Claude Code session opens with an empty context window, and everything that happens inside it competes for the same finite space: your instructions, the files it read, the commands it ran, the output of those commands, and every approach it tried and abandoned. Two mechanisms carry knowledge across that boundary. CLAUDE.md files hold instructions you write. Auto memory holds notes Claude writes from your corrections, loaded at the start of every session, capped at the first 200 lines or 25KB. Anthropic's own documentation is explicit that both are treated as context rather than enforced configuration, which is the first thing a product manager should internalise: nothing you put in a file is a guarantee, only a strong prior. What goes wrong in hour three is not that the model got dumber. It is that the transcript now contains a decision you reversed at minute forty, a schema you abandoned at minute ninety, and a summary of a file that has since changed. Builders Camp's Building with Claude Code certification quiz gives this failure a name, memory rot, and defines it as long sessions accumulating outdated decisions, abandoned approaches and contradictory instructions. That definition comes from teaching material, not from a measurement of model behaviour, so treat it as a diagnosis rather than a statistic. It still describes the thing you will actually experience: the agent starts confidently citing something that stopped being true two hours ago. ## The four habits that keep a working session usable None of these require you to understand a token count. They require you to treat the session as a workspace you tidy, not a conversation you continue. 1. **Check the meter before you trust the answer.** Run `/context` to see what is consuming space, `/usage` for token totals, or configure the status line to display context window usage continuously. Drift is visible in the meter before it is visible in the output, which is the only reason to look. 2. **Clear between tasks, not between messages.** `/clear` starts fresh, and stale context costs tokens on every subsequent message until you do. Use `/rename` before clearing so you can find the session again, and `/resume` to come back to it. 3. **Compact with an instruction attached.** A bare `/compact` lets Claude decide what mattered. `/compact Focus on the interview quotes and the decisions we agreed` tells it what to preserve. You can write standing compaction instructions into your project's CLAUDE.md so the same rule applies every time without you retyping it. 4. **Put durable facts in files, not in the chat.** If you are typing the same correction you typed last session, that belongs in CLAUDE.md. If it is a multi-step procedure, it belongs in a skill. If it only matters for one part of the repository, it belongs in a path-scoped rule. The economics are not trivial. Anthropic reports an average of around 13 dollars per developer per active day across enterprise deployments, with 150 to 250 dollars per developer per month. That figure covers engineers running agents all day, not a product manager doing a research synthesis once a week, and it does not separate a disciplined session from a bloated one. What it still shows is that context size is the lever with money attached to it, and the habits above are the lever you can actually pull. ## A worked example: 220 support tickets and one afternoon Take a real piece of product work: you have exported 220 support tickets and you want the themes, the frequency of each, and a shortlist of the five that suggest a roadmap change. The version that fails looks obvious while you are doing it. You paste the export into one session, ask a question, ask a follow up, ask a third, and by the ninth question the agent is confidently grouping tickets under a category name it invented in question three and you have since rejected. The version that works treats the session as disposable and the artifacts as permanent. Write a short context file first that names your real taxonomy, the product areas, and the two categories you already know are noise. Point Claude at it. Then work in batches: forty tickets, write the findings to a file, `/clear`, open the next batch with a two-line rehydration briefing that points at the findings file and nothing else. The agent never holds more than one batch plus the accumulated findings, and the findings file is the memory. When you reach ticket 220, the synthesis runs against a file you can read, not against a transcript nobody can audit. The same move works in the other direction. A [hook](https://builderscamp.com/guides/glossary/automation-hooks-claude-code) can preprocess data before Claude ever sees it: instead of the agent reading a ten thousand line log to find errors, a hook greps for the error lines and returns only those, which Anthropic documents as cutting context from tens of thousands of tokens to hundreds. A product manager rarely writes that hook. A product manager does decide that the agent should be reading the filtered view, and that decision is the same one every time. ## When should you clear instead of compact? Clear when the next task shares no facts with the last one. Moving from a pricing analysis to a bug triage means nothing from the first task helps the second, and everything from it costs you. Compact when you are mid task and the conclusion depends on what came before, which is exactly the case where a summary beats a blank slate. One practical detail: run `/compact` in a brand new session and it reports that there is not enough conversation to summarise, which is a useful reminder that compaction is a mid-flight manoeuvre, not a warm-up. The related decision is what to connect. MCP tool definitions are deferred by default, so only tool names and server instructions enter context until a tool is actually used, but every configured server still contributes something. Run `/mcp`, look at what is enabled, and disable what you are not using this week. A command line tool the agent can call directly is more context efficient than the equivalent server, because it adds no per-tool listing at all. ## What does clearing actually cost you? It costs you the unwritten agreements. Halfway through a long session you and the agent have converged on a dozen small conventions that were never stated: which of two metric definitions you meant, that "churn" in this conversation excludes trials, that the second column of the export is unreliable. `/clear` deletes all of it, and a rehydration briefing that does not mention them means the next session cheerfully contradicts the last one. That is the honest trade, and it is why the habit is not "clear often" but "write it down, then clear". The rehydration briefing has a real cost: you have to produce it. In practice it is three or four lines, and producing it forces you to name decisions you were carrying implicitly, which is work a product manager should be doing anyway. If writing the briefing is hard, that is a signal the decisions were never as settled as the transcript made them feel. ## Where context management stops being a personal habit One person running clean sessions is a personal discipline. A team running them the same way is [context architecture](https://builderscamp.com/guides/glossary/context-architecture), and that is a different problem: shared CLAUDE.md files, agreed compaction instructions, a convention about which files hold decisions. Builders Camp teaches the individual layer in Building with Claude Code, taught by Guilherme Salgueiro, which covers CLAUDE.md, skills, agents and memory across 2 live sessions and 9 microlessons, and its own certification quiz puts context quality ahead of prompt quality and model version as the biggest determinant of agent performance. The team layer sits in Building your AI Operating System, led by Inês Lourenço, which is built around designing a context layer and reusable skills for product work rather than around a single session. If your problem is that your own sessions rot, start with the first. If your problem is that five product managers each invented their own conventions, start with the second. And if the underlying issue is that your prompts are vague enough that no amount of context management saves them, AI Prompting for Product is the earlier fix. ## Who this is for, and who it is not for This fits a product manager who already uses Claude Code for real work, research synthesis, spec drafting, data pulls, and has noticed that long sessions produce confident answers that do not survive checking. It assumes you can run a slash command and edit a markdown file, and nothing beyond that. It does not fit someone who has not started yet. If you are still deciding whether the tool belongs in your week, the question is not how to manage context, it is what to point it at first, and [the wider tool comparison](https://builderscamp.com/guides/tools/best-ai-tools-for-product-managers) is a better starting page than this one. ## Start with the meter, not the rewrite Before you restructure anything, run `/context` in your next real session and look at what is actually filling it. Most product managers find one surprise there, usually a connected server or a file the agent re-read four times, and fixing that single thing buys more than any prompt rewrite would. The [context window](https://builderscamp.com/guides/glossary/context-window) is a budget, and you cannot manage a budget you have never looked at. [See the Building with Claude Code bootcamp](https://builderscamp.com/bootcamps/building-with-claude-code?utm_source=guide&utm_medium=organic&utm_campaign=claude-code-context-management-for-pms) If memory is the part you want to get right first, [what agent memory actually stores](https://builderscamp.com/guides/glossary/agent-memory) covers the review discipline that keeps it from going stale, and [how to design an AI agent](https://builderscamp.com/guides/tools/how-to-design-an-ai-agent) covers the layer above a single session. ## Frequently asked questions ### Does Claude Code remember anything between sessions? Every session starts with a fresh context window. Two things carry across: CLAUDE.md files, which you write, and auto memory, which Claude writes from your corrections. Both load at the start of every conversation, and auto memory loads only its first 200 lines or 25KB, so it is a briefing, not an archive. ### What is the difference between /clear and /compact? /clear starts a new session and drops the conversation entirely. /compact keeps working in the same session but replaces the history with a summary. Clear when the next task shares no facts with the last one. Compact when you are mid-task and the next answer depends on what came before. ### Can I tell Claude Code what to keep when it compacts? Yes. Pass an instruction with the command, for example /compact Focus on code samples and API usage. You can also write standing compaction instructions into your project's CLAUDE.md so every compaction in that repo preserves the same things without you retyping it. ### How do I see how much context I have left? Run /context to see what is consuming space and /usage for token totals, or configure the status line to show context window usage continuously. Checking the meter is more reliable than noticing that answers have started drifting, because drift shows up after the damage. ### Why do MCP servers make long sessions worse? Each connected server adds to what Claude carries. Tool definitions are deferred by default, so only tool names and server instructions enter context until a tool is used, but unused servers still cost something. Run /mcp to see what is configured and disable what you are not using. ### Should a product manager put research notes in CLAUDE.md? Only the parts that are always true. CLAUDE.md is for facts that hold in every session: the product's taxonomy, the naming conventions, the sources of truth. A specific research round belongs in its own file that you point Claude at when the task calls for it, not in the file loaded on every single run. ### Is context management taught in a Builders Camp bootcamp? Yes. Building with Claude Code covers CLAUDE.md and context architecture, skills, agents and memory across 2 live sessions and 9 microlessons, and its certification quiz names context quality as the single biggest determinant of agent performance. ## Sources - [Anthropic: How Claude remembers your project](https://docs.claude.com/en/docs/claude-code/memory) - [Anthropic: Manage costs effectively](https://docs.claude.com/en/docs/claude-code/costs) - [Anthropic: Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) - [Anthropic: Hooks in Claude Code](https://docs.claude.com/en/docs/claude-code/hooks) ## How this guide was made Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.