By Alex Urevick-Ackelsberg, Zivtech

Part 2: The "Just One More Turn" Trap

Context rot is superlinear. Past the knee, you pay more to carry old context than to do new work.

Part 1 was about gaps killing the cache. This one is the opposite: sessions that never stop.

You're in a flow. Claude is writing good code, tests are passing, you're knocking things off the list. Turn 20. Turn 40. Turn 60. Why stop?

Because every turn is getting more expensive than the last, and you can't feel it happening.

Problem #2: Context Rot

Every file Claude reads, every tool result, every code block it writes back becomes permanent context. Claude rereads the entire conversation on every turn. Turn 5 rereads five turns. Turn 50 rereads fifty.

Reading a 2,000-line file adds roughly 20,000 input tokens, reprocessed at cache-read rates on every subsequent turn. Read it again because you forgot? Two copies.

The cost per turn isn't fixed. It's a function of everything that's come before.

What I Was Doing

Two patterns. The second one cost me.

The honest marathon. A big refactor across six files. Claude reads, plans, implements. I give feedback, it iterates. By turn 50, we've touched all six files, run tests twice, read a config, read a migration. Every artifact is still in context. The session feels the same as turn 10, but the meter is 3-4x what it was at the start.

The session that should have been two. I finish the refactor at turn 35 and think "while I'm here, let me fix that auth bug." Different task, different files, different mental model. But starting a new session feels like overhead. So I keep going, carrying 35 turns of irrelevant refactor context through every turn of the new task.

This is the trap. The marginal cost of "just one more turn" is invisible. It rises like a slow tide.

The knee lands around turn 50. Past that, you're paying principal-engineer rates for junior-engineer context management.

The Numbers

Opus 4.6 ($15/MTok input, $1.50/MTok cache read), warm-cache session:

These figures include all token costs (input, output, cache writes and reads).

Annually, one session per workday, 250 days. A developer who routinely rides into the rot zone: ~$7,000/year. One who splits at the knee: ~$1,250/year. Difference: $5,750 per developer, per year, on context accumulation alone. Mix in idle-tax penalties from Part 1 and it gets worse.

Two failure modes look completely different on the meter. The bloated session creeps. The cache-miss session spikes. Knowing which one you're in tells you what to fix.

What I Do Now

One task per session. When I finish a task and think "while I'm here," that's the signal to save and start fresh. The new session starts with a 5,000-token handoff instead of 200,000 tokens of irrelevant history.

Watch the turn count. Turns 30-40 are the yellow zone. Not a hard cutoff (some tasks genuinely need 50+), but past 40 I ask: is this one task that needs more turns, or two tasks masquerading as one?

Split on task boundaries, not turn counts. The turn count is a proxy. The real signal is when the work shifts to different files, a different problem, or a different mental model. That's the seam.

Why This Surprised Me

The session feels fine at turn 60. Claude doesn't slow down perceptibly. The responses don't get visibly worse (though they can: large contexts degrade model performance in subtle but measurable ways). The cost quietly climbs.

I ran 80-turn sessions for weeks before I looked at the numbers. No single session was terrible. Multiplied across workdays, it was the single largest category of avoidable spend.

"Keep your sessions short" sounds like generic advice. It's specific economics: the cost curve is superlinear, the knee is around turn 50, and past it you're paying more to carry old context than to do new work.

The just-one-more-turn helper: make the curve visible

The companion helper installs a UserPromptSubmit hook that tracks turn count and estimated context size. Past the yellow zone (~30+ turns or ~200K+ context), it warns you. Past the knee, it tells you what the session has cost and what a fresh start would save.

git clone https://github.com/zivtech/claude-cost-helpers
cd claude-cost-helpers/just-one-more-turn
./install.sh

Informational only. Some sessions genuinely need 60 turns. The hook makes sure that's a choice, not an accident.

At the fleet level

At team scale, the question is which developers are routinely riding into the rot zone and what it costs.

Joyus AI Internal's cache-economics module (spec 011) tracks totalInputTokens, totalCacheReadTokens, and messageCount per session. That surfaces the growth curve: which sessions accumulate context faster than they produce value, and which developers burn cache reads on conversation management instead of work.

The Rule

If you've finished one task and are about to start another in the same session, stop. Save the session. Start fresh. The cost of re-explaining is always less than the cost of carrying dead context.

Coming Up

Visuals: cumulative cost curve at visuals/econ-mini-02-turns-vs-cost.html, three trajectories at visuals/econ-d2-cost-trajectory.html — embeddable via iframe, dark-mode aware, color-blind safe.

Code: zivtech/claude-cost-helpers on GitHub. GPL-3.0-or-later licensed.