Every agent builder has a cost-cutting trick in the drawer: compress the history, rank hypotheses before acting, feed back coverage, give the agent a call graph. I have reached for most of them. A new study of where the tokens go in vulnerability-discovery agents tested four such tricks head to head and found that only 39 of 160 method-enhanced runs (24.4%) kept success and lowered cost.
The paper is Where Do the Tokens Go? Understanding and Reducing Costs in LLM Agents for Vulnerability Discovery, from Li Lu, Yanjie Zhao, Hongjie Chen and Haoyu Wang at Huazhong University of Science and Technology. The domain is C/C++ vulnerability discovery on CyberGym, not general coding. But the cost anatomy applies to any long-horizon agent that reads a lot of code.
Two phases eat 60% of the bill#
The authors ran 200 traces: 10 tasks, 4 agents (Codex, OpenCode, Cybench, EnIGMA), and 5 configurations (a baseline plus the four efficiency methods). Together they burned 776.60M tokens. They then hand-coded 32,924 turns to see what the tokens bought.
Code localization and understanding took 43.1% of tokens.
Vulnerability reasoning and trigger design took another 17.3%.
Auxiliary models, the helpers many efficiency methods add, accounted for 7.0% (54.53M tokens).
Failures cluster in the same two places. Of 67 failed traces, those two phases account for 68.7% of attributed failure weight. So the expensive part and the failing part are the same part: reading the code and deciding what it means.
Spending also did not track results. OpenCode with DeepSeek-V4-Pro succeeded on 10 of 10 tasks at $8.58. Cybench and EnIGMA hit 50% at $49.34 and $21.06. The authors put it plainly:
higher spending does not consistently yield better outcomes
The agent, not the model budget, drove the spread. Of the 67 failed traces, OpenCode contributed none, Codex 7, Cybench 29 and EnIGMA 31. Codex's baseline sat at 80% success, 50% recall and $21.43 on the same 10 tasks, so it was neither the cheapest nor the most reliable. For anyone choosing a harness, that is a reminder that scaffolding differences can swamp the tuning you do on top of it.
The four tricks mostly traded success for savings#
The methods were AgentDiet (history compression), Revelio (hypothesis ranking), PAgent (coverage feedback) and CodeGraph (call-graph navigation). Across the 160 baseline-versus-method pairs, the paper counts 14 gains and 21 losses in success. Its conclusion: "no evaluated method reduces cost while preserving success across all four agents."
The accounting detail is the part I would steal. Codex with Revelio cost 0.61× the baseline if you only count the main model. Add the auxiliary calls and the total was 1.15×. A cheaper main loop with a hidden helper bill is a pattern I suspect shows up in plenty of sub-agent setups, where the cost dashboard watches the primary context and forgets the rest.
Read that as a warning about how these methods get evaluated. My guess, not the paper's claim: a trick that shaves tokens can also nudge the agent into a shorter, shallower search, and a shallower search fails the task. If a paper reports only cost, or only cost on the tasks that succeeded, you cannot see that trade. Reporting success next to cost, per pair, is what made this result visible.
The one thing that worked changed the interface, not the prompt#
The authors' own system, AVRI, gives the agent a persistent Bidirectional Evidence Trace: a structure that keeps what has been established about the code and the vulnerability, rather than leaving it in scrolling context. On 20 different tasks it behaved like this:
Codex (GPT-5.5): success flat at 85%, recall 65% to 75%, cost $132.65 to $108.75 (−18.0%).
OpenCode (DeepSeek-V4.1-Flash): success flat at 100%, recall flat at 90%, cost $4.38 to $3.34 (−23.7%).
It is the only evaluated method that cut cost for both agents without lowering either effectiveness metric. That fits the cost anatomy: if localization and understanding dominate, persistent evidence beats squeezing the transcript.
How far I would trust it#
Not all the way. Each configuration and task ran once, so method effects cannot be separated from run-to-run variance, which matters when the headline is a count of wins and losses. A single author coded the failure bottlenecks, with no independent review. There are no ablations of AVRI's pieces. Everything is C/C++ on one benchmark, and the model changes between the study (DeepSeek-V4-Pro) and the AVRI evaluation (DeepSeek-V4.1-Flash), with a model difference in the Codex comparisons too. The AVRI savings of 18 to 24% are suggestive, not settled.
One more caveat on scope: this is vulnerability discovery with an explicit fuzz-driver entry point and input-format guidance, no vulnerability description, patch or reference PoC. A feature-building agent working from a spec has a different shape, so treat the percentages as a prior to test in your own harness rather than a number to import.
Even so, the negative result is the useful one, because it is hard to explain away with noise: 121 of 160 pairs failed to keep success while lowering cost.
What I am changing#
First, I will measure total cost including every helper and sub-agent call before I call any optimization a win. Second, I will stop treating transcript compression as a default and look at what the agent re-reads instead. If it keeps rediscovering the same facts about a file, a durable notes structure is the better bet. My prediction is that the next round of agent efficiency work moves from shrinking context to persisting findings, and that the papers will report success rate next to cost, because cost alone is easy to win.