Your AI agent's real cost is cost per accepted task

A team compares two models on price per million tokens and picks the cheaper one. A month later, the bill is lower but the workflow costs more. The cheaper model needs more retries, produces more drafts that a person must repair, and fails more often on the cases that matter.

Token price is an input, not the cost. The operating number is cost per accepted task: what the team spends to produce one outcome that meets the acceptance rule without rework.

Token price is not the cost

A single AI task can consume:

• input tokens, including retrieved context and tool results;
• output tokens, including retries and rejected drafts;
• tool calls with their own fees;
• human review minutes;
• recovery time for failures and duplicates;
• infrastructure for orchestration, logging, and storage.

A model that is 40% cheaper per token can be more expensive per accepted task if it increases any of the other buckets. The comparison only becomes useful when all buckets share a denominator: accepted outcomes.

Define “accepted”

“Accepted” must be a property, not a feeling. For a support triage workflow, it might mean:

• the queue is correct;
• the urgency is correct;
• the missing-information question is present when needed;
• no customer commitment appears;
• a reviewer does not need to rewrite the output.

A task that is generated but rejected is not accepted. A task that is accepted after ten minutes of repair is accepted, but the repair time belongs in the cost. A task that is never reviewed is not “free”; it is unmeasured.

Write the acceptance rule before calculating cost. Otherwise the team will optimize the denominator by calling more outputs “accepted.”

The equation

Use a simple monthly model:

Cost per accepted task = (model + tools + retries + human review + failure recovery + infrastructure) / accepted tasks

Each bucket needs a unit and an owner:

Bucket	Unit	Example source
Model	Input/output tokens × price	Provider billing export
Tools	Calls × unit price	Tool vendor invoice
Retries	Extra model/tool calls	Orchestration logs
Human review	Minutes × loaded hourly cost	Review queue export
Failure recovery	Minutes + external fees	Incident/repair log
Infrastructure	Monthly run rate / tasks	Hosting and observability bill

Do not allocate the entire engineering salary to the workflow. Use the review and recovery time that actually changes when the workflow changes. The goal is a decision number, not an accounting standard.

Example: support triage cost per accepted ticket

An illustrative run processes 1,000 tickets in a month. The team’s acceptance rule is the five-part triage rule above. Seven hundred tickets pass without repair; 200 pass after a short edit; 100 are rejected and routed manually.

The monthly cost:

• model and tools: $420;
• retries: $60;
• human review: 40 hours × $30 = $1,200;
• failure recovery: 6 hours × $30 = $180;
• infrastructure: $140.

Total: $2,000. Accepted tasks: 900 (700 clean + 200 repaired). Cost per accepted task: about $2.22.

The token bill is only 21% of the total. A 30% token discount saves $126; a 20% reduction in review time saves $240. The review queue is the larger lever. The example is illustrative, but the structure is the point: measure the buckets that move.

Counterexample: the cheaper model that raised review cost

A second team switches to a model with a lower token price. The new model is slightly less consistent on mixed-intent tickets. Reviewers spend more time correcting queue labels and missing-information questions.

The token bill falls by $90. Review time rises by 12 hours, or $360. The cost per accepted task rises even though the “AI cost” fell.

The team almost missed it because the dashboard reported model spend, not review spend. The fix was not to switch back immediately. It added a per-slice review-minute metric and a rule: any model change that increases review minutes by more than the token saving must be re-evaluated on quality, not price.

What to measure monthly

A small operating dashboard is enough:

• cost per accepted task, split by task slice;
• accepted-without-repair rate;
• review minutes per accepted task;
• retry rate and retry cost;
• failure recovery minutes;
• false-accept rate from sampled review;
• model/tool price changes.

The dashboard should answer three questions: Is the workflow getting cheaper per useful outcome? Is the saving coming from quality? Which slice is driving the cost?

Do not report a single average across slices. A cheap easy slice can hide an expensive edge case. The refund or eligibility slice is often where review and recovery costs concentrate.

How to reduce cost without hiding quality

Cheapest-first, in order:

1. Reduce rejected drafts. Better acceptance criteria and context reduce retries and review. This is usually the largest saving.
2. Route by difficulty. Send routine cases to a cheaper model or a deterministic path; reserve the stronger model for ambiguous or high-stakes cases.
3. Cache reusable prefixes. Measure cache hits and accepted-task impact, not just latency.
4. Cap retries. A retry that cannot change the outcome is pure cost. Use a per-operation limit and a clear stop.
5. Improve the review interface. Show the evidence, the diff, and the policy version on one screen. Faster review is a real cost reduction.
6. Batch non-urgent work. Batching can reduce overhead, but only if the user deadline allows it.

Do not “reduce cost” by removing human review from a workflow that has not earned autonomy. That moves cost into errors, which are more expensive and harder to measure.

Boundary

This model fits workflows with a stable acceptance rule and a review step: triage, extraction, policy answers, draft generation, approval preparation. It does not fit open-ended creative work, research exploration, or tasks where “accepted” cannot be defined. It is not a full cost-accounting method; it is a decision tool for comparing models, prompts, and operating designs. If the team cannot measure review minutes or accepted outcomes, start with a one-week sample before trusting a monthly number.