# AI agent cost beyond the vendor price

> Compare AI agent cost across per-seat, per-task, per-outcome, and token pricing, then model the real total with labor, failures, and tools.

AI agent cost is rarely the number printed on a pricing page. That number tells you how the vendor meters one part of the service. It does not tell you what a resolved support case, reviewed pull request, qualified lead, or reconciled invoice will cost after retries, human review, integrations, and failures.

I have seen founders choose the cheapest looking meter and end up with the most expensive operating model. A seat plan sat idle because only two people trusted the agent. A task plan charged again every time the agent retried. A token plan looked cheap until long context windows and tool calls multiplied the bill. The useful comparison starts with a business unit and works backward to the vendor charge.

## Unit cost comes before the pricing model

Pick the unit of useful work before comparing plans. If the agent handles customer support, that unit might be a case resolved without reopening within seven days. If it reviews code, count a pull request that reaches a human decision, not every review run. If it researches accounts, count an accepted account brief, not a generated document.

This sounds obvious, yet pricing sheets encourage the opposite behavior. They give you seats, tasks, runs, credits, and tokens because those units are easy for the vendor to meter. Your company earns money or saves labor through outcomes. The two units need a conversion rate.

Write one sentence that defines success and one that defines failure. For example: "A completed invoice extraction has all required fields, passes validation, and enters the accounting queue once." A duplicate, an incomplete record, a rejected record, and a run that requires manual reentry all fail. That definition stops a vendor from calling a technically completed run a successful task.

Then track three denominators, because one ratio hides too much:

- Cost per attempted unit shows demand and raw consumption.
- Cost per technically completed unit exposes run failures.
- Cost per accepted business unit includes quality and human review.
- Cost per dollar of benefit tests whether the automation deserves to exist.

AWS Well-Architected Cost Optimization guidance recommends allocating workload cost through usage metrics or business outcomes. I agree with the outcome part, but hourly allocation alone does not solve agent accounting. Agent work often crosses an hour boundary, retries asynchronously, and calls several services. You need a durable work ID that follows the job through the whole path.

A sensible comparison therefore starts with `work_id`, `outcome`, and `accepted_at`, then attaches every vendor charge and labor event to that record. Without that join, procurement compares price cards while engineering pays for behavior nobody can explain.

## Per seat pricing buys access, not completed work

Per seat pricing works when a stable group uses the agent often and usage varies within a reasonable band. It gives finance a predictable subscription and frees users from thinking about a meter every time they ask for help. It also makes a poor proxy for value when adoption is uneven.

The basic equation is simple:

```text
monthly seat cost = paid seats x price per seat
cost per accepted unit = monthly seat cost / accepted units
```

The dangerous variable is not seat price. It is accepted units per paid seat. A ten seat plan used heavily by two people has the same invoice as a ten seat plan used by everyone, but its unit economics can be several times worse. Login counts do not fix this. A curious login is not productive use.

Seat plans fit coding assistants, research tools, and internal copilots when named people use them throughout the day. They fit poorly when work arrives in a shared queue, seasonal staff rotate, or an automated process runs without a clear human owner. Ask how the vendor handles contractors, service accounts, reassignment, inactive users, and simultaneous use. Those details decide whether the plan stays predictable.

Model a seat plan at three adoption levels. Use your current active users, a conservative case, and a high adoption case. For each level, estimate accepted work, review minutes, and any included usage limit. An "unlimited" plan may still have fair use controls, rate limits, model restrictions, or a separate charge for premium operations. Put those limits in the model as capacity constraints, not footnotes.

The right negotiation target is often flexibility rather than a lower seat price. Monthly reassignment, a small pool for occasional users, and visibility into active use can save more than a headline discount tied to an annual commitment. Do not buy seats for the org chart. Buy them for a measured workflow.

## Per task pricing depends on who defines a task

Per task pricing works when a task has an unambiguous boundary, similar resource demand, and a result you can verify automatically. It fails when the vendor's billable event is smaller than the business job or when one failed job creates several billed attempts.

Suppose an agent processes a supplier invoice. Is one task the uploaded file, each page, every extracted field, each validation attempt, or the final accounting record? All are defensible technical events. Only one maps cleanly to the business outcome. The contract and telemetry must name the same event.

Ask the vendor to walk through five cases: a successful first attempt, a retry after a timeout, a user correction, a duplicate submission, and a task abandoned after partial work. For each case, write down how many tasks appear on the invoice. If the answer depends on internal implementation you cannot observe, the price is not truly per task from your perspective.

