Synthesis: Jan 28 -- Mar 4, 2026

36 days of Claude Code session logs across a multi-project ecosystem. What follows is not a summary of what happened each day, but an analysis of the structures, shifts, and tensions that emerged over the period.

---

The shape of the work

The ecosystem contains 25+ active repositories across four GitHub orgs. Over these 36 days, the developer touched most of them, but not evenly and not randomly. The pattern is closer to a rotating cast: a project dominates for a stretch (days to a week), then recedes while another takes center stage, then resurfaces when something unblocks or irritates enough to demand attention.

Week 1 (Jan 28--Feb 2): Hologram (Discord bot) and Aspect (identity sandbox) dominate. Heavy feature work, Y.js migration, template engine decisions. Pteraworld gets sustained visual tuning. This is the "ship features" phase.

Week 2 (Feb 3--9): Reincarnate emerges as the dominant project and stays dominant for nearly three weeks. The Flash decompiler goes from scaffolding through IR pipeline, type inference, multiple codegen backends, and runtime implementation in a compressed burst. Normalize gets its Datalog fact enrichment. Motif gets scaffolded. Existence gets its first design sessions.

Week 3 (Feb 10--16): Reincarnate continues but the character of work shifts from "build the pipeline" to "make the output not embarrassing." Twine/SugarCube frontend bootstrapped, parser migrated from hand-rolled to oxc_parser. Existence enters deep design territory (identity, health, mood systems). The pattern shifts from feature velocity to correctness and design rigor.

Week 4 (Feb 17--23): Architecture questions start dominating. De-singleton refactoring across four game engine runtimes. Save system philosophy. Sensory prose generation design (a 13-hour continuous session). Normalize linter redesign. The mood shifts from "build" to "is what we built right?"

Week 5 (Feb 24--Mar 2): Infrastructure and introspection. Server-less CLI unification, Crescent typechecker design, tiltshift binary analysis tool, rescribe format validation against real corpora. The ecosystem starts building tools to understand itself (session analysis, normalize observability commands). Format quality standards harden.

Week 6 (Mar 3--4): Architectural compression. The dominant pattern is removing unnecessary complexity from what was built in prior weeks. Ptera.world's grouping system gets systematically depedentialized -- hardcoded ecosystem grouping logic, tier attributes, and cross-layout position contamination all removed. Normalize undergoes crate reorganization: generalist functionality stays in the main binary, specialist features (sessions, architecture queries, graph analysis) split into separate crates. Binary bloat becomes a first-class concern -- ripgrep alone is 6.4MB, ast-grep vendoring requires strategic selection rather than wholesale inclusion. Scribble's runtime architecture crystallizes in a 143-turn design marathon: disjoint runtimes (DOM, Canvas 2D, WebGPU), each with its own stdlib primitives, built natively on reincarnate's platform layer. And manifest parsing infrastructure arrives via evaluation-based strategy -- let the language runtime do the parsing, output JSON, rather than fighting tree-sitter for every format.

The progression through the full period is legible: ship features, build pipelines, question architecture, harden infrastructure, build introspection, compress architecture. The final phase is not a return to the beginning -- it is the same projects being revisited with accumulated understanding. Week 6's refactoring is only possible because weeks 2--5 built the things that now need simplifying. This is not a plan that was followed -- it is a pattern that emerged from daily decisions about what to work on next.

How Claude Code is actually used

Session economics

Daily session counts range from 1 (Feb 3, a quiet day) to 93 (Mar 1). Typical active days run 30--60 sessions. Most sessions are short (3--15 turns), but several per week are marathon sessions (40--100+ turns) that hit context limits and require continuation summaries.

The developer's interaction style is distinctive and consistent: terse directives ("commit?", "push?", "what's next?", "up to you"), aggressive interruption of inference when it drifts, and a willingness to delegate task selection to the agent ("do whichever one you want", "anything 😃 up to you. pick something and do it i guess"). This is not someone who needs Claude to explain what it is doing. The agent's job is execution with occasional self-direction.

