The 1M context window shipped, so the obvious question: doesn't a five-times-bigger window solve the context problem? This chapter closes on the opposite claim, that the context window is the one constraint everything else in agentic coding bends around. So before that lesson lands, the reflex is worth answering. The window just got five times larger. Is the constraint even still real?
Short answer: the capacity changed, the principle didn't. The 1M window is headroom, not a replacement for structured context. This lesson is the bridge between the quick wins you just saw and the constraint lesson that closes the chapter. It's here to kill the "1M solves it" reflex before the rest of the course builds on the opposite assumption.
What actually got better
One thing improved, and it's worth naming precisely: compaction fires less often. In sessions that used to push past the old 200K ceiling (multi-file refactors, long debugging runs across several modules), the agent hits the wall later, so it summarizes (and loses precision) less often. Sessions that never grew past ~150K feel identical; nothing changed for them. The workarounds people built up over months, aggressive .claudeignore files and manual pruning before a hard task, still help for precision, but they're no longer required just to keep a session functional.
That's the real win: a relief valve that fires less often. Not a transformation of how sessions work.
Context rot: the part the headline skips
Here's the part the announcement glosses over. Reasoning quality degrades non-linearly as context grows, not proportionally. A session at 800K tokens doesn't perform 20% worse than one at 200K. On tasks that need sustained multi-file reasoning or holding an architectural constraint across a long session, degradation runs 40–60%, and the drop isn't smooth: there's a cliff past certain thresholds. The model doesn't read tokens uniformly; attention degrades the further back a token sits.
The number that reframes it
A focused 80K-token session with a well-built CLAUDE.md outperforms an unfocused 900K-token session on most real engineering tasks. The window is a ceiling, not a floor you should fill.
On multi-step reasoning, tighter structured context beats a full-repo dump, and the bigger window doesn't change this
Pricing at scale (the one place the window size shows up on the bill)
For an interactive session you pay a flat subscription, so window size is invisible to your wallet. It stops being invisible the moment you scale to pipelines. Anthropic's 1M window is flat-rate: one price from token 1 to token 1,000,000, no surcharge past a threshold. Some competitors reprice the entire request past a cutoff (e.g. 2x past ~272K tokens, applied to all tokens, not just the overage). For a CI pipeline running dozens of large sessions a day, that's a very different budget conversation, and it connects directly to the headless-billing math you'll meet in Chapter 4.
Where this points: smaller agents, not bigger windows
The 1M window extends the useful life of the single growing context model: one agent, one window, getting larger. The more interesting structural answer goes the other way. Multi-agent setups (one lead, several specialists, each with its own window and its own worktree) make the compaction problem largely dissolve, because the agents don't share context. Each specialist starts focused on its slice. That's the same logic behind subagents (Chapter 4) and parallel worktrees (Chapter 6).
So the takeaway sets up the rest of the course rather than excusing you from it: if you're seeing regular compaction past ~180K tokens, the bigger window helps you today. If you're designing a system from scratch, reach for smaller agents with focused contexts. One large agent with everything loaded is the wrong model for complex work, regardless of how large the window gets.
The next lesson is the constraint itself, stated in full. Read it knowing the window got bigger and the constraint stayed.