Reading the gauges: a real readout, dissected

TL;DR. /context and /usage are only useful if you can read them, so this chapter dissects a real readout from the Claude Code session that built this book, field by field, with what each value means and what to do about it. The short version of what they showed: a tiny cached prefix (about 28k tokens) and a conversation that had grown to 497k, a session that was 90% at over 150k context and 87% subagent-heavy, which is the exact expensive pattern the rest of this part warns about, and the exact prescription (compact, clear, cheaper subagents) follows straight from the numbers.

Contents

• The /context readout, dissected
• The /usage readout, dissected
• Observations and findings
• The other diagnostic commands
• Further reading
• Takeaways

Chapter 17 introduced the two gauges and Chapter 20 showed how to measure tool savings. This chapter is the missing skill between them: reading your own telemetry and turning it into an action. The numbers below are a genuine readout from this session, so treat it as a worked example of the diagnosis you will run on your own sessions.

The /context readout, dissected

/context answers "what is in my window right now." Here is the panel, verbatim:

claude-opus-4-8[1m]      525.2k / 1.0M tokens (53%)

CATEGORY            TOKENS    USAGE
System prompt         3.0k     0.3%
System tools         12.3k     1.2%
MCP tools             4.8k     0.5%
Custom agents          345    <0.1%
Memory files          3.6k     0.4%
Skills                4.0k     0.4%
Messages            497.1k    49.7%
Free space          474.8k    47.5%

MEMORY FILES  /memory
  CLAUDE.md                                           3.1k
  .../memory/MEMORY.md                                 488

Read it top to bottom and a clear story emerges. The model is claude-opus-4-8[1m], the 1M-token context window from Chapter 14, and the session has used 525.2k of it, just over half. Now the categories, which map one to one onto the anatomy from Chapter 17:

The single observation that matters: everything except Messages sums to about 28k tokens, and Messages alone is 497k. The entire stable, cacheable front of the context (system prompt, tools, MCP, agents, memory, skills) is a rounding error next to the conversation. This is the central claim of Chapter 17 made concrete: the window is dominated by what the tools pulled in over many turns, not by your instructions or the agent's setup. If this session felt expensive, the 497k of Messages is why, and the fix is in that row, not in trimming the 3k system prompt.

A second, smaller finding: CLAUDE.md is 3.1k tokens, which is over the 500-token budget from Chapter 20. That is a fixed tax paid on every turn. It is small next to 497k of Messages, so it is not this session's problem, but it is a standing cost worth trimming. The MEMORY.md index at 488 tokens is healthy: well under the 25KB / 200-line cap, so the whole index loads and the detail stays in topic files fetched on demand (Chapter 18).

Remember. When /context shows Messages dominating (it almost always will in a working session), the lever is compaction, clearing, and delegating verbose reads, not shaving the prefix. Optimize the big number, not the satisfying small one.

The /usage readout, dissected

/usage answers a different question: "what is my usage doing against my limits, and what is driving it." Here is that panel:

Plan: Claude max

Session (5hr)    97%    resets in 6m
Weekly (7 day)   61%    resets in 21h

WHAT'S CONTRIBUTING TO YOUR LIMITS USAGE?   (Day)
  Approximate, based on local sessions on this machine.
  Last 24h. These are independent characteristics, not a breakdown.

  90% of your usage was at >150k context
  87% of your usage came from subagent-heavy sessions
  34% of your usage came from subagents under "general-purpose"

  Skills        /claude-api        6%
  Subagents     general-purpose   34%
                claude-api        10%

The two bars at the top are plan limits, not a dollar bill. On a Claude Max subscription, usage is included in the plan, so /usage shows how much of your rolling allowances you have consumed, not an invoice (Chapter 17 noted the dollar figure is for API users). There are two windows: a 5-hour rolling session (here 97%, resetting in 6 minutes) and a 7-day weekly budget (61%, resetting in 21 hours). The session bar at 97% is the actionable one: this session is about to hit the 5-hour ceiling, which on a long, heavy session is itself a signal that the work is context-expensive.

The "what's contributing" block is the diagnostic gold, and it comes with two caveats printed right on it that you must respect. First, it is approximate and local: based on sessions on this machine only, not other devices or claude.ai. Second, and easy to misread, the percentages are independent characteristics, not a breakdown: they do not sum to 100, because the same usage can be counted under several lenses at once. A session can be both ">150k context" and "subagent-heavy," so 90% and 87% can coexist. Read each line as "this fraction of your usage had this property," not as slices of a pie.

