The Triage Call

Abstract.

Most cost advice for research agents starts with the model: use a cheaper one, route between several. This post starts one step earlier, at the decision an agent makes after every search: which of ten results to open. We simulate a four-sub-question research agent under five policies (read everything, read a fixed top three, and three versions of a short "triage" call that picks pages from snippets) and compare tokens, cost, latency and a modeled quality score. In this model, selecting before reading cuts cost per task by about 65% and latency by about 41% against reading everything, mostly because unread pages are never re-sent on later turns. Which model runs the triage call matters far less than whether the call exists. A cheap triage model with no confidence fallback costs a few points of quality and a few percent of savings.

Every number and chart in this post comes from a simulation with assumptions listed below. It is illustrative, not measured on production traffic, and your results will differ. The quality score depends on an assumed distraction penalty, so treat the quality gap as a hypothesis to test, not a finding.

Introduction.

Agent token bills are growing for a boring reason: agents re-read. Anthropic's documentation says web search results "are counted as input tokens, in search iterations executed during a single turn and in subsequent conversation turns" (Claude Platform Docs, "Web search tool"). Research on coding agents makes the same point from the other side: trajectories accumulate "useless, redundant, and expired information" that is paid for again on every call (Xiao et al., arXiv:2509.23586).

We have covered the anatomy of a ReAct step, trajectory reduction and the search tax. This post isolates one small hop none of them priced: the decision between the search call and the read call.

Research question.

When an agent gets ten search results back, what does it cost, in tokens, dollars, seconds and answer quality, to decide which ones to read before reading them, and does the model making that decision need to be a premium one?

Methodology.

We modeled an agent that answers a task by resolving four sub-questions. Each sub-question runs one search round, with one retry if no relevant page was read. All parameters are assumptions:

• Search results: 10 per round, about 120 tokens of snippet each. Each result is relevant with probability 0.2 (at least one per round is relevant). 20% of results repeat a page already read earlier in the session.
• Pages: 4,500 tokens each, 30% of which is boilerplate (navigation, ads, footers).
• Fixed overhead: a 2,000-token system prompt and tool schema on every call.
• Prices (illustrative): premium class $5 input / $25 output per million tokens; small class $0.50 / $2.50.
• Latency (illustrative): 0.9 s per page fetch; 60 output tokens per second premium, 150 small; fetches are sequential in the read-everything agent and parallel elsewhere.
• Triage: one call over the ten snippets (about 1,200 input tokens, 60 output). Premium triage has noise 0.3; small triage 0.75, on a relevance score where relevant pages average 1.0 and irrelevant 0.0.
• Quality: the share of sub-questions with a relevant page read, times 0.97, reduced by 1.2% per 10,000 irrelevant tokens in context (capped at 25%). That penalty is our assumption, motivated by long-context degradation work such as Liu et al., "Lost in the Middle", which found accuracy drops when relevant information sits in the middle of long inputs and as input length grows.

