Agent cost per task: the formula and where it leaks

The cost per task of an agent is the sum of every call in the task, not the model price per token: ten steps with two retries are twelve prompts that pay for the context twelve times.

The formula in one line

node -e "const u={input:360000,output:9600,cached:0};const p={in:0.15,out:0.60,cache:0.003};const c=(u.input-u.cached)/1e6*p.in+u.cached/1e6*p.cache+u.output/1e6*p.out;console.log(c.toFixed(4),'USD per task')"

The command prints 0.0598 USD per task: 360,000 input tokens at $0.15 per million plus 9,600 output tokens at $0.60. The three terms never change: uncached input, cached input, output. The usage field of the API response carries the first two separately, and without that split the sum is off by an order of magnitude.

Four scenarios, same task

The cache-hit row assumes all input is cached: that is the ceiling of the discount, not the normal case. In practice part of the prompt changes on every step, so the saving sits between the two rows. The 1,000-task column multiplies the task cost: it shows how a difference of cents becomes an invoice.

Where the budget leaks

• Retries: every new attempt resends the whole context, so a retry does not cost a tenth of the task, it costs a full step.
• Tool output: a 20,000-token result stays in context for every later step and is paid for each time.
• Invalidated cache: a date or a randomly ordered list at the top of the prompt puts input back at full price.
• Verbose output: a model writing 2,000 tokens instead of 800 doubles the cheapest line, which is still not free.

Measure, do not estimate

The sum comes from logs, not quotes: for every call record model, input tokens, cached tokens, output tokens, step number and task id. In EneUI the mcp_call row carries the tool name and the plan, so cost is attributed to an account without rebuilding it from access logs. If telemetry has no task id, the customer pays an average and you cannot tell which feature costs.

Attribute and forecast

With a measured cost per task, the forecast is a multiplication: average cost per task times tasks per month, plus a share for the tasks that fail. An agent closing 70% of tasks on the first attempt has a cost per successful task above the cost per task, and the difference is exactly what you pay for errors. The procedure for choosing a model with that metric lives in another article; here the point is the running bill.

The limitation

List pages change and the real cache rate is not the one in the table: the two deepseek-flash rows are an upper and a lower bound, not two measurements. The sum ignores the human cost of review, which on a coding task can exceed the tokens, and it ignores waiting time, which is not free for the user. An honest bill keeps tokens, review and latency apart.

Where to continue

Choosing a model by cost per successful task is in evaluating a model for code, the arithmetic of price tiers in long context: real costs, the order of steps in orchestrating multi-step agents. The catalogue behind the examples is 111,985 components and 1,556 blocks; a record with a declared MIT licence upstream is dqnamo agent dock.