Where the tokens go: what VBW 1 saved, and how we counted

Run a team of AI agents and a surprising share of the bill is not the work. It is the team. Loading instructions. Passing context around. Re-explaining where things stand. Recovering after the conversation gets compacted and forgets.

We call it coordination overhead. Shrinking it is what VBW 1 was built for.

The numbers

Compared with stock Claude Code Agent Teams, per the latest analysis in the VBW repository (VBW 1.30.0):

Tokens	Stock	VBW 1.30.0	Less
Spawn and context, per phase	87,100	26,535	70%
All coordination, one phase	97,900	29,885	69%
All coordination, five phases	4,809,500	1,289,425	73%

Roughly a third of the overhead remains, and two thirds is gone.

How it got there

No single trick. Five habits, applied everywhere, all with one idea underneath: the model should read only what it needs, and a program should do everything a program can.

Load on demand, not on every request. A plugin’s commands normally sit in the model’s context for the whole session. VBW switches most of them off until you run them, so only 7 of its 24 commands were loaded on every request in the analysis. Moving the largest command, vibe, to on-demand cut per-request overhead by another 17%.
Let shell do the thinking that is not thinking. Detecting what phase a project is in, working out the next step, routing, checking: these are if statements, not reasoning. VBW runs 85 scripts as ordinary bash, at zero model tokens. Pre-computing the project state alone saved about 1,100 tokens every time a command ran.
Give each agent only what its role needs. Before, every agent loaded the same project files. Now a small script compiles one context file per role. A planner sees the 5 requirements mapped to its phase, not all 30. A builder skips the status file it never used. That routing work, together with trimming redundant loads, cut spawn and context overhead by 40% to 50% in the analysis.
Stop saying the same thing twice. Shared references are loaded once and lazily, not copied into every agent. Cutting the duplicates saved about 1,600 tokens each time an agent started.
Pass notes on disk, not in chat. Agents hand work to each other through files with fixed shapes, instead of long message exchanges that every one of them then has to read.

Two more levers sit around the edges. Per-role budgets cap how much context any agent is given, and smart routing skips agents a small job does not need. And cheaper models go to the roles that do not need the best one, which saves money rather than tokens, so it is not in the table above.

The per-mechanism figures come from the early analyses and are mostly high confidence, with a few marked medium in the reports. They add up to the table. They do not add up to a promise about your project, which depends on its size and how you work.

How we counted

This is a calculation, not a benchmark, and the difference matters.

We counted the lines of every file that gets loaded into the model, at about 15 tokens per line of markdown.
We separated what loads on every request from what loads only on demand.
We assumed 80 requests per phase.
Shell scripts, config, hooks and tests cost zero model tokens, because they run outside the model. That is the design: push work out of the model wherever a program can do it.
The stock baseline comes from an earlier analysis of Agent Teams and is carried forward.

How sure are we? Line counts are exact. The per-request arithmetic is high confidence. The request count and the stock baseline are medium. The full method, with a confidence label on every row, is in the report.

What it is not: an end-to-end run, and a judgement of how good the output was.

Why you may have seen 86%

The VBW README has quoted 86% for a while. That was the high point of the analysis at v1.10.7. Later releases added enforcement content so agents behave better, and that costs tokens: every analysis since v1.20 lands between 69% and 77%, and the latest, at v1.30.0, reads 69% to 73%.

We would rather show you the figure that went down than the one that looked best.

The analysis behind these figures covers VBW 1.30.0. Later VBW 1 releases have not been re-analysed.

What a smaller bill does not tell you

Saving tokens is only worth it if the work is still right. A tool that saves 70% by doing less has saved nothing.

That is where VBW 2 starts. Read the preview.