Mar 3--4 add a new dimension to session management: active interrupt-and-resume as a context strategy. Multiple sessions show "[Request interrupted by user for tool use]" markers, with the developer explicitly checkpointing work before context limits hit rather than waiting for them. The checkpoint pattern -- interrupt, let the agent summarize, continue from the summary -- is a more proactive version of the context overflow handling seen earlier in the period.

Parallelization as default

By early February, the developer is routinely running 10+ concurrent sessions across different projects. Mechanical work (batch comparisons, name mappings, documentation) gets delegated to Haiku subagents. The main agent handles architecture and design. This is not ad-hoc multitasking -- it is a deliberate division of labor where different model tiers handle different cognitive loads.

The cost data confirms this is efficient. Feb 25 cost $43.59 for 66 sessions with 67.7M cached tokens and only 10.2% unique input ratio -- heavy cache reuse from sessions branching off similar codebases.

By Mar 3, the subagent pattern extends to manifest parsing: batches of subagents spawned for TOML+JSON+XML parsers, line-based parsers, and eval-based implementations respectively. The developer is treating agent spawning as a fan-out operation -- partition work by type, parallelize, collect results.

Context as a resource to manage, not a limitation to fight

Context overflow is frequent (multiple sessions per day hit limits during sustained work). But the developer treats this as normal workflow, not a failure mode. Sessions end with handoff summaries. New sessions begin with "This session is being continued from a previous conversation that ran out of context." Context management becomes a practiced skill rather than a frustration.

The Feb 27 session on session analysis tools shows this becoming self-aware: discovering that Claude Code deletes sessions after ~30 days, setting up backups, and building normalize tooling to query session metadata. The developer is building infrastructure to compensate for the tool's own limitations.

The Mar 3--4 Scribble design session (3dcd6b94, 143 turns spanning ~21 hours) is the period's clearest example of context-as-resource: a single architectural conversation sustained across a full day, producing disjoint runtime definitions, asset pipeline decisions, persistence model choices, and editor integration plans -- all accumulated in one context window. The 354K output tokens and 98.7% cache hit ratio show this was efficient despite its length; the context was doing useful work on every turn.

The three recurring tensions

1. Velocity vs. architecture

The logs show a recurring cycle: build fast, discover the architecture is wrong, debate whether to patch or rethink, choose rethink, spend days restructuring. This happened with:

• Hologram's template engine: custom engine built, then migrated to Nunjucks within days
• Reincarnate's Flash rewrites: hardcoded in the TypeScript backend, then extracted into isolated modules after a full day of architectural debate
• Reincarnate's parser: hand-rolled Pratt parser (~760 lines), then replaced with oxc_parser after discovering the scope of SugarCube's actual semantics
• Game runtime singletons: all four engines discovered to have the same singleton problem, requiring a systemic refactor rather than four independent fixes
• Normalize's linting: initial approach (copy existing lint rules) rejected in favor of architecture-specific semantic analysis
• Ptera.world's grouping system (Mar 3--4): layout system accumulated special cases (buildEcosystemGrouping, tier: artifact, hardcoded position flows) that "sort of worked" but were architecturally indefensible. Systematic elimination over 56 turns: independent layouts, no cross-contamination, tier concept removed entirely
• Normalize's crate structure (Mar 4): monolithic binary grew through accumulated features (ripgrep, ast-grep, manifest parsing). Forced reckoning: generalist stays in main, specialist splits into separate crates. Binary bloat measured, not assumed

The developer's characteristic move is to push back on the agent's first architectural suggestion ("but is it really the backend's responsibility to know about flash?", "are you just throwing things out there?", "why is X special-cased at all?"), test the suggestion from multiple angles, then commit decisively once convinced. The Mar 3 ptera.world session exemplifies this at the UI layer: each turn either removes a layer of special-casing or exposes why it was wrong.

2. Simulation fidelity vs. arbitrary numbers

The Existence game sessions reveal a hard constraint that hardens over time: the simulation must be grounded in reality, not in game-designer intuitions. This emerges gradually:

• Feb 11: "Prose must reflect actual game state -- no fake artifacts the simulation can't back up" (prose honesty principle)
• Feb 13: "Event reuse as a bandaid is never acceptable"
• Feb 19: Agent criticized for inventing probabilities ("1 in 5!??!?!?!", "4-14%!??!") -- leads to CLAUDE.md rule against arbitrary numbers
• Feb 20: Citation discipline introduced -- PMID references required for biophysiological claims
• Feb 22: Push back on abstract "points" systems in favor of physiologically-grounded simulation
• Feb 23: Rejection of arbitrary wardrobe caps, demand for principled limits

This is a design philosophy crystallizing in real time. By late February, the constraint is explicit: "every correction means a rule is missing" -- if the agent gets something wrong, the response is not just to fix the output but to encode the principle that was violated.

3. Naming as load-bearing work

Project naming consistently takes significant time and is treated as architecturally important:

• Motif (Feb 9): naming brainstorm after rejecting polymath and others, settled quickly once "motif" resonated with structure exploration
• Deskspace (Feb 13): ~15 messages and 45 minutes on naming (freeview, osmose, wall, ledger, folio rejected)
• Tiltshift (Feb 28): 30+ turns in a single session dedicated to finding the right name for a binary format analysis tool
• Wick (Feb 2): dew-to-wick rename cascading across 9 crate directories
• Scribble (Mar 3--4): naming explorations (scuff, cubby, ember, flufflet) before settling on scribble for the sketch-level creative environment

Names are not labels applied after the fact. They encode design direction and are selected to be semantically precise, memorable, and available on crates.io. The ecosystem treats naming with the same seriousness as API design.

What evolved during this period

CLAUDE.md as a living constitution

The developer's CLAUDE.md files are not static configuration -- they are updated throughout the period as new principles are discovered:

• Jan 28: Basic project-specific guidance
• Feb 9: Commit discipline rules strengthened after agents failed to commit regularly
• Feb 12: Prose honesty principle encoded
• Feb 14: Module isolation rules clarified after CLAUDE.md assumptions were violated
• Feb 17: "Don't hand-roll what a library does. Use crates for standards."
• Feb 19: "Never invent numbers" and "always externalize decisions" added
• Feb 26: "Every correction means a rule is missing" -- meta-rule about rule creation
• Mar 3: "Never, ever hardcode file extensions" added after discovering hardcoded dispatch in normalize's type graph
• Mar 3: Ecosystem-wide CLAUDE.md propagation (handoff protocol, subagent guidance) pushed across multiple orgs

The feedback loop continues to tighten: Mar 3's extension-hardcoding rule came from discovering the issue in a type graph audit, escalating it to a CLAUDE.md rule, and applying it everywhere -- all in the same session. The time between violation-discovery and rule-encoding has compressed from days (early Feb) to minutes (early Mar).

From feature work to corpus validation

The period shows a clear trajectory from "build features" to "validate against reality":

• Early Feb: Write parsers, implement codegen, ship features
• Mid Feb: Compare output against reference implementations (FFDec for Flash, reference GameMaker for GML)
• Late Feb: Design quality standards, reject sloppiness for any format
• Early Mar: Download govdocs1 corpus (330 GiB), test rescribe/tiltshift against real-world data, measure statistical distributions

By March 2, the validation philosophy is explicit: production readiness means corpus-validated, not test-suite-passing.

From building to introspection

The ecosystem develops self-awareness over the final ten days:

• Feb 26--27: Discovery that Claude Code deletes sessions, backup infrastructure created
• Feb 28: normalize sessions commands improved for better introspection
• Mar 1: normalize analyze commands added (health, imports, test-ratio, ceremony, clusters, layering, provenance)
• Mar 2: Session message analysis tooling implemented, daily archiving with Haiku subagents
• Mar 3: normalize sessions messages gains per-turn token usage tracking (in/out/cache_read/cache_create), sorting by token count, date range and role filtering

The developer is building tools to understand not just the code but the process of building the code. normalize is both a code intelligence tool and a meta-tool for understanding the ecosystem's own development patterns.

From building to compressing

Mar 3--4 introduce a pattern not visible earlier in the period: architectural compression. Where weeks 2--4 were additive (build the pipeline, add the backend, implement the runtime), week 6 is subtractive:

