Returning a 50K-token web page into context burns budget for content the model will mostly ignore, and silently triggers lost-in-the-middle across the trajectory. The model cannot 'choose what to read' inside a tool result; it sees the entire blob. Capping at the tool boundary gives the application control: truncate to the top-N most relevant sections, prepend metadata (URL, title, retrieved-at), or run a small summarizer pass before handing back. The agent can always re-call the tool with a more specific query if needed. Tool wrappers that respect a max output tokens budget are one of the single biggest reliability wins for agent systems.
Tools in an agent system can return enormous outputs. A web-search tool that fetches a page can produce tens of thousands of tokens. A file-read tool over a log file can produce hundreds of thousands. An API call to a database can return a giant JSON document.
If the tool wrapper returns this blob unchanged into the model's context, two bad things happen. The token budget is consumed by content the model will mostly ignore, and the relevant tokens end up buried in the middle of a long context where the **lost-in-the-middle** effect kicks in. The model cannot "scroll" through a tool result and pick out the useful section; it sees the entire blob as one chunk in the conversation.
The canonical fix is to cap tool output at the tool boundary, inside the wrapper code that calls the underlying service. The wrapper can truncate to the top-N most relevant sections, prepend useful metadata (URL, title, the time the result was fetched), or run a small summarization pass before handing back to the model.
If the agent decides it needs more, it can call the tool again with a narrower query or with an explicit "give me page 2" argument. This shifts the decision of *what to read* from the model, which has poor information about the source format, to the wrapper, which knows exactly how the underlying response is structured.
Tool wrappers in agent systems sit between the model and the outside world: a search API, a file-read function, a database query, a shell command. The wrapper is the right place to enforce a token budget on tool output, and the reason is structural rather than stylistic.
The model cannot skim a tool result. When a 50K-token web page lands in context as one tool_result message, the model sees the whole thing at once and has to allocate attention across all of it. The relevant content is buried in the middle of the trajectory, and the **lost-in-the-middle** curve guarantees attention skips it. Meanwhile, the entire blob is billed at input-token rate and erodes the remaining context budget for the rest of the trajectory.
Capping at the wrapper turns this from a model problem into an application problem, which is the right layer to solve it. The wrapper knows the source format: it can parse the HTML, strip nav and footer, and return only the article body. It can truncate to the top-N sections by a relevance heuristic. It can prepend structured metadata, URL, title, retrieved-at, so the model knows what it got. For very large sources, it can run a small summarizer LLM and return the summary plus a handle (a URL fragment, a chunk id) that the agent can use to fetch more.
The agent loses nothing important. If it decides the truncated result is insufficient, it can re-call the tool with a more specific query, request a different page, or ask for a different section. The cost of one extra tool call is far less than the cost of one polluted context window.
Production agent systems treat tool-output capping as load-bearing. Anthropic's Claude Code, Cursor, Devin, and every coding agent in 2026 enforces strict per-tool token budgets. Without that discipline, multi-step agent trajectories collapse under their own context weight by step five.
Quick reference
TL;DR
Capping tool output at the wrapper keeps a single tool call from torching the context budget and triggering lost-in-the-middle, and the wrapper has structured-format knowledge the model lacks.
Picture a research assistant who can fetch books from a library for you, and your desk only fits five books at a time. If the assistant dumps every book they can find onto the desk, half of them slide off and the ones underneath are buried. A good assistant skims each book first, hands you the relevant chapter, and writes the rest of the title on a sticky note so you can ask for more if you need it. The tool wrapper is that assistant. The model is you at the desk. Without a cap at the wrapper, one tool call can bury everything else on the desk, including the question you were trying to answer. With a cap, the desk stays usable and the agent can ask for more on demand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Tools whose entire output is structurally small and bounded, like a calculator or a unit converter. If the underlying response is already a single number or a short string, adding a wrapper-level cap is pure overhead with no benefit.
Trajectories where the model genuinely needs the full document to reason correctly, like a contract-review task on a single legal clause. Aggressive capping can drop the exact phrasing the model needs to cite. In these cases, the right move is to keep the full text but isolate it as a dedicated retrieval document with paragraph anchors, not to chop it at the tool boundary.
Latency-sensitive flows where running a summarizer pass inside the wrapper would push end to end latency past the budget. Summarization is a real cost. For sub-second tool calls, hard truncation with structural awareness (top of file, top of JSON fields) is preferable to a slower summarizer round trip.
Quick scan · 2–4 min
Everything important, quickly.
State the problem: tool outputs can be huge and the model cannot skim. Connect to lost-in-the-middle and context-budget consumption. Name three capping strategies (hard truncate, top-N relevance extraction, summarize then return) and when each is appropriate. Explain why the wrapper has better information than the model for choosing what to cut: it knows the source format. Close with how capping composes with lazy retrieval and pagination tools, plus the rule that the wrapper must always tell the model when it cut.
Real-world examples
Real products, models, and research that use this idea.
1Anthropic's Claude Code caps Bash and file-read tool outputs at a few thousand tokens by default and appends a 'use grep for more' hint when truncated.
2Cursor's agent mode wraps file-read with a chunked by symbol reader that returns one function or class at a time rather than the whole file.
3Perplexity and Tavily web-search APIs return abstracted snippets by default and require an explicit follow-up call to fetch full page content.
4LangChain's WebBrowser tool runs a summarizer over fetched HTML before returning to the agent, capping at a configurable max-tokens parameter.
5OpenAI's Responses API for code-interpreter and file-search truncates large outputs and surfaces a tool_call_chunks pattern so the agent can request continuations.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow do you decide between hard truncation, top-N extraction, and summarization for a given tool?
Sign in or go Pro to see the approach for this follow-up.
QHow does tool-output capping interact with tool-result caching and reuse across turns?
Sign in or go Pro to see the approach for this follow-up.
QWhat goes wrong when the cap is too aggressive and the agent gets too little context?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Treating tool outputs as raw passthroughs and assuming the model will handle truncation on its own, when in fact the model sees the entire blob and burns budget over it.