Agent Cost Per Completed Task: The Four Multipliers a Vendor Benchmark Never Shows

AWS says 45%% cheaper. Grok says cheap per token. But agent cost per completed task is set by four multipliers no vendor benchmark ever holds fixed.

A vendor told me last week that their agent was 45% cheaper. I asked cheaper per what. The answer was per token.

That is a numerator. Nobody's budget is denominated in tokens. Agent cost per completed task is the only unit a finance review can act on, and it is the one number the current wave of agent cost claims does not report.

Three things landed inside the same seven days, and read together they say something none of them says alone.

AWS open-sourced a coding agent built on its Strands harness and claimed it runs about 45% cheaper than Claude Code and Codex, attributing the advantage largely to token efficiency (The New Stack). xAI shipped Grok 4.7 with coding gains at unchanged per-token pricing, and the coverage immediately flagged that its token consumption threatens the real-world return. And a separate evaluation of the same model, engineered explicitly for hours-long autonomous work, found it still fails the majority of long-horizon tasks.

One of those is a cost claim, one is a pricing claim, and one is a completion rate. They are the same story told from three angles: price per token has stopped predicting spend.

Why does cost per token no longer predict the bill?

Because four things sit between the price you are quoted and the cost you are charged, and a benchmark holds all four fixed in a way your production stack never will. I have started calling the set the Task Cost Stack.

Turns: how many calls the loop takes before it stops

Turn count is a harness property, not a model property. The loop decides how many times to re-plan, how often to re-read, and what counts as done. In benchmark work comparing identical models across different scaffolds, token usage has been observed varying up to 70-fold. Same weights. Different code around them.

I wrote about the scoring half of this problem in harness engineering for enterprise agents. The cost half is worse, because a score is reported once and a token bill arrives every month.

Injection: retrieved context that is billed as input

This is the line item almost nobody separates. Recent work on exact cost attribution in multi-agent workflows (arXiv 2609.23790) isolates what the authors call memory injection: the retrieved context each agent node is handed, billed as input tokens, and indistinguishable from prompt tokens in standard observability.

On a 200-task enterprise benchmark it came to roughly 12% of billed cost. The more useful finding is that it scales with workflow depth, from 0% at depth one to 27.6% at depth six, growing near-linearly. It is also directly controllable: shrinking the retrieval window from 32 entries to 2 cut injected tokens by 28.7%, with the accuracy change inside seed noise.

A vendor benchmark runs at depth one or two. Your orchestrator runs at depth five or six.

Placement: which model runs which step

Tier selection is usually made once, for the whole workflow. But subtask complexity varies inside a single trajectory. A planning step may need a frontier model; a formatting step needs a small one.

Step-level routing work published this month (arXiv 2609.22951) put a 12M-parameter classifier in front of each step at under 5ms of overhead and reported a 72% cost reduction against frontier-only while retaining 97.3% of quality. Per-step versions of single-turn routers managed 31% and 44%, because single-turn training misses quality dependencies that only exist across a trajectory.

Placement is the multiplier most enterprise stacks have never touched. It is also the one with the largest published headroom.

Retries: the runs that did not finish

A failed run bills in full. If a long-horizon agent completes 40% of what you ask, your cost per finished task is 2.5 times your cost per run, and no benchmark that reports cost per run will tell you that.

This is why the Grok 4.7 stamina result matters more than the Grok 4.7 pricing result. Autonomy duration is a marketing number. Completion rate is a division problem.

Isn't this just FinOps with extra steps?

The objection is fair and I want to take it seriously, because cloud cost management has spent a decade learning that unit economics beat line-item totals. The difference is where the variance lives.

In a conventional cloud bill, the unit of work is stable and the price moves. You know what a request is; you are arguing about what a request should cost. In an agent workload, the price is the stable part and the unit of work is what moves. The same customer question can cost four calls or forty depending on how the loop was written, how much context got re-sent on each pass, which tier answered which step, and whether the run finished at all.

That inverts the standard playbook. Reserved capacity and rate negotiation address the stable term. The four multipliers above are the volatile term, and none of them appear on an invoice. They appear in a trace.

It also explains why the current benchmarks feel simultaneously honest and useless. They are honest about the term they measure and silent about the terms that dominate. A 45% token reduction measured on a shallow, high-completion benchmark is a real result about a workload that is not yours.

What should a buyer actually ask for?

Stack four multipliers and a 45% per-token advantage disappears inside the error bars. So the question I ask now is not about the model, the framework, or the benchmark. It is about the denominator.

The Finished-Task Test: take any agent cost claim and ask, cost per what? If the answer is per token, per call, or per run, you were handed a numerator and asked to imagine the rest.

Two numbers make the test pass: tasks attempted and tasks completed, on a workload that looks like yours. Every vendor has both. Almost none publish them, and the reason is not that the numbers are hard to produce.

None of this makes the AWS claim false. A token-efficient harness is a real advantage, and open-sourcing it is a real contribution. But "45% fewer tokens on our benchmark, in our harness, at our depth" and "45% cheaper for you" are different sentences, and only one of them is being said.

What I'd actually do this quarter

Pick one agent already running in production and instrument the four multipliers for a single week.

Turns. Log calls per completed task. Not average calls per run, which hides the failures.
Injection. Separate retrieved-context tokens from prompt tokens in your billing view. If you cannot, that is the finding.
Placement. Count how many distinct model tiers appear in one trajectory. If the answer is one, you have not started.
Retries. Divide tasks completed by tasks attempted, over the whole week, including the ones a human quietly restarted.

Then compute one number: total spend divided by tasks completed. That is your baseline, and it is the only figure against which any vendor claim can be evaluated.

Most teams I ask cannot produce it today. That is not a tooling gap. It is the reason the cost conversation in this category is still being run on numerators.

Part of the enterprise agentic AI reality pillar guide, which maps the four layers no benchmark measures: the scoreboard, the runtime, the denominator and the verifier.