How to Save Tokens in Claude Code: Practical Habits for Test Automation Sessions

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.

• ❌ Explore the whole app and test everything you find.
• ✅ Test the login form at /login: valid credentials, empty password, and wrong password cases.

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

/clear

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

/compact

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.

.claude/skills/playwright-form-tester/SKILL.md

• 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

npm install -g @playwright/cli@1.2.0

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!