How much does an AI agent actually cost?

An AI agent's cost depends on the work it attempts, the resources it uses and how much checking the result needs. Model charges are one part of the bill. Tool subscriptions, execution, storage, unsuccessful attempts and human attention can matter just as much.

For a company choosing whether to adopt an agent, the useful unit is a completed piece of work that meets an agreed standard. A low cost per model request can still produce an expensive workflow if many requests lead to results that people must redo.

This article builds a cost model around one recurring task, then shows how to adapt it. Every amount in the example is illustrative. The model rates are assumptions for the calculation, not quotations from a provider or estimates of Swarm pricing.

First define what the company is buying

Imagine an operations team that monitors changes announced by the software vendors it relies on. The team wants an agent to prepare an impact note for each relevant notice: what changed, which service may be affected, what evidence supports that assessment and who should examine it next.

A completed note must pass a review against the original announcement and the team's current service inventory. A draft that merely paraphrases the vendor's message does not meet the requirement. Neither does a plausible impact assessment that identifies the wrong product edition.

Use that acceptance rule before estimating cost. It determines the evidence the agent must read, the tools it needs and the effort required from a reviewer. It also gives the team a denominator: the number of distinct notes accepted, with repeated attempts grouped under the same notice.

The FinOps Foundation's unit economics guidance distinguishes technical consumption measures from units connected to business activity. Both are useful. Token counts help explain consumption; accepted work helps explain what that consumption achieved.

Build the bill in layers

Start with direct model usage. For a model priced by tokens, record the billed categories and applicable rates. Input, output and cached input may have different prices. Some services introduce other billing units or include allowances inside a subscription.

For a simple model with two token categories, the calculation is:

Model cost = input tokens / 1,000,000 * input rate + output tokens / 1,000,000 * output rate

Use provider billing definitions when applying this to a real service. Do not add a token category twice because it appears in both a usage breakdown and a total. If several models participate, calculate each under its own rates and then reconcile the sum with the bill.

Next add the tools and environment. Paid searches, document processing, remote browser sessions, a runtime that stays available between jobs, storage and monitoring can all have separate costs. Shared subscriptions need an explicit allocation method if several workflows use them.

Human work belongs in a separate, visible layer. Record preparation, review and correction effort using an agreed planning rate. That is a capacity cost; it does not mean that every minute saved turns into a cash saving or that an existing salary disappears.

The FinOps Foundation's AI tooling guidance describes how individual agent requests can involve multiple model calls and why operational tooling belongs in the cost assessment. The exact composition depends on the application. An agent that reads three short records and an agent that searches a large changing source collection will behave differently.

A monthly example with every assumption visible

Suppose the vendor monitoring workflow receives 120 distinct notices in a month. It makes 420 model calls in total, including retries and further investigation. Across those calls, billed usage is 4.8 million input tokens and 0.6 million output tokens.

Assume an input rate of $2 per million tokens and an output rate of $8 per million tokens. These round values make the arithmetic easy to inspect; replace them with the rates and billing categories that apply to your service.

The reviewer accepts 96 notes. The other 24 remain unresolved or need work outside the workflow. They still consumed resources, so their costs stay in the numerator. A later revision to one of the accepted notes does not create another completed unit.

The technical cost is $60 divided by 96, approximately $0.63 per accepted note. Including review effort, the figure becomes $420 divided by 96, approximately $4.38. Report the acceptance rate, 80%, alongside either number.

These figures describe different things. The first helps explain the technology bill. The second helps a manager understand the operating effort associated with usable work. Neither establishes that the workflow is cheaper than the process it replaces.

If building the workflow required $2,400 of setup effort, a team might spread that planning cost across 12 months at an assumed stable workload. That adds $200 a month, producing a planning total of $620, or approximately $6.46 per accepted note. The choice of allocation period is an assumption, not an accounting rule or a prediction that the workflow will remain useful for a year.

Keep failed work attached to its original request

A retry is another attempt to satisfy the same request. Counting it as a new task makes unit costs look better while obscuring reliability.

Assign each incoming notice an identifier. Associate its model calls, tool use and review outcome with that identifier. Record why an attempt stopped: an unavailable source, insufficient access, unsupported content, a system failure or a rejected result.

