Unrelated tasks, same answer on /clear
Our last test found staying in one session cheaper for related tasks. We repeated it with three unrelated tasks in different parts of a codebase. Staying still won on cost, with one catch.
In our first context test, staying in one session beat clearing between tasks by 28%. But all three tasks touched the same files, the best case for staying. The fair follow-up: what if the tasks have nothing to do with each other?
The setup
A small notes API: about 470 lines across 24 files (routes, services, middleware and utilities). Three tasks, each in a different part of the code:
- Fix a bug where dates show the wrong month, and add a test. (A utility file.)
- Add pagination to
GET /noteswithpageandpageSize(default 5, max 50). (A route and its tests.) - Write a new rate-limiter middleware from a spec, with tests. (A new file.)
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
/cleargives you.
What happened
| One session | Clear between | |
|---|---|---|
| Month bug fixed (hidden test) | 3 of 3 | 3 of 3 |
| Pagination matches our spec (hidden test) | 2 of 3 | 3 of 3 |
| Rate limiter correct (hidden test) | 3 of 3 | 3 of 3 |
| Average total cost | $0.145 | $0.176 |
| Cost of task 1 (same in both setups) | $0.054 | $0.060 |
| Cost of task 2 | $0.063 | $0.074 |
| Cost of task 3 | $0.029 | $0.041 |
| Average turns | 21.7 | 24.7 |
Claude Code 2.1.296, Sonnet 5.5, 3 runs per column. Every run, check and diff: run data.
What we learned
Staying was still cheaper, by less. One session averaged 17% less than clearing, down from 28% when the tasks were related. Task 1 starts fresh either way, so its small gap is run-to-run noise; the real difference is in tasks 2 and 3. That fits what cached history does: even context that doesn’t help the next task costs little to carry in a codebase this size.
The “failure” was most likely our wording, not the session. In one single-session run, Claude rejected a pageSize over 50 with an error instead of capping it at 50. Our prompt said “max 50”, which supports either reading, and our hidden test assumed capping. We count it as a miss because it doesn’t match our spec, but the lesson is about wording: write “cap at 50” or “reject above 50”, not “max 50”.
Context grew, but never got big. By the end of the single session, the conversation carried about 28,000 tokens, against 20,000 to 25,000 for a fresh one. That’s small next to the context window, which is why it stayed cheap. In a large codebase with long tasks, the numbers could flip, and we haven’t tested that yet.
The recipe
- In a small codebase, don’t clear just because the topic changed. It cost more here, even for unrelated tasks.
- Clear when the old context gets big or misleading. Run
/contextto see what’s in the window. A long debugging session or a pile of file dumps from a finished task is the time to clear or/compact. - Say exactly what limits mean. “Max 50” got two different behaviours from the same model. Cap, reject or clamp: pick one and write it down.