DevOps
I Started Using /clear After Testing with Playwright MCP
Tohru Yaginuma DEV Community
7 views
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.
Read original: https://dev.to/tohru_yaginuma_4f041533c6/i-started-using-clear-after-testing-with-playwright-mcp-5ggk
← Previous
Why AI Keeps Making the Same Coding Mistakes—And How Teaching It Pain Gives It Wisdom
Next →
Agentic development needs a famous 5 minute install
Related
How I Built an Agentless Self-Hosting Orchestrator with 100+ Tested Stacks & 100% Local AI
DevOps
2
DEV Community
Postman Collection to MCP: From Requests to MCP Tools
DevOps
2
DEV Community
Можно ли, не имея доступа к маршрутизаторам провайдера, повлиять на выбор его upstream для своего трафика?
DevOps
2
Dev.to (EN Zone)
An Alarm Dashboard + Tecnoalarm Keypad in Home Assistant
DevOps
2
Dev.to (EN Zone)
Comments0
No comments yet — be the first