This analysis organizes the evidence behind context Is Claude Code's Scarce Resource, then explains the practical implications, trade-offs and current limits.
Read the evidence below as a decision trail: what changed, why it matters, which trade-offs shaped the result, and where the conclusion still depends on context.
After using Claude Code for a while, you will often find that it becomes clumsier the more you use it - but this is probably not because the model has become worse, but because the context window has become overused. Context is not an unlimited capacity, but a scarce resource with a budget. Learning to use /compact and /clear within a session and using CLAUDE.md across sessions is much more important than memorizing more prompt skills.
When I first started using Claude Code, I always felt that it was sometimes awesome and sometimes stupid. For the same task, the session was done smoothly at the beginning, but later on it began to miss requirements, confuse files, and give out things that I had already told it not to do again. I thought it was because the model was unstable or because some prompts were not written well enough - but later I discovered that it was mostly the same thing: the context window was exhausted.
When you see this clearly, you will have a completely different understanding of how Claude Code is used. It is not a tool that gets better and better as you use it, but it is an Agent that has a working desktop budget. The size of the desktop determines how much it can remember at the same time. How to take care of that desktop is what this article will talk about.
Why context is budget, not capacity
The course describes the context window as the "working memory" of Claude Code - everything entered into it will eat up this space: the prompt you type, the files it reads, the results of tool calls it runs, and the responses it receives. Every interaction consumes budget.
I prefer "memory" to "memory"work desktop"This metaphor. Memory sounds like the more the better; the desktop clearly lets you know - too many things will crowd out new ones, you will not be able to find them, and you will make mistakes. The Context window is the desktop. The desktop is limited and things cannot be piled up infinitely.
Another key difference is: context is not "capacity", it is "budget”. When a session ends, the entire desktop is cleared. Next time you open it, Claude can't remember what you talked about last time. Things that need to be remembered for a long time must be written somewhere outside the session - this is also the reason why CLAUDE.md exists (will be discussed later).
When the budget is almost exhausted, Claude Code will automatically compact - summarize the previous conversations and tool call results to make room to continue. This mechanism is convenient, but at the cost of losing detail. The instructions that were originally kept intact may be reduced to a two-sentence summary, and the original content of the file that is remembered may only be the title. If your task requires a complete context, you will often feel like "Claude suddenly forgot something" after auto-compact - in fact, it is not that it forgot, but that it was abstracted by itself.
The command to check the current usage is /context. It will tell you how much context is currently used and what is taking up the most space. I myself would hit this first when I thought Claude was starting to react slower and clumsier - it was usually obvious at a glance what the problem was.
How to manage within Session: The difference between /compact and /clear
Only two directives for context management within a Session are really important:/compact follow /clear. The difference is not a technical detail;Applicable situations。
/compact It will summarize all current conversations, remove unnecessary tool call results, and then keep the summary and continue. Applicable to: Are you still doing it?same feature, stuck at the upper limit of context, but need to continue to use the context established previously. It helps you extend the life of the same vein.
/clear Quite the opposite - clear the entire conversation, Claude doesn't remember anything that happened before, and start from scratch. Applicable to: you wantSwitch to new feature, the context of the previous mission should not be brought over.
My own judgment criteria are simple:If the context is the same as the feature card, it will be compact, if it is changed to the feature card, it will be clear.. The latter is particularly important - many people habitually put all tasks into the same session because they "don't want to re-explain it". But the context of the previous task will become the bias of the new task: a certain file structure hypothesis you established during debugging, something you just told Claude not to do, and the remaining plan that was not completed in the previous round. Bringing these things into new features will only interfere with it, not help.
So what I use more often is /clear, no /compact. It's better to spend 30 seconds giving Claude a clean onboarding than to do something new with a bunch of noise.
CLAUDE.md is a cross-session context
No matter how well the budget is managed within the session, the project information still has to be re-explained every time it is restarted - this is the problem CLAUDE.md wants to solve. It is a Markdown file placed in the root directory of the project. It will be automatically read every time Claude Code is started, and the content will be appended to your prompt. In other words,It's something that Claude can remember without spending the session context budget.。
But there is a misunderstanding about this tool: CLAUDE.md is not a prompt template, nor is it a "more is better profile". It is an onboarding file for the Agent - so that the Agent does not need to re-explore the same things every time. I have written several myself (gwarket-site, blog-writer, publish-tools, insidewriter, outsidewriter), and slowly figured out three judgment criteria.
What to write and what not to write: write what Agent asks you repeatedly
CLAUDE.md's best content, is"The agent asks you repeatedly, or repeats the answer to something you made the mistake of". For example: what is the stack of this project, what are the commonly used instructions, what are the commit specifications, and what are the security rules that cannot be violated. If these things are not written, each new session will have to be re-explained, which is a complete waste.
In turn,Don’t write things that the Agent already knows. Writing "Please use React to write the front end" is nonsense - Claude already knows React. What you need to write is "Our React project uses Server Components + Server Actions, do not use API routes".Project-specific trade-offs. The former accounts for the context budget but has no information volume; the latter is the reason why CLAUDE.md should exist.
My publish-tools CLAUDE.md is the product of this kind of thinking. It barely describes how to use the tool or how to write the program. The entire document only contains four "iron rules of publishing": no new WordPress categories or tags are allowed, the default is to publish drafts, the password can only be read from.env, and the security word "confirm" must be entered completely. Each of these four items is a mistake that Agent will make repeatedly - it must be written down.
shared-rules is an evolved version of CLAUDE.md
When you have written several CLAUDE.md, you will encounter an embarrassment:Multiple projects require the same specification. For example, both insidewriter and outsidewriter need the same set of writing style specifications, the same set of FB posting rules, and the same set of Threads algorithm facts. If you each write a copy in your own CLAUDE.md, you will have to change two things once you make a change - sooner or later there will be a split.
The solution is to extract the common specification into a separate layer. There is one in my directory shared-rules/, which contains writing-style.md, fb-writing.md, threads-writing.md, and reading-protocol.md. CLAUDE.md of each project does not repeat these contents, only reference: "Read before writing:../shared-rules/reading-protocol.md」。
When you write the same words for the third time, you should take them out. This principle works surprisingly well on CLAUDE.md - it not only reduces duplication, but also allows "spec changes" to only happen in one place. Change writing-style.md once, and all writers will automatically apply the new specification without manual synchronization.
CLAUDE.md becomes shorter as you write it.
Counter-intuitive observation:CLAUDE.md will become shorter and shorter as you write it for a long time.. If you step on the pit and add another one at first, then step on the pit and add another one, it will seem to go on indefinitely. But when you step on a certain specification that is "required by the third project", it will be extracted to shared-rules - CLAUDE.md will become shorter instead.
As a result, the CLAUDE.md of each project is becoming increasingly streamlined, leaving only "Unique to this project” part. gwarket-site CLAUDE.md has about 76 lines, all of which are Next.js workflow and deployment details; publish-tools has about 56 lines, all of which are publishing security rules. Writing style rules are not in either file at all - they're all in the shared-rules layer.
This evolution is very similar to software architecture: initially stuffing everything into a file, slowly extracting shared modules, then utilities, and then design systems. The CLAUDE.md system is also in the same maturation process. The difference is that what you draw is not the program code, but the specification.
My point of view: context budget thinking is more important than prompt skills
Most Claude Code teachings will focus on "how to write a good prompt", "how to use plan mode", and "how to interact with subagent". These are all important, but I think the real watershed lies further ahead — Have you managed context as a scarce resource?。
A user who can memorize a bunch of prompt templates is not necessarily better than a user who can manage context. The former solves the problem of "how to make Claude answer correctly once", while the latter solves the problem of "how to make Claude maintain the ability to answer correctly". The problem of sessions getting dumber as they run longer is not solved by prompt, but by context budget thinking.
Thinking about it from this perspective, CLAUDE.md is not just a "config file for Claude", it isLong-term memory without draining session context budget. Writing CLAUDE.md became a design exercise - what things are shared frequently and worthy of occupying context? What are the low-frequency special cases that should not be loaded every time? This trade-off thinking is the real learning curve of Claude Code.
And when you start to think like this, you will find that the next question naturally arises: "What should not be written into CLAUDE.md and is it more cost-effective to use Skill instead?" This is the topic to be dealt with in the third article of the series.
Practical questions and boundaries
How long should CLAUDE.md be?
There is no absolute answer, but my own standards are:Every item in it must be used in every session, otherwise it will be a waste of context.. Length doesn't matter, density matters. If a rule is only used in specific situations (for example, "5 checks to do when publishing an article"), putting it in CLAUDE.md means that the context tax is paid once per session but rarely recycled - this kind of rule should be written as a Skill or workflow file and loaded on demand.
What is written in CLAUDE.md and what is written in Skill?
The simple division is:Write CLAUDE.md which should always be loaded, write Skill which should be loaded only on demand. CLAUDE.md is loaded into the context at the beginning of each session; Skill is only fully loaded when Claude determines that it is needed (look at the name and description first, and then decide whether to expand it). Stack description, security rules that cannot be violated, and commit specifications are written in CLAUDE.md for content that "you should know no matter what you do." Skills are more cost-effective for multi-step processes that are required for a specific situation (such as "listing articles" and "running fact checks"). Part 3 of the series will delve deeper into this trade-off.
This is Part 2 of Claude’s Code 101 series:
- Part 1: Claude Code is not a stronger completion - it is essentially Agentic Loop (to be released)
- Article 2: Context is the scarce resource of Claude Code (this article)
- Article 3: Why I wrote these 7 things as Skills - a PM’s customized judgment (to be released)
Some of the concepts in this article are based on the Anthropic open course Claude Code 101 (https://anthropic.skilljar.com/claude-code-101). The content of the article is the author's own study notes and observations, not a translation or paraphrase of the course.
What to take away
The article's value is in the evidence and trade-offs behind context Is Claude Code's Scarce Resource, not in treating the conclusion as universal.