Also distinguish useful abstention from a broken workflow. A note that correctly identifies missing evidence can protect the team from an unsupported recommendation. It may be a valuable result, but it belongs in a defined category. Decide whether the purchased unit is an accepted assessment, an accepted recommendation or a correctly triaged notice, then apply that definition consistently.

Our guide to LLM evaluation explains how to establish result criteria. Cost comparisons depend on those criteria remaining stable. A configuration can appear more efficient simply because its reviewer has begun accepting weaker evidence.

Late corrections matter as well. If a note is accepted and later withdrawn, update the outcome for its original reporting group. Avoid silently leaving the original success count in place while recording correction costs in an unrelated month.

What did the agent achieve for that cost?

For repeatable work with an automatic acceptance check, teams can compare verified results against the resources consumed. A structured extraction task checked against fixed test records is one example.

Inference Work Units (IWU), an open research proposal from Swarm Research, measures verified outcomes relative to a declared reference system. Its score uses a fixed automatic verifier and the reference's success rate for each kind of task. Successful outcomes contribute positively; unsuccessful outcomes subtract from the total. This adds a reference point to the question of what the spending achieved.

For a separate illustrative test, suppose the fixed reference succeeds on 50% of a particular task type. Under IWU, each accepted episode contributes one unit and each rejected episode subtracts one. Eighty accepted episodes and twenty rejected episodes produce 60 IWU. If their total measured cost is $10, the result is 6 IWU per dollar.

Include the resources consumed by every retry under its original episode and score the final outcome once. Compare system configurations using the same workload, verifier and reference, with each configuration recorded explicitly. Calculate efficiency from total IWU divided by total cost across the complete experiment.

The vendor notes above rely on human review, so their acceptance count is not an IWU score. Keep cost per accepted result as the practical business measure; IWU offers an additional way to investigate efficiency when the work has a reliable automatic check.

Where an optimization can make a difference

In this example, cutting input token use in half saves $4.80 for the month, assuming the same rate and unchanged results. Reducing review from three minutes to two minutes per incoming notice would release two hours of capacity, valued at $120 under the stated planning rate.

That comparison is not a reason to rush review. It identifies a question to test: could clearer evidence references and a better comparison with the service inventory reduce review effort without losing material findings?

Test an improvement on comparable notices. Keep the acceptance standard, reviewer instructions and source access consistent. Examine the cases that become harder, such as a vendor announcing several changes in one document or withdrawing a previous notice.

Caching, narrower retrieval and choosing a smaller model for a bounded step can reduce consumption. Their effect on the complete workflow needs measurement. A cheaper first attempt may lead to more repeated investigation; a useful cached result may cease to apply after the source changes.

Record quality, latency and review effort alongside cost. A longer processing time may be acceptable for a weekly impact review, while a time critical response would have different requirements. The useful comparison follows the responsibility the workflow serves.

A worksheet the team can reuse

Before starting a pilot, write down the following fields. Fill in estimates first, then preserve the observed values separately as the pilot runs.

Track maintenance as it occurs. A new vendor format, an access change or a model update can create work that the original estimate missed. Keep that work visible even when another team performs it.

For a comparison with the existing process, choose a common scope and quality standard. Include the time people already spend checking sources and handling exceptions. Keep the benefits specific: a smaller review burden, earlier identification of relevant changes or more complete coverage. Avoid converting uncertain benefits into a precise return figure.

Connect usage to an inspectable work record

In Swarm, a Task describes a responsibility and a Run records an attempt to carry it out. Teams can keep the resulting Artifacts and review decisions alongside their shared project context. That gives a cost investigation a concrete piece of work to follow.

Use available execution records and recorded telemetry to investigate the attempt, then reconcile charges with the services that issued them. Human review time and external subscriptions may need their own records. Missing measurements should remain visible in the calculation.

Our article on AI observability covers the relationship between execution evidence and result review. The connection guide describes how authorized agents can contribute to a Space from compatible tools.

A useful answer has a denominator

The honest answer to the cost question is a range tied to a defined responsibility. The work, quality threshold, volume and operating environment determine whether a given setup is economical.

Begin with a small measured workload. Keep unsuccessful attempts in the calculation, separate technology charges from human effort, and show the assumptions behind allocations. A company can then judge what an agent costs to produce something it can actually use.