Anthropic recently shared guidance on how to get more out of Claude Code, and one idea stood out: context management is becoming an engineering skill in its own right. Not a productivity tip. Not a nice-to-have. An actual discipline, with its own failure modes, its own trade-offs, and its own compounding costs when it’s ignored.
Most developers still treat context the way they treated RAM in the early days of programming — assume there’s plenty, and only think about it once something breaks. That mental model doesn’t hold up anymore. Here are the practices worth taking seriously.
Clear Context Between Unrelated Tasks
Not every task needs the history of everything that happened before it. When you finish one piece of work and move to something unrelated, the previous conversation doesn’t disappear — it keeps riding along, resent with every new exchange. Keeping irrelevant context around increases noise, costs tokens, and can make the agent measurably less effective, because it now has to sift through a longer, less relevant history to find what actually matters for the task in front of it.
The fix is simple and easy to skip: start fresh when the task genuinely changes. A new feature, a different part of the codebase, an unrelated bug — these deserve a clean slate, not a continuation of yesterday’s debugging session.
Understand What Is Already Being Loaded
The /context command shows you what Claude is actually receiving before you even send your next prompt. Most people never run it, which means most people are working blind.
Memory, MCP servers, skills, agents, project instructions, and other configuration all quietly accumulate. You may be starting a task with tens of thousands of tokens already loaded before you’ve typed a single word. That should make us rethink the assumption that “more context is always better.” Context isn’t just fuel — it’s also noise, and noise competes with the signal that actually matters for the task at hand.
Run /context before assuming the agent needs more information. Often it already has more than it needs.
Use Compact Intentionally
Compaction isn’t just a nicer version of clearing. It summarizes the conversation so far instead of discarding it, which sounds strictly better — but timing matters, because prompt caching affects how much work needs to be reprocessed. Compact at the wrong moment and you can invalidate a cache that was saving you real time and money, then pay to rebuild context you didn’t need to rebuild yet.
The lesson here generalizes beyond this one command: understand what a context-management tool actually does before reaching for it out of habit. Clear, compact, and starting a new session are three different operations with three different cost profiles. Treating them as interchangeable is how teams end up with inconsistent, hard-to-explain token bills.
Be Explicit When Referencing Files
If you already know which file matters, reference it directly instead of asking the agent to search the entire project for it. This sounds obvious, but it’s one of the most common sources of avoidable overhead in real sessions.
Every open-ended search is a chain of tool calls — list directories, grep for a term, read a handful of candidate files, narrow it down. Each step adds tokens and adds latency. When you already know the answer, saying so directly collapses that entire chain into a single read. Less searching leads to fewer tool calls, which leads to less noise, which leads to lower token consumption. It’s a small habit that pays off on every single prompt where you have the information to spare the agent the search.
Push Noisy Work to Sub-Agents
A good example is git status, large logs, repository-wide searches, or any command that can generate a huge amount of output. Your main agent often doesn’t need the entire raw output — it needs the two or three lines that are actually relevant.
Let a smaller, cheaper agent process the noisy output and return only the distilled result. This is context isolation in practice: the expensive, high-context main thread stays focused on the actual problem, while a disposable sub-agent absorbs the cost of reading through thousands of lines of logs or search results. The sub-agent’s context gets thrown away when it’s done. The main agent’s context stays clean.
A cheap sub-agent that reads 5,000 lines and returns three is doing exactly what it should. Don’t make your main agent do that reading itself.
A Different Way of Thinking About AI Coding
Put these practices together and they point at a real shift in mindset. We’re moving away from “give the AI more context and let it figure everything out” and toward “design the context, tools, and agents so the AI only processes what it actually needs.”
The first approach feels generous and low-effort. The second one is genuinely more interesting engineering, because it treats context the way we’ve always treated any other constrained resource — memory, bandwidth, database connections — as something to budget deliberately rather than something to assume is infinite.
Token Economics Will Become an Engineering Concern
This matters more as we move beyond heavily subsidized AI coding subscriptions and start running agents against APIs, open-source models, and our own infrastructure. When someone else is absorbing the marginal cost of every wasted token, sloppy context habits are invisible. When you’re paying per token against a metered API, or running your own inference, they show up immediately on a bill or a latency graph.
If you’re building with AI agents today, understanding context windows, prompt caching, tool calls, sub-agents, and context isolation isn’t optimization you get to later. It’s part of the architecture, in the same way that understanding indexes and query plans is part of building anything on top of a database.
The developers who learn to manage context effectively will build agents that are not only cheaper, but also faster and more reliable. That combination — cheaper, faster, more reliable — isn’t a trade-off you have to choose between. It’s what naturally falls out of not making the agent do more work than the task actually requires.