Claude Code’s own documentation states plainly that certain models “have a 1M-token context window” [1], and the number is real: Anthropic prices it flat, so a 900,000-token prompt costs the same per token as a 9,000-token one. What the ceiling does not tell you is how much of that window stays worth trusting. The same documentation names the failure mode: “As token count grows, accuracy and recall degrade, a phenomenon known as context rot” [1]. Anthropic’s engineering blog puts it more plainly: “more context isn’t automatically better” [2]. We spent months treating the advertised ceiling as our working budget, and our longest sessions kept getting worse the further they ran, not because the model got dumber, but because we kept feeding a window well past the point where it did its best work.
This piece is about the gap between the advertised window and the one you can actually trust, and about a small, disposable file called handoff.md that turned out to be the most useful session-management habit we picked up this year.
Figure 1 - The Window You’re Sold vs. The Window You Get: Claude Code advertises up to 1,000,000 tokens on qualifying models. Practitioners report a much smaller high-quality zone inside it, and Anthropic’s docs now name the degradation curve that explains the gap: context rot [1].
The Window You’re Actually Renting
Start with what is vendor-confirmed. Claude Code’s default context window, for models without the extended tier, is 200,000 tokens [1]. The 1M-token tier is not universal: per Anthropic’s live platform documentation, fetched 2026-07-21, the models carrying it are Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5, and Sonnet 4.6 [1]. That roster changes as Anthropic ships new models, so the number worth remembering is the docs URL to re-check, not a name.
A second number gets confused with the first constantly: the auto-compact threshold. On a 1M-token Sonnet 5 session, Claude Code auto-compacts before the window fills, by default around 967,000 tokens, configurable through CLAUDE_CODE_AUTO_COMPACT_WINDOW [3]. That is a mechanical compaction trigger, not the practitioner-observed quality ceiling below, and conflating the two is a common mistake.
One more quiet fact: the project-root CLAUDE.md is re-read from disk every turn, while a nested, folder-level CLAUDE.md is not automatically reinjected once it drops out of context [17]. Root instructions are durable. Everything else, file contents, tool outputs, prior turns, competes for space that shrinks as the session runs.
Why More Tokens Isn’t More Quality
“Context rot” is not marketing language invented for this article. Anthropic’s own platform documentation defines it and links to the company’s engineering post on the subject [1][2]. The mechanism is not exotic: attention is a finite resource spread across every token in the window, so as the count grows, the model’s ability to recall and weight any single piece of it degrades.
The clearest independent evidence comes from outside Anthropic. Chroma’s July 2025 report, “Context Rot: How Increasing Input Tokens Impacts LLM Performance,” tested 18 frontier models, Claude, GPT, Gemini, and Qwen3 families among them, and found “models do not process context uniformly… performance grows increasingly unreliable as input length grows” [4]. All 18 degraded, non-uniformly, so the drop is not a clean line you can plan around. We are deliberately not quoting a specific percentage or failure token count here. Secondary commentary circulates numbers like that, but we could not confirm a specific figure against the report’s own results tables, so we keep the claim to what it actually states.
A second, unrelated finding shares the exact same coined phrase. Cursor’s engineering team, in an April 2026 harness-improvement post, uses “context rot” for accumulated tool-call errors degrading a session’s decisions, “while the agent can often self-correct, errors remain in context, wasting tokens and causing ‘context rot,’ where accumulated mistakes degrade the quality of the model’s subsequent decisions” [5]. That is an error-residue problem, not an input-length problem: a session can rot at a low token count if dense with failed calls, or at a high count with no errors at all. “Researchers tested 18 models, they all degrade” cites Chroma, not Cursor.
KEY INSIGHT: “Context rot” is vendor-confirmed, but it names a family of degradation curves, not one number. Check whether a source measures input volume (Chroma) or error accumulation (Cursor) before you cite it. They point at different fixes.
Figure 2 - What Actually Lives in the Window: The root CLAUDE.md is re-read every turn; nested CLAUDE.md files are not. Auto-compact fires around 967,000 tokens on a 1M-token Sonnet 5 session, a different measurement from a practitioner’s quality ceiling [17][3].
The Community’s 120K Heuristic
Vendor documentation gives the ceiling and the compaction trigger. It does not say where quality starts to suffer during real work, and Anthropic has not published a number for that. The most cited community figure comes from developer Matt Pocock, on camera in “/handoff is my new favourite skill”: “around by the 120k token mark, I start to feel like I’m in the dumb zone… even though Anthropic advertises a ton of context window on these models, really for proper smart tasks you’ve only got about 120k to work with” [6].
To be explicit: this is one practitioner’s subjective threshold, not a benchmark or a vendor specification, and not the same number as the 967,000-token auto-compact trigger above; one measures quality, the other a mechanical compaction point. What makes 120K worth repeating is that the mechanism behind it, attention diffusion as the window fills, is the same mechanism Anthropic and Chroma both describe. The number is a heuristic. The direction of the effect is corroborated. Practical consequence: assume a fraction of the advertised window is your genuinely high-quality workspace, and plan accordingly.
The Sediment Problem
Claude Code ships a documented /compact command, described in the docs as freeing “up context by summarizing the conversation so far” [7]. It works well for one case: a long, single-topic debugging session where you want to keep trying approaches and retain a record of what already failed.
The failure mode shows up with repeated compaction across unrelated work. Each /compact pass produces a lossy summary layered on top of whatever the previous pass already summarized. Run that cycle across a session picking up loosely related tasks, and it accumulates strata of compressed context, sediment, where each layer refers back to an earlier layer rather than the original detail. The session is technically continuous. It is not clean, and it never actually returns to the smart zone it started in, it just gets a temporary token-count reprieve while carrying more compressed history than before.
Figure 3 - The Sediment a Long Session Accumulates: Each /compact pass summarizes what came before, but a summary of a summary loses precision. A session that compacts repeatedly across unrelated tasks never returns to a clean slate.
/handoff: A Clean Fork Instead of a Longer Session
/handoff is a user-authored skill, not a built-in command, published by Matt Pocock in the mattpocock/skills repository [8][9]. Instead of summarizing the current session in place, it writes a fresh, scoped handoff.md to the operating system’s temp directory rather than the project workspace [8]. The current session continues unchanged. The document seeds a different session with none of the parent’s sediment.
The SKILL.md is specific about what a well-formed handoff document contains. It should not restate material that already lives somewhere durable: “Do not duplicate content already captured in other artifacts (specs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead” [8]. It redacts secrets before anything hits disk, and its frontmatter sets disable-model-invocation: true, so it only fires when a developer explicitly calls it [8]. The repository has been starred well over 100,000 times, a rough, self-reported figure [9]. The count matters less than the discipline, five rules:
- Pass a purpose argument. No stated focus produces a generic summary instead of a surgical bridge.
- Use pointers, not duplication. Reference the issue, file, or commit instead of copying its content in.
- List suggested skills. Name the slash commands the next session should invoke.
- Redact secrets before writing. The file lands in a plaintext temp directory.
- Treat the file as disposable. It is a bridge, not documentation.
The artifact is plain markdown, so nothing about it depends on Claude Code’s internal state. A handoff.md written at the end of a Claude Code session can seed a Codex session, a Copilot CLI session, or any tool that accepts a text prompt, useful whenever you want a second model’s independent read without a shared API. Worth distinguishing from IDE “agent handoff” features that route a task to a different mode inside the same tool, role routing within one harness: what we describe is session-context handoff, a portable artifact that crosses harness boundaries entirely. The two share a name and nothing else.
Figure 4 - Two Answers to a Filling Window: /compact keeps one session alive and summarizes it in place, well suited to a long single-topic debugging run. /handoff forks: the current session continues untouched while a small document seeds a genuinely fresh one [7][8].
Figure 5 - The Anatomy of a Well-Formed handoff.md: A purpose argument scopes the document. Pointers replace duplicated content. A suggested-skills section tells the next session what to invoke. Secrets are redacted, and the whole artifact is treated as disposable, not documentation [8].
Figure 6 - One File, Three Harnesses: Because handoff.md is plain markdown with no tool-specific state, a session in Claude Code can seed a session in Codex or Copilot CLI with no shared API or vendor-side integration [8].
The DIY Sub-Agent Round Trip
The most powerful use of /handoff in Pocock’s own workflow is bidirectional. A parent planning session identifies a sub-task that deserves its own isolated context budget, calls /handoff with a scoped purpose, and starts a fresh child session from that document. In one example Pocock walks through, a prototype session spun up this way ran to roughly 169,000 tokens, larger than the planning session that spawned it and well past the practitioner-observed 120K ceiling [6], exactly the case the pattern is built for.
When the prototype resolves, the child session calls /handoff a second time, capturing “all of the learnings from the prototype, anything that’s not directly captured in the prototype itself or that’s non-obvious” [6], and that return document gets pasted back into the original session. The parent never carried the child’s exploratory work, only the compressed result. Pocock’s own label is “a DIY sub-agent”: two disposable markdown files doing the coordination work a harness-level sub-agent feature would otherwise provide [6].
A stronger, independently measured version of the same idea: Anthropic’s own multi-agent research system, Claude Opus 4 as lead agent with Claude Sonnet 4 subagents, outperformed a single-agent Opus 4 configuration by 90.2% on an internal research evaluation [10]. The architectural reason lines up: isolating each subagent’s context window prevents the sediment a single long session accrues. Anthropic built that isolation into a harness feature; Pocock’s version achieves it with two markdown files and a developer bridging them by hand.
KEY INSIGHT: Context isolation is measurably worth doing, not just a nice-to-have. Anthropic’s multi-agent architecture and a solo developer’s two-file
/handoffround trip both isolate a subagent’s window from the parent’s for the same reason: sediment that never enters a window cannot degrade the session reading it.
Figure 7 - The DIY Sub-Agent Round Trip: A parent session forks a child with a scoped purpose. The child does token-heavy exploratory work in its own window. When it resolves, it hands a curated summary back. The parent’s context never absorbed the raw exploration [6].
Structural Counterparts: DOX and /checkup
Session budgeting is per-session. Two other patterns keep unnecessary material out of the window at different layers, worth naming because this is a convergent idea, not one developer’s workaround.
DOX, maintained by Agent Zero developer Yan at agent0ai/dox, is a per-folder documentation hierarchy: every folder carries an AGENTS.md describing its domain, rules, and an index of child folders [11]. An agent editing a file traverses the doc chain from repo root to target folder, carrying parent rules forward, and touches nothing else, “no installation, no dependencies, no package, no runtime,” compatible with “any AI agent that supports AGENTS.md files, including Codex, Claude Code, OpenCode, and similar tools” [11]. Claude Code does not read AGENTS.md natively. Its docs are explicit it reads CLAUDE.md, with an @AGENTS.md import shim or a symlink as the bridge [12]. Where /handoff budgets a session’s history, DOX budgets what a session loads in the first place.
/checkup addresses a third layer: the standing harness, accumulated across every session. It is real and shipped, confirmed against the changelog as the alias of a rebuilt /doctor, v2.1.205: “/doctor is now a full setup checkup that can diagnose and fix issues; /checkup is its alias” [13]. The premise, popularized by a YouTube walkthrough organized as “seven fixes,” is that a setup accumulates dead weight the way a session does, every skill, every MCP server, every rule bolted onto CLAUDE.md, loading into every session whether used or not [14]. Two of the seven are independently changelog-confirmed: trimming a checked-in CLAUDE.md, and catching a stale installed version [13]. The rest is the video’s own synthesis, attributed to the source rather than Anthropic. /handoff is per-session; /checkup is per-harness.
/goal, v2.1.139 or later, rounds this out: a separate evaluator, by default Haiku, checks your stated completion condition after every turn and “does not call tools,” judging only what is visible in the transcript [15]. A session deep in the dumb zone is also the one most prone to declaring itself finished prematurely, and a cheap evaluator checking the original goal guards against that.
Figure 8 - DOX: Loading Only the Map You Need: Before touching a file, an agent walks the AGENTS.md chain from repo root to target folder, carrying parent rules forward and reading nothing else. Context budgeting starts before the session begins [11].
Figure 9 - Two Hygiene Loops, Two Time Scales: /handoff forks clean state when one conversation ends. /checkup, the vendor-confirmed alias of /doctor, audits the skills, MCP servers, and CLAUDE.md rules loading into every session regardless of topic [13][14].
Beyond One Tool: The Shared Work Queue
Everything above budgets a single tool’s context. A different pattern shows up once work crosses vendor boundaries, when a Codex agent finishes work and a Claude agent needs to pick it up with no shared runtime. Developer Nate B Jones, describing a system called Open Engine, names the failure: “if every loop lives in its own room, the human becomes the hallway” [16].
His answer is a shared ticket queue, Linear in his demo, that both humans and agents read and write. A well-formed ticket carries what handoff.md carries, scope, context, a stopping point, plus a claim-lock protocol so two agents never pick up the same work: “output is what the AI returns right now. Work is what someone can review, accept, and build on” [16]. /handoff solves the single-tool version of this problem; a shared queue solves it when no single tool is in the room with every agent involved.
Figure 10 - The Queue as the Only Shared Runtime: A Codex agent writes a ticket; a Claude agent claim-locks and completes it. Neither shares an API. The queue is the entire integration surface, the cross-vendor analogue to a single-tool handoff.md [16].
Our Own Hand-Rolled Handoffs
We did not adopt this discipline in the abstract. This project already runs a version of it, unnamed. Every article pipeline pass writes a research-brief.md into the draft folder before the writer starts, scoped to exactly what the next session needs. A second-opinion review pass writes findings to a dated REVIEW-opus-*.md rather than keeping the reviewing context alive inside the drafting session. Our /whats-next and session-end routines exist for the same reason /handoff does: close one working session by writing down what a fresh one needs, rather than dragging a sediment-heavy session forward indefinitely.
None of these predates the pattern by intention. They converged on it the way DOX, /checkup, and Open Engine’s queue did, from the same pressure: a session that keeps extending itself degrades, and the fix is a small, purpose-scoped document a fresh session can read instead.
Figure 11 - A Hand-Rolled Version of the Same Idea: A research-brief.md before drafting, a dated REVIEW-opus-*.md after review, a session-end handoff between sessions. None were built with /handoff in mind, and all solve the identical problem.
Conclusion
The advertised context window and the usable one are different numbers, and Anthropic’s own documentation now names the gap: context rot [1]. The auto-compact threshold, the practitioner-observed smart zone, and Chroma’s 18-model finding are three separate measurements of related but distinct phenomena, and keeping them separate is most of the discipline this article argues for. /compact is the right tool for a long, single-topic session you want to keep alive. /handoff is the right tool the moment a session has a natural scope boundary, and its five discipline rules, a stated purpose, pointers instead of duplication, a suggested-skills list, redacted secrets, a disposable file, are what keep the artifact useful instead of becoming clutter of its own. The pattern repeats at the codebase layer in DOX, the harness layer in /checkup, and across vendor boundaries in a shared ticket queue, because the underlying constraint, a finite, degrading attention budget, is the same no matter which layer you look at.
The next article in this sub-series moves from budgeted sessions to a harness that never closes at all.
The Series
This is Part 1 of the 2-part Context Lifecycle & Autonomous Harnesses sub-series:
- Your 1M-Token Context Window Is a Lie After 120K: Budgeting Sessions with /handoff (this article). Why the advertised ceiling and the usable session are different numbers, and how
/handoffforks a clean session instead of piling sediment onto one long one. - The Always-On Agent: What 100 Hours With Hermes Teaches About AI Employees. What changes when the harness never closes a session at all, and what discipline an autonomous, self-improving agent needs in place of the reset button.
References
[1] Anthropic, “Context windows,” Claude Platform Docs. https://platform.claude.com/docs/en/build-with-claude/context-windows
[2] Anthropic, “Effective context engineering for AI agents,” Anthropic Engineering Blog. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
[3] Anthropic, “Model configuration: Extended context,” Claude Code Docs. https://code.claude.com/docs/en/model-config#extended-context
[4] K. Hong, A. Troynikov, and J. Huber, “Context Rot: How Increasing Input Tokens Impacts LLM Performance,” Chroma Research, Jul 2025. https://www.trychroma.com/research/context-rot
[5] Cursor, “Continually improving our agent harness,” Cursor Engineering Blog, Apr 2026. https://cursor.com/blog/continually-improving-agent-harness
[6] Matt Pocock, “/handoff is my new favourite skill,” YouTube, published 2026-05-21. https://www.youtube.com/watch?v=dtAJ2dOd3ko
[7] Anthropic, “Commands,” Claude Code Docs. https://code.claude.com/docs/en/commands
[8] Matt Pocock, mattpocock/skills, handoff skill file. https://github.com/mattpocock/skills/blob/main/skills/productivity/handoff/SKILL.md
[9] Matt Pocock, mattpocock/skills, repository root. https://github.com/mattpocock/skills
[10] Anthropic, “How we built our multi-agent research system,” Anthropic Engineering Blog. https://www.anthropic.com/engineering/multi-agent-research-system
[11] Agent Zero (Yan), agent0ai/dox. https://github.com/agent0ai/dox
[12] Anthropic, “How Claude remembers your project,” Claude Code Docs. https://code.claude.com/docs/en/memory
[13] Anthropic, “Claude Code changelog,” Claude Code Docs. https://code.claude.com/docs/en/changelog
[14] Hyperautomation Labs, “Claude Code /checkup: The One Command That Makes It Fast Again (7 Fixes),” YouTube, published 2026-07-09. https://www.youtube.com/watch?v=zddDcasWjL4
[15] Anthropic, “Keep Claude working toward a goal,” Claude Code Docs. https://code.claude.com/docs/en/goal
[16] Nate B Jones, “I Was The Only Thing Connecting Claude, ChatGPT, and Codex. So I Built My Replacement,” YouTube. https://www.youtube.com/watch?v=QSK4vf_ZTRA
[17] Anthropic, “Explore the context window,” Claude Code Docs. https://code.claude.com/docs/en/context-window
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.