The token bill is the cost you can see, because the provider mails you an invoice for it every month. So that’s the number that gets optimized: people switch models, trim prompts, cache prefixes, and celebrate a 30% drop in spend. Meanwhile the same agent is holding a worker process open for ninety seconds per task, paging a human for one review in five, and polling a queue that’s empty 95% of the time — and none of that is on the invoice. For a surprising number of real workloads, the tokens are the cheapest thing the agent consumes.

This post is a checklist and a model. The checklist is the six axes an agent actually spends across. The model sums them into one number per task, so you can see which axis dominates your workload instead of assuming it’s the one with the invoice attached. My retry-budgets post worked out one axis — token cost under retry — in detail. This one zooms out to the other five.

The six axes

Here they are, roughly in the order people discover they exist:

  1. Tokens. Input (prefill) plus output, priced separately, multiplied by retries and context growth. The one with an invoice.
  2. Latency-as-cost. Wall-clock time isn’t free even when the compute is. A task that takes 90 seconds instead of 9 ties up a worker, delays a user, or misses an SLA. If a human is waiting on the result, latency converts directly into wages.
  3. Orchestration and infra. The queue, the worker pool, the state store, the vector database you query for retrieval, the egress on every tool call. This runs whether or not any agent is doing useful work.
  4. Tool-call fees. Every external API the agent calls may bill per request: search APIs, enrichment services, code execution sandboxes, other paid models. An agent that makes twelve tool calls per task can spend more on those than on the model driving them.
  5. Human-in-the-loop. Review, approval, correction, and the escalations the agent kicks up when it’s stuck. A human minute is the most expensive resource in the whole system by one to two orders of magnitude, and agents are very good at generating them.
  6. Idle and polling. The cost of being ready. Workers held warm, connections kept alive, queues polled on an interval. This scales with uptime, not with throughput, so it’s the cost that’s largest exactly when the agent is doing the least.

The trap is that axis 1 is the only one the provider itemizes for you, so it’s the only one that gets a budget. The other five are smeared across your cloud bill, your team’s calendar, and your latency dashboards, where nobody adds them up per task.

A model that sums all six

Same spirit as the retry-budgets model: deliberately small, all the numbers stated so you can swap in your own. It costs one task across all six axes and reports where the money goes.

# Per-task cost across six axes. All rates are illustrative — swap in yours.
N            = 8          # logical steps per task
TOK_IN       = 12_000     # total input tokens for the task (incl. context growth)
TOK_OUT      = 2_400      # total output tokens
IN_PRICE     = 3.0 / 1e6  # $/input token
OUT_PRICE    = 15.0 / 1e6 # $/output token

WALL_SECS    = 90         # wall-clock seconds per task
WORKER_RATE  = 0.06 / 3600     # $/sec to hold one worker (a small always-on box)
USER_WAIT_R  = 0.0             # $/sec if a paid human is blocked on the result

TOOL_CALLS   = 8          # external tool calls per task
TOOL_FEE     = 0.004      # $ per tool call (e.g. a search / enrichment API)

HUMAN_RATE   = 1.0        # fraction of tasks needing human review (0..1)
HUMAN_MINS   = 3          # minutes of review when it happens
HUMAN_COST_M = 75.0 / 60  # $/min for the reviewer

IDLE_SECS    = 0          # idle/polling seconds amortized onto each task

def dimension_cost():
    tokens = TOK_IN * IN_PRICE + TOK_OUT * OUT_PRICE
    latency = WALL_SECS * (WORKER_RATE + USER_WAIT_R)
    tools = TOOL_CALLS * TOOL_FEE
    human = HUMAN_RATE * HUMAN_MINS * HUMAN_COST_M
    idle = IDLE_SECS * WORKER_RATE
    return {"tokens": tokens, "latency": latency, "tools": tools,
            "human": human, "idle": idle}

d = dimension_cost()
total = sum(d.values())
for k, v in sorted(d.items(), key=lambda kv: -kv[1]):
    print(f"{k:8} ${v:7.4f}  {v/total*100:5.1f}%")
