VibeMind · The receipts
Every number VibeMind publishes traces back to a run we actually did. This page is the full record: what we measured, exactly what the numbers were, and the one caveat that keeps each one honest. We publish only what we ran, so where you see a gap, it means we have not tested that yet and we say nothing about it.
Every number below comes from one pile of real, paid-for runs.
Nothing here is a marketing estimate. We ran the same coding work through different setups, paid the real bill, and audited the logs. Where a result is an average, it is the middle of five runs on real open-source code, not a best-case cherry-pick, and the few single-run anchors are labeled as such.
A task was real work, not a toy.
This matters for reading the calculator on the front page: when it asks how many tasks you do a day, here is the size of task we measured, so you can size its slider against your own work.
Most of our runs used real small features, the kind of change you actually ship: each one took roughly three minutes of agent working time on a 24,000-line open-source codebase. On top of that, we ran one larger feature that took about sixteen minutes in a single long session, to see whether the story holds when the work gets heavier.
So when you set the front-page calculator to, say, six tasks a day, picture six real features of that size. If your own tasks run longer than three minutes, the time you get back grows, not shrinks.
The same three tasks, run three ways, side by side.
We gave the same batch of three real features to three setups and measured what each one cost. The reader takeaway is simple: isolated lanes finish in under half the wall time of one long chat, at about the same token count, and they make far fewer tool errors than throwing several sessions at one shared copy of the code.
| How the work was run | Wall time | Output tokens | Dollars | Tool errors |
|---|---|---|---|---|
| One long chatall three tasks in one session, in a row | 547 s | 38,185 | $1.50 | 9 |
| Naive shared checkoutseveral sessions on one copy of the code | 302 s | 44,996 | $2.26 | 28 |
| Isolated lanesVibeMindeach session in its own copy of the code | 259 s | 39,078 | $1.89 | 17 |
Medium repo, 24,000 lines, sonnet coder. Each number is the middle result of five runs. The machine was shared, so the exact wall-clock seconds are directional; the ratios between the setups are what hold.
The row that costs you is the middle one. Opening several sessions on a single shared copy of the code was the most expensive setup we measured, and it made the most tool errors (28, against 17 for isolated lanes), because the sessions kept stepping on each other's changes to the same files. Isolated lanes avoid that by construction: each lane works in its own copy and owns a separate set of files, so that particular collision cannot happen in the first place. On dollars, isolated lanes came in about 16 percent under that naive shared-checkout run, the one comparison where running organized is measurably cheaper on the bill.
The technical detail
On a bigger feature, the gap gets wider, not narrower.
The story above holds on small tasks. To check the heavier end, we ran that one sixteen-minute feature two ways: in a single long session, and in an isolated lane. Here is what changed.
On the small tasks, the dollar premium for running organized was larger and the token counts were about even. On this heavier feature, the isolated lane pulled ahead on every axis: it finished about three times faster, used about 36 percent fewer tokens than the one-long-session run, and the dollar premium shrank to 8 percent. This is a single measured run each way, stated as such, so treat it as one solid data point rather than a five-run average.
The technical detail
The organizing itself is nearly free to run.
A fair question: all these lanes and merges and memory, do they quietly eat the savings? We timed the machinery's own footprint. It is small enough to round off.
So the machinery is cheap to run: about a hundredth of the wall clock, mostly cache reads, and never once stopped by a plan limit. The expensive thing was never the structure. It was the disorganized default that most people already reach for: several sessions colliding on one folder, the setup that topped the cost table above.
The technical detail
Even a top model will not organize the work on its own.
If the best setup is isolated lanes, why not just let a smart model choose it? We tested exactly that. We handed the whole job to the model and watched what it picked.
Across nine runs, spanning three quality tiers of model (including the strongest), not one chose to run the work in parallel isolated lanes on its own. Every run reached for the slow, single-track shape by default. None split the work into lanes. None handed the cheaper parts to a cheaper worker.
Every run still finished the work correctly. The gap was not reliability, it was strategy: left to its own judgment, even the strongest model reached for a slower, less efficient shape. That is the job VibeMind's lane machinery does. The good strategy does not appear on its own, so the machine encodes it.
The technical detail
We wrote down the answer before we ran the test.
Before we ran the final benchmark, we wrote the cost model's prediction to a file with a timestamp. Then we ran the test. Here is what it predicted, next to what actually happened.
The prediction landed within 8 percent on all three measurements. That is why the calculator on the front page is an instrument, not an illustration: it is the same cost model, and we have shown it can predict a run it had never seen.
Honest scope, in one sentence: this was a prediction made between two points we had already measured, not beyond them, so the model is proven on the range it was tested on and we do not stretch it further.
The technical detail
The gaps are on purpose. We only claim what we tested.
A page like this is only worth reading if it also tells you where it stops. So here is the honest edge of the data.
- We publish only what we ran. Small-repo and large-repo shared-checkout comparisons were not run, so we make no claims there.
- The larger feature is a single run each way. It is a strong data point, not a five-run average, and we label it that way.
- The cost model is proven between the points we measured, not beyond them. We do not stretch it across repo size, task complexity, or coder tier.
- Wall-clock seconds come from a shared machine, so treat them as directional. The ratios between setups are the durable part.
- We make no quality-degradation claim and no cheaper-worker economics claim beyond the specific numbers shown above.
If a number is not on this page, we did not measure it, and we would rather leave the space blank than fill it with a guess. That is the whole point of the receipts.