Part 3 of the "Automating Playwright with Claude Code" series. Catch up on Part 1: Getting Started with Claude Code and Playwright CLI and Part 2: Playwright CLI vs MCP if you missed them.
In Part 2, we saw nearly a 90,000-token gap between Playwright MCP and Playwright CLI on the exact same test. But tool choice is only one lever. Once you're running longer test-writing sessions with Claude Code — building out a whole regression suite, not just one test — a handful of everyday habits make just as much difference to your token bill and your context window. This post covers the ones that consistently pay off.
#
Why Token Usage Matters for Test Automation
Long sessions hit context limits. A regression suite with 15+ forms to test can genuinely exhaust a session if every step re-sends unnecessary state. #
Cost scales with usage. If you're on API pricing rather than a flat subscription, token-heavy sessions translate directly into a bigger bill. #
Wasted tokens mean wasted time. Once a session gets bloated, responses slow down and Claude has to work harder to find the relevant thread in a cluttered context. #
Good habits compound. None of these tips are dramatic on their own, but stacked together across a full day of test-writing, they add up to meaningfully longer, cheaper sessions.
#
Prerequisites
- Claude Code installed and set up (see Part 1 if you need the Playwright CLI setup too).
- Comfortable running slash commands (
/clear
, /compact
) inside a Claude Code session.
#
Table of Contents
- Scope Every Task Tightly
- Use
/clear
Between Unrelated Tasks
- Use
/compact
Instead of Letting Context Grow Unchecked
- Prefer Headless Mode by Default
- Push Repeatable Work into Scripts and Skills
- Pin Tool Versions in CI
- Conclusion
#
Step 1: Scope Every Task Tightly
The single biggest lever is also the simplest: be specific about what Claude should touch.
- A broad, open-ended instruction invites Claude to navigate multiple pages, take extra snapshots, and explore paths you didn't actually need tested — all of which costs tokens.
- A scoped instruction gets a scoped result: Claude touches exactly the pages and elements relevant to that form.
- If you do want broader exploration, do it as its own deliberate step ("first, list every form on this page"), not bundled into the same request as the actual testing.
#
Step 2: Use /clear
Between Unrelated Tasks
- Run this whenever you're switching from one unrelated task to another — say, finishing the login form tests and starting on the checkout flow.
- Without it, Claude's context keeps accumulating snapshot history, tool outputs, and conversation turns from the previous task, none of which is relevant to the next one.
- Rule of thumb: if the next thing you're about to ask has nothing to do with what you just finished, clear first.
#
Step 3: Use /compact
Instead of Letting Context Grow Unchecked
- For tasks that genuinely need the earlier context (you're still working through the same feature, just many steps in),
/compact
summarizes the conversation so far instead of wiping it — you keep continuity without carrying every raw tool output forward.
- Use this proactively in long sessions rather than waiting until you hit a context warning.
#
Step 4: Prefer Headless Mode by Default
- Headed (visible) browser sessions are useful when you're actively debugging and want to watch what's happening, but they tend to invite more exploratory screenshotting and back-and-forth.
- For routine test writing where you already know the flow, default to headless and only switch to headed mode when something's actually failing and you need to see why.
#
Step 5: Push Repeatable Work into Scripts and Skills
If you find yourself explaining the same steps to Claude across multiple sessions — say, your team's standard login flow before every test — that's a sign it belongs in a script or a Skill, not in a fresh prompt every time.
- A script's output is what costs tokens, not the logic that produced it — so deterministic steps run far cheaper as a script than as freshly reasoned-through instructions.
- A Skill only loads into context when it's actually relevant, so you're not paying for it on unrelated tasks either.
- We'll build a full example Skill for this exact use case in Part 4 of this series.
#
Step 6: Pin Tool Versions in CI
- Using
@latest
in CI means an upstream update can silently change behavior mid-pipeline, causing retries — and retries cost tokens twice over.
- Pin explicit versions for both Playwright CLI and your browser binaries in CI configs, and upgrade deliberately rather than automatically.
#
Conclusion
None of these habits are complicated, but together they're the difference between a Claude Code session that runs out of steam halfway through a regression suite and one that comfortably gets through your whole day's testing. In the next and final post of this series, we'll put several of these ideas together and build a real, reusable Skill for Playwright form testing — the SKILL.md file that ties this whole series together.
What's your current token-saving habit in Claude Code — anything I missed? Let me know in the comments!