How to Estimate an AI Agent's Cost Before It Starts Working

Before an agent starts, estimate its likely tokens, model cost, tool calls, retries, and human review time. A practical framework for budgeting agent work instead of finding out the cost after the fact.

Quick Answer

Before an AI agent starts a task, it’s worth estimating what it’s likely to cost: tokens, tool calls, the number of passes it will probably take, and how much human review the result will need. This isn’t about getting an exact number. It’s about having a low, expected, and high range so a task’s actual cost doesn’t come as a surprise, and so you can catch a runaway agent before it burns through a budget for nothing.

Why Agent Costs Are Hard to Predict

A single prompt to a chat model is fairly predictable: you can estimate input and output tokens and get a close cost figure. An agent is different. It’s a chain of steps, read context, form a plan, call a tool, check the result, maybe retry, maybe call another tool, and eventually produce an output. Each step adds tokens. If the agent hits an unexpected error or misunderstands the task, it can retry several times before either succeeding or getting stuck, and every one of those attempts costs something.

This is why a flat “price per token” figure understates real agent cost. The real question isn’t what a token costs, it’s what a finished, usable result costs, including the steps that don’t show up on the first pass.

Cost Per Token vs. Cost Per Completed Result

These are genuinely different numbers. A cheap model with a low per-token price can still be the more expensive option in practice if it needs three retries and heavy manual cleanup to produce something usable. A pricier model that solves the task cleanly in one pass, with no retries and minimal review, can be the cheaper choice overall. This is what cost per completed task actually measures, the total spend across every attempt it takes to get one accepted result, not the price of a single call.

When estimating, don’t just multiply tokens by price. Ask: how many attempts is this realistically going to take, and how much human time will it take to verify and fix the result.

Cheap Model vs. Cheap Workflow

It’s worth making this concrete with numbers, because the difference between a cheap model and a cheap workflow is exactly where estimates go wrong. Say Model A costs $0.05 per attempt but only succeeds on roughly one attempt in three, the other two need a retry before the result is usable. Model B costs $0.12 per attempt but succeeds immediately most of the time. Priced per attempt, Model A looks less than half the cost. Priced per accepted result, the picture flips: Model A’s real cost, counting the retries it typically needs, lands closer to $0.15 for one accepted output, more than Model B’s $0.12.

Model A had cheaper tokens and produced a more expensive workflow. This is exactly the distinction Cost per Completed Task is built to capture, and it’s the number worth estimating before a task starts, not just the sticker price of a single call. When you’re comparing models for a workflow, estimate both figures side by side: cost per attempt, and cost per accepted result once realistic retry rates are factored in. The cheaper-looking option on the first number is often not the cheaper option on the second.

The Components of Agent Cost

Context and input. What has to be loaded before the agent can start: relevant files, instructions, prior conversation, background documents. Larger context costs more per call, but too little context often causes more retries, which costs more overall.

Output. What the agent actually generates: code, text, a plan, a summary. Longer or more elaborate outputs cost more directly.

Tool calls. Each time the agent calls an external tool, a search, an API, a code execution, that has its own cost, separate from the model’s token price.

Number of turns. A multi-step agent doesn’t make one model call, it makes one per planning step, per tool result it needs to interpret, per check it runs on its own work. Even at a low per-token price, a task that takes fifteen turns instead of three costs roughly five times as much, and the turn count is usually the least predictable part of the whole estimate before the agent actually starts.

Context growth per turn. Turns aren’t uniformly priced across a session, and it’s worth budgeting for that instead of treating every turn as identical. Agents accumulate conversation history, search results, tool outputs, file contents, and logs as they work, and each new call typically has to carry that accumulated context forward. A turn near the end of a long agent run can cost meaningfully more than one near the start, purely because of what it’s now carrying, even though nothing about the per-token price changed.

Retry probability. Separate from the planned number of turns, agents fail and retry: a tool call errors out, generated code doesn’t pass a test, a search returns nothing useful, a verification step rejects the result. Budget for this explicitly rather than assuming the first attempt succeeds. A rough starting point: estimate the probability a step needs at least one retry, and add that probability’s worth of extra cost to your expected-case number, not just your worst case.

Model escalation. Some tasks start on a cheaper model and escalate to a stronger one when the cheap model can’t clear the bar, see Model Escalation. If your workflow includes an escalation path, budget for the probability it triggers, not just the cost of the cheap model succeeding on the first try.

Verification cost. Trusting agent output usually means checking it, and checking has its own cost: a critic model reviewing the work, a test suite actually running, a browser-based check or a screenshot comparison, source verification for anything making factual claims. This is often the most underestimated line item, because it’s easy to plan for the agent’s own tokens and forget the review step has a cost too.

Human review. The time a person spends checking, correcting, or approving the result. A human not typing doesn’t mean the work is free. Estimate this in real minutes or hours at a real hourly rate, the same way you’d estimate any other line item, not as an afterthought that happens “for free” because the AI did the typing.

A Conceptual Cost Formula

Estimated cost = context + output + tools + turns + retries + escalation + verification + human review

