Claude Code: context, compact, clear and session hygiene

Claude Code: the bottleneck is context

Before talking about models or plugins, look at the context window. With Claude Code, every message, every file read, every tool log and every answer piles up in the session. The model rereads all that past to predict the next token. As the session grows, the cost rises, and quality can drop before you even feel “done”.

Current windows are large, from a few hundred thousand tokens up to a million depending on the model and the plan. A large window does not guarantee unlimited quality, though. In practice you observe two zones: a “smart” zone where answers stay solid, then a zone where relevance falls. It is often called the dump zone: past a certain share of the window, the reasoning is not the same.

To steer the team, keep a useful order of magnitude in mind. Several field reports point to a clear degradation when you approach half to 60% of the useful window, especially with long tool loops. Take it as an alarm signal rather than a physical law: it is the moment to compact or split the session, not to push a little further.

Claude Code actually warns you early: when you approach the useful end, the tool pushes you to compact. Day to day, the token war is won with less noise, shorter sessions, intentional summaries and bounded tools.

Compact vs clear: two commands, two jobs

The compact command asks the model to summarize the useful history (the tool also offers it on its own). It compresses the back-and-forth, the file searches, the edit attempts and the flow understanding. You then continue the same thread with a smaller summary, without reloading everything by hand. Careful: the summary itself costs tokens, a compact is never “free”.

The clear command, on the other hand, changes threads. You leave the current conversation context to start from scratch. Keep the difference this way: compact compresses to continue the same goal, clear resets the chat for a different goal.

What survives when you close Claude Code depends on what you materialized elsewhere. A summary that only lives in the session can vanish when it closes. A note written in a repo file (CLAUDE.md, memory, skill, handoff) does survive. The rule is simple: what must last from one day to the next gets written in the repo.

On a monorepo or a long feature, compact intentionally and frequently, without waiting for the dump zone. We compact after each step (research, plan, implementation of a sub-goal) and we write a short handoff: the goal, the decisions, the files touched, the next step. Less magic, more control.

Dump zone: signals and countermeasures

LLMs lean mostly on the beginning and the end of the context, and the middle erodes. With too many MCP servers, too many files and too many logs, you quickly enter the zone where answers turn generic, contradict themselves, or “forget” a constraint set 40 messages earlier.

Some signals never lie:

• The agent rereads files it has already seen for no reason
• It proposes out-of-scope diffs or ignores the definition of done
• It loops on tools
• It tells you that you are “completely right” in sycophant mode just before derailing

That last reflex is a good marker: when the agent agrees with you too much, it is time for a reset or a handoff.

The countermeasures fit in a short list:

• One goal per session
• A compact after each step, a clear when the topic changes
• Fewer active MCP servers and destructive permissions denied (rm -rf for instance)
• A sliced monorepo (subtree, package, local CLAUDE.md)
• Subagents to isolate heavy research

Also keep in mind that more commits from a saturated session does not mean more value. We look at incidents and review time after merge.

Permissions, sandbox, yolo

Every shell command or MCP tool can request a permission. We grant what is needed (tests, build) and deny the destructive by default. Team settings can pre-approve an allowlist and block everything else.

Yolo mode, which skips all permissions, is tempting in a throwaway sandbox. It becomes dangerous on a dev machine with secrets and prod access. The rule is simple: an isolated sandbox, or no yolo.

Without the third brick, the control one (permissions, human validation, allowlist), you just have a POC or a demo, even with the best coding agent.

Init, CLAUDE.md, skills and plan mode

The init command and the repo instruction files give permanent context: the stack, the test commands, the forbidden zones, the conventions. Version them. A root CLAUDE.md plus one CLAUDE.md per hot package beats a 40-message monologue.

Skills are reusable competencies: creating a plan, running a migration, applying design tokens, playing a test scenario. A skill beats a throwaway prompt. As a team, a single plan skill avoids every dev producing their own plan format and making review impossible.

