← All recipes
  • context
  • workflow
  • cost

/clear on a bigger repo: one session was still cheaper

We reran our /clear test on a 197-file codebase with 14 feature modules, up from 24 files last time. All 24 hidden-test checks passed both ways. Staying in one session cost 14% less ($0.137 vs $0.159 a run).

Cost per run Each bar is the average cost of the runs, starting at $0.

See every run, check and diff →

Our last /clear test found that staying in one session was 17% cheaper than clearing between three unrelated tasks. But that ran on a 24-file API. A fair question came back: does that still hold on a bigger codebase, where there’s more for old context to get in the way? So we reran the same test on a bigger repo.

The setup

The same notes API, grown into a bigger app: 197 files and about 3,000 lines of JavaScript. On top of the original routes, services, middleware and utilities, it has 14 feature modules (projects, teams, invoices, subscriptions, webhooks, exports and more). Each module has its own model, validation, storage, permissions, service, routes and tests, all wired into the same server. The modules are generated from one template, so they look alike.

Same three unrelated tasks as last time, word for word:

  1. Fix a bug where dates show the wrong month, and add a test.
  2. Add pagination to GET /notes with page and pageSize (default 5, max 50).
  3. Write a new rate-limiter middleware from a spec, with tests.

We ran them two ways, 3 times each:

  • One session: all three tasks in one continuous conversation.
  • Clear between: a fresh session for each task, which is what /clear gives you.

Afterwards, hidden tests Claude never saw checked each task, and the repo’s own npm test (48 tests before any changes) had to pass.

What happened

One session Clear between
Month bug fixed (hidden test) 3 of 3 3 of 3
Pagination correct (hidden test) 3 of 3 3 of 3
Rate limiter correct (hidden test) 3 of 3 3 of 3
npm test passes 3 of 3 3 of 3
Average total cost $0.137 $0.159
Cost of task 1 (starts fresh in both setups) $0.045 $0.042
Cost of task 2 $0.065 $0.075
Cost of task 3 $0.027 $0.043
Average turns 22.7 28.7
Average time per run 45.5s 46.6s
Average input tokens, including cached 296,059 328,817
Average output tokens 6,413 6,208
Largest context in task 3, tokens (average) 30,803 20,870

Claude Code 2.1.302, Sonnet 5.5, 3 runs per column. Every run, check and diff: run data. The six runs cost $0.89 in API charges in total. That’s what we measured: API cost, not how much of a Pro or Max plan’s usage limit this would use.

What we learned

Staying was still cheaper. One session averaged $0.137 against $0.159 for clearing, 14% less. On the 24-file repo the gap was 17%. Task 1 starts fresh either way, so its small gap is run-to-run noise. The difference is in tasks 2 and 3, where a fresh session has to find its way around the repo again. Clearing took 28.7 turns on average against 22.7.

A bigger repo didn’t mean a bigger context. Claude didn’t read the codebase. It searched with Grep and Glob, then opened only the few files each task needed, and no run opened a file in the 14 modules. So a fresh session started at 18,153 to 18,267 tokens, and the single session’s largest request was 34,143 tokens. That’s far from the context window, so carrying the history stayed cheap.

Context did grow in one session. In task 3, the single session’s largest request averaged 30,803 tokens, against 20,870 for a fresh session doing the same task. It didn’t hurt here: every hidden test passed in both columns. Last time, one single-session run rejected a too-large pageSize instead of capping it. This time all six got it right.

What failed, and the limits of this test

  • Nothing failed a check. All 24 hidden-test checks passed (3 tasks × 6 runs), and so did npm test every time.
  • Some shell commands were blocked. In two runs per column, Claude tried to write or edit a file through a shell command our test sandbox doesn’t allow. It used its normal edit tools instead and still passed. In a normal session you’d have been asked to approve the command.
  • Bigger, but not messy. The extra modules are generated from one template, and the three tasks never touch them. A real codebase this size, with tasks that span modules or long debugging sessions, could push context much higher. We haven’t tested that yet.
  • Six runs is a small sample. The cost gap is consistent with last time, but a few cents either way is within normal run-to-run variation.
  • API cost only. We report what the API charged. We can’t measure how much of a subscription’s weekly limit the same work would use.

The recipe

  1. Don’t clear just because the topic changed, even in a bigger repo. Staying was 14% cheaper here, with the same results.
  2. Repo size isn’t the trigger, context size is. Claude searched instead of reading the whole repo, so 7.5 times as many source files (180 against 24) barely changed what it carried. Run /context and clear or /compact when the window fills with old file dumps or a finished debugging session.
  3. Clear when the old context is wrong, not just old. None of these tasks left misleading context behind. If one does, a fresh session is the cleaner start.