An agent budget needs more than a model's token price. A task can involve several calls, growing context, tool fees, retries, and human review. The useful estimate starts with the whole run and ends with the work that actually passed review.
Count the loop, not just the answer
Tool results become input on later model calls if they remain in context. A large API response can therefore cost more than once. Retries can add another attempt, while parallel agents may each process the same material. Trimming tool output and limiting unnecessary steps can change the bill without changing the model.
Do not assume every step carries the full transcript at the same rate. Context compaction can shorten it; prompt caching can discount eligible repeated input. Check the provider's usage records rather than estimating from the final answer's length.
A worked estimate
Consider an illustrative support-triage workload with 1,000 submitted tasks per day. These are assumed rates, not a vendor quote or production measurement. Each attempt uses 20,000 uncached input tokens in total across its model calls, plus 2,000 output tokens. Assume $2 per million input tokens and $8 per million output tokens.
- Input per attempt: 20,000 / 1,000,000 × $2 = $0.040.
- Output per attempt: 2,000 / 1,000,000 × $8 = $0.016.
- Model cost per attempt: $0.056.
- If 20% of tasks need exactly one extra attempt of the same size, that is 1,200 attempts per day: $67.20 in model spend.
Suppose tools and hosting add $12 per day. Human review takes one minute on 100 tasks, at an assumed loaded labor rate of $36 per hour: another $60. Total daily cost is $139.20.
If 900 of the original 1,000 tasks ultimately finish and pass review, cost per completed task is $139.20 / 900 = about $0.155. At this workload for 30 days, the operating estimate is $4,176. That excludes development, evaluation work, and fixed vendor commitments; add those separately when budgeting the feature.
What changes the estimate?
Completion rate belongs in the denominator. Failed work still spends money, and an apparently cheap model can lose its advantage if it needs more retries or review. Compare models on the same tasks with the same acceptance criteria.
In this example, halving input tokens saves $24 per day across 1,200 attempts, assuming quality stays unchanged. Halving review time saves $30. That gives the team two experiments to measure instead of a vague instruction to use fewer tokens. Neither saving is worth it if more errors reach users.
Build the estimate around observable quantities
Before launch, record expected task volume, model calls per attempt, input and output tokens, extra attempts, tool charges, review minutes, and accepted completions. Keep input and output rates separate. If caching is part of the plan, price cached input separately and test whether the workload actually produces cache hits.
After launch, measure those same quantities by feature and customer. Track the expensive tail as well as the median; a few looping tasks can consume a budget that looked comfortable on average. Set per-run spending limits and a defined handoff when they are reached.
Keep the assumptions beside the measured values. When the bill changes, that comparison should show whether traffic grew, tool output got larger, or the workflow started needing more help.
If this is the kind of problem your team is working through, I am always glad to compare notes.