AI business case for Claude: cost per task 2026

TL;DR

A defensible AI business case for Claude prices one task, not one department. Take the real token counts, apply current prices, add caching, then compare against the loaded cost of the hours the task consumes today. Most use cases that fail this test fail by an order of magnitude, which makes the portfolio decision easy rather than political.

Why price a task and not a department?

Pricing a task gives you a number you can verify in a week. Pricing a department gives you a number nobody can falsify, which is why those numbers survive in slide decks and die in procurement. A task has a measurable input size, a measurable output size, a measurable volume per month, and a measurable human cost today.

The arithmetic is simple enough to do in a spreadsheet, and that is the point. Four inputs: input tokens per task, output tokens per task, tasks per month, and the loaded hourly cost of the person doing it now. Everything else is a rate lookup.

The two mistakes that wreck most business cases:

1. Counting the saved hours as cash. Freed capacity is not a cost reduction unless somebody actually leaves or a hire does not happen. Write it as capacity, and let the business owner decide whether it converts.
2. Pricing against the wrong model. A triage task priced on Opus looks terrible and priced on Haiku looks free. The model choice is part of the business case, not an implementation detail.

What does a task cost at current prices?

Take a document triage task with 8,000 input tokens and 1,500 output tokens. At current list prices the same task ranges from about 0.0016 USD on Haiku 5.5 to about 0.155 USD on Fable 5.1, a factor of 100. The model choice moves the business case further than anything else you can decide.

Prices from the model pricing page, with our arithmetic for the example task:

Model	Input per MTok	Output per MTok	Cost per task	20,000 tasks per month
Claude Haiku 5.5	0.10 USD	0.50 USD	0.0016 USD	31 USD
Claude Sonnet 5.5	2 USD	10 USD	0.031 USD	620 USD
Claude Opus 5.5	4 USD	20 USD	0.062 USD	1,240 USD
Claude Fable 5.1	10 USD	50 USD	0.155 USD	3,100 USD

Set that against the human side. If the task takes 12 minutes and the loaded cost of the person is 60 EUR per hour, the task costs 12 EUR today. At 20,000 tasks per month that is 240,000 EUR of effort per month. The Sonnet 5.5 line is 620 USD. This is the shape of nearly every well-chosen document use case: the token cost is a rounding error and the real question is quality and review effort, not price.

That also tells you which use cases to cut. When the token cost lands within an order of magnitude of the human cost, the use case is wrong: either the model is too large, the prompt is carrying too much context, or the task is not repetitive enough to automate. Our Sonnet versus Opus comparison works through which workloads justify the larger model.

Which four adjustments change the number materially?

Four adjustments move a Claude cost model by more than 10 percent each: prompt caching downward, the newer tokenizer upward, regional endpoints upward, and batch processing downward. Apply all four before presenting a figure, because reviewers will find them later.

Prompt caching, downward. If 6,000 of the 8,000 input tokens are a stable prefix, cache reads on Sonnet 5.5 cost 0.10 USD per million rather than 2 USD. The task drops from 0.031 USD to about 0.0196 USD, roughly 37 percent lower, and 20,000 tasks fall from 620 USD to about 392 USD. The write costs 2.50 USD per million once per cache lifetime, so caching pays off whenever the prefix is reused more than a couple of times. Our Claude prompt caching guide covers what invalidates a cached prefix.

The tokenizer, upward. Claude 4.7 and later models use a newer tokenizer that produces approximately 30 percent more tokens for the same text, while Sonnet 4.6 and earlier use the previous one. A model built on token counts measured against Sonnet 4.6 understates Sonnet 5.5 by about a third: the example task becomes roughly 10,400 input and 1,950 output tokens, so 0.031 USD becomes about 0.040 USD. Re-measure on the model you will actually run.

Residency, upward. Regional and multi-region endpoints carry a 10 percent premium over global endpoints for Claude Sonnet 4.5, Haiku 4.5, Opus 4.5 and later models. On the first-party API, US-only inference through inference_geo is priced at 1.1x the standard rate across input, output, cache writes and cache reads. If the use case touches personal data and needs an EU region, add the 10 percent before anyone sees the figure.

Batch, downward. Amazon Bedrock offers select models, including Anthropic’s, for batch inference at a 50 percent lower price than on-demand. For any use case that does not need a response within seconds, that halves the line. Nightly document processing and backfills belong here.

Combined, on the example task with caching, the newer tokenizer and an EU regional endpoint:

Adjustment	Cost per task	20,000 tasks per month
List price, Sonnet 5.5, no adjustments	0.031 USD	620 USD
Plus newer tokenizer, 30 percent more tokens	0.040 USD	806 USD
Plus 90 percent cached prefix	0.025 USD	507 USD
Plus regional endpoint, 10 percent premium	0.028 USD	558 USD
Same, as a nightly batch on Bedrock	0.014 USD	279 USD

Our Claude API pricing guide for the EU keeps the per-route rate tables current.

How do you price the seats and the engineering use cases?

Seats and engineering work on a different model: you pay per person, not per task, and the token cost is not yours to optimise task by task. Price those two lines from published per-seat rates and Anthropic’s own deployment figures rather than from a task model.

For knowledge workers on chat and Cowork, claude.com/pricing gives Team Standard seats at 20 USD per seat per month billed annually, or 25 USD monthly, for teams of 2 to 150, with up to 500 USD per month in pooled API credits. Enterprise is 20 USD per seat per month billed annually with usage billed separately at API rates, with a 20-seat minimum. Premium Team seats are 100 USD per seat per month annually and carry 5 times the usage of a Standard seat.

