Long Story Short
- After using tools like Playwright MCP that can return large tool results, continuing to work with that context still in the session can make subsequent processing heavier.
- Since then, when I finish testing with Playwright MCP and do not need that context for the next task, I use
/clear. - My rule is simple: “Will I need this context for the next task?”
Context
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.
Usage Is Not Just About How Many Times You Talk to Claude
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:
- My context was too large
- I was using too many subagents
- Playwright MCP was expensive
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:
- Open a page
- Inspect elements
- Click a button
- Fill in a form
- Check the state after navigation
- Fix something and try again if necessary
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.
The Test Was Finished, but the Context Wasn't
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:
- Implement a feature
- Verify it with Playwright MCP
- Confirm that it works
- Start implementing another feature
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.
After Playwright MCP Testing, I Use /clear
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.
Conclusion
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.
Top comments (1)
Those browser snapshots are especially heavy because accessibility trees and raw DOM dumps easily run 10k to 20k tokens per tool turn. When you stay in the same session, you pay the input token rate on those dead DOM trees on every single subsequent prompt, even if you are just asking for a commit message.
I ran into the same 150k context ceiling and started running browser verification in an isolated subagent instead. The subagent inspects the UI, returns a clean three-line pass or fail summary to the main session, and the entire DOM tree gets garbage collected on exit without needing to wipe the main chat history.