Create plan mode is nothing like a one-shot: the agent researches, asks trade-off questions, writes the plan, then iterates. If you switch mode or tool halfway through without materializing the plan in a file, you lose the thread. Keep the plan in the repo.

When you do the same thing twice, extract a skill or a command. Mature teams accumulate dozens of skills and thousands of versioned context lines: that is an internal product, not a chat gadget.

Hooks complete the setup: they are extension points to enforce steps (lint, tests, checks) at precise moments of the cycle. They are useful to keep determinism around the agent.

Subagents, scripts and “free” tokens

A subagent has its own context window. The orchestrator therefore does not swallow the whole research history. You keep a focused context and often go faster on isolable tasks: exploration, docs, a local audit.

A deterministic script (lint, format, a transformation) burns no LLM tokens. When a step is purely mechanical, a skill that calls a script beats an agent reinventing the wheel in prose.

Reducing tooling noise (monster command outputs, file trees) is also IDE-side context engineering. “Token killer” style tools exist to compress what enters the model. The key idea is token efficiency, not only the model's unit price.

MCP: build, design, outside world

MCP is a common standard to wire tools to the agent, often described as the “USB-C” of agents. Claude Code can orchestrate several servers: build and simulator (the Xcode ecosystem for instance), design (Figma with tokens, hierarchy, screenshots), tickets, docs.

MCP servers bring outside-world context, and Claude orchestrates. A prompt without that context produces generic code you throw away. A design-system skill combined with a design MCP narrows the gap between the mock and the code.

That context has a cost: more MCP servers and more skills mean more input tokens, before a single line gets written. For day one, keep few tools, favor reading, and put writes behind confirmation. Disable what the session does not need.

The details of MCP architecture (allowlist, security, computer use) live in the Model Context Protocol article. Here we focus on the impact inside the Claude Code session.

Autonomy plugins: plan first, exit after

Autonomy loop plugins (in the “persist until done” style) promise an agent that iterates alone. Without parameters, you mostly burn tokens: no maximum number of turns, no exit condition, no plan.

The healthy pattern fits in four steps:

1. Build the plan with the human, that is where the real leverage sits
2. Generate a versioned implementation plan file
3. Loop over the tasks while updating the plan (done, remaining)
4. Set explicit exit conditions per goal

The structural limit remains context saturation in a long loop: the agent derails within the same thread. The solutions are known: compact, split into sessions, or replay the “batch” pattern outside the plugin with file handoffs. The logic is the same, with more control.

A yolo mode plus a plugin without a sandbox ends in an incident. The spec first, bounded autonomy after.

Debug, ADE, cloud coding agents

Giving the agent a debugger (or a debug CLI) changes the loop: it reproduces the bug, forms a hypothesis, patches, then retests, instead of guessing in the void. The context discipline stays the same: bounded logs, no unfiltered monster dumps.

We are gradually moving from “sidebar chat” IDEs to agentic environments (ADE) and cloud or CI agents, useful for headless jobs. The team policy (permissions, secrets, review) stays the same whatever the client.

On the craft side, keep your guardrails: AI is easy to adopt, the protections (tests, review, file segmentation, short precise prompts) less so. One precise prompt beats three fuzzy ones and saves tokens.

Team routine (checklist)

The team routine fits in eight points:

1. One goal per session
2. A spec or a plan file before any large generation
3. A compact after each major step, or before 50-60% of the window if the tool signals it
4. A clear when the topic changes
5. A file handoff if the session exceeds 30-40 useful minutes
6. MCP servers and permissions listed for the session
7. Deterministic scripts for the mechanical work
8. Human review on auth, payments, migrations and PII

For enablement, we favor a one-day workshop, 8 people maximum, on a real repo. We force compact, clear and the versioned plan there, not a feature tour.

If you want to scope Claude Code and team conventions on a real process, we can do it in 20-40 minutes.