Task pricing is attractive because it matches a queue. It also lets departments allocate spend more easily than a shared token bill. The weakness is variance inside the unit. A two sentence email and a forty page contract might both count as one task while consuming very different resources. Vendors respond with task classes, credits, size bands, or overage rules. Each addition makes the meter harder to audit.

Use a billable task ratio:

```text
billable task ratio = billed tasks / accepted business units
effective task price = total task charges / accepted business units
```

If the ratio drifts upward, investigate retries, user behavior, and changed task definitions before blaming volume. A price of $0.20 per task with a ratio of 1.8 costs $0.36 per accepted unit before review and integration. The advertised price remains true while the buyer's assumption fails.

Per task pricing is a good middle ground for document processing, scheduled research, content moderation queues, and other repeatable work. Demand idempotency support, stable task identifiers, and a downloadable usage record. Otherwise a billing dispute becomes a debate between screenshots.

## Per outcome pricing transfers risk only on paper

Per outcome pricing can align the vendor with business value, but only when both sides can observe acceptance, attribute the result, and limit disputes. The phrase sounds clean because it hides the hard work in the definition of outcome.

A support vendor might charge for a resolved conversation. Your team may care whether the customer returns, escalates, receives a refund, or gives up. A sales agent might charge for a booked meeting, while you care whether the prospect attends and fits the target profile. The vendor will prefer an event close to its system. You will prefer an event closer to revenue or saved labor. The contract must bridge that gap.

Outcome pricing does transfer some execution risk. Failed runs that never become billable outcomes can sit with the vendor. Yet buyers often take back the risk through minimum commitments, broad acceptance rules, exclusion clauses, and data quality obligations. Read the commercial schedule and the definition schedule together.

Set an acceptance window and a dispute mechanism. Decide which system records the final state, how corrections work, and what happens when a human changes the result after acceptance. Include a sample calculation using real edge cases. If two reasonable people can calculate different invoices from the same event log, the definition is not ready.

Outcome plans also need a value ceiling. Paying $20 for an outcome that saves $8 makes no sense even if the agent succeeds perfectly. Estimate gross benefit per accepted unit, subtract human handling and downstream costs, then set a maximum vendor charge that leaves enough margin for uncertainty. Do not price from the vendor's cost plus markup. Price from your retained value.

This model suits narrow workflows where quality has an objective test and the vendor controls enough of the path to own the result. It suits regulated or judgment heavy decisions less well because a person still carries accountability. In those cases, the honest outcome might be "case prepared for review" rather than "case approved."

## Token pass through exposes usage and hides the system

Token pass through works for technical teams that can control prompts, model routing, context, and retries. It gives the buyer a direct view of model consumption. It does not make the total agent cost transparent by itself.

An agent may use input tokens, cached input, output tokens, and reasoning tokens. It can call a search service, run code, store files, query a database, or invoke another model. The provider may add a platform fee or apply a markup to the underlying model price. A token ledger that omits tool charges and orchestration still shows only one layer.

OpenAI's API documentation, for example, reports input tokens, cached tokens, output tokens, and reasoning tokens in usage details for supported endpoints. That breakdown is useful because the categories can carry different rates or explain unexpected behavior. It does not tell you whether the generated answer was accepted, how many retries occurred, or how long a reviewer spent fixing it. Your application has to join usage to the work outcome.

Token cost should be calculated per model call and then rolled up by work ID:

```text
call cost =
  input_tokens x input_rate
  + cached_tokens x cached_input_rate
  + output_tokens x output_rate
  + tool_charges

accepted unit cost = sum(call cost for work_id) / accepted outcome
```

Check the vendor's convention carefully. Some usage records include cached tokens inside total input tokens, so subtracting or adding them incorrectly causes double counting. Reasoning tokens may appear inside output token details rather than as a separate billable line. Your ledger should preserve the raw vendor fields and calculate normalized fields separately.

Long context is the usual budget leak. Teams keep appending conversation history, tool results, policy text, and retrieved documents because removing context feels risky. Each follow-up sends much of that material again unless caching or prompt design reduces it. Put a context budget on each workflow and log the cause when a run exceeds it.

Token pass through gives engineering the strongest optimization controls. Smaller models can handle classification, cached prefixes can reduce repeated input cost, and asynchronous batch processing can suit work without an immediate deadline. Those savings require measurement and maintenance. A finance team that wants a fixed unit price may reasonably reject the operational burden.

## Total cost has more than one invoice

Total cost includes the agent vendor, model and tool consumption, integration work, human review, failure handling, and ongoing operations. Leaving any of these out biases the comparison toward the plan that moves costs off its own invoice.

Use this monthly model:

```text
TCO = fixed_fees
    + usage_charges
    + integration_amortization
    + review_hours x loaded_hourly_cost
    + exception_hours x loaded_hourly_cost
    + operations_hours x loaded_hourly_cost
    + expected_failure_loss
```

Fixed fees include seats, platform subscriptions, minimum commitments, and support tiers. Usage charges include tasks, outcomes, tokens, model calls, tools, storage, and data transfer. Integration amortization spreads setup work over a realistic decision period. Do not spread it over three years if you expect the workflow or vendor to change in six months.

Human review deserves its own line. Measure minutes spent reviewing accepted work separately from minutes spent rescuing failed work. The first may be a permanent control. The second should fall as the system improves. Combining them lets a recurring defect hide inside a legitimate approval process.

Expected failure loss covers more than rerun cost. A bad answer can create a refund, a missed deadline, duplicated outreach, or rework in another department. Do not invent a grand risk number. List observable failure types, estimate frequency from a pilot, and attach a conservative cost only where you have evidence.

Opportunity cost belongs in the decision, but keep it outside the vendor unit comparison. If one option launches a quarter earlier, speed may justify a higher operating price. AWS guidance explicitly notes that optimizing for market speed can sometimes beat spending more time on the lowest cost deployment. Record that trade as a management choice so it does not masquerade as cheap infrastructure.

FOCUS, the FinOps Open Cost and Usage Specification, makes another useful distinction. List Cost reflects published unit prices, while Effective Cost spreads discounts and applicable prepaid purchases across usage. For agent buying, compare offers on an effective basis. A discounted annual commitment is not cheaper in the months when unused capacity expires; allocation should make that idle portion visible.

## A small model beats a polished forecast

A useful model needs scenarios and measured ratios, not a detailed forecast built on guessed adoption. Start with one workflow and calculate low, expected, and high monthly volume. Keep the acceptance rate, retry rate, review time, and unit price as separate inputs.

Consider an invoice extraction agent with the following assumed month. The numbers illustrate the method; they are not a market benchmark.

- 10,000 submitted invoices and an 85 percent acceptance rate
- 1.2 billed tasks per submission under the task plan
- 900,000 tokens per 100 submissions under token pass through
- 300 reviewer hours at a loaded cost of $60 per hour
- $4,000 in monthly amortized integration and operations cost

Assume a task offer at $0.40 per billed task, an outcome offer at $1.10 per accepted invoice, and a token route averaging $6 per million tokens after model mix and caching. Assume the seat offer costs $500 for each of 15 seats. These invented offers exist only to show the arithmetic.

The vendor charges would be $7,500 for seats, $4,800 for tasks, $9,350 for outcomes, and $540 for tokens. Human review adds $18,000 to every option if the workflow behaves identically. Integration and operations add $4,000. The resulting monthly totals are $29,500, $26,800, $31,350, and $22,540.

Those totals do not prove token pricing wins. They reveal the assumptions that could reverse the result. If token usage triples on long documents, token cost rises. If the outcome vendor improves acceptance enough to cut review time, its higher charge can pay for itself. If seat users handle other workflows, allocating the full subscription to invoice extraction overstates its cost.

Put the model in a table with inputs on the left and plan formulas on the right. Then change one variable at a time. Find the break-even review time, task ratio, accepted volume, and token consumption. A decision is safer when you know exactly what must go wrong before another plan wins.

Track actual events with a record that looks like this:

```json
{"work_id":"inv_10482","pricing_model":"per_task","attempts":2,"billed_tasks":2,"input_tokens":18420,"output_tokens":1260,"tool_cost":0.03,"review_minutes":4.5,"outcome":"accepted","vendor_charge":0.80}
```

One record should not replace raw vendor logs. It is the normalized join between technical usage, invoice data, labor, and outcome. Reconcile the sum of `vendor_charge` to the bill, then calculate accepted unit cost from the same dataset. That gives engineering and finance one argument they can actually resolve.

## Hybrid pricing splits risk more honestly

Hybrid pricing is often the most defensible choice because agent costs contain both reserved capacity and variable work. A base platform fee plus usage can fund the vendor's fixed service while keeping growth tied to consumption. A seat allowance with task overages can fit a human team that also runs shared queues. An outcome fee with a volume minimum can work if the minimum matches proven demand.

The danger is stacking meters. Some offers combine a platform fee, seats, credits, token pass through, tool markups, premium model surcharges, and support. Each line can have a rationale, but the combined invoice becomes hard to predict and nearly impossible to attribute. Count how many independent variables can increase the bill. More than two deserves strong telemetry and a real reason.