For engineering, use the published deployment figures rather than a task model. Anthropic’s cost management page reports around 13 USD per developer per active day and 150 to 250 USD per developer per month across enterprise deployments, below 30 USD per active day for 90 percent of users. At 40 developers that is 72,000 to 120,000 USD per year, which is the number to carry into the business case, not a per-task estimate.

Where the seat model goes wrong: on seat-based Enterprise plans the spend report appears only when usage credits are turned on and covers overage spend only, because usage inside the seat allowance is not metered in dollars. A business case that promises per-task cost reporting on a seat plan is promising something the platform does not produce. Plan the measurement around what the analytics actually report: weekly active members, adoption level, product stickiness, estimated time saved, and a daily spend report with a one-day delay.

How do you rank a use case portfolio?

Rank by two axes only: how repetitive the task is, and how expensive a wrong answer is. Volume justifies the build effort; error cost determines how much review you have to fund. Everything else, including executive enthusiasm, is noise that will not survive the first quarter.

Our scoring sheet, with four questions per use case:

1. Volume. How many times per month? Under about 200 times a month, the build and review effort rarely pays back, whatever the per-task saving looks like.
2. Error cost. What happens if the answer is wrong and nobody notices? If the answer is “a customer is billed incorrectly”, the review step is mandatory and the business case must carry it.
3. Verifiability. Can a reviewer check the output in less time than doing the task? If not, the saving is illusory, because the review becomes the new bottleneck.
4. Data class. Does it touch personal or regulated data? If yes, add the residency premium and the processor agreement work before comparing.

The portfolio decision that follows:

Volume	Error cost	Verdict
High	Low	Build first. Best return, least governance
High	High	Build second, with a funded review step
Low	Low	Give people a chat seat and a skill, do not build
Low	High	Leave it with people. Automation adds risk without return

The use cases that die in this grid are the ones most often presented first: a high-error-cost, low-volume process that somebody important finds annoying. Be direct about it in the business case rather than scoring it politely.

Run it yourself or outsource?

Build the business case yourself. It needs four numbers that only you have: the real token counts from your own prompts, the real volume, the loaded hourly cost, and the honest review effort. External help is worth paying for on the token measurement and the rate modelling, which is tedious and version-sensitive, and on challenging the volume claims.

What the work takes, as our estimate rather than a sourced benchmark:

Step	Effort	Owner
Measure real token counts on 20 sample tasks	1 to 2 days per use case	Engineer with a Console key
Establish current volume and handling time	2 to 5 days per use case	Process owner
Build the rate model with caching and residency	3 days once, then updates	Finance plus engineer
Review effort estimate from a pilot	5 days per use case	The team that will review
Portfolio scoring and cut list	3 days	Whoever can say no

Our view: the measurement is cheap and the volume claims are where the fraud lives. A business case built on a process owner’s estimate of “about 2,000 cases a month” that turns out to be 300 is the most common way these programs lose credibility. Pull the number from a system, not from a person.

What to demand from anyone building a business case for you:

1. Token counts measured on your prompts and on the model you will run, with the tokenizer generation named.
2. Volume pulled from a system of record, with the query shown.
3. Review effort included as a cost, not assumed away.
4. The residency premium applied where the data class requires it.
5. A named cut list. A portfolio where every use case passes has not been assessed.

Our Claude pricing overview holds the current plan and API tables these models depend on.

FAQ

What is an AI business case for Claude?

An AI business case for Claude prices a specific task at current token prices, adds the review effort it needs, and compares the total against the loaded cost of the hours the task consumes today. It covers seats separately at per-seat rates and engineering use at published per-developer figures rather than per-task estimates.

What does one Claude task cost?

For a task with 8,000 input and 1,500 output tokens, about 0.0016 USD on Haiku 5.5, 0.031 USD on Sonnet 5.5, 0.062 USD on Opus 5.5 and 0.155 USD on Fable 5.1 at list prices. Caching a stable prefix cuts the Sonnet figure by roughly a third; a regional endpoint adds 10 percent.

Which adjustments do cost models usually miss?

Four. Prompt caching lowers the figure, the newer tokenizer on Claude 4.7 and later raises it by around 30 percent for the same text, regional endpoints add 10 percent, and Bedrock batch inference halves it. A model missing any of these is wrong by more than 10 percent.

Per-task pricing vs per-seat pricing: which applies?

Per-task pricing applies to API and automation use cases, where you control the prompt and the volume. Per-seat pricing applies to people using chat, Cowork and Claude Code, where you pay 20 USD per seat per month on Team Standard or Enterprise annually. Engineering use is best priced at 150 to 250 USD per developer per month.

How do we decide which use cases to drop?

Score volume against error cost. High volume and low error cost gets built first. Low volume and high error cost stays with people, because automation adds risk without return. Under roughly 200 cases per month the build and review effort rarely pays back, whatever the per-task saving looks like.

Can we report cost per task on a seat-based plan?

Not reliably. On seat-based Enterprise plans the spend report appears only once usage credits are on and covers overage spend only, because usage inside the seat allowance is not metered in dollars. For per-task cost reporting, route the workload through the API or a cloud provider where tokens are billed directly.

Sources

1. Anthropic: Model and feature pricing (28 October 2026)
2. Anthropic: Claude pricing plans (28 October 2026)
3. Claude Code: Manage costs effectively (28 October 2026)
4. Anthropic: Data residency (28 October 2026)
5. AWS: Amazon Bedrock pricing (28 October 2026)
6. Anthropic Support: Usage analytics for Team and Enterprise plans (28 October 2026)