• Ptera.world: remove tier concept, remove ecosystem grouping special case, remove cross-layout position contamination
• Normalize: consolidate normalize-output + normalize-view into one crate, extract specialist features into separate crates, measure and reduce binary bloat
• Normalize type graph: remove hardcoded file extensions, rebuild as language-agnostic dispatch

The compression is not refactoring for its own sake. It is driven by concrete failures: layout bugs caused by special-casing, binary bloat from unchecked feature accumulation, type graph dispatch that broke for unlisted languages. Each removal is motivated by a discovered defect in the existing architecture.

Evaluation as parsing strategy

Mar 3--4's manifest parsing work introduces a new technical pattern: instead of writing tree-sitter grammars for every manifest format (Cargo.toml, package.json, go.mod, requirements.txt), write a script in the target language that evaluates the manifest and outputs JSON. This "let the runtime do the work" approach sidesteps the complexity of structural parsing when the goal is data extraction. It appears in the manifest parser but the principle generalizes: when a language already has a runtime that understands its own formats, parsing is better delegated than reimplemented.

What the frustration signals reveal

The logs contain periodic frustration markers: "what the hell?", "why tf", "HELLO???", "can you please stop confidently making wrong guesses?", "did you read what i said?", "that's awful". These are not random -- they cluster around specific failure modes:

1. Agent ignoring documented constraints: using any types when CLAUDE.md warns against it, inventing numbers when the rule says to ground them
2. Agent being confidently wrong: proposing architectural changes without understanding the codebase's actual shape
3. Agent not committing work: multiple reminders that "commits aren't happening, full stop"
4. Agent tunnel vision: missing the general principle while fixing the specific case

The response to frustration is consistently structural rather than emotional: identify the missing rule, encode it, move on. By late February, the frequency of frustration signals decreases, suggesting either the rules are working or the developer's expectations have calibrated.

Mar 3's "why is X special-cased at all?" during the ptera.world refactor is a subtler form of the same frustration -- not at the agent, but at accumulated design debt. The target of frustration shifts from agent behavior (early period) to codebase entropy (late period) as the CLAUDE.md rules increasingly prevent the former.

The ecosystem's actual structure

Despite the flat project list in CLAUDE.md, the logs reveal a dependency hierarchy:

Foundation layer: server-less (CLI macros), portals (interfaces), normalize (code intelligence) These are tools that other projects consume. Changes here cascade everywhere.

Pipeline layer: reincarnate (lifting), rescribe (documents), paraphase (routing), tiltshift (binary analysis) These are the data transformation projects. They share format validation patterns and quality standards.

Runtime layer: crescent/moonlet (Lua), rainbow (web), dusklight (UI client), scribble (creative environment) These provide execution environments for the pipeline outputs. Scribble's Mar 3--4 design sessions place it definitively here: it is a set of runtimes built on reincarnate's platform layer, not an application.

Application layer: hologram (Discord bot), existence (game), aspect (identity sandbox), interconnect (federation) These are the end-user-facing projects that consume everything below.

Meta layer: normalize, github-io (docs), ptera-world (visualization) These exist to understand and present the ecosystem itself.

The daily logs show work flowing primarily downward: foundation changes trigger pipeline updates, runtime decisions constrain application design. The exception is when application-layer work surfaces architectural problems that require foundation-layer rethinking -- the de-singleton saga being the clearest example.

Mar 3--4 add a lateral flow pattern: normalize's crate reorganization is driven by its own growth (not by downstream consumers), and ptera.world's refactoring is driven by internal layout bugs (not by changes in the data it visualizes). The meta layer is now large enough to generate its own architectural pressures independent of the layers it observes.

The cost of breadth

36 days, 25+ repositories, daily session counts in the dozens. The developer maintains coherence across this breadth through:

1. TODO.md as the canonical work queue per repository
2. CLAUDE.md as behavioral constraints per repository
3. Conventional commits with scope for traceability
4. Weekly activity logs for direction-setting
5. Session handoff summaries for context continuity

But the logs also show the cost: context fragmentation (40 sessions in one day with many continuations), duplicate work (parallel sessions sometimes tackling the same problem), and scope creep (sessions that start with a bug fix and end redesigning the architecture).

