CLAUDE CODE | Context Window Mechanics , Min Token Usage

Claude Code CLI is a powerful tool but only if you know how to use it right. In this post (and the ones coming after it), we’ll talk about how to get more consistent outputs, use Claude Code’s components effectively, and produce results without bloating your context window or burning through tokens without realizing it.

To do that, we first need to understand how Claude Code actually works.

You’ve probably noticed that after a while, the outputs start getting weird. Responses take longer. Token usage quietly climbs. Here’s why.

What Is Claude Code Actually Doing?

Every time you send a message, this loop runs in the background:

1. You write a message
2. Claude reads the entire conversation history from the beginning
3. It decides which tool to call (Read, Write, MCP…)
4. The full output of that tool call gets added to the context
5. Claude generates a response
6. Next message → go back to step 2

The critical part is step 2: Claude re-reads everything from scratch on every single message. It doesn’t “remember” previous answers — it reads and re-understands the whole thing each time. Once you realize this, the runaway costs start making a lot more sense.

Cumulative Re-Read Cost

When you send a message to Claude Code, it goes into the context window. Every next message gets added there too — but before Claude generates a reply, it reads all of that accumulated history from the top.

So with every message, a cumulative cost starts building up.

In practice, it looks something like this:

Message 6 can cost 45x more than message 1. You’re talking the same way, Claude is responding the same way — but the cost is growing exponentially. That “it got slower after a while” feeling? This is exactly why.

The good news: there are ways to control this. Let’s look at them.

• CLAUDE.md

This is a file that loads before Claude reads anything or starts any task. It stays in the context window for the entire session — it never gets removed.

This is where you write your project rules: which package manager you use, architecture constraints, formatting preferences. That way you don’t have to explain the same things at the start of every session.

A well-structured CLAUDE.md is usually 300–600 tokens. If yours is over 2,000 tokens, you've probably put task notes or documentation in there that doesn't belong.

A real comparison: A bloated 3,847-token CLAUDE.md vs. a clean 312-token version — 91.9% reduction in context, zero change in output quality.

• Hooks

A hook lets your own script run before or after Claude calls a tool. Think of it as reaching in and shaping Claude’s behavior from the outside.

Normal flow:

prompt → Claude thinks → Tool runs → Response generated

Flow with hooks:

prompt → Claude thinks → [PreToolUse Hook] → Tool runs → [PostToolUse Hook] → Response generated

Hooks enforce fixed rules before and after each operation. They block unnecessary commands, long explanations, and trial-and-error loops — cutting input/output token costs by 40% to 85%.

Scoped Execution: Instead of Claude reading the full raw terminal output, hooks trigger scripts that filter it. For example, when a test fails, the hook steps in and only tells Claude which file, which line has the error. Huge terminal logs never touch the context at all.

# ❌ Without hook — full flutter analyze output goes into context (~2,400 tokens)
flutter analyze

# ✅ With hook — only critical issues surface (~60-200 tokens)
flutter analyze 2>&1 | grep -E "^  (error|warning)" | head -30

State Validation: After Claude makes a change, the hook directly runs a specific linter (eslint, ruff, dart analyze, etc.) or test tool. This stops Claude from going "hm, let me check a few more things 🤔" and re-reading extra files. The model just focuses on the precise feedback the hook returns.

Hooks aren’t only about saving tokens, though. You can write hooks that send a Mac notification when a long task finishes, auto-format files on write, or veto dangerous commands. I’ll cover the details in a separate post.

• Multi-Agent & Subagents

In a normal Claude session, everything lives inside one context window — every tool call output, every message, every file read. It all piles up, and you pay for it again on every message. Classic cumulative cost problem.

A subagent is a completely separate, isolated Claude instance. It has its own context window. It knows nothing about the main session. When it’s done, it returns only a summary result to the main session. No unnecessary noise accumulates in the main context.

Example: Instead of loading all the files into its own context, the main session can spawn a subagent and say: “Find every place that calls loadUser and summarize it.” The subagent does the work, returns just the result. The main session stays clean.

The numbers are striking:

• Main session: Resends the entire conversation history every turn. A 200-turn session costs ~200K tokens per message.
• Subagent: Starts with a clean context. First message is ~20K tokens.

Clean context = Claude does better work = less chance of wrong results that need to be redone. That’s an indirect saving, but it adds up.

• MCPs

MCP (Model Context Protocol) is the protocol that connects Claude to services like GitHub, Figma, and Supabase. Think of it like USB-C — same port, different device each time.

A common assumption is that MCPs only cost tokens when you actually use them. That’s not true. The cost starts the moment an MCP is connected.

Here’s why: before Claude can call a tool, it needs to know what that tool is — its name, parameters, what it does. All of that gets loaded as “tool definitions” at the very top of the context window. Before you’ve typed a single word, it’s already in the history Claude will read.

With a few MCPs connected, just typing “hello” can come back to you as a 100K+ token hit.

not: If you’re not going to use an MCP that day, disconnect it.

Final

This post is the first piece of a series aimed at taking you from zero to expert with Claude Code. I’ll cover each topic in detail — CLAUDE.md anatomy, automation with Hooks, multi-agent architecture, MCP optimization, and then CLI flags, the plugin system, and advanced workflows.

For now, the three things to keep in mind:

• Claude re-reads history on every message — keeping context clean saves money
• Full tool outputs go into the context — if you don’t filter, you’re quietly burning tokens
• MCPs cost on every message as long as they’re connected — not just when you use them

🇵🇸Free Palestine