The API costs $20 a month. Your agent doesn't.

The estimate is right. It prices the wrong thing.

A public teardown that circulates among founders adds up a retrieval agent line by line: hosting at $8.50 a month, a model at $0.40 per million input tokens and $1.60 per million output, a vector database, a reranker. The total lands under twenty dollars a month. We checked the arithmetic. It holds.

It holds for one request that works the first time. Everything that keeps the agent working sits outside the sum: checking whether the answers are right, retries and failed runs, re-indexing when the documents change, monitoring, the person who reviews output, and any assumption about volume. That gap is the difference between the price list and the invoice. In our view it is most of the invoice.

So here is the answer before the proof: stop pricing the call and price the completed task. The number to quote, budget and watch is what one job costs to actually finish, including the runs that had to happen twice.

The proof is in other people's invoices

You get variance, not a unit price. A platform-engineering write-up on agent reliability finds that the same agent interaction can cost $0.02 or $2.00, depending on whether it falls into a retry loop. The same piece finds that multi-turn agents reach 4x the token cost by turn 30, with no gain in quality.

Budgets that ran out. At Uber, Claude Code use went from 32% to 84% of 5,000 engineers, at $500 to $2,000 per engineer per month, and the whole year's AI budget was gone by April. LangChain, writing in July 2026: "Uber blew through their full 2026 AI budget in 4 months." The same LangChain post opens with a startup whose coding-agent bill grew 6x in two quarters.

Nobody owned it. A professional-services firm budgeted £400k for an AI document-review programme and spent £1.2m. The post-mortem found that no one owned the context architecture.

Cockroach Labs names the unit all three stories point to: "the relevant unit is no longer cost per prompt, but cost per completed task." An agentic workflow makes 10 to 20 model calls where a chatbot made one.

Where the money goes

There are three mechanics. None of them raises an error.

1. The agent re-reads everything, every turn

Stanford Digital Economy Lab's cost-attribution work, as cited by Cockroach Labs, puts re-sent context at 62% of agent inference bills. Before each action the agent sends the original prompt and its history again. The history only grows, and all of it gets billed again.

turn 1:   system + task                          -> billed
turn 2:   system + task + turn 1                 -> billed again
turn 3:   system + task + turn 1 + turn 2        -> billed again
...
turn 30:  system + task + 29 turns of history    -> billed again

2. One line switches the cache off

Prompt caching works on an exact prefix match. If anything near the start of the request changes, you lose the discount on everything after it. The common advice to put the current date in the system prompt does exactly that. One practitioner's public cost model puts the price of that single line at 7.8x over an 80-turn session. That is one person's model, not an audited benchmark. The mechanism behind it is not in question. Per-user details at the top of the prompt, like name, plan or mode, break the cache the same way.

# volatile line first: the prefix changes on every call, the cache never hits
system = f"Current time: {now()}\n" + INSTRUCTIONS + TOOL_DEFINITIONS

# stable prefix first, volatile detail last: the cached part stays identical
system = INSTRUCTIONS + TOOL_DEFINITIONS
turn   = f"{user_message}\n\n(current time: {now()})"

The second shape is our suggestion, not something the sources prescribe.

This happens to real users. In a public issue on the open-source agent OpenClaw, a routine update moved the cost per call from $0.01–0.08 to $0.04–0.51. Three of the last five logged calls cost about half a dollar each and produced zero output tokens. Nothing errored. The agent did what it was supposed to do and cost several times more.

3. A retry buys the work again

This one happened to us. One of our automations calls a paid video-generation API, and the work is charged when it starts. The client library's default timeout gave up at 10 minutes, while the render took 18. The job came back, couldn't see what it had already paid for, and paid for it again. The log even recorded the timeout as the model refusing.

The question that found it: does your attempt counter count money spent, or function invocations? Ours counted invocations. Since the fix, it counts paid launches only, and the receipt is written before the wait:

start:
  job_id = provider.create(request)
  save(job_id)                  # receipt persisted before waiting
  paid_attempts += 1

resume:
  status = provider.get(saved_job_id)
  ready             -> take the result          (no new charge, no new attempt)
  still running     -> keep waiting
  failed / unknown  -> clear the trace, start over   (paid, and counted)

That counter is our cost per completed task, in a form a script can read.

The check you can run tonight

1. Pull last week's usage from your model provider.
2. Sum cache-read tokens and cache-write tokens.
3. Reads should dominate. If writes keep pace with reads,
   something at the top of your prompt changes on every call.
4. Count paid runs per finished task. Anything above 1.0 is the loop.

Step 2 is the audit the cache research points to. Steps 3 and 4 are how we read it.

What would change our mind: if cache reads dominate and paid runs per finished task sit near one, your price list is close to your bill. In that case the twenty-dollar estimate is fine for you, and we would say so.

FAQ

Is the $20-a-month estimate wrong? No. The arithmetic is correct for a single request that succeeds. It leaves out evaluation, retries and failed runs, re-indexing, monitoring, human review and volume, and those are the parts that decide the bill.

What exactly is cost per completed task? It is everything you paid (calls, retries, failed runs, review, re-indexing, monitoring) divided by the tasks that actually finished. Cockroach Labs calls it the relevant unit because an agentic workflow makes 10 to 20 model calls where a chatbot made one.

Do longer agent sessions at least give better answers? Not by default. The platform-engineering write-up found multi-turn agents at 4x the token cost by turn 30 with no gain in quality.

How would I know the cache broke? You won't get an alert. In the OpenClaw issue there was no error and the output didn't get worse. Only the price per call changed. Compare cache-read and cache-write tokens every week.

Who should own this? A named person. In the £400k-to-£1.2m document-review overrun, the post-mortem found no owner for context architecture. Our view: whoever owns the prompt prefix owns the cache, and whoever owns the retry policy owns the second purchase.

Related case

We also made a thirty-second version of this argument, as a two-person sketch: {{anchor_url}}

For a product built around keeping the model out of the loop where it doesn't belong, see Holt. Its rule is "math owns the schedule, AI owns the content": the engine that decides what a learner sees next never calls a model. We read that as a cost decision as much as a quality one. The case is at iloblique.com/holt, and you can try it at holt.iloblique.com.