The question the logs do not answer is whether this breadth is productive or dissipative. The developer is building a comprehensive ecosystem, but several scaffolded projects (Deskspace, Motif) have had no implementation work weeks after creation. Scribble, scaffolded Mar 3, immediately received a 143-turn design session -- suggesting the scaffolding-to-design pipeline has shortened, though scaffolding-to-implementation remains untested for newer projects. The activity logs from late February explicitly note the Deskspace and Motif absences. Whether they represent healthy backlog management or abandoned ambition is not determinable from the session data alone.

What is genuinely novel here

Most analyses of developer-AI interaction focus on individual sessions: how well does the AI complete a task? The interesting thing about this dataset is that it captures something different: how a developer uses an AI agent as a persistent collaborator across dozens of projects over weeks.

The patterns that emerge -- CLAUDE.md as accumulated behavioral rules, parallelized sessions across model tiers, corpus validation as the definition of production readiness, tools that introspect on the development process itself -- are not patterns that exist in the single-session literature. They represent a workflow that could only develop through sustained daily use.

The developer is not using Claude Code as a code generator. They are using it as an execution layer for a technical vision that spans too many projects for one person to implement manually. The CLAUDE.md files, the TODO.md queues, the session handoff protocols -- these are the governance structures of a one-person organization that delegates implementation to AI agents while retaining architectural control.

Mar 3--4 add a nuance: the agent is also used as a design interlocutor (the 143-turn Scribble session), not just an execution layer. The Scribble conversation is collaborative narrowing -- rapid-fire micro-questions (30-word turns asking for implications) interspersed with the agent's longer design explanations, creating tightly-iterated architectural decisions. This mode -- design through dialogue rather than design through specification -- is distinct from both the execution-delegation pattern and the traditional "generate code" pattern. The developer uses the agent differently depending on the phase of work: execution layer for implementation, sounding board for architecture, parallelizable worker for mechanical tasks.

Whether this scales, and whether the architectural control is actually maintained as the codebase grows, is the open question these logs pose but cannot answer.

Token usage patterns

The daily logs now include per-session token breakdowns (output counts, cache read/create volumes, hit ratios). Across 35 days with data, the quantitative story is consistent with the qualitative narrative but adds dimensions the prose alone could not surface.

The scale of the operation

Daily token consumption varies by two orders of magnitude:

Day	Total Tokens	Sessions	Character
Jan 28	3.09B	51	Heaviest single day -- Hologram feature sprint
Jan 31	1.58B	83	Aspect Y.js migration + Hologram polish
Mar 1	1.39B	93	Normalize analysis commands + tiltshift + rescribe
Mar 2	995M	80	Corpus validation + introspection tooling
Feb 22	1.08B	58	Reincarnate test suite + existence design
Mar 3	589M	54	Introspection tooling + ptera.world overhaul
Mar 4	321M	29	Architectural compression + vendor work
Feb 3	1.2M	1	Quietest day -- single brief session
Feb 18	~0	0	Model switch only, no substantive work

The median active day runs 250--650M tokens. The billion-token days correspond to sustained multi-project sprints with high parallelism, not just longer hours. Mar 3--4 are moderate days by token volume but architecturally dense -- the compression work is token-efficient because it removes code rather than generating it.

Cache efficiency tells a story about workflow

The headline number -- 96--99% cache hit ratios on most days -- is remarkably stable. But the consistency is the finding, not the number itself. What it reveals:

Prompt caching works extraordinarily well for this workflow. The ecosystem's CLAUDE.md files, project structures, and codebase context are loaded into every session. With 30--90 sessions per day branching off similar codebases, the first session pays the context cost and every subsequent session reads from cache. The developer's parallelization strategy (many concurrent sessions across related projects) is essentially a cache-warming pattern, whether intentionally designed as one or not.

The floor is informative. The lowest per-session cache hit ratios cluster at 46--79%, and these consistently correspond to either: (a) single-turn sessions with no opportunity for cache reuse, (b) first sessions of the day establishing fresh context, or (c) cross-cutting changes like ecosystem-wide CLAUDE.md propagation that load novel content across many repos. Session 06a796ad on Feb 8 (46% cache, 2 output tokens, 1 turn) is the extreme -- a session that barely started. The structural minimum for any multi-turn session is around 85%.