Now each line, and the action it implies:

The Skills and Subagents tables at the bottom attribute usage to specific named extensions: the /claude-api skill at 6%, the general-purpose subagent at 34%, claude-api subagent at 10%. This is where you find the specific thing to tune. If general-purpose is 34% and runs often, it is the first candidate for a cheaper model.

Don't be confused. The percentages in "what's contributing" are independent lenses on the same usage, not a partition of it. "90% at >150k context" and "87% subagent-heavy" describe overlapping usage and will not add to 100. Reading them as a breakdown leads you to chase phantom slices; reading them as properties tells you which patterns dominate, which is what you act on.

Observations and findings

Put the two panels together and this session diagnoses cleanly. The findings:

1. The window is conversation-bound, not setup-bound. 497k of 525k used is Messages; the prefix is ~28k. The cost is the accumulated tool results and turns, exactly as the model predicts.
2. The session is the expensive archetype. 90% over 150k context and 87% subagent-heavy is the precise combination this part flags as costly: a long, high-context session that also fans out into many subagent instances. The 97% session bar is the consequence.
3. There is a named culprit. The general-purpose subagent is 34% of usage on its own. That is the highest-leverage single knob.
4. A standing, minor tax. CLAUDE.md at 3.1k is over budget but not the issue today.

The prescription follows directly from the findings, in order of leverage:

• Right-size the general-purpose subagent. Configure it with a cheaper model or a tighter prompt; it is a third of usage and the easiest win (Chapter 19).
• Break the long sessions. /clear between unrelated tasks and /compact with a focus instruction when one thread runs long, so usage stops accumulating at >150k context (Chapter 11).
• Spawn subagents deliberately. Delegate verbose reads, yes, but do not fan out where one window would do; each subagent is its own metered instance (Chapter 13).
• Trim CLAUDE.md to its 500-token budget when convenient, to stop paying the standing tax every turn (Chapter 20).

That is the whole loop: read /context for what is in the window, read /usage for what is driving your limits, name the dominant pattern and the named culprit, then apply the matching lever. The numbers told you where to look; the levers are what you do about it.

The other diagnostic commands

/context and /usage are the two main gauges, but a specialist reads several instruments together. Here is what each tells you and the action it implies.

And the actions those readings call for, the controls from Chapter 19: /compact [focus] to fold a long thread while protecting key facts, /clear to start fresh on unrelated work, /rewind to restore to a checkpoint when a path went wrong, /effort to lower reasoning cost on routine work, and a subagent model: haiku to cheapen a heavy delegate. A habit worth forming: glance at /context when a session feels slow or forgetful, and at /usage at the end of a heavy day to see which pattern to change tomorrow.

Further reading

• Claude Code, "Explore the context window" (code.claude.com/docs/en/context-window): the authoritative guide to the /context categories dissected here.
• Claude Code, "Manage costs effectively" (code.claude.com/docs/en/costs): the /usage panel, the plan-versus-API distinction, and the contributing-factors guidance.
• Claude Code, statusline (code.claude.com/docs/en/statusline): how to show context usage continuously.
• Chapter 20 of this book: rtk gain and rtk cc-economics, and why a realized savings number can be far below the headline.

Takeaways

• /context shows what is in the window by category; in a real session Messages (the conversation and tool results) dominate (here 497k of 525k), and the stable prefix is a small fraction (~28k). Optimize the big number.
• /usage on a subscription shows plan-limit consumption (a 5-hour rolling and a 7-day window), not a dollar bill, plus what is driving it.
• The "what's contributing" percentages are independent characteristics, not a breakdown, and are approximate and local. Read them as dominant patterns, not pie slices.
• This session's readout diagnosed the expensive archetype (90% over 150k context, 87% subagent-heavy, general-purpose subagent at 34%), and the prescription followed directly: cheaper general-purpose subagent, /clear and /compact to break long sessions, deliberate fan-out, and a trimmed CLAUDE.md.
• Read the gauges together, name the dominant pattern and the named culprit, then apply the matching lever. The numbers tell you where to look; the controls are what you do.

👉 You can now read your own telemetry and act on it. One question remains about the machine itself: how does a harness that runs for hours keep telling the model new things without ever breaking the cache the gauges just showed you? That rule, and the proof of it mined from real transcripts, is next. Continue to The injection channel.