- In short
- Loading every tool definition or document into context on every request multiplies token cost by call volume, even when most of it goes unused per request. A large monolithic context also increases the chance the model is distracted by irrelevant tool definitions when selecting which tool to call. The token cost of monolithic loading scales with the size of the full tool or document set, not the size of what a given request actually needs.
Why monolithic cost scales with the full set
Having distinguished monolithic from progressive strategies, the exam wants you to understand precisely why monolithic loading gets expensive. The mechanism is a multiplication: monolithic loading puts the entire tool or document set into context on every request, so the per-request token cost is the size of the full set, and the total cost is that full-set size multiplied by call volume. Crucially, this scales with the size of the full set, not with the size of what any individual request actually uses. A request that needs two tools still pays for all two hundred, and it pays that on every call.
That is the cost trap of monolithic loading. It looks cheap when the set is small, but because cost tracks the full set times volume, a large set at high volume produces a bill dominated by context nobody used on any given request. Understanding that the multiplier is full-set-size, not per-request-need, is the point.
- Token cost of monolithic loading at scale
- The cost dynamic of a monolithic context strategy: loading the entire tool or document set on every request multiplies the full-set token size by call volume, so cost scales with the full set size rather than with what a request uses, and a large context also raises the chance of distracted tool selection.
The multiplier is volume, and the base is the full set
Two numbers drive monolithic cost, and both point the wrong way at scale. The base is the full-set token size: every tool definition and document loaded, whether relevant to the request or not. The multiplier is call volume: that full base is paid on every single request. Multiply a large base by a high volume and the cumulative cost is substantial, even though on any one request most of the loaded context sat unused. The intuition that 'unused context is basically free' fails here because the unused context is not loaded once, it is loaded on every request, so its cost is paid over and over.
This connects to the cost-and-latency levers: input tokens are priced per token per request, and monolithic loading inflates the input token count on every call. The context strategy is therefore a direct cost lever, and a monolithic one at scale is a large, standing input-cost burden.
Irrelevant definitions distract tool selection
Cost is only half the harm. A large monolithic context also degrades tool selection. Every tool definition in context is a candidate the model must consider when deciding which tool to call, and a big context full of irrelevant definitions raises the chance the model is distracted and picks the wrong one. This is the same wrong-tool-selection dynamic as capability bloat: more candidates, more chances to misfire, and here the candidates are inflated by the monolithic strategy loading the whole set rather than a relevant subset.
So the exam's second point is that irrelevant tool definitions are not harmless just because the model does not call them. Even uncalled, they cost tokens on every request and they crowd the selection space, making a wrong selection more likely. 'It goes unused, so it does not matter' is exactly the misread to avoid. Monolithic loading's harm is both the standing token cost and the degraded selection, and both grow with the size of the loaded set.
What the exam trips candidates on
Two traps. The first is underestimating the cumulative cost of loading a large, mostly-unused context on every single request across high call volume, treating unused context as if its cost were paid once rather than per request. The second is assuming irrelevant tool definitions in context are harmless to model performance as long as the model does not call them, ignoring their effect on tool selection. The credited answer recognises that monolithic cost scales with the full set times volume and that irrelevant definitions degrade selection even when uncalled.
Worked example
An agent loads a catalogue of 150 tool definitions into context on every request. On a typical request it uses two of them. Traffic is high. An engineer says the 148 unused definitions 'don't matter because the model never calls them,' and the cost is negligible 'since they're just sitting there.' Correct the reasoning.
Both claims are the traps in this knowledge point, and both misjudge how monolithic cost and selection actually work. Take the cost claim first. The 148 unused definitions are not 'just sitting there' for free, they are loaded into context on every request, so their token cost is paid on every call, not once. With a monolithic strategy, per-request cost is the full 150-definition size, and total cost is that full size multiplied by the high call volume. Because the base is the full set (not the two tools a request uses) and the multiplier is volume, the cumulative cost of carrying those 148 unused definitions across high traffic is substantial, the opposite of negligible. This is the first trap, treating unused context as if its cost were paid once.
Now the 'never calls them, so they don't matter' claim. Even uncalled, each of the 148 irrelevant definitions is a candidate the model must consider at tool-selection time, so a 150-candidate context makes a distracted, wrong-tool selection more likely than a focused two-or-few-candidate context would. So the unused definitions do matter to performance, they degrade selection quality, which is the second trap. The corrected reasoning: the 148 unused definitions impose a standing token cost paid on every request across high volume, and they raise wrong-tool-selection risk by bloating the candidate set, so they are neither free nor harmless. This is precisely the situation where a progressive strategy, exposing a small relevant subset per step, would cut both the cost and the selection degradation.
Common misreadings to avoid
Misconception
Unused context loaded on every request has negligible cost because it is 'just sitting there.'
What's actually true
Misconception
Irrelevant tool definitions in context are harmless as long as the model never calls them.
What's actually true
How this shows up on the exam
Expect a large monolithic context defended with 'the unused parts don't matter,' at high volume. The reliable reading is that cost scales with the full set times volume and that irrelevant definitions degrade tool selection even uncalled. This knowledge point builds on monolithic vs progressive context strategies, shares its cost-and-selection logic with tool connections as attack surface and cost and the cost-latency levers, and unlocks the scale-based choice capstone.
An agent loads 150 tool definitions per request but uses about two, at high traffic. Why is the claim that the 148 unused definitions 'don't matter and cost nothing' wrong?
People also ask
How does monolithic loading cost scale?
Do unused tool definitions in context matter?
Why does a large context hurt tool selection?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.