Skip to main content

Module context

Module context 

Source
Expand description

Context-bloat attribution — the v0.2 headline feature (CLAUDE.md §2.2, §11).

Answers “why is my context window full, and what’s filling it?” by breaking a session’s window down by source. Two kinds of number, kept strictly apart so the user is never misled (CLAUDE.md §8):

  1. MEASURED (real, agent-reported tokens, from Usage):

    • startup overhead — on a cold-start first request (cache_read == 0), input + cache_creation is the fixed prefix cached before any real work: system prompt + tool definitions + memory/CLAUDE.md + the first user turn. VERIFIED on real files: a fresh session’s first request shows e.g. input=3, cache_creation=18104, cache_read=0 → ~18 k tokens sitting in the window before you type. A warm resume (cache_read > 0 on the first request) can’t isolate this floor, so it’s reported as unknown, not zero.
    • peak / final input contextmax/last of input + cache_read + cache_creation across requests = how full the window got. The agent does not log per-tool definition sizes, so this measured bundle cannot be split further; we report the inventory instead (below).
  2. ESTIMATED (from on-disk content sizes ÷ EST_CHARS_PER_TOKEN, NEVER billed): the relative composition of transcript content by ContextSource, per-MCP-server tool footprint, and the heaviest single contributors (the context “fat tail” — one giant Read/MCP result can dominate the window).

Plus an exact inventory from attachment lines and tool calls: how many MCP servers are in play, how many tools were deferred (available but NOT loaded into the window — so they do not bloat it, a common misconception), how many skills were listed, and how heavy the MCP-instruction blocks are.

Inputs already captured by the model: Usage on assistant events, Event::content_chars/Event::thinking_chars, ToolCall::input_bytes + ToolCall::server, Event::tool_use_id (links a ToolResult back to the tool that produced it), and [Event::attachment_kind]/[Event::item_count].

Structs§

ContextReport
The whole context report: per-session profiles plus cross-session rollups.
HeavyItem
One unusually large individual context contributor (the context “fat tail”).
ServerBreakdown
Per-MCP-server context footprint: the tool-use JSON the assistant emitted to call the server’s tools, plus the result payloads that came back (attributed via crate::model::Event::tool_use_id). Plain built-in tools (Read/Edit/…) are grouped under the synthetic server name ServerBreakdown::BUILTIN.
SessionContext
Context-bloat profile for one session (each session — parent or sub-agent — is its own window, so each gets its own row; nothing is folded, nothing is double-counted).
SourceBreakdown
Estimated share of transcript content from one ContextSource.

Enums§

ContextSource
Bucket a piece of transcript content is attributed to. The split between AssistantText and Thinking uses crate::model::Event::thinking_chars (a subset of content_chars); ToolCalls is the tool-use input JSON.

Functions§

profile
Build a ContextReport from parsed sessions.
profile_refs
Same as profile but over borrowed sessions, so a caller that already holds &Session references (e.g. the drill-down, which profiles one session group at a time) need not clone whole transcripts. profile is the thin owned-slice wrapper.