Calculate Agent Cost per Completed Task

Count accepted outcomes, not just cheap runs

Define a completed task before measuring usage. Divide the cost of all attempts—including failures and retries—by the number of distinct tasks that meet that definition. Report cost per attempted run, task completion rate and cost per successful task together. Then add allocated seat costs for the same reporting period.

This is a documentation-based walkthrough and a proposed costing method, not a vendor benchmark. Account-level steps were not exercised by the publisher, and no account billing is claimed. Source-check date: 2026-09-16, using the sources linked in this guide. All worked-example inputs are invented; the arithmetic is not a measurement of any vendor.

1. Write the completion contract

Choose one task type and a checkable acceptance rule. A hypothetical invoice-extraction task might require every required field to match a reference record, pass schema validation and be accepted before a specified deadline. Producing a response would not, by itself, count as completion.

Before collecting a small sample of real runs, record:

• The input, required output and person or check that judges acceptance.
• Whether human correction is allowed. If so, label those results as assisted completions and record correction time.
• The maximum attempts and elapsed time allowed for each task.
• The included costs: model usage, separately charged tools, platform usage, seats, infrastructure and human work.

For this worksheet, a task is one distinct work item. An attempted run is one end-to-end execution toward completing it. A run can contain multiple model requests and tool-call round trips. An HTTP retry inside a run stays under that run ID; a fresh end-to-end attempt gets a new run ID but retains the task ID. Neither creates another distinct task.

If you need help defining acceptance and preserving representative work, use Build an Agent Regression Set Before Adoption. Here, the focus is assigning costs to those outcomes.

2. Instrument a sample you can inspect

Select real work across the sizes and difficulty levels you expect to deploy. Keep those categories separate in the report, include unsuccessful runs and do not extrapolate a monthly bill from a single run.

Prefer reported request-usage quantities over word-count estimates. Preserve raw records and document the mapping into worksheet columns. Do not assign zero cost to an error merely because its usage record is missing; mark the amount unresolved until it can be reconciled.

Anthropic documents total input tokens as the sum of cache_read_input_tokens, cache_creation_input_tokens and input_tokens. Source: Anthropic rate-limit documentation, read 2026-09-16. Use that provider-specific definition when mapping Claude records; do not assume similarly named fields from another provider have identical meanings.

3. Build a rate sheet, not a vendor price comparison

For every real rate you use, record the original pricing URL, date read, exact model or plan, currency, billing unit, processing mode, context band, region and applicable conditions. Normalize text-token rates to currency per one million tokens for the formula below; preserve non-token units in separate rows. An unavailable or unclear rate is an unresolved cell, not zero.

OpenAI's pricing table separates short- and long-context input, cached input, cache writes and output. Source: OpenAI pricing, read 2026-09-16. OpenAI also publishes a separate Batch pricing table. Source: OpenAI pricing, read 2026-09-16.

Interpretation for your worksheet: a headline input-token rate is not an effective price for an entire workflow. Apply these checks:

• Cache: price measured reads and writes separately. Do not assume every repeated prompt receives a discount, or add cached tokens to an input total that already includes them.
• Batch discounts: use the applicable batch rates only for eligible traffic actually assigned to that mode. Do not apply a blanket discount to all usage or assume the schedule meets your deadline.
• Output-heavy work: calculate input and output charges separately. In the formula, a low input rate cannot offset an arbitrarily large output charge.
• Growing context: if later requests include earlier messages or tool results, record each request's actual input and applicable context band. Do not multiply the first request's tokens by the number of turns.
• Tools: map call, session, storage and token charges separately. Do not count model tokens again if already included in request usage.
• Terms: keep the list-price estimate separate from documented credits, discounts, commitments, included usage and overages. Do not assume a subscription includes separately metered API usage.

Check tool-specific billing rules before summing tokens