Negotiate a risk collar around uncertain usage. A monthly floor gives the vendor commitment; a ceiling protects the buyer during a runaway loop or demand spike. The agreement can trigger a review near the ceiling instead of silently continuing at overage rates. A ceiling is not useful if essential work simply stops, so define graceful degradation, approval, or fallback behavior.

Credits require special attention. Ask what one credit represents, whether conversion rates differ by model or feature, when credits expire, and whether the vendor can change conversion. Treat credits like an internal currency whose exchange table belongs in the contract. If you cannot map credits to observable consumption, you cannot forecast them.

Volume tiers can also distort marginal cost. A lower rate above a threshold helps only if the lower rate applies to enough volume and the commitment does not force waste. Model the full bill just below and just above every tier. Procurement sometimes celebrates a cheaper unit while total spend rises because the company bought demand it did not have.

Choose a hybrid when it mirrors how the service actually incurs cost and how your workflow creates value. Reject it when it merely bundles every available meter into one proposal.

## Contract terms decide whether the model survives

The pricing schedule must define the billable event, data source, retry treatment, credits, overages, and change process. A clear spreadsheet cannot protect you from a vague contract.

Require a usage export at the granularity needed to reproduce the invoice. It should include a stable event or work identifier, timestamp, meter name, quantity, rate, and charge. For outcome pricing, add acceptance state and correction events. For token pricing, preserve model and usage categories. Aggregated monthly totals are insufficient because they cannot explain a spike.

Write down how these cases are billed:

- Vendor caused retries, timeouts, and duplicate events
- Customer corrections and reopened outcomes
- Test, staging, and evaluation traffic
- Failed tool calls and partial completions
- Suspended service during a spend review

Add notice for rate changes, model substitutions, task definition changes, and credit conversion changes. A vendor may improve its model while changing latency or cost behavior. You need the right to test the change before it becomes the default for a controlled workflow.

Commitment terms should match evidence. An annual discount makes sense after a pilot shows stable volume, acceptance, and review labor. Before that, the discount is payment for optimism. Include ramp periods or quarterly resizing if adoption depends on teams you do not control.

Set a reconciliation routine before signing. Finance should match charges to the vendor invoice, while the workflow owner matches billable units to accepted work. Investigate both absolute variance and unit cost variance. A flat bill can hide declining usage; a growing bill can be healthy if accepted outcomes grow faster.

Security, compliance, and data retention may change the price even when they are not billing units. Private networking, regional processing, audit logs, or a higher support tier can sit behind enterprise packaging. Treat them as requirements before comparing plans. A cheap plan that cannot meet a hard requirement is not a candidate.

## Choose the meter your team can control

Choose per seat when people are the stable capacity unit, per task when work has a clean boundary, per outcome when acceptance is objective, and token pass through when your team can operate the full technical cost loop. Choose a hybrid when fixed capacity and variable demand are both real. There is no universally cheapest meter.

Score each option on economic fit, predictability, observability, control, and switching cost. Economic fit asks whether the billing unit follows your accepted work. Predictability asks how far actual bills can move from the forecast. Observability asks whether you can reproduce a charge. Control asks whether your team can change the cost driver. Switching cost covers data, workflow, training, and contract commitment.

Do not average those scores blindly. A regulated workflow may require observability even if another plan looks cheaper. A cash constrained startup may put a hard limit on monthly variance. A mature platform team may accept variance because it can optimize tokens and routing every week.

Run a paid pilot long enough to include ordinary failures, not only a scripted happy path. Capture accepted units, retries, review time, exception time, and vendor charges by work ID. Recalculate every proposal with those measured ratios. Vendors should compete on your dataset, not on separate examples designed around their preferred meter.

Keep the pilot comparison operationally fair. Give each option the same input set, quality threshold, review policy, and failure definition. If one vendor receives cleaned documents while another receives raw uploads, the resulting unit costs describe different jobs. Record exclusions as carefully as successes. A workflow that handles only the easy sixty percent may still help, but its price cannot be compared with a service that owns the entire queue. Also separate learning period costs from steady operation. Early prompt changes and integration debugging belong in implementation, while recurring review and exception work belong in the ongoing unit cost.

For founders who do not have clean workflow data or a shared view between finance and engineering, the Team & AI Audit from oleg.is is a five business day, fixed $5,000 engagement that identifies at least $50,000 a year in savings or it is free. The useful output in this context is not a generic AI plan; it is a cost baseline that shows which work deserves automation and which pricing risk your team can carry.

The decision should end with an owner and a review threshold. Name who watches unit cost, what variance triggers investigation, and when the team can change models or plans. AI agent pricing will keep changing. A durable work ID, an accepted outcome, and a reconciled cost record let your company change with it without restarting the argument.