I Ran /insights on 374 Claude Code Sessions. 219 Were Accidentally Multi-Clauding.

I didn't have the epiphany reading a changelog. It hit me mid-session, three agents deep into a refactor, main thread barely at 30%. No /compact. No restart. Just... clean.

Six weeks earlier, I was like everyone else. Context decay at 60%, vague answers, Claude forgetting the file it just read. The kind of situation where you want to punch something (but you can't punch an AI, so you just stare at the screen and breathe).

Then /insights dropped the diagnosis I never asked for: 219 overlap events in 28 days. I was multi-clauding without knowing it.

March 2026 was a festival of tools. Mature subagents, Agent Teams, context: fork. This article is not a feature tour. It's how my mental model changed, and the decision framework I use now to decide whether I launch one agent, two, or five.

Three Agents, One Refactor, Zero Compaction

The refactor was a WooCommerce product sync that had been accumulating technical debt for six months. The kind of codebase where every file has a comment that says "temporary fix" from January.

Three agents, each in its own context. One on the API layer (twelve endpoints, validation, error paths). One rewriting the transform logic that had turned into spaghetti because of six months of "just add a condition." One auditing the test suite to figure out which tests were actually testing something versus which ones were just... there. Vibes tests.

Main thread at 30%, coordinating, not doing the heavy lifting. No moment where Claude starts answering questions about files it read forty minutes ago with the confidence of someone who definitely did not read that file. (You know the face. The confident wrong face.)

The same refactor, two months earlier: single session, context fills up by the second endpoint, responses get vague around file seven, I restart, re-explain the whole mise en place, lose twenty minutes, restart again. By the third restart I'm not refactoring anymore. I'm babysitting Claude's memory.

This time, two hours. Clean summaries from each agent. Merge, test, push.

I wasn't managing a window anymore. I was designing a system of contexts.

The Diagnosis I Didn't Ask For

I ran /insights on my Claude Code usage. 374 sessions. 219 multi-Claude overlap events in 28 days. Not because I was being clever. Because I kept opening new sessions when the old one decayed, without closing it. Accidental multi-clauding, the reason behind bad habits.

The overlap count was a symptom. The disease was underneath: I was treating context like a scarce resource. Every /compact was a small admission that the session was degrading. Every restart was a bigger one. And every time I opened a second terminal "just to check something quick," my workflow was trying to distribute context before I had the tools to do it on purpose.

Context decay was the symptom. Treating context like a constraint was the disease.

Multi-clauding by accident isn't a sign of incompetence. It's a signal that the workflow outgrew the single-session model. If your /insights shows overlaps, you're probably there too.

Context Stopped Being a Constraint. It Became a Building Material.

The result first.

In March 2026, four things shipped at the same time: the 1M token context window, mature subagent types (Explore, Plan, General purpose), context: fork as a first-class feature in custom skills, and Agent Teams as an experimental multi-agent mode. Each one useful alone. Together, they changed what a context window is.

Not a box that fills up. A material you distribute.

Think of the shift from monolith to microservices. Not the hype version with twelve services and a message bus for a todo app. The real version: you stopped trying to save RAM in one big process and started designing isolation boundaries. Each service gets its own memory. The orchestrator stays light. Communication happens through defined interfaces, not shared state. Same shift, applied to context. Each subagent gets a fresh 200K window. The main thread stays light. Results come back as summaries, not raw bleed.

The practitioner community is converging on similar numbers. "Split by context, not by role" keeps surfacing as a pattern. Main context sits around 30-40% for people who've made the switch. Lydia Hallie from the Claude Code team presents context: fork as a design feature, not a workaround. Simon Willison formalized subagent patterns in his agentic engineering writeups.

Why now? These patterns aren't new (Docker didn't invent containers). But the March convergence made them accessible to any solo dev on a Max plan. Before March, distributing context meant fighting the tools. After, the tools expect it.

Fair warning: the microservices analogy breaks down fast if you push it. No service discovery between agents. No "context mesh." Agent Teams are experimental, not a mature distributed runtime. The mental model helps. The analogy is a starting point, not a destination.

Same model, same tokens. Completely different relationship.

The theory is clean. In practice, the question every session comes down to is brutally simple: do I launch one agent, two, or five?

The Decision Framework I Actually Use

Task arrives
├── Coherent scope, related files, context < 40%
│   └── Single agent. Scope-lock prefix. Done.
├── Heavy exploration (> 3 unrelated files to read), result = summary
│   └── Subagent / context: fork. It explores, you stay clean.
└── Independent subtasks + coordination benefit
    └── Agent Team. But: if agents need to constantly
        read each other's output → back to single agent.

Three regimes. The boundaries matter more than the categories.

Single agent is still the right call for most tasks. A feature addition touching three related files. A bug fix where the scope is obvious. If the context fits comfortably and the files are related, spawning a subagent adds overhead for zero benefit. A scope-lock prefix in your prompt does the job: "You are working on X. Only touch files Y and Z. Do not explore beyond this scope."