OpenAI states that file-search tool-call pricing applies only to the Responses API. Source: OpenAI pricing, read 2026-09-16. For gpt-4o-mini and gpt-4.1-mini with the non-preview web search tool, OpenAI documents search-content billing as a fixed block of 8,000 input tokens per call. Source: OpenAI pricing, read 2026-09-16.

Interpretation: raw token totals alone are not a universal billing formula. Preserve reported usage, but add a separate billing-quantity mapping for product-specific rules. Check whether a charge is already represented before adding it; if the mapping is unclear, leave that component unresolved rather than inventing an invoice total.

For an organizational seat budget or a Claude API token estimate, obtain the applicable published organizational plan or API rate schedule before filling those cells. Do not substitute a personal subscription price for an organizational seat offer. The generic seat illustration below is not an Anthropic offer.

4. Calculate requests, runs and successful tasks

The following is a proposed accounting formula, not a promise about any vendor's invoice. Map the provider's billing categories first. Input categories must not overlap; split rows further when rates differ by model, context, mode or cache-write category. Add separate rows for charges outside this text-token model.

Request token cost =
  (uncached_input_tokens × uncached_input_rate
   + cache_read_tokens × cache_read_rate
   + cache_write_tokens × cache_write_rate
   + output_tokens × output_rate) / 1,000,000

Run variable cost = sum of request costs in that run
                  + separately charged tools and other usage

V = variable cost of ALL runs in the sample
A = number of attempted runs
N = number of distinct tasks attempted
S = number of distinct tasks accepted as complete

Cost per attempted run = V / A
Task completion rate = S / N
Attempts per successful task = A / S
Variable cost per successful task = V / S

Keep abandoned tasks and exhausted retries in N, and their costs in V. Count each accepted task only once in S. Report first-attempt completion and successful runs divided by all runs when useful for explaining retries; neither replaces S/N. Here, A/S includes attempts spent on tasks that never completed, not just attempts attached to successful tasks.

For a pilot, use a closed task cohort: select the work items, follow each to acceptance or the declared attempt/deadline limit, and include all associated costs. If some remain pending, label the result provisional and show their count and accrued costs separately. Do not divide costs from one cohort by completions from another.

When S is zero, cost per successful task is undefined. Report spend, attempts and zero completions, not a zero unit cost. When there were no attempts, do not report V/A as a measured run cost.

5. Worked example: half-price runs, higher completion cost

Everything in this worksheet is hypothetical. The model labels, dollar rates, token quantities, task count, retry behavior, successful outcomes and zero additional charges are invented inputs. No number represents a real vendor benchmark or an account charge.

A run = (10,000 × $1 + 2,000 × $5) / 1,000,000 = $0.02
B run = (10,000 × $2 + 2,000 × $10) / 1,000,000 = $0.04

A: 30 runs × $0.02 = $0.60 total variable cost
B: 10 runs × $0.04 = $0.40 total variable cost

A cost per successful task = $0.60 / 10 = $0.06
B cost per successful task = $0.40 / 10 = $0.04

Under these invented assumptions, A costs half as much per run but 50% more per completed task. Both workflows eventually complete every task; A requires three attempts per task. This illustration assumes identical token totals on every run, including failed runs. Replace that simplification with the sum of your actual request records.

6. Add the seat floor without double-counting

For the same reporting period, let F be the fixed seat and platform cost allocated to this workflow. Reserve the full cost of dedicated seats, or document a consistent allocation rule for shared seats and account for the remainder elsewhere. Keep allocated cost separate from the incremental cost of one additional task.

Provider-cost estimate per successful task = (V + F) / S

Fully loaded cost per successful task =
  (V + F + allocated infrastructure + human-work cost) / S

If usage is subscription-included under the applicable terms, do not add a hypothetical API charge to F as another invoice item. Include only separately payable usage or overages in V. Keep any notional API-equivalent cost in a separate analytical column.

