Correction, 30 September 2026: an earlier version of this article reported a 71% reduction. Its “without patterns” baseline counted each step’s previous output twice, because every step’s input already contains the output of the step before it. Corrected, the reduction is 61%. The figures and conclusions below are corrected.
The “85% context reduction” claim for Claude Code skill chaining has been circulating since Mansel Scheffel’s video “I Finally Solved Claude Code Skill Chaining (85% Less Context)” ( https://www.youtube.com/watch?v=JdqJ2ekWt8M )and if you’ve built anything serious with Claude Code or the Anthropic SDK, you’ve probably wondered whether to believe it. We built measurement tooling to find out: per-node token tracking across an instrumented multi-step workflow, with a controlled accumulation baseline to compare against. The result is 61% reduction in total input tokens—and that discrepancy from 85% is the most useful thing we found. Because it reveals what most developers get wrong about Claude Code context management: the value isn’t in the billing.
The Original Claim
Mansel Scheffel’s video introduced the pattern: chaining skills through sub-agents, rather than accumulating all outputs in one context, dramatically reduces how much context the model needs to carry. The 85% figure spread because it was striking and, frankly, because context costs are real and developers are looking for ways to control them.
We wanted to know whether the number held up under measurement—and whether “context reduction” was actually the right frame for what was happening.
What We Actually Measured
We instrumented a four-node workflow: fetch transcript → structure content → write brief → save to file. Run 20260504-122207 recorded per-node input and output token counts with all patterns applied. A simulated accumulation run (exp-002) modeled the same workflow without them—each node receiving the full accumulated output of all prior nodes rather than a distilled handoff.
With Patterns Applied
| Node | Input tokens | Output tokens |
|---|---|---|
| fetch | 265 | 5,971 |
| structure | 6,080 | 1,048 |
| write | 1,149 | 938 |
| save | 945 | 4 |
| Total input | 8,439 tokens |
Peak context occupancy: 3.04% of the 200K window, at the structure node.
Without Patterns (Simulated Accumulation)
| Node | Input tokens | Multiplier vs. forked |
|---|---|---|
| fetch | 265 | 1.0× |
| structure | 6,080 | 1.0× |
| write | 7,120 | 6.2× |
| save | 7,964 | 8.4× |
| Total input | 21,429 tokens |
Result: 61% reduction in total input tokens. The save node alone is 8.4× more expensive without context management, and the gap grows with every node you add.
Why 61%, Not 85%—And What “Context Shift” Means
The gap between 61% and 85% isn’t a contradiction. It’s the most important thing to understand about Claude Code context management.
Most context management patterns don’t eliminate tokens. They relocate them. When you use a Context Fork—a sub-agent call—the parent context improves because the sub-task’s intermediate reasoning and tool outputs stay isolated in the child context. But the child context has its own initialization overhead: system prompt plus tool schemas. Typically 800–2,000 tokens per fork. The parent wins. The system total may be unchanged, or even higher. This is a valid trade-off—isolation and working space are worth the overhead—but it must be measured, not assumed to be neutral.
The 85% figure captures context reduction in the primary agent’s context window—which is accurate from that perspective. Our 61% measures total input tokens across the whole system. Both numbers are real. They measure different things. The classification that makes this tractable:
- Context Reduction: tokens genuinely removed from total system consumption. A summary replaces a full document; the original is discarded. Net usage decreases.
- Context Shift: tokens move from one location to another. Distribution improves; totals may be unchanged or higher. Still valuable—but for different reasons than you’d optimize for billing.
Understanding the distinction is what separates defensible architecture decisions from intuition-based optimization. A pattern that improves the primary agent’s headroom while adding system-level overhead is worth using—but not for the cost reason you might assume.
The Real Value: Reasoning Headroom, Not Billing
Here’s the reframe that changes how you should think about all of this: Claude Code context management is primarily an operational concern, not an economic one.
A 200,000-token context window is not a cost meter. It is the model’s working memory. Fill it with accumulated outputs from prior steps, and reasoning quality degrades—not because you’ve exceeded a limit, but because you’ve crowded out the space the model needs to think about the current task. We call this cognitive collapse: the failure mode where accumulated content competes with the reasoning space required to do the next step correctly.
Context Rot Is Empirically Real
Chroma’s research tested 18 LLMs and found that every one degrades as context fills. The finding most relevant to workflow design: models perform better on shuffled haystacks than on logically structured ones. Coherent, ordered context creates stronger recency bias—meaning filling a context window with well-organized prior-step outputs can produce worse reasoning than a shorter, focused input. A NoLiMa benchmark from LMU Munich and Adobe Research (ICML 2025) found that when surface-level pattern matching was removed, 11 of 13 LLMs dropped below 50% of their baseline scores at just 32K tokens. Context degradation is not a theoretical concern—it shows up in the numbers.
What 3% Occupancy Actually Means at Scale
In our instrumented run, peak context occupancy with patterns applied was 3.04%, at the structure node. Without patterns, the final node would carry about 4% (7,964 tokens), on a four-node workflow processing a single transcript. We didn’t run a longer workflow, but the direction is clear: without forking, every node carries every earlier output, so the load grows with each step you add, while the forked run stayed at or below about 3% at every node. That stability is the value: not billing, but clean working space at every step. The forked workflow doesn’t accumulate; the non-forked one keeps growing.
The Nine Patterns Across Four Modalities
The Context Economics framework we documented covers nine patterns, classified by whether they reduce or shift tokens, with implementations across four modalities.
The Pattern Classification
| Pattern | Classification | Primary effect |
|---|---|---|
| Context Fork | Shift (additive) | Isolates sub-task context; parent receives only the result |
| File Handoff | Shift → Reduction | Distills output to only what downstream needs; discards the rest |
| Command Injection | Reduction | Injects known values before the LLM sees the prompt; zero tool-call overhead |
| Wave Parallelism | Shift (neutral) | Concurrent independent calls; token-neutral, latency-reducing |
| Prompt Caching | Cost reduction | Stable content at 10% cost on cache reads; token count unchanged |
| Context Compression | Reduction | Intermediate summary call replaces accumulated history |
| Token Budgeting | Reduction (preventive) | Explicit limits prevent unbounded output from propagating as input debt |
| Selective Tool Pruning | Reduction | Excludes unused tool schemas per call; ~200–500 tokens saved per excluded schema |
| Layered Context | Reduction (structural) | Partitions stable/dynamic/ephemeral layers managed independently |
In our run, the File Handoff at the structure node achieved 83% compression: 6,080 input tokens produced 1,048 output tokens, and only those 1,048 tokens were passed to the write node. The 5,000+ tokens of raw structured content were discarded rather than propagated. Most of the 61% reduction, though, comes from not carrying fetch’s 5,971-token raw output into every later step: without forking, the write and save nodes would each receive it again.
The Modality Matrix
All nine patterns are natively available in Claude Code CLI—the runner implements Context Fork (every node is an isolated Agent call), File Handoff (declared port outputs), Command Injection (! cat template interpolation), and wave computation automatically. In the Direct Anthropic SDK—the highest-control modality and EchoForgeX’s primary AI integration target—context management is fully explicit: cache_control for Prompt Caching, separate messages.create() calls for Context Fork, Pydantic field extraction for File Handoff. Agentic frameworks (LangChain, CrewAI) provide first-class tool pruning and parallelism but require SDK fallthrough for Prompt Caching. Web/IDE interfaces accumulate by default with no programmatic control—all patterns require manual equivalents. The interface you choose determines which optimizations are available to you at all.
Where to Start
If you’re building multi-step workflows with Claude Code or the Anthropic SDK, three actions have the highest immediate return—and they compound:
- Find your highest-output node. Apply File Handoff: extract only what downstream steps need. If your structure node produces 6,000 tokens but the next step needs three fields, pass three fields. The raw output gets discarded, not propagated.
- Cache your stable system prompt. Add
cache_control: {"type": "ephemeral"}to any system prompt repeated across multiple calls. At 10 calls with a 4,000-token prompt, this cuts that layer’s cost by 78%. - Make new workflow steps Context Forks. Each new step should be a separate call receiving only distilled input. This keeps every step’s working memory clean regardless of how many steps precede it—the occupancy stays flat at ~3% instead of growing linearly.
Measure as you go. Without per-node token tracking, you cannot know whether your patterns are helping, neutral, or quietly compounding. The 61% reduction we found was measurable because instrumentation was built in from the start. The pattern classifications—reduction vs. shift—only become actionable when you can see the actual numbers. For teams building production AI workflows, this observability is where the real work is. You can explore how EchoForgeX approaches this in our AI tooling stack.
The frame that matters: context management isn’t a billing optimization. It’s how you give the model room to reason well at every step of your workflow, regardless of how long that workflow becomes.
At EchoForgeX, we build AI-powered tools and help businesses integrate AI into their workflows. Get in touch to learn how we can help your team work smarter with AI.