Subagents are for when exploration would poison your main context. The trigger I've landed on: if I need to read more than three unrelated files to answer a question, that's a spawn. Last week, a subagent exploring a partner API's auth flow read fourteen files across three repos, returned a six-line summary. My main context didn't move. The same exploration in a single session would have eaten 35-40% of the window with file contents I'd never look at again.

Agent Teams are for when subtasks are independent but the overall outcome benefits from parallel execution. The refactor from section one. A debugging session with three hypotheses explored simultaneously. The critical test: if agents need to constantly read each other's output to proceed, you don't have independent subtasks. You have a single task wearing a trenchcoat pretending to be three. Go back to single agent.

The prompt structure I use to launch an Agent Team:

"Three parallel agents. Each agent gets ONE scope:
- Agent 1: [scope]. Deliver: [specific output].
- Agent 2: [scope]. Deliver: [specific output].
- Agent 3: [scope]. Deliver: [specific output].
No agent reads another agent's files. Final merge is mine."

Each agent receives a scope, constraints, and an expected deliverable. If you recognize the pattern, it's because context boundaries work like prompt contracts applied to multi-context architecture. Same discipline. Scope, constraints, deliverable. Except now you're writing the contract for an isolated context, not a single session.

This framework is calibrated on solo/indie usage. In a team of four devs, the dynamics shift (git conflicts, permissions, human coordination stacked on agent coordination). Haven't stress-tested Agent Teams in a team yet. Solo, it holds.

The rule: if you can't write the subagent's contract in two sentences, it doesn't need to exist.

The Token Bill Nobody Wants to Talk About

Distributing context costs more tokens. That's the honest part, and pretending otherwise would be dishonest.

Agent Teams run 4-7x the tokens of a single session doing the same work. Subagents in parallel on a Pro plan hit the rate limit in about twenty minutes. The Max plan at $100-200/month is the realistic floor for this workflow.

Now the part nobody calculates.

Prompt caching changes the math. On heavy sessions, 90%+ of tokens are cache reads at $0.50 per million tokens for Opus. The multiplier is real, but it's a multiplier on a base that's dramatically cheaper than sticker price. My monthly bill went up maybe 40% after switching to multi-context. Not 400%. The prompt caching layer is what makes the whole multi-context economy actually work.

But forget the token bill for a second. Karen from Accounting would kill me for saying this, but the token bill is the wrong spreadsheet.

The real cost of context decay: the twenty minutes re-explaining context after a restart. The bug you ship because Claude's answer was based on a file it half-remembered. The third restart where you give up on the refactor and do it by hand. That cost doesn't show on any invoice. It shows up on your Friday afternoon, the one you were supposed to spend at the pool with the kids, debugging a session that rotted at 65%.

Multi-context eliminates the invisible cost. The token bill goes up. The total cost goes down.

These numbers are Max plan with Opus prompt caching. On Pro, the ratio shifts hard. On direct API without caching, multi-context can get prohibitive. Don't copy my numbers to your tier.

What Changes When Everyone Thinks This Way

The clearest signal that this shift is real isn't the features. It's that practitioners who've switched don't go back. "Split by context, not by role" is becoming a reflex, not advice. The people running multi-context daily aren't evangelizing it. They're just doing it, the way nobody talks about using git anymore. You just use git.

The tools are following. Agent Teams is experimental today but the direction is set. Context persistence between sessions is already shipping (auto-memory, /resume). There are 100+ community subagent configs on GitHub building on the pattern before it even has an official name.

Most devs still use Claude Code as a monolith with a big window. And it works. But some tasks deserve more. And knowing which ones, that's the whole point. 🤷

Two months ago we were fighting context decay. Restart, compact, clear, optimizing MCPs, pruning skills... praying Claude would remember line 42.

Today my CLAUDE.md files are a different animal. No more "don't do X" lists. Scope declarations for each context. My skills have context: fork by default. Project structure reflects context distribution, not the other way around.

The shift wasn't technical. The tools already existed in pieces. The mental model moved: stop protecting a single session, start architecting isolated contexts. Everything else followed.

One agent is enough for most tasks. But knowing when it's not enough, and forking at the right moment instead of clinging to a session that's rotting, that's the difference between using Claude Code and understanding it.

Sources

Simon Willison, "Agentic Engineering Patterns" (simonwillison.net). Lydia Hallie (Anthropic), Claude Code context: fork documentation and presentations. Akshay Pachaar, "split by context, not by role" (X/Twitter, March 2026).

(*) The cover is AI-generated. The three agents in the picture have better coordination than most standups I've attended.

---

If you're tired of AI agents forgetting context mid-session, this newsletter breaks down how to design with context windows instead of fighting them.

→ Join the newsletter