The quadratic problem (the insight most people miss)

Recall from Chapter 2 that every new turn re-sends the entire conversation history. Now combine that with tokens costing money per call, and you get a nasty surprise.

Here is the growth pattern, straight from the Codex deep-dive:

Turn 1:  [system] + [user msg 1]                       -> ~2k tokens
Turn 5:  [system] + 4 turns + tool calls               -> ~15k tokens
Turn 20: [system] + 19 turns + dozens of tool calls    -> ~80k tokens
Turn 50: [system] + 49 turns + hundreds of tool calls  -> potentially millions

Each turn re-sends everything before it. So the total amount of data sent over the lifetime of a session is quadratic in the number of turns. Double the session length and you roughly quadruple the total tokens sent, and therefore the cost.

If that word "quadratic" feels abstract, here is the everyday version. Imagine a meeting where the rule is that before anyone speaks, they must first read the entire transcript of the meeting so far, out loud. The first person reads almost nothing. The tenth person reads nine speeches. The fiftieth person reads forty-nine. The meeting does not get linearly longer; it balloons. That is your agent session.

This is not a bug. The model genuinely needs the history to reason coherently from turn to turn; it has no memory otherwise. But the consequences are real and worth stating plainly:

• Long sessions are disproportionately expensive. The cost is not linear in length.
• Editing-heavy sessions burn context fastest. Lots of apply_patch calls means lots of large diffs piling up in history. A session that does heavy file editing exhausts the window faster than one doing light Q&A.
• One session should do one focused task. This is the single most important workflow habit that falls out of understanding the loop. Do not run a marathon session that does everything; start fresh sessions, or delegate to subagents (Chapter 11), for distinct jobs.