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):
-
MEASURED (real, agent-reported tokens, from
Usage):- startup overhead — on a cold-start first request (
cache_read == 0),input + cache_creationis 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 > 0on the first request) can’t isolate this floor, so it’s reported as unknown, not zero. - peak / final input context —
max/last ofinput + cache_read + cache_creationacross 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).
- startup overhead — on a cold-start first request (
-
ESTIMATED (from on-disk content sizes ÷
EST_CHARS_PER_TOKEN, NEVER billed): the relative composition of transcript content byContextSource, per-MCP-server tool footprint, and the heaviest single contributors (the context “fat tail” — one giantRead/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§
- Context
Report - The whole context report: per-session profiles plus cross-session rollups.
- Heavy
Item - One unusually large individual context contributor (the context “fat tail”).
- Server
Breakdown - 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 nameServerBreakdown::BUILTIN. - Session
Context - 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).
- Source
Breakdown - Estimated share of transcript content from one
ContextSource.
Enums§
- Context
Source - Bucket a piece of transcript content is attributed to. The split between
AssistantTextandThinkingusescrate::model::Event::thinking_chars(a subset ofcontent_chars);ToolCallsis the tool-use input JSON.
Functions§
- profile
- Build a
ContextReportfrom parsed sessions. - profile_
refs - Same as
profilebut over borrowed sessions, so a caller that already holds&Sessionreferences (e.g. the drill-down, which profiles one session group at a time) need not clone whole transcripts.profileis the thin owned-slice wrapper.