The transcript is not the memory.

The largest file a long coding session leaves behind is its own conversation. On one workstation, one session's transcript reached 224 MB over seventeen days while a comparable project's transcript stayed at 18.6 MB on identical hooks and settings — accumulation, not configuration. The API beneath the session is stateless, so every request carries the conversation before it, and a session that never ends sits at its context ceiling permanently. The transcript is an accumulation surface, not a memory: what a session learned must be extracted into files, or the residue is paid for as long as the session lives.

§1One session accumulated 224 MB in seventeen days

The measurement that opens this series was not made for these notes. It was recorded on 15 September 2026 in the protocol file that loads at the start of every session on the estate it governs — one operator's machine, its workspace folders and two product repositories. The record: one project "reached a 224 MB transcript over seventeen days in a single session, against 18.6 MB in a comparable one — identical hooks and settings, so it was accumulation, not configuration". The comparable project is described in that file and named nowhere on disk, so the comparison survives only as recorded. The transcript itself can be re-measured, and was.

# recorded 2026-09-15, in the operator's protocol file
one project        224 MB   seventeen days, a single session
a comparable one   18.6 MB  identical hooks and settings

# re-measured 2026-09-21, same machine
ls -l ~/.claude/projects/*/*.jsonl | awk '{print $5, $9}' | sort -rn | head -1
236422970  …-longevity/15bbd718-0521-40f9-ab46-2eb650dcd9a8.jsonl

The re-measurement, 236,422,970 bytes on 21 September 2026 — 226 MB as du -sm rounds it — sits above the 224 MB recorded six days earlier: the accumulation had continued while the record aged. Both figures are kept in this paper, each with its date, because the gap between them is itself the finding restated.

Neither session was misconfigured, which is the point of the pair. The rest of this paper derives why the surface accumulates, why the accumulation returns less than it costs, and what has to leave the transcript for a session to stay cheap.

§2A ceiling reached is a ceiling kept

The API beneath these sessions holds no conversation between calls. Anthropic's Messages API reference states it in one sentence: "The Messages API can be used for either single queries or stateless multi-turn conversations."^[1] The conversation lives in the client's request: "When creating a new Message, you specify the prior conversational turns with the messages parameter, and the model then generates the next Message in the conversation."^[1] The same vendor's context-window documentation describes the consequence turn by turn: "Progressive token accumulation: As the conversation advances through turns, each user message and assistant response accumulates within the context window, and previous turns are preserved completely", and the input phase of each turn "[c]ontains all previous conversation history plus the current user message".^[2]

The operator's protocol file compresses those sentences into the clause its budget rests on: "cost and latency track the TRANSCRIPT, not the task". The serving layer softens the arithmetic — Claude Code's own cost documentation says it "automatically optimizes costs through prompt caching, which reduces costs for repeated content like system prompts, and auto-compaction, which summarizes conversation history when approaching context limits"^[3] — so the accumulated history is not re-processed from nothing on every call.

Caching changes the price, not the shape. In the vendor's words, "[i]nstead of reprocessing the same large system prompt, document, or conversation history on every request, the API reads from cache at a fraction of the standard input price".^[4] A fraction of the price is still a price with the history's size in it, charged on every request that carries the history — and compaction bounds the history's length without emptying it. Neither changes what the residue is. The vendor names what remains after both: "As token count grows, accuracy and recall degrade, a phenomenon known as context rot. This makes curating what's in context just as important as how much space is available."^[2] A ceiling that compaction keeps a session under is still a ceiling the session sits at, permanently, from the first day it is reached, where the smallest question is billed like the hardest. The session does not get cheaper by finishing its task. It gets cheaper by carrying less.

§3Most of what accumulates is not load-bearing

The cost side of that trade has a plain statement in the literature: "the time and memory complexity of self-attention are quadratic in sequence length."^[5] That paper is about mitigating the cost, and modern serving mitigates it further, so the realized curve is gentler than quadratic — but per-request compute still scales with what is carried, and the thing carried here is the conversation.

The return side scales worse. Models use long inputs unevenly: performance on retrieval from long contexts degrades significantly when the relevant material sits in the middle of the input, with the ends favoured, even on models built for long contexts.^[6] And advertised length overstates usable length: of models claiming contexts of 32K tokens or more, "only half of them can maintain satisfactory performance at the length of 32K" on synthetic tasks harder than simple lookup.^[7] Both results are measured on 2023- and 2024-era models with constructed retrieval tasks rather than agent transcripts, and they speak to accuracy, not cost — so they establish the direction of the effect on today's models, not its size.

Meanwhile the tokens themselves are mostly droppable. A prompt-compression method reports "up to 20x compression with little performance loss" across four benchmarks^[8] — a measured way of saying that most of what a long input carries, the answer never needed. What that line of work does not characterize is which kinds of content compression silently loses on agent histories: a correction, a decision, an invariant. Dropped corrections and stale invariants are precisely the loss a summary can commit silently, and they are exactly the sentences the rest of this series is about keeping on purpose.

No one of these papers states the conclusion these notes need. Assembled — compute scales with length, accuracy does not, and most tokens are droppable — they support it: a long transcript costs more than it returns. That assembly is this paper's own synthesis, and the 224 MB case is its instance, not its proof.

§4The residue is extracted, or paid for indefinitely

What deserves to survive a session is small and specific: the decisions made, the holes fallen into, the files touched, the next step. In a 236,422,970-byte transcript those sentences exist, at addresses nothing indexes, interleaved with seventeen days of everything else. Extraction is the act of writing them into files whose size is bounded by a rule rather than by a session's lifespan — and then ending the session that produced them.

The protocol measured in this series does it with ordinary files and two commands: a handoff that persists current state, then a clear. The vendor's cost page states the two exits: "/compact reads the conversation it summarizes, so compacting a large context is itself a large request. When you want a fresh start instead of continuity, /clear costs nothing".^[3] The hook that polices the transcript budget ends its warning with the operative sentence: "Finish with /handoff, then /clear. The memory files are the continuity, not the transcript." The files load at the next session's start instead of riding along on every request in between.

Three limits bound this paper. The comparison that opens it is two projects on one machine, recorded once on 15 September 2026; the smaller of the pair cannot be re-identified today, so the pair survives as a dated record, not a benchmark. The file size is a proxy for accumulation, and these notes claim nothing about bytes per request. And nothing here measures what extraction loses — which facts deserve a file, how they are merged, and what forces the loop to run are the subject of Paper 002. The literature already built the third place as a managed runtime: MemGPT pages hierarchical memory tiers between the context window and outside storage.^[9] The construction the next paper describes is that idea's plainer cousin — files in a directory, written by two commands and read by a hook.