Prioritization and cost: the budget the agent ignored

A research agent writes short product briefs. The lead agent reads the request, spawns a subagent per source, and merges what comes back. Tuesday's request: summarize three recent reviews of the Volt 2 scooter, and keep it under ten searches. The lead spawned four subagents, one per review site, each told to search until it found a review. Site A had two reviews. Site B had none. The B subagent searched, got nothing, rephrased, got nothing, and kept going. Search 11 ran at the same pace as search 1. Search 41 was the last, when the run hit its wall clock limit. No brief was written. The two reviews from site A sat in the lead's context the whole time.

The bill for that run was far above a normal one, and the user got a timeout. This lesson covers two patterns, resource aware optimization and prioritization, because this run broke both.

Line 5 is the eleventh search. The budget was in the user's message, line 1. The subagent never saw line 1; it saw its own instruction, which said search until you find a review. Even the lead, which did see the budget, had no counter. A budget that lives in a prompt is a wish. The only budget that holds is one that code enforces: a counter that refuses the next call.

The second failure is priority. Two reviews were in hand by search 3. A brief from two reviews, with a note that a third was not found, is most of the value. The run spent 38 more searches on the lowest value item on the list and delivered none of the value it already had. The agent had no idea that some work matters more than other work, or that returning early with a partial result is a legitimate outcome.

Anthropic's research system post (June 2025) gives the costs plainly: agents use about 4 times the tokens of a chat, and multi agent systems about 15 times. On the BrowseComp eval, token spend alone explained 80 percent of the variance in performance, which is why teams work and also why they are expensive. The same post describes early versions that searched the web endlessly for sources that did not exist. The fix was the same as here.

Put the budget in code, at every level. The run has a token ceiling and a wall clock. Each subagent has a call allowance, and the tool wrapper counts. When the allowance is spent, the next call returns a budget error and the subagent must report what it has. Frameworks give you a start: the OpenAI Agents SDK stops a run with MaxTurnsExceeded when it passes max_turns. Use what the framework gives you, then add your own counters on the tools that cost money.

Then order the work by value per cost. Cheap and likely sources first. A result that is good enough ends the run early: three reviews were asked for, two were found, write the brief and say so. Returning partial work with an honest note is a success state, and the prompt and the code must both say so. Size the team to the question. One lookup is not a four subagent job, and a deep comparison is not a one search job.

Match models to work. In the research system the lead ran on Claude Opus 4 and the subagents on Claude Sonnet 4, because the subagents do narrow, repeated jobs. Most of the cost is in the subagents, and most of the judgment is in the lead.

Finally, watch it. Log tokens, calls and cost per run, and alert when a run is above its usual range. A run at 15 times a chat that is normal for the task is fine. A run at 15 times its own usual cost is a bug.

"Line 5. The eleventh search ran because the budget was a sentence the subagent never saw and nothing counted. I would enforce the budget in code at the run and subagent level, order sources by value per cost, and make a partial brief with two reviews a valid stop." Then name the number: multi agent runs cost about 15 times a chat, so the budget is a design input, not a prompt line.