Context Window

Every model has a context window: the total amount of text it can consider at once — your instructions, the code it has read, the conversation so far, its own previous answers, all sharing one finite budget measured in tokens (lesson 3). Current Claude models give you 200,000 tokens, roughly a 500-page book. That sounds enormous. In agentic coding it is the scarcest resource you manage, and the single most useful diagnostic instinct you can build is this: most mysterious agent failures are context failures wearing a costume.

The desk, not the memory

The window is not memory. It is a desk. Whatever is on the desk right now, the model can use brilliantly; whatever fell off does not exist — the model doesn't remember it and doesn't know it ever existed. Every practical rule in this lesson falls out of three consequences:

1. Nothing persists by itself. A new conversation starts with an empty desk. The agent that "knew" your architecture yesterday knew it because the relevant files were on the desk yesterday.
2. Everything on the desk is paid for, every turn. In an API conversation, the entire context is re-sent and re-billed with each request. Your next message might be twenty tokens; the request carrying it might be ninety thousand. Picture the whole desk being shipped every time, not the note you just added to it. (Lesson 12 shows how caching discounts the stable part; lesson 20 shows how to keep clutter off entirely.)
3. When the desk fills, something leaves — silently. Tools handle overflow by truncating or summarizing older material. The model never says "I no longer have your instruction from an hour ago." It just stops following it.

What filling up actually looks like

Textbook descriptions say "context exhaustion." Here's what you'll actually see, two hours into a productive session:

• The agent reintroduces a bug you fixed together at the start.
• It "forgets" the constraint you set in message three and does the forbidden thing cheerfully.
• It confidently describes a function that's no longer in front of it, slightly wrong — because it's now reconstructing from a summary rather than reading source.
• Its answers get vaguer, more generic, more tutorial-flavored — the specific texture of your codebase fading as the specifics fall off the desk.

Nothing errors. Quality sags. And there's a subtler effect that begins before hard truncation: attention is not uniform across a huge context. A fact buried in the middle of 150,000 tokens is attended to less reliably than the same fact in a 5,000-token context. Long context is real; uniform long context is not. The middle of a huge transcript is where details go to be ignored.

The working practices

Start fresh more often than feels natural. When a task is done, its conversation is done. /clear in Claude Code wipes the desk; /compact compresses the session into a summary and carries that forward (do it at a natural boundary — after a milestone, not mid-thought, because the summary is what survives). The professional rhythm is task → clear → task → clear. If ending a session feels like losing something valuable, that valuable thing should be written to a file — a decision log, a CLAUDE.md line, a memory note (lesson 24). "The context is precious" is a smell; contexts are disposable, artifacts are precious.

Feed files, not vibes. "Look around the codebase and figure out auth" can put 40,000 semi-relevant tokens on the desk. "Read src/auth/session.ts and docs/auth.md" puts 2,000 relevant ones. Precision about what gets loaded is as valuable as precision about what you ask (lesson 1) — and when you genuinely don't know where things live, delegate the search: a sub-agent can do the dirty exploration in its own disposable context and return a two-line answer (lesson 11), leaving your desk clean.

Watch what accumulates — it's mostly tool output. Every file read, grep, test run, and build log lands on the desk. The classic silent killer: a failing test suite that prints 8,000 tokens of stack traces, re-run five times while debugging, is 40,000 tokens of nearly identical noise — often more than all your instructions combined. Desk hygiene is promptable: "run tests with the dot reporter," "pipe long output through tail -30," "don't cat whole files, read the relevant function." Agents comply happily; they just don't volunteer.

Put standing rules where they can't fall off. An instruction from message two is at eviction risk by message eighty. Rules that must survive the entire session — "never touch migrations," "always run the linter before committing" — belong in a file the tool re-supplies every turn. That is precisely what CLAUDE.md is (lesson 8), and "this rule keeps getting forgotten" is precisely the signal that a rule belongs there.

Budgeting like it's engineering

For any agent setup, know your fixed overhead: system prompt + standing instructions + tool definitions + always-loaded files — the tokens spent before any work happens. What remains is working room. Overhead accretes exactly like app startup time: each addition looks free (one more MCP server, one more section in CLAUDE.md, one more "always load this"), and the sum is why complex tasks mysteriously underperform in "fully loaded" environments. Two numbers worth actually knowing for your own setup: overhead at session start, and typical desk size when quality starts sagging. Neither requires tooling — cost readouts and a bit of attention will calibrate you within a week.

The chart on this page shows the other side of the ledger — what happens when material must be dropped to fit a budget: the loss is gradual, then total, and nothing announces the boundary as you cross it. Every truncation strategy has this shape; the only variable is whether you chose what got dropped or let recency choose for you.

The rule to carry forward

Every advanced technique in this course is, underneath, a context-window strategy. Sub-agents exist because one desk is too small (lesson 11). Caching exists because re-shipping the desk is expensive (lesson 12). Memory files exist because desks get cleared (lesson 24). Progressive disclosure exists because desk space is worth more than loading convenience (lesson 20). Orchestrators exist because some jobs don't fit on any single desk at all (lesson 22). When an agent behaves strangely, ask what was actually on the desk when it went wrong? — what had been loaded, what had accumulated, what had been silently evicted. Most of the time, that question answers itself, and the fix is never "a smarter model." It's a cleaner desk.