# How to Save Tokens in Claude Code: Practical Habits for Test Automation Sessions > Source: > Published: 2026-07-16 16:30:00+00:00 *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!