Context Management: Don't Let It "Lose Its Memory" or Burn Up Tokens

📚 Series Navigation: The previous post 18 · CLAUDE.md Usage Guide taught you to put project conventions into that "onboarding manual". This post goes one level up — this manual, along with your conversations and the files you've read, are all crammed together on a workbench called the "context window". How to manage this workbench well and avoid overflowing it is what we'll cover today.

When you first start using Claude Code, it's easy to do something pretty silly.

Taking over an unfamiliar medium-sized project, you might think "Let it read the entire repository first before doing anything, so it understands the big picture best," so you toss out a command: "Read all the files in this project, then tell me the architecture."

And the result? It actually reads the files one by one, the terminal scrolls furiously, and after reading twenty-something files, it becomes noticeably slower and sluggish. When you then ask it to fix a login bug, it actually asks you "which file is the auth module you mentioned in" — a file it just read ten minutes ago. The work isn't done, but it has "lost its memory" first, and burned a large amount of tokens.

Once you understand this, you'll know: The context window isn't the fuller the better; when it's full, it actually becomes dumber. Today, we'll thoroughly explain this "workbench" — what it is, what happens when it's crammed full, how to clean it up with /compact and /clear, how to monitor usage in real-time, and how to save tokens from the source.

After reading this post, you will get:

• An analogy that lets you thoroughly understand the "context window", and what exactly happens when it is full
• When to use /compact (compress), /clear (clear), or directly open a new session, explained clearly in one table
• How to use /context and /usage to keep a real-time eye on specific actions that take up space + expected outputs
• Five token-saving habits you can use every day, each coming from real pitfalls
• An understanding of what "auto-compact" actually does behind the scenes, so you won't be startled by its sudden interruptions anymore

---

01 The Context Window: How Big is Claude's "Workbench"

Let's establish this core concept first.

Context window — is the total capacity of everything Claude can "see" at the same time in this session, measured in tokens (the minimum billing unit for a model to process text).

It holds not just the words you type, but a whole pile of things. The official context-window.md breaks it down very clearly, let me translate it into plain English for you:

Things loaded onto the workbench	When they come in	How much space they take
System prompts (Claude's behavior guidelines)	Every startup, you can't see them	A fixed chunk
Your CLAUDE.md (Global + Project)	Loaded in full at startup	Depends on file size
Auto memory	Loaded at startup (has a limit)	Medium
Every sentence you type	Enters every time you send one	Usually very small
Every file it has read	Appended every time it reads one	The biggest chunk, burns the fastest
Command outputs, tool results	Appended after each tool call	Fills up extremely fast for logs/large files

See that? You might think a conversation is mainly "the words you say", but the bulk is actually the files it reads and command outputs. Asking it to read twenty-something files earlier was equivalent to suddenly piling the workbench high with other engineering blueprints, leaving very little empty space for "doing work".

Analogy: Workbench Size. Think of Claude as a carpenter working on a workbench. The bench is only so big, blueprints, tools, semi-finished products, and the sticky notes you hand him all have to be spread out on this bench. If the bench is large, he can attend to many things simultaneously; if the bench is crammed full, he has to push earlier blueprints aside — and he "forgets" the information on those blueprints.

How big is this bench? It depends on the model you use. Most models are in the 200,000 token range, and some models (like those with the [1m] tag) can reach 1 million. But remembering one sentence is more useful than remembering numbers:

No matter how big the bench is, it has boundaries. The fuller it gets, the dumber it becomes.

💡 One-sentence summary: The context window is Claude's workbench, and the bulk of what it holds is the files it reads, not what you say; the bench has boundaries, and when it's full, it starts "dropping" early information.

---

02 What Happens When the Workbench is Crammed Full: It Gets Slower, Dumber, and Even "Loses Its Memory"

This is the most important judgment to remember in this post: The context is not the fuller the better; when full to a certain extent, Claude's performance will visibly decline.

Why? The more things there are on the bench, the thinner the model's "attention" is spread, and earlier irrelevant content starts interfering with the current task. The industry calls this phenomenon "context rot".

How do you know it has "rotted"? I've summarized a few frontline symptoms, and you should be on alert if any of these hit:

• It starts contradicting itself, forgetting the plan the two of you had clearly already agreed upon
• Answers become vague and generalized, with fewer and fewer details, starting to speak correct nonsense
• It repeatedly asks you things you have already answered (like the "which file is auth in" question at the beginning)
• For the same problem, you correct it more than twice and it's still spinning in circles

For example, when writing a data migration script, after debugging repeatedly for over an hour, towards the end it served up the erroneous plan we had jointly rejected in the first half. It's not that its capabilities have degraded, it's that the context has been polluted by an hour of debugging garbage.

So what does Claude do when the bench is truly full? It will auto-compact — detailed in Section 05. For now, just know this: It's a passive life-saving action, the timing is not up to you, and it might suddenly interrupt you right in the middle of a critical task.

So the correct posture is: Don't wait for it to auto-compact, you actively manage it. How to manage? Read on below.

💡 One-sentence summary: A crammed context triggers "context rot" — contradictions, vagueness, repeated asking; rather than repeatedly correcting on a polluted bench, it's better to actively clean up.

---

03 Two Brooms: /compact (Compress) vs /clear (Empty)

To tidy up the workbench, Claude Code gives you two brooms, their purposes are completely different, never mix them up.

/compact: "Pack and Flatten" the things on the bench, but keep them

What /compact (compress) does is: summarize this long string of conversation history into a concise abstract, then replace the original verbatim record with the abstract, and continue working on the same task.

Analogy: Organising a desk full of scratch paper into a single page of bullet points. You discuss with a colleague for two hours, and the desk is piled high with discarded sketches. /compact is summarizing this pile of sketches into a one-page bullet point list of "We finally decided on A, rejected B, next step is C", freeing up the desk, but the conclusions remain.

A key point is that it supports using instructions to tell it what key points to keep:

/compact Keep the architectural decisions for the authentication flow and confirmed API formats, discard invalid attempts from debugging

The English example given in the official costs.md is /compact Focus on code samples and API usage, which means the same thing.

When to use /compact: The task isn't finished yet, but the context is almost full, and what was discussed earlier is still needed later. For example, when a feature is halfway done, the early architectural decisions can't be lost, but a bunch of trial-and-error command outputs in the middle can be thrown away.

/clear: Empty directly, start over from scratch

/clear (empty) is more ruthless: it completely clears the entire conversation history, which is equivalent to starting a brand-new session.

But don't be afraid — /clear will not touch your CLAUDE.md and auto memory, they will still load automatically in the new session. What you lose is only "the content chatted about in this conversation", the project conventions and long-term memory are still there.

Analogy: Switching to a brand new task, just wipe the workbench clean before starting work. The previous job is done, and the next job has absolutely nothing to do with it, so completely emptying the bench is much neater than keeping the previous mess around as interference.

The official costs.md original text suggests: When switching to unrelated work, use /clear to start over, because "stale context will waste tokens on every subsequent message".

Here is an iron rule worth setting: If you correct the same problem twice and it's still wrong, don't waste time in this session, just use /clear directly, take the lessons learned from these two times, rewrite a more precise prompt and ask from scratch. A clean bench + a better prompt almost always beats continuing to argue in a polluted context — this is one of the most valuable experiences from actual testing.

💡 One-sentence summary: /compact is "pack, flatten, and keep for continued use", /clear is "empty completely and restart for a different job"; if it's still wrong after correcting twice, don't hesitate, just /clear.

---

04 Monitoring Usage: Use /context and /usage to see clearly how much space is left on the bench

Judging "is it almost full" by feeling is too metaphysical. Claude Code gives you two commands to see real numbers, don't mix up these two names.

/context: See what has filled the bench

/context

/context will visualize the current context's real-time usage with a colored grid chart, and list it by category — how much the system prompt takes, how much CLAUDE.md takes, how much each MCP service takes, how much the conversation history takes, and it will also give optimization suggestions. The official context-window.md is clear: If you want to know your real context usage at any given moment, just run /context.

A habit worth developing is: before starting a large task, run /context to check the baseline first. If you find that a certain MCP service is taking up a large chunk for nothing, or CLAUDE.md is ridiculously bloated, clean them up before working.

There is also a companion command /memory, used to check exactly which CLAUDE.md and auto memory files were loaded at startup — use it to check when you suspect it has "remembered wrongly".

/usage: See how many tokens / how much money this session burned

/usage

The Session block at the top of /usage gives token usage statistics for the current session, and will also convert it to USD based on local estimates. The layout given in the official costs.md looks roughly like this:

Total cost:            $0.55
Total duration (API):  6m 19.7s
Total duration (wall): 6h 33m 10.2s
Total code changes:    0 lines added, 0 lines removed

Expected output explanation: Total cost is the estimated cost of this session (calculated locally, may differ from the real bill, authoritative figures are subject to the Claude Console); Total duration (API) is the actual time spent calling the model; Total duration (wall) is the total time you have had this session open.

⚠️ Reminder: The session cost for Pro / Max subscribers is included in the subscription, this USD amount has no direct relationship with your bill, just look at the relative magnitude. We already discussed specific plans and billing in Chapter 06, this post only looks at tokens from a "context" perspective.

Hate typing it manually every time? The official also supports persistently displaying context usage in the statusline, letting it hang on the screen at all times. See the official statusline documentation for specific configuration methods, this post will not expand on that.

💡 One-sentence summary: /context sees "what is taking up the bench", /usage sees "how many tokens / how much money burned this time"; before starting a large task, run /context first to check the baseline.

---

05 Auto-compact: It saves its own life, but don't count on it

We mentioned "auto-compact" a few times earlier, this section clarifies what it exactly is.

Auto-compact — is a built-in life-saving mechanism in Claude Code: when the context is about to hit the window limit, it will automatically summarize the conversation history into an abstract, freeing up space to continue working, saving you from hitting the wall and getting an error directly. The official costs.md lists it alongside prompt caching as one of two means for Claude Code to "automatically optimize costs".

Analogy: Automatic unloading on an assembly line. The conveyor belt is almost full, the system automatically gathers and compacts the old materials to prevent the whole line from jamming. You don't need to manage it, it triggers automatically.

It sounds very considerate, but I advise you not to rely on it, for two reasons:

First, you don't control when it triggers. It's very likely that you are having it do a critical step, the bench happens to be full, and it "snaps" to a stop to compress first — the rhythm is completely interrupted.

Second, auto-compact is "instruction-less" compression. The moment it triggers is precisely when the context is fullest and the model is most sluggish. At this time, it decides itself what to throw away and what to keep, and it's very likely to compress away what you consider important.

So the correct approach is to act proactively: when you feel the conversation getting long and /context shows high usage, run /compact yourself first, and include instructions to tell it to keep the key points. Proactive compression has two benefits — you decide the timing, and you decide what to keep.

There is another, more worry-free trick: Write your compression preferences directly into CLAUDE.md. The syntax given in the official costs.md is to add a section in CLAUDE.md:

# Compact instructions

When you are using compact, please focus on test output and code changes

This way every time it compresses (whether manual or automatic), it will prioritize keeping your specified content, which is equivalent to putting an insurance policy on auto-compact. For example, writing "Keep confirmed architectural decisions and interface contracts when compacting" in the CLAUDE.md of a frequently used project saves you from having to instruct it manually every time.

💡 One-sentence summary: Auto-compact is for saving its life, but it interrupts you and might compress away key points; instead of waiting for it, it's better to actively /compact with instructions, or hardcode the retention preferences in CLAUDE.md.

---

06 Five Tricks to Save Tokens: Stop the bench from filling up so fast from the source

Tidying up the bench is remediation, preventing it from piling up so fast is the best policy. The following five tricks can be used every day, each starting from the "context" perspective, independent of plan pricing.

Trick 1: Don't use large projects for practice. Just like what was said in Chapter 07 — during the learning and experimentation phase, create a toy project with three to five files. Fewer files mean it reads less, the bench is clean, and you can see clearly what it has done. The root cause of the "read twenty-something files and lost memory" pitfall at the beginning was using an unfamiliar medium-sized repository right off the bat.

Trick 2: Use @ to point to files precisely, don't let it search all over the repository. Rather than saying "fix the login bug" and letting it rummage through files one by one, it's better to just @src/api/auth.ts fix the 401 issue. The official costs.md says it very bluntly: Vague requests trigger broad scanning, specific requests allow it to work efficiently with minimal file reads. @ simply nails its gaze directly onto that file.

Trick 3: Don't cram too many requirements in at once. Tossing out five unrelated tasks in one breath will cause the files it reads and outputs it produces to burst the bench. Break them down into five small questions, and finish one before moving to the next, keeping the bench permanently clean.

Trick 4: Break down long tasks, and clear after finishing a section. Don't expect one session to carry a large feature from start to finish. After finishing a relatively independent phase, do a /compact collection once; when switching to a completely unrelated part, use /clear to start over.

Trick 5: Throw lengthy operations to a subagent. Tasks that produce massive amounts of output, like running tests, flipping through tons of logs, or checking documentation, should be handed over to a subagent — it messes around on its own independent workbench, and only brings the conclusion summary back to your main conversation. In the example given in the official context-window.md, a subagent read a 6100-token file and only took up 420 tokens when returning to the main context. There will be a dedicated post on subagents later, for now just know it's a sharp weapon for saving context. (Link to be added later)

Put "remediation" and "prevention" together to compare, and you'll know where to put your effort:

Action	Nature	When
/compact	Remediation · Compress to keep	Task unfinished, context usage high, previous text still needed
/clear	Remediation · Clear and restart	Switching to unrelated tasks, or pollution too heavy
Open new session directly (Exit then claude)	Prevention · Thoroughly clean	Want an absolutely clean bench, not even traces of memory from this time
@ precisely point to files	Prevention · Read fewer files	Should do this every time asking for a requirement
Toy project for practice	Prevention · Less from source	Learning, experimentation phase
Subagent runs lengthy tasks	Prevention · Isolate output	Running tests / flipping logs / checking docs

💡 One-sentence summary: Tidying up the bench is remediation, reading fewer files, breaking down small tasks, and tossing to subagents are prevention; the muscle memory you should develop the most is — use @ to accurately point to files when asking for requirements.

---

07 Hands-on: Walk through context management in three steps

Just reading without practicing won't stick in your memory. Below, we use a minimal flow to let you see with your own eyes how the context grows, and how /compact compresses it back down. Start claude in any project directory and follow along.

Step 1: Check the baseline at the start

After starting Claude, the first thing is to type:

/context

Expected: The terminal lists the categorical usage of the current context — you will see that system prompts, CLAUDE.md, etc., already occupy a chunk (it's totally normal to have usage before even chatting), and a total usage and optimization suggestions are provided at the bottom. Note down this initial number.

Step 2: Deliberately "feed" it some content, then look at the change

Just ask it to read a few files and chat for a few rounds, for example:

Read the main source code files of this project, and tell me the overall structure

Wait for it to finish reading and answering, then type it again:

/context

Expected: The usage has obviously gone up, the numbers for the conversation history and files columns have grown larger. This is the process of "the workbench being filled", you saw it with your own eyes.

Step 3: Use /compact to press it back down

/compact Keep the overall structure conclusion of this project, discard the raw content of individual files

Expected: A prompt similar to "Conversation compacted" appears in the terminal, the compression is completed silently in the background, and will not flash a screen of summaries at you. After compacting, check again with /context, the usage in the conversation history column should have dropped — it still remembers the structure conclusion, but the raw bytes of individual files were compressed into an abstract.

Controlled verification: Run /context once before and after compression, if the token count of the conversation history goes from high to low, it means /compact worked. If you want to verify that it "didn't lose memory", go ahead and ask "what is the project structure you summarized just now", and it should still be able to answer.

⚠️ A detail: Compression is a lossy operation. It keeps the key points and general outline you specify, but the verbatim content of earlier tool outputs will be discarded. So for truly important conclusions, make it a habit to jot them down into CLAUDE.md as explained in Chapter 18 — telling Claude directly to "add it to CLAUDE.md", or editing it yourself with /memory, is safer than leaving it compressed in the conversation.

💡 One-sentence summary: Run /context → feed content → /compact → then /context again, you see with your own eyes how context grows and how compression presses it back; comparing the token count of the conversation history before and after tells you if it took effect.

---

08 Summary

In this post, we've explored the "context window" workbench from the inside out:

What you learned	One sentence clarification
What is the context window	Claude's workbench, the bulk is the files it reads, not your words
What happens when it's full	Triggers context rot — gets slower, vague, contradicts itself, loses memory
/compact	Pack, flatten, and keep for use, can take instructions to specify key points to retain
/clear	Empty completely and restart for a different job, doesn't touch CLAUDE.md and memory
/context · /usage	One looks at "what's occupying", the other looks at "how much was burned"
Auto-compact	Life-saving mechanism, but will interrupt you and might compress away key points, proactive action is better
Saving tokens	Toy projects, @ pointing to files, don't cram too much, break down tasks, throw to subagents

You should now be able to: Understand what is inside the context window, why Claude gets dumb when it's full; use /compact when it's time to compress, use /clear when it's time to restart; use /context and /usage to keep a real-time eye on usage; and from the moment you raise a requirement, use a bunch of token-saving habits, so the bench always has empty space for doing work.

Ultimately, the essence of managing context is just one sentence: Frugally spend Claude's limited attention on things that truly matter.

This image compares the context window to a workbench: When it's crammed full of files and conversations (about 92% in the picture), you rely on /compact to compress a stack of chats into a page of bullet points (keep to continue using), or /clear to sweep the entire bench clean (start over from scratch) — the former preserves information, the latter aims for cleanliness.

---

The next post 20 · Permissions Configuration — in this post we managed how much Claude "can remember", in the next post we'll manage how much it "can do hands-on". Reading files, modifying code, running commands — which ones exactly need to ask you first, which ones can be let through, and how to configure a set of permission rules that are both safe and handy? Let's leave a question for you to think about first: Are you willing to let it run git push directly without your nod?

---

Recommended Reading

• Agent SDK: Bring Claude Code's capabilities into your own programs
• How to choose features: CLAUDE.md vs Skill vs Hook vs MCP vs Subagent
• Subagents: Outsource the work, don't carry everything yourself