Claude Code can write a whole test suite in an afternoon. It can also burn a week of budget doing it. The difference isn’t the model. It’s the system around it: which tool does which job, how much “brain” each step gets, and who decides that a test is really done.
I use Claude Code with two open-source plugins: ECC (Everything Claude Code) and oh-my-claudecode (OMC). Most people install both, switch everything on, and wonder why their sessions feel slow and their bill keeps growing. Here’s how I use them as a tester: what each one is for, the rules that save money and time, and my step-by-step workflow.
01Two plugins, two jobs
The easiest way to waste money is to make both plugins do the same work. So I give each one a clear job.
| ECC | oh-my-claudecode (OMC) | |
|---|---|---|
| Its job | How the work is done well | Who does the work, and in what order |
| Think of it as | The team’s standards and expert reviewers | The team lead who splits up work and doesn’t stop until it’s finished |
| I use it for | Testing skills (Playwright, test-first, verification), code and security review, coding rules | Planning big decisions, running several agents in parallel, pushing a task to a verified finish |
| Saves money by | Getting it right the first time: fewer rewrites | Sending simple tasks to cheaper models and big ones to stronger models (the project says this saves 30–50% of tokens) |
One rule above all: only one tool is “in charge” of a long-running loop at a time. If OMC is pushing a task to completion, don’t also start an ECC loop on the same task. Two managers giving orders to the same worker costs double and finishes later. OMC’s own docs give the same advice.
02Install once, then trim
Type these inside Claude Code, one line at a time:
Then trim. Every installed skill, rule and hook takes a little of the AI’s attention in every session, and attention is tokens.
- Choose ECC’s hook level on purpose. Run
/ecc:configure-eccand pick a hook mode: off, minimal, standard or strict. Strict hooks are great on a shared team repo. Working alone, I found them slowing me down: a strict pre-edit check made me re-explain the same facts before every file change. For solo work, minimal is enough. - Install language rules only for what you use. A Playwright + TypeScript project doesn’t need rules for Go, Rust and Kotlin.
- Write a short CLAUDE.md. Run
/initonce per project. It records how to install, run and test the project, so Claude doesn’t pay to rediscover it every session.
03Seven money rules
These are the habits that made the biggest difference to my token bill.
- Use the cheapest brain that can do the job. Renaming selectors or fixing a typo doesn’t need the strongest model. Switch with
/model, and turn thinking down with/effort lowfor mechanical edits. Save high effort for test strategy and hard debugging. OMC routes this for you inside its own workflows. - Start fresh between unrelated tasks.
/clearwhen you switch tasks,/compactat a natural break inside a long one. A long session drags its whole history into every new message./contextshows you what’s taking up space. - Let the computer run the tests, not the AI. Ask Claude to run the suite with a short reporter and read back only the failures. Never paste a full log or a 5,000-line report into the chat.
- Parallel agents cost parallel money. Three agents working at once use roughly three times the tokens. That’s worth it for three independent page objects, not for a one-file fix.
- Spend big only on decisions. Use the expensive moves, like multi-agent planning or deep reasoning, for “what should we test and why”. Never for “add a wait here”.
- Stop runaway loops early. If OMC is going in circles, type
stopomc. A loop that isn’t converging after a few rounds rarely converges later. - Watch the meter. OMC’s status line shows what’s running and how much it uses, and ECC’s
/ecc:cost-reportsummarises tracked spend. You can’t cut what you don’t measure.
04My workflow for a new test project
Here’s the full path, from “we need tests” to a suite I’d trust in CI. Each step names the tool and roughly what it costs.
1. Clarify what to test cheap
If the request is vague (“can you test our checkout?”), let OMC interview you before anything is written. It asks the questions that expose hidden assumptions. Skip this step when the requirements are already clear.
2. Set up the project cheap
Before the first test: /init for CLAUDE.md, a .gitignore for dependencies, test reports and secrets, and a clean first commit so every later step can be undone.
3. Plan the test strategy expensive, worth it
This is the one decision worth paying for. OMC’s ralplan has several agents argue about the plan until they agree. For a small project, ECC’s single planner is enough and much cheaper.
4. Write the tests, test-first cheap
AI is very good at writing a test that passes. That’s exactly the problem: a test that has never failed proves nothing. ECC’s testing skills make it show the failure first.
5. Go parallel only when the work is independent costs per agent
Three page objects that don’t touch each other? That’s a good job for a small team. One flaky test? That’s a job for one agent.
6. Push to green, honestly cheap if guarded
OMC’s /execute keeps going until the task is verified, not just “looks done”. As a tester, I always add one guard. The fastest way for an AI to make a test pass is to weaken the test, so I forbid it.
7. Prove it’s stable cheap
Green once isn’t green. Run everything several times and treat any test that changes its answer as a bug.
This habit comes from real projects. On a Java and Selenium suite, fixing flaky tests at the root cut false-positive failures by 60% and made the CI results trustworthy again.
8. Review before anything merges cheap
Run ECC’s review, then read the diff myself. For each AI-written test I ask: does each assertion check something that matters, and would this test fail if the feature broke?
05Testing AI needs its own rules
When the thing under test is an AI agent, “does it pass?” becomes “how often does it misbehave, and is that getting worse?”. Two practices matter most:
- Attack it on purpose. Design adversarial scenarios: make the agent try to reveal data it shouldn’t, ignore its instructions, or invent answers. Each one gets a metric that fails on a real leak.
- Lock in a baseline. Today’s scores become the floor. If a prompt or model change drops any score below it, the build fails.
My AI agent evaluation demo does both: a strict voice agent contains the attacks, a deliberately weak one leaks as a control, and a regression gate runs in CI on every push.
06Which tool for which job
| When I want to… | I use | Cost |
|---|---|---|
| Turn a vague request into clear requirements | OMC /deep-interview | Low |
| Decide the test strategy on a big project | OMC /ralplan | High, worth it |
| Plan a small change | ECC /ecc:plan | Low |
| Write or fix Playwright tests | ECC e2e-testing skill | Low |
| Add a test safely, failing first | ECC tdd-workflow skill | Low |
| Build several independent pieces at once | OMC /team | Per agent |
| Push a task to a verified finish | OMC /execute | Medium |
| Prove the suite is stable | ECC verification-loop skill | Low |
| Get a second opinion from another AI | OMC /ask codex | Low |
| Review before committing | ECC /ecc:code-review | Low |
| Design evaluations for an AI feature | ECC eval-harness skill | Low |
07Mistakes that cost me money
- Installing everything. Hundreds of skills I never used, loaded into every session.
- A team of agents for a one-line fix. Three agents, three times the bill, same result.
- Letting the AI “fix” a red test by changing the assertion. The suite went green and stopped testing anything. Now the guard in step 6 is in every prompt.
- One endless session. By the afternoon, every message was carrying the whole morning with it.
/clearfixed it. - Pasting full logs. Thousands of lines when the answer was in the first failure.
08The short version
ECC decides how the work is done, and OMC decides who does it. Only one runs the loop at a time. Pay for strong models only on decisions, keep sessions short, and let the computer run the tests. Make every test fail before you trust it, run everything more than once, and read every diff before it merges.
Sources
- ECC (Everything Claude Code) on GitHub
- oh-my-claudecode on GitHub