print(f"{'TOTAL':8} ${total:7.4f}")

With those defaults — a middling agent that needs a review on every task — you get:

human    $3.7500   97.3%
tokens   $0.0720    1.9%
tools    $0.0320    0.8%
latency  $0.0015    0.0%
idle     $0.0000    0.0%
TOTAL    $3.8555

The token bill is 1.9% of the per-task cost. You could cut it in half — switch models, gut the prompt, cache aggressively — and move the total by less than one percent. The whole cost of this workload is the human review. That’s not a knock on tokens; it’s a statement about where the leverage is, and it’s the opposite of where the invoice points you.

Now flip it. A fully autonomous agent that needs no review (HUMAN_RATE = 0), makes no paid tool calls (TOOL_FEE = 0), and blocks a paid human on its output (USER_WAIT_R = 40/3600, someone on a $40/hr wage waiting):

latency  $1.0015   93.3%
tokens   $0.0720    6.7%
...
TOTAL    $1.0735

Now latency is the whole cost, because a person is standing idle for ninety seconds per task. Making the agent 2× faster is worth vastly more than making it 2× cheaper in tokens. Same code, different deployment, completely different cost center — and in neither case is it the tokens.

Reading your own distribution

The point of the model isn’t the specific percentages; it’s that the dominant axis is a property of your deployment, not your agent. The same agent is a token-cost problem when it runs unattended overnight, a latency problem when a user waits on it live, and a human-cost problem when every output needs sign-off. Three deployments, three different things to optimize, one invoice that only ever shows you the first.

A few patterns that fall out once you’ve summed the axes:

  • Human review dominates almost everything it’s attached to. At $75/hr, three minutes of review costs more than fifty typical agent runs’ worth of tokens. If you’re paying for review on every task, your entire cost-reduction budget should go to reducing the review rate — better confidence signals, tighter autonomy on the easy cases — not to the model bill. (Getting the agent to fail loudly enough that a human only looks when it matters is its own discipline: predicting which runs will fail before you ship is where that starts.)
  • Latency is a cost multiplier the moment anything waits on the agent. An idle worker is cheap; an idle person is not. If your agent is in a human’s critical path, wall-clock time is priced at that human’s wage, and a slow-but-cheap model can be the expensive choice.
  • Tool fees scale with the agent’s chattiness, which retries amplify. Every retried step re-runs its tool calls. So retry overhead isn’t only a token story — it’s a tool-fee story too, and on a per-call-billed API the tool line can move faster than the token line when failure rates climb.
  • Idle cost is the one that’s biggest when you’re doing the least. A warm worker pool sized for peak load spends most of the night at 5% utilization, and that reserved capacity is real money amortized across very few tasks. It’s invisible per-task and enormous in aggregate.

What I’d actually do

  1. Sum all six before optimizing any one. Run the model with your real rates. The axis that dominates is almost never the one you assumed, and optimizing the wrong axis is worse than doing nothing because it feels like progress.
  2. Price latency in wages, not milliseconds, wherever a human waits. That single change reorders the whole table for interactive deployments.
  3. Attack the human-review rate, not the token cost, for supervised agents. It’s where 90%+ of the money is, and it’s a reliability problem more than a cost one — which is the whole reason failure modes and cost are the same subject told from two ends.
  4. Re-sum when you change deployment, not when you change the agent. Moving from overnight batch to live interactive doesn’t touch a line of agent code and completely relocates your cost. The invoice won’t warn you; the model will.

The token bill is the cost you can see. The reason to build the model is to stop optimizing the visible cost and start optimizing the dominant one — and to notice, more often than is comfortable, that they were never the same number.

The rates in this model are illustrative and stated so you can replace them with your own; the ratios (human review dwarfing tokens, latency priced in wages) are the durable part and transfer across providers. The token pricing ratio happens to match Anthropic’s at the time of writing.