This is a planning model, not a precise universal billing formula. Actual pricing depends on your specific model, provider, and task. The point of writing it out this way is to force yourself to consider every component instead of only thinking about the model’s per-token rate. Two components are worth adding once you’re comfortable with the basic version: a caching discount, since stable context and repeated queries can meaningfully lower the context and retrieval cost on later calls (see How to Make Cheaper AI Models Work Smarter for how prompt, retrieval, and query caching work), and a probability buffer, covered next, which turns a single-scenario guess into a weighted estimate.

Building Low, Expected, and High Estimates

For any task worth estimating, sketch three scenarios:

• Low: the task goes cleanly, minimal context needed, no retries, light review.
• Expected: a typical run, some back-and-forth, one or two tool calls that need adjusting, a normal review pass.
• High: the agent hits friction, needs multiple retries, calls extra tools to recover, and needs a more thorough review before the result is trusted.

Having a range instead of a single number does two things: it sets honest expectations, and it gives you a trigger point, if actual cost is tracking toward the high end without a clear reason, that’s a signal to check in rather than let the agent keep going.

A Simple Way to Budget for Failure Probability

You don’t need sophisticated modeling to make your estimate more honest, just a rough breakdown of how likely each outcome is. Say a task has an 80% probability of succeeding on the first try, a 15% probability of needing one retry, and a 5% probability of needing escalation to a stronger model. Budget accordingly: mostly the low-cost, first-try scenario, a meaningful slice for one retry’s worth of extra cost, and a small slice for the more expensive escalation path.

Keep this simple. The goal isn’t a precise probability model, it’s forcing yourself to plan for the fact that not every run goes cleanly, before you’re surprised by an actual bill that reflects the 20% of runs that didn’t.

Cloud vs. Local: Different Cost Shapes, Not “Free vs. Paid”

Where an agent actually runs changes the shape of its cost, not just the size of it. A cloud-hosted model has a variable, usage-based cost: pay per token, per call, scaling directly with how much you run. A locally hosted model swaps that for a different set of costs entirely: the hardware itself, the electricity to run it, the setup time to get it working reliably, and the ongoing maintenance to keep it running as models and requirements change.

Don’t assume local automatically means free. It doesn’t, it means the cost moved from a per-use meter to an upfront and ongoing infrastructure cost, which is a better deal at high, predictable volume and a worse deal for occasional or unpredictable use. Estimate both shapes before assuming one is obviously cheaper for your situation, and see Frontier Open Models Explained for more on what running an open model yourself actually requires.

Matching Estimate Effort to Task Value

Not every task needs a formal estimate. A quick rewrite doesn’t need this process. A task that will run for a long time, touch a lot of files, call several paid tools, or feed into something high-stakes does. This pairs directly with effort routing: the more complex and costly a task’s failure mode, the more worth it becomes to estimate before committing resources. See Match the AI Agent to the Risk for that broader framework.

Budget Caps, Stop Conditions, and Approval Checkpoints

An estimate is only useful if you also act on it. Set a budget cap or step limit so a stuck agent fails safely instead of running indefinitely. Define a stop condition, what does “this isn’t working” look like, so the agent (or you) knows when to escalate rather than keep retrying. For higher-cost or higher-risk tasks, add an approval checkpoint partway through, not just a debrief after the fact.

A Copy-Paste Cost-Estimation Prompt

Before starting, estimate this task's likely cost: context/input size, expected output size, number of tool calls, expected turns, realistic retry probability, whether this task might escalate to a stronger model and how likely that is, verification cost (tests, critic review, source checks), and how much human review the result will need. Give a low, expected, and high range, and flag anything that could make this significantly more expensive than the average case.

Example Cost Scenarios

A short content rewrite: low context, one pass, no tool calls, quick human skim. Low cost, low variance, quick effort tier is fine.

A coding agent fixing a bug across a mid-sized codebase: moderate context (relevant files), a few tool calls (search, run tests), one or two likely retries if the first fix doesn’t pass tests, a real code review before merging. Moderate cost with real variance between the low and high estimate.

A research agent compiling a competitive analysis from multiple sources: larger context, several tool calls (search, fetch, summarize), a review pass to check sourcing and accuracy. Cost scales mostly with the number of sources and how much cross-checking the task demands.

Beginner Checklist

• Did I estimate context, output, tool calls, turns, retries, escalation, verification, and human review time separately, not just tokens?
• Do I have a low, expected, and high range, not a single guess?
• Did I budget for the probability of failure, not just the best-case run?
• Is there a budget cap or step limit so a stuck agent fails safely?
• Is there a clear stop condition and an approval checkpoint for anything costly or high-stakes?
• If this could run locally, did I compare the actual cost shape (hardware, electricity, maintenance) against the cloud alternative instead of assuming one is obviously cheaper?
• Am I tracking actual cost against the estimate, so next time’s estimate gets better?

Final Takeaway

Estimate the workflow, not just the model call. You don’t need a perfect number before an agent starts, you need a reasonable range across every real cost component, turns, retries, escalation, verification, human time, not just tokens, and a plan for what happens if reality tracks toward the expensive end of it. Estimating cost up front turns “find out what it cost after the fact” into “know roughly what to expect and catch problems early,” which is a meaningfully different, and cheaper, way to work with agents.

A lightweight worksheet covering the cost components above is enough for most teams. A full interactive cost calculator is a reasonable idea for later if estimating becomes frequent enough to justify the tooling, but it isn’t necessary to get the benefit of this process today.