The "winning" arm of my agent A/B-test was lying: 56k tokens on the surface, 205,800 more hidden in sub-agents it spawned silently
I was running a fairly boring A/B: does a persistent code graph actually save a coding agent tokens compared to plain grep? Two identical clones of an unfamiliar 2,125-file repo (NestJS), identical prompts, same model, full telemetry. Arm A gets the graph, arm B doesn't.
On the "understand the HTTP request lifecycle end-to-end" task, top-line telemetry said arm B - the one WITHOUT the graph - won: 56k tokens vs 76k. I almost wrote that down as the result.
Then I opened its transcripts.
Arm B had silently spawned 5 sub-agents and burned 205,800 tokens inside them. None of that showed up in the top-line number. True cost: ~262k tokens - 3.5× the arm it was supposedly beating.
That's the finding I actually care about, because it's not about code graphs: "agent with tool X vs agent without" comparisons systematically undercount the arm that quietly delegates. Modern agents fan out sub-agents on their own initiative, and if your harness only reports the top-level session, your benchmark measures politeness, not cost. An honest benchmark counts the whole agent tree. I suspect a lot of published "our tool saves N%" numbers don't.
Since you're here, the actual A/B results, whole-tree accounting, by task class:
- Impact analysis ("who consumes ModuleRef, what breaks if get() changes?") - parity: 71.4k vs 71.9k. Grep on a literal symbol name is cheap even at 2,125 files; the graph's win is −16% tool calls and indirect edges, not tokens.
- Subsystem understanding - the graph won big: 75.9k vs ~262k. −71%, measured. Mechanism below.
- Full repo audit - parity again: ≈445k vs ≈500k (nested costs estimated, labeled as such). Fan-out is needed either way; the graph improves partitioning, not price.
So the marketing-style "N% savings" number doesn't exist as a universal multiplier. There are classes of tasks: on one the saving is dramatic and real, on the others it's zero.
And the −71% itself isn't what tool marketing implies either. Graph queries aren't "cheaper than grep" - the graph is a local CLI (Graphify: open source, tree-sitter, built the index for 2,125 files in seconds), it spends zero tokens either way. The saving came from corpus narrowing: the graph scoped the subsystem instantly, so ONE agent answered what forced the graph-less arm to unfold FIVE. The real economics of agent tooling is orchestration you no longer need, not cheaper calls.
Two rules that made the graph usable at all (an index is a cache, and caches lie): the graph points but never testifies - every fact needs a live file behind it, verified by reading ±30 lines around the candidate, or verification eats what the graph saved; and a freshness gate first - index build time vs last commit, stale means say so and downgrade trust.
Honest limitations before you roast me: n=1 per cell (no variance), one repo, one model tier, two of six cells have estimated (labeled) nested costs, and the arms chose their own strategies - by design (I'm measuring the system, not the query planner), but it mixes "graph" with "the decision not to orchestrate". Poke holes.
Does your harness even expose nested sub-agent costs? And has anyone re-checked a vendor benchmark with whole-tree accounting — curious if the pattern holds beyond my n=1.
Posted Jul 4, 2026, 6:25 PM UTC