Cache efficiency improved slightly over time. Early period (Jan 28--Feb 5) averages 92--97% cache hit ratios. Late period (Feb 19--Mar 4) averages 97--99%. Mar 3 and Mar 4 both hit exactly 98.4%. This likely reflects accumulated CLAUDE.md content and project structure stabilizing -- as the ecosystem's documentation hardens, more of each session's context is invariant and cacheable.

Output token volume correlates with work type, not session length

The heaviest output sessions are not necessarily the longest by turn count:

• Jan 28, session 7ce416ac: 2.43M output tokens, the single largest session in the dataset -- Hologram feature development with massive code generation
• Feb 22, session 09050a8b: 296K output, 58 turns -- reincarnate test suite integration
• Feb 24, session 036d34ec: 968K output, 70 turns -- sustained multi-project architectural work
• Mar 1, session 0a4aedd1: 648K output, 58 turns -- normalize analysis command implementation
• Mar 4, session 3dcd6b94: 354K output, 143 turns -- Scribble runtime design (highest turn count of the period, moderate output)
• Feb 20, session 1e13057d: 58K output, 216 turns -- sensory prose design (second-highest turn count, lowest output)

The pattern: implementation sessions (writing code, generating tests, scaffolding) produce high output-per-turn. Design sessions (the sensory prose marathon, existence identity systems, architecture debates) produce many turns with lower output-per-turn. The 216-turn sensory prose session averaged ~270 tokens per turn -- the agent was responding to design questions, not generating code. The 70-turn architectural session on Feb 24 averaged ~13.8K tokens per turn -- it was producing implementations.

The Scribble session (Mar 4) sits between these modes: 143 turns averaging ~2,475 tokens per turn. This is the quantitative signature of "collaborative narrowing" -- the agent is writing design explanations and architectural sketches, not full implementations, but they are more substantial than the terse design exchanges of the sensory prose session.

This distinction is invisible in the qualitative logs, which describe both session types as "intensive." The token data reveals that "intensive" means different things: intensive design is conversation-heavy and token-light; intensive implementation is conversation-light and token-heavy; intensive collaborative design falls in between.

The reincarnate period stands out quantitatively

Feb 6--22 (the reincarnate-dominated stretch) shows the highest sustained daily output token volumes: 160K--860K output tokens per day, with multiple sessions regularly exceeding 40K output each. This matches the qualitative narrative -- the Flash decompiler required generating IR pipelines, type inference engines, codegen backends, and runtime implementations in rapid succession. It was the most code-generative period in the dataset.

By contrast, the infrastructure/introspection phase (Feb 24--Mar 2) shows higher total token volumes (due to more sessions) but lower output-per-session. The work shifted from "generate large code artifacts" to "analyze, validate, and refactor existing code" -- which consumes context (cache reads) but produces less new content (output).

Mar 3--4 continue this trend: 2.87M and 1.53M output tokens respectively, concentrated in fewer sessions (54 and 29) than the 80--93 session days of late February. The output is going into architectural refactoring (ptera.world), crate reorganization (normalize), and design conversations (Scribble) rather than greenfield implementation. The token profile of an ecosystem entering its compression phase is: fewer sessions, similar output per session, lower total volume, same cache efficiency.

What the numbers add that the narrative does not

1. Feb 3 was genuinely quiet. The qualitative log says "quiet day" and the token data confirms it: 1.2M total tokens, a single session, 71 output tokens. The developer stopped for a day. In a dataset of 30--90 session days, this is the only true rest day.

2. The cost of parallelism is mostly cache, not output. A 93-session day (Mar 1) consumed 1.39B tokens but only 5.2M were output. The remaining 99.6% was context loading -- reading the same codebases into dozens of parallel sessions. The actual "work" (measured by generated tokens) is a thin layer atop a massive context substrate.

3. Marathon sessions have diminishing output returns. The 216-turn sensory prose session (Feb 20) and the 100-turn reincarnate macro debugging session (Feb 21) both show output per turn declining as the session progresses -- the agent is doing more reading and less writing as context accumulates. This is the quantitative signature of the context overflow pattern described in the qualitative logs. The 143-turn Scribble session (Mar 4) partially escapes this: its output per turn remains relatively stable because the design conversation generates new architectural decisions on each turn rather than refining existing code.