Policies: read everything (premium, sequential), fixed top-3 (read the first three results, no judgment), premium triage, small triage, and hybrid (small triage, escalating to the premium model when the small model's best score is under a threshold). 4,000 simulated tasks per policy, seed fixed.

Results.

Where the tokens go.

The read-everything agent bills about 466K tokens per task. Search snippets and final synthesis are rounding errors. The largest stage is reasoning calls that carry history, about 280K, and that history is mostly pages read in earlier rounds. Page reading itself is another 180K. Selecting before reading shrinks both, because a page that was never opened is never carried.

Cost.

Against $4,712 per 1,000 tasks for reading everything, the three triage policies land between $1,634 and $1,733. The triage call itself is cheap: about 1,200 input tokens. The saving comes from what it prevents. Note how little separates the triage tiers. Premium triage is 5% cheaper than small triage here, because the small model's misses cost retries.

Latency.

Triage adds a hop (roughly one extra second per round) and still wins by about 41% on wall-clock, because it removes sequential page fetches and shorter prompts speed up every later call. Parallel retrieval alone would capture the fetch savings but not the token savings: it can increase token load, since it reads at least as much, faster.

Cost against quality.

The fixed top-3 policy shows the danger zone: it is cheaper than reading everything and worse on quality, because rank order is a weak proxy for relevance and it misses evidence without noticing. Small triage with no fallback loses about 1.2 points against premium. The hybrid recovers most of that gap while escalating only about a third of rounds. This is the one place the model tier shows up, and it shows up as a confidence rule, not a blanket choice.

What is being wasted.

Of 180K page tokens read, about 40% went to irrelevant pages, 30% to boilerplate and 14% to pages the agent had already seen. Each needs a different fix: triage for the first, extraction or reader-mode for the second, a session-level URL ledger for the third. Compression helps with the second and does little for the first, which is why we would compress after selecting rather than blindly before.

Discussion.

Four caveats follow from the model.

1. Cheaper is not always cheaper. The small triage model cost more than the premium one once retries were counted. A per-token discount is not a per-task discount.
2. Quality is the soft spot. Our distraction penalty is assumed. If your model is robust to noisy context, the quality gap shrinks and only the cost and latency gains remain. Measure it on your tasks.
3. Caching only helps repeating work. A URL ledger and prompt caching pay off when sessions revisit the same pages; our 20% duplicate rate is a guess.
4. Rules need monitoring. A fallback threshold tuned on today's search provider drifts when results change. Log the escalation rate and alert on it.

Implementation guide.

1. Instrument tokens by stage. Tag every call as reasoning, query, snippet, page read or synthesis.
2. Separate reasoning from context. Report carried history and new content separately; carried history is where growth hides.
3. Detect over-reading and duplicates. Count pages read per relevant page used, and keep a per-session ledger of URLs.
4. Route simple steps. Triage and extraction over short snippets are narrow, closed-context tasks; send them to a smaller tier.
5. Compress after retrieval. Strip boilerplate from the pages you chose to read, not from everything.
6. Add a confidence threshold and fallback. Escalate when the cheap model's top score is low.
7. Monitor cost, latency and quality together. A dashboard of one without the others will reward the wrong change.

def triage(snippets, small, premium, min_conf=1.4, k=3):
    scores = small.score_relevance(snippets)       # one short call, ~1.2K tokens
    if max(scores) < min_conf:                      # no clear winner: escalate
        scores = premium.score_relevance(snippets)
    ranked = sorted(range(len(snippets)), key=lambda i: -scores[i])
    return [i for i in ranked[:k] if scores[i] > 0.5]

Where Nadir fits.

This is the kind of problem model routing is built for. Instead of treating every step as a flagship-model problem, a team can classify each step's difficulty and send it to the cheapest model that clears a quality floor. Nadir does that with model="auto", and its response metadata reports the routing decision and cost per request, so the by-stage view in step 1 comes from data you already have. Whether a given step is safe to downgrade is an empirical question; Observe mode records what Nadir would have done without changing any response, so you can check before you switch.

Conclusion.

The future of LLM cost optimization is not only cheaper models. It is better orchestration, better routing, better retrieval discipline and better measurement. In our simulation, the biggest lever was a short decision before the read, and the model tier on that decision was second-order. Benchmark your own workflow: log tokens by stage for a week, count pages read per page used, and see what the numbers say. If you want help with the measuring, start with a free key and run Observe mode on your agent traffic.

Sources: [Claude Platform Docs, "Web search tool"](https://platform.claude.com/docs/en/agents-and-tools/tool-use/web-search-tool). [Xiao, Gao, Peng and Xiong, "Reducing Cost of LLM Agents with Trajectory Reduction," arXiv:2509.23586](https://arxiv.org/abs/2509.23586). [Liu et al., "Lost in the Middle: How Language Models Use Long Contexts," arXiv:2307.03172](https://arxiv.org/abs/2307.03172). Simulation parameters are assumptions as stated in Methodology; prices are illustrative round numbers, not any provider's rate card.