Separate hypothetical seat illustration—all inputs are invented: five seats at $20 per seat per month, with the entire cost allocated to one workflow, create F = 5 × $20 = $100 per month. At an assumed 20 successful tasks in that month, the seat allocation alone is $100/20 = $5 per task. At an alternative assumed 1,000 successes, it is $100/1,000 = $0.10 per task. These are volume scenarios, not monthly forecasts or real plan prices. In this example, low utilization makes the seat floor dominate cheap variable usage.

Do not attach a full monthly seat bill to a short pilot sample and describe the result as a representative monthly unit cost. Either disclose that you are showing the pilot's full acquisition cost or use explicit monthly volume scenarios with a matching monthly allocation. For an annual commitment, distinguish cash paid from expense allocated to the reporting period.

Anthropic's pricing page says displayed prices exclude applicable tax. Source: Anthropic pricing, read 2026-09-16. State your tax treatment and currency assumptions rather than silently mixing gross and net costs.

7. Treat rate limits as a scheduling constraint

Anthropic measures Messages API rate limits in requests per minute, input tokens per minute and output tokens per minute for each model class. Source: Anthropic rate-limit documentation, read 2026-09-16. Anthropic describes its published limits as maximum allowed usage, not guaranteed minimums. Source: Anthropic rate-limit documentation, read 2026-09-16. Anthropic defines spend limits as a maximum monthly cost an organization can incur for API usage. Source: Anthropic rate-limit documentation, read 2026-09-16.

Budgeting interpretation: neither a throughput limit nor a spend ceiling is a token price. If throttling forces serialization while billed usage and processing mode stay unchanged, waiting does not itself add a token charge. Record the extra wall-clock time separately. Include any additional billable requests or time-metered resources that actually result; do not assume waiting is free across the whole deployment.

If waiting requires staff attention, allocate active human time in the fully loaded view, rather than charging every queue minute as labor. Check your applicable account limits against the measured request pattern separately from the cost calculation. A scenario that meets the budget but misses the acceptance deadline should not pass the deployment decision.

8. Publish a budget with an audit trail

1. Attach the completion contract, sampling window, task mix, retry policy and cohort-closing rule.
2. Show N, A and S alongside total variable cost, cost per attempted run, task completion rate and cost per successful task.
3. Show seat allocation, human-work assumptions, pending work, unresolved usage and excluded charges.
4. Build low-, expected- and high-volume scenarios from measured task categories and explicit workload assumptions—not one successful run multiplied into a month. For each category, estimate attempts and completions separately before summing costs and dividing by total expected completions.
5. Keep three views distinct: measured usage priced at list rates; an estimate adjusted for documented commercial terms; and reconciled effective cost supported by billing records. Do not label the first two as an observed invoice.
6. Re-read each applicable price page before budget approval. Preserve the rate-sheet version and source dates so later changes can be explained.

Limitations: this method does not establish future success rates, cache-hit rates, retry distributions, negotiated terms or invoice totals. A small sample is a starting estimate, not a guarantee. Preserve sample counts and show sensitivity to lower completion, more retries, longer context, higher output and lower seat utilization. If material billing quantities or plan terms remain unresolved, label the budget incomplete instead of presenting a precise total.

Prices change: Anthropic says prices and plans are subject to change at its discretion. Source: Anthropic pricing, read 2026-09-16. Re-read the original pricing pages rather than trusting figures in this article. Review this canonical guide monthly; next review due 2026-10-16. A changed pricing structure requires updating the rate mapping and method here, not a new dated post. This source check is not evidence of a newly announced change.

Sources

• OpenAI API pricing — source extract checked 2026-09-16; pricing categories, Batch table and tool-specific billing rules. platform.openai.com
• Anthropic pricing — source extract checked 2026-09-16; subscription pricing caveats. Not used here as an organizational seat or API rate schedule. anthropic.com
• Anthropic API rate limits — source extract checked 2026-09-16; input-token accounting, throughput units and spend limits. Not a price list. docs.anthropic.com