09 — Managing Context — Keeping the Window Lean and the Meter Predictable

"Just close the app when it gets weird" was my context-management strategy, and the weirdness always came back. The lever underneath all the fixes: the meter is driven by the window, so every cost and reliability technique is the same lever — fewer tokens reprocessed per turn. [1] Claude Code re-reads the entire conversation history with every new message to maintain state. Unmanaged, that history balloons, and you get both higher bills and worse answers (context rot, lost-in-the-middle accuracy loss). Every feature in this post is a different way to keep the window small.

The framing that clicked is to stop treating cost and quality as separate problems. They're the same problem seen from two sides: a full context window costs more _and_ produces worse output. So /compact, /clear, subagent delegation, hook-driven cleanup, prompt caching, and the effort dial all reduce to one move — shrinking or discounting the tokens the model re-reads each turn [1][2].

The two meters: pricing first

Before the techniques, the roadmap is clear that there are two ways the meter runs, and which one I'm on changes how aggressively I manage tokens [3]:

• Subscription (Pro/Max) — a flat recurring fee with a shared message allocation. /usage shows remaining capacity, not money. Cost is predictable; the risk is hitting the allocation cap.
• API usage — pay-as-you-go per token. /cost shows the real-time USD spend for the active session. Cost scales directly with context size; the risk is a runaway session on a large codebase.

On subscription I manage context mostly for _quality_ (rot prevention). On API I manage it for _both_ — every token is money, so the same hygiene that keeps answers sharp also keeps the bill sane.

The core techniques: compact, clear, fresh sessions

The most direct levers are the context commands [4]:

• /compact — when the window is filling but the work isn't done, instructs Claude to summarize the key decisions, code changes, and project state so far, then replace the bulky history with that summary. It "zips" the conversation: tokens drop, essential knowledge survives.
• /clear — wipes the current context entirely. The right move when switching to an unrelated task; the previous thread's baggage would only cause drift.
• Fresh sessions per task — the discipline behind both. A new task gets a new session so context starts lean, rather than layering unrelated work into one growing window.

The rule of thumb: /compact to _continue_, /clear to _switch_.

Delegating and cleaning via subagents and hooks

Two structural techniques keep the main window lean without me running commands manually:

• Subagents for verbose operations. Any task with large inputs and a small conclusion (read twenty files, return one fact) goes to a subagent. The verbose work stays in the bubble; only the summary enters the main thread [5]. The roadmap states this directly as a cost-reduction technique.
• Hooks for cleanup and enforcement. A PostToolUse hook can run a formatter or prune throwaway files after every edit, so transient junk doesn't accumulate in the workspace the model perceives [6]. A SessionStart hook bootstraps high-priority context, and SessionEnd does teardown — both keep the right things in context at the right times [7].

These matter because they're automatic. I don't have to remember to compact; the architecture keeps the window small by design.

Thinking modes and the effort dial

A less obvious lever is effort — how much "thinking time" the model allocates to a problem [8]. Higher effort means deeper reasoning and more thinking tokens; lower effort means faster, cheaper responses. The roadmap points at the effort parameter (available through the /model command) as a way to balance deep reasoning with operational efficiency.

The pattern: high effort for hard architectural puzzles where a wrong answer is expensive; low effort for mechanical tasks (boilerplate, simple edits) where the answer is obvious and I'm paying for speed. Treating effort as a dial, not a fixed setting, is a real cost lever on API billing — the thinking tokens cost money too.

Prompt caching: discounting the static prefix

The most powerful cost technique is one I don't drive manually at all: prompt caching [9]. Claude Code automatically stores the frequently used "prefixes" of a conversation — the codebase state, system instructions, tool definitions — so they don't get reprocessed from scratch each message. The initial write to the cache carries a slight premium, but every subsequent turn that reuses that prefix gets roughly a 90% discount on those input tokens and up to 85% lower latency.

The reason this is automatic and worth understanding anyway: Claude Code places cache breakpoints at strategic points (after the CLAUDE.md and project structure), so the static foundation of the project stays cheap to access even as the conversation grows. The practical implication for me is that _keeping the static parts stable_ (not churning the memory file or the tool list mid-session) preserves the cache and the discount. Every unrelated change to the prefix invalidates it.

Mind the extensions

One last hygiene point the roadmap flags: every active extension consumes context. MCP servers, skills, and subagents all add tool definitions and instructions to the window, and "context pollution" degrades reasoning or raises cost [10]. The discipline is to enable only what a given session actually needs — not every MCP server I own, all the time. Idle extensions aren't free; they cost tokens every turn.

How I use this

The habit these notes left me with is a session rhythm built around the window. Fresh session per task (lean start), /compact to continue a long thread (zip, don't wipe), /clear to switch tasks. Large-read tasks go to subagents; formatting and cleanup run as PostToolUse hooks so junk never accumulates. I keep the effort dial high only for hard problems and low for mechanical ones. And I treat the static prefix as something to keep stable — no churning the memory file mid-task — so prompt caching keeps doing its work. The throughline: cost and quality are the same lever, and the lever is the size of what gets re-read each turn.

References

[1] Anthropic, "Manage costs effectively," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/costs#reduce-token-usage

[2] Anthropic, "The context window," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/how-claude-code-works#the-context-window

[3] Anthropic, "Pricing in detail," Claude API Docs, 2025. [Online]. Available: https://platform.claude.com/docs/en/about-claude/pricing

[4] Anthropic, "Interactive mode — /compact, /clear," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/interactive-mode

[5] Anthropic, "Delegate verbose operations to subagents," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/costs#delegate-verbose-operations-to-subagents

[6] Anthropic, "Automate workflows with hooks," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/hooks-guide

[7] Anthropic, "Hooks reference," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/hooks

[8] Anthropic, "Adjust effort level," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/model-config#adjust-ef

[9] Anthropic, "Adjust extended thinking," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/costs#adjust-extended-thinking

[10] Mario Giancini, "The Hidden Cost of MCP Servers (And When They're Worth It)," 2025. [Online]. Available: https://mariogiancini.com/the-hidden-cost-of-mcp-servers-and-when-theyre-worth-it