Key facts.
- WebArena measured the best agent at about 14% on realistic web tasks against roughly 78% for humans, so high-volume web-style work produces constant retries and escalations, each billed. source
- GAIA found GPT-4 with plugins around 15% versus about 92% for humans on realistic assistant tasks, so the support-style queries a high-volume agent handles include many it cannot complete in one pass. source
- OSWorld reported the best models near 12% versus about 72% for humans on real computer tasks, reinforcing that data-processing workflows spanning multiple apps are far from one-shot reliable. source
Why does volume multiply consumption instead of just adding to it?
Because the per-task cost is not a single number, it is a number times a retry factor times a context factor, and volume scales the product. In a support queue, each ticket may take several agent turns, each turn carries the growing conversation as context, and a meaningful share of tickets fail the first attempt and retry, as the WebArena and GAIA gaps imply. At a hundred test tickets, the waste is a rounding error. At a million production tickets, the same per-ticket waste is the budget. Data processing is the same story: a job that touches multiple systems retries on the ones it gets wrong, and OSWorld shows it gets a lot wrong, so the real token count is the clean estimate inflated by the failure and context factors.
The trap is that high volume is precisely where teams feel most confident, because the per-task cost looks tiny. But a tiny number multiplied by a huge one is a huge number, and the multiplier is the failure and context overhead the test never triggered. The estimate that survives is the one built on realistic per-task consumption, not the best-case single run.
How do you estimate high-volume consumption honestly?
Measure the real per-task token count on a representative sample, including the multi-turn conversations and the context they carry, not a single clean call. Apply a retry factor from the measured first-pass success rate, which the benchmarks suggest is well below one on realistic tasks. Then multiply by true production volume, including peak. The result is usually several times the naive estimate, and it is the number that lets you decide whether the high-volume use case is actually economical before you have committed to it. Narrowing the task to raise the success rate is often the highest-impact cost move, because it shrinks the retry factor that volume multiplies.
| Estimate input | Naive | Honest at volume |
|---|---|---|
| Per-task tokens | One clean call | Multi-turn plus carried context |
| Retry factor | 1.0 assumed | From measured success rate |
| Volume | Average | True production incl. peak |
| Result | Looks tiny per task | Several times the estimate |
The Pattern Intelligence Layer is where per-task consumption, the retry factor, and context carry are measured and held steady, so a high-volume estimate reflects how the agent actually runs. Reliability at the pattern level is what keeps a million-task deployment inside the budget it was approved on, instead of discovering the multiplier after the first full month.
Frequently asked questions
High volume is our best case. Why would it cost more?
Because volume multiplies per-task overhead. A small retry or context cost that was invisible in testing becomes the dominant line item across millions of tasks.
What is the multiplier we keep missing?
The retry factor. Benchmarks like WebArena and GAIA show realistic first-pass success is low, so the real token count is the clean estimate times a retry overhead.
What lowers high-volume cost most?
Narrowing the task to raise first-pass success. It shrinks the retry factor that volume multiplies, which beats a per-token price cut.