4. The billion-token days are not the most productive days. Jan 28 (3.09B tokens) was dominated by two sessions that together produced 4.27M output tokens but spent most of their budget on cache reads. Feb 14 (624.6M tokens, 83 sessions) produced 864K output tokens with tighter cache efficiency. Raw token volume measures resource consumption, not output. The most efficient days by output-per-token-consumed are the moderate-parallelism days (Feb 13, Feb 17) where 10--40 focused sessions produce substantial output without the overhead of 80+ concurrent contexts.

5. Compression work is token-efficient. Mar 4 (321M tokens, 29 sessions, 1.53M output) achieved substantial architectural restructuring -- crate reorganization, layout system overhaul, manifest parsing infrastructure -- at roughly one-third the token cost of a typical active day. Removing code costs less than writing it.

---

Quantitative analysis: cross-session patterns

Derived from normalize sessions messages --sort-by-tokens across the full period (Dec 31, 2025 -- Mar 3, 2026): 1,502 sessions, 14,472 user turns.

Scale: 14.2B cache_read tokens, 1.1B cache_create tokens, 32.5M output tokens. Cache reads are the dominant cost by volume; at Sonnet pricing they account for ~47% of spend, with the remainder split between cache creation, output, and Opus usage.

Context continuations dominate the heaviest turns. 799 "session is being continued" turns consumed 3.2B cache_read tokens (22% of total), and 462 handoff plan turns consumed another 1.9B (14%). These 8.7% of turns drove 36% of all cache reads — because each one re-reads an entire accumulated conversation history. The longest-lived sessions paid this tax repeatedly: 7ce416ac (402 turns, Jan 7--15) hit the context limit 49 times; 117e8a69 accumulated 673M cache_read tokens across 9 days.

The handoff pattern is the right tradeoff. 19% of sessions were interrupted on turn 0 — the plan-mode handoff pattern, where a session generates a plan and hands off immediately to a fresh context. This looks like overhead but isn't: one cache_create to start fresh is far cheaper than accumulating 50K+ tokens of cache_read on every subsequent turn in a session approaching its context limit. Handoff usage exploded over the period (66 in January, 288 in February, 110 in the first 3 days of March) as the pattern matured.

The 82M token warmup. The single largest cache_read on any turn was 82M tokens on a subagent warmup message containing just the word "Warmup." Agent spawning inherits parent context. The Jan 28 agent-spawning experiments created 199 agent sessions in one day; 69 warmup turns total consumed 228M cache_read tokens before doing any work.

Retry waste is real but concentrated. ls failed 1,068 out of 1,693 attempts (63%), burning an estimated 51.7M output tokens in retry cycles — this is the server-less agent-af3501f pattern (376 ls calls) now quantified across all sessions. Glob had a 39% success rate. These are sandbox/permission issues in agent subprocesses, not tool failures in interactive sessions.

February's interactive character shows in the numbers. February averaged 1,372 output tokens/turn vs January's 3,572 and early March's 4,439. More turns, less output per turn — the quantitative signature of design and discussion work rather than implementation sprints. Long sessions are more token-efficient (output-to-cache-read ratio nearly 2× that of short sessions), but they also hit context limits, making clean handoffs the better long-run strategy.

March 2 cost spike: ~$331, more than double any prior day. Driven by 50 handoff plan executions in one day generating 1.3M output tokens, and cascading context accumulation in the normalize v2 parser and rescribe format work. The ecosystem building tools to understand itself turned out to be one of the most expensive days of the period.

Mar 3--4 show cost normalization. After the Mar 2 spike, Mar 3 (589M tokens, 54 sessions) and Mar 4 (321M tokens, 29 sessions) return to moderate levels. The lower session counts reflect focused architectural work rather than broad-front parallelism. The early March output-per-turn average (4,439) is inflated by the Mar 1--2 infrastructure sprint; Mar 3--4 individually show output-per-turn closer to February's design-conversation levels, consistent with the shift from building to compressing.