/clear.
Recently, I hit the usage credits limit in Claude Code, which I use at work.
What confused me was that my plan usage still had plenty of room, while the additional usage credits I had configured had already reached their limit.
After looking into it, I realized that Fable usage was what had caused me to go beyond the included usage and consume additional credits.
That explained why the credits had run out.
But it also made me ask a different question:
Why was I consuming so much usage in the first place?
Until then, I had been using Claude Code every day without paying much attention to what was actually driving my usage.
So I started looking more closely at /usage and reviewing how I had been working.
One thing that stood out was Playwright MCP.
That did not mean Playwright MCP itself was the reason I had exceeded my usage limit.
Rather, it made me notice how much context could accumulate during browser testing, and how that context could continue to affect subsequent work if I kept using the same session.
The habit I eventually changed was very simple:
After finishing a test with Playwright MCP, if I do not need that context for the next task, I use /clear.
This article is a short learning log about how I got there.
I used to think about Claude Code usage in a fairly simple way:
The more questions I ask, the more expensive it gets.
That is not entirely wrong.
But the size of the context Claude is working with also matters.
Claude Code is not looking only at the latest sentence I type.
It works with the context needed for the current task, including previous conversation history, files it has read, and tool results.
So, if I simplify my understanding quite a bit:
The larger the context is, the heavier it can become to keep processing within that context.
/usage Made Me Look at Playwright MCP
When I checked /usage, I saw results like these:
79% of your usage was at >150k context
61% of your usage came from subagent-heavy sessions
36% of your usage came from the MCP server "playwright"
At first, I thought these were three separate problems:
But after looking at how I had been working, they seemed more connected than I initially thought.
When using Playwright MCP for E2E checks, I repeatedly do things like:
For Claude to understand the browser state, relatively large tool results can be added to the context during these interactions.
Each individual operation may feel like a simple browser check.
But after repeating them several times, browser-related context can accumulate quickly.
That part can be considered a necessary cost of testing.
The more interesting problem for me was what happened afterward.
From my perspective, once I reach:
Test complete. Time to move on to the next task.
much of the information generated during the Playwright session has already served its purpose.
But if I continue using the same session, I also continue working with that context.
For example:
I used to move directly to step 4 without resetting the session.
But when working on the next feature, I may no longer need all the browser information generated during the previous E2E test.
There is a gap between:
“This context is no longer useful to me”
and:
“Claude Code is no longer carrying this context.”
Looking into my usage made me much more aware of that difference.
So I now follow one simple rule:
After finishing a Playwright MCP test, if I do not need that context for the next task, I use /clear.
I do not clear the session mechanically after every test.
My rule is simply:
Will I need this context for the next task?
If not, I clear it.
When I first started using Claude Code, I tended to think of context as something that was simply better to have more of.
And of course, having the right context is important.
But after looking into my usage, I started thinking about the cost of keeping context that is no longer useful.
This feels especially relevant with tools like Playwright MCP, where repeated browser interactions can add a lot of information to the session in a relatively short period of time.
And once the test is finished, that information may no longer be useful for the next task.
This experience made me start thinking of Claude Code context as having a kind of lifecycle:
Collect it when needed.
Keep it while it is useful.
Let it go when its job is done.
For now, that is the rule I am following.