What an AI automation actually costs to run

You asked what an AI automation costs and got a wall of numbers: fifty dollars a month, five hundred, five thousand, ten thousand upfront, six figures for enterprise. The ranges overlap, disagree, and never explain themselves. So you cannot tell whether the quote in front of you is fair, and you cannot tell what happens to the bill in month seven.

There is a reason those numbers are unusable. Almost all of them are what someone charges to build an automation, priced as a service. The question of what the finished thing costs to operate is a different question, it has four lines, and three of them are missing from the answer you found.

Here is the arithmetic, with published rates you can check today.

The short answer

Running an AI automation costs four things: the model calls, the person who checks the output, the platform it runs on, and the work of keeping it alive when a model or an API changes underneath it. At business volumes the model calls are usually the smallest of the four and are trivially calculable from published rate cards, often single or low double digits of dollars per month. The review loop is normally the largest, because it is paid in salary and scales with volume exactly as the savings do. The test of whether an automation is worth building is therefore not a money comparison but a minutes comparison: how many minutes the task takes a person, against how many minutes it takes to check one automated output. If checking takes longer than doing, no hourly rate and no volume will rescue it.

The model is the cheapest line, and you can check it in a minute

Model providers publish per-token rate cards. That makes this the one line item nobody has to guess at, and it is worth doing the sum yourself before anyone quotes you.

Take a common classification job: sorting 2,000 inbound emails a month into categories and routing them. Each call sends the email plus a system prompt, call it 1,200 input tokens, and returns a label with a short reason, call it 100 output tokens. That is 2.4 million input tokens and 200,000 output tokens a month.

Against Anthropic’s published pricing, verified 29 July 2026:

Model	Input rate	Output rate	This workload, per month
Claude Haiku 4.5	$1 / MTok	$5 / MTok	$3.40
Claude Sonnet 5 (to 31 Aug 2026)	$2 / MTok	$10 / MTok	$6.80
Claude Sonnet 5 (from 1 Sep 2026)	$3 / MTok	$15 / MTok	$10.20
Claude Opus 5	$5 / MTok	$25 / MTok	$17.00

The entire spread from the cheapest model to the most capable one, on a job running every working day, is fourteen dollars a month. Anthropic publishes a worked example of its own on the same page: processing 10,000 support tickets at around 3,700 tokens per conversation on Claude Haiku 4.5 comes to roughly $37.

Two discounts make it cheaper still, and both are published rather than negotiated. The Batch API takes 50 percent off input and output for work that does not need an answer this second, which covers most overnight processing. Prompt caching charges a cache hit at a tenth of the base input price, which matters when every call ships the same long system prompt or the same reference document.

Document work is priced per page rather than per token and is equally checkable. Amazon Textract’s published pricing in US West (Oregon) is $1.50 per 1,000 pages for plain text detection, $10 per 1,000 pages for its invoice and receipt extraction, and $50 per 1,000 pages for full form key-value extraction. Two thousand invoices a month is twenty dollars.

None of this is where your money goes.

The line that decides it is the person checking the output

Every automated output has to be checked, or accepted unchecked, which is a decision rather than an absence of one. That check is the running cost that nobody quotes, because the vendor does not pay it. You do, in salary.

Stay with the 2,000 emails. Suppose checking one routed email takes 20 seconds: read the message, glance at the label, agree or correct. Checking all of them is 11.1 hours a month. Eurostat puts average hourly labour costs in the EU at 34.9 euros for 2025, extracted 31 March 2026, ranging from 12.0 euros in Bulgaria to 56.8 in Luxembourg. At the EU average, that review is roughly 390 euros a month against a token bill of $3.40.

Two orders of magnitude. Currency conversion does not touch that conclusion and neither does picking a different country.

Check a 10 percent sample instead and it falls to about 39 euros, still more than the model. But sampling is only available once you have measured an error rate you can live with, and you can only measure that by checking everything for a while first. The sampling discount is earned, not assumed, and the period where you earn it is part of the build.

This is why the six job types have such different economics. The check cost is a property of the job, not of the technology:

• Extraction. The correct answer is on the document. Checking is comparing a field to a scan, seconds per item, and sampling works once the error rate is known. Cheap to verify, which is why it pays first.
• Classification. As above, and you can measure accuracy against a labelled sample before you commit anything.
• Retrieval. The citation is the check. Following a link to confirm the answer is in the source is fast; noticing an answer that is confidently wrong and has no source is not.
• Monitoring. You can audit everything it flagged. You cannot audit what it missed without sampling the unflagged stream, so the check has a second half most designs omit.
• Generation. There is no correct answer to compare against, so checking means reading with the same judgement it would have taken to write. This is the category where the review loop routinely eats the entire saving, and it is the category most companies start with because it is what a chat window does.
• Action. The check has to be a gate before the effect, not a review after it, because the thing being verified has already happened by the time you read the log.

The comparison that actually decides it is minutes against minutes

The standard advice is to multiply time saved by frequency by an hourly rate and subtract costs. That is arithmetic, but it hides the thing that decides the answer.

Write down two numbers instead:

• T, the minutes a person spends doing one item now.
• C, the minutes it takes to check one automated output, multiplied by the fraction of outputs you will actually check, plus the time spent handling the ones that come back wrong.

If C is larger than T, the automation loses labour on every single item. No hourly rate fixes that, because the same rate applies to both sides and cancels out of the comparison. No volume fixes it either, because both sides scale with volume together. Higher volume makes a bad automation lose faster.

If T is larger than C, you have a real saving per item, and only now does the hourly rate matter. It decides how big the win is, not whether there is one. Multiply the difference by volume and by your loaded rate, then set it against the running cost: tokens, platform, and maintenance.

Worked both ways, with the same 2,000-item volume:

• Invoice keying. Four minutes to key one invoice by hand. Twenty seconds to check an extracted one against the scan. T is four minutes, C is a third of a minute, so the automation removes roughly 3.7 minutes of work per invoice before any rate is applied. At 2,000 a month that is around 122 hours. This pays, comfortably, and it would still pay at half the volume.
• Product descriptions. Eight minutes to write one. Six minutes to read a generated one properly, fix the tone and verify the specifications are true, on every single item because you cannot sample-check something you are about to publish. The saving is two minutes, not eight. The quote you were given almost certainly assumed eight.

That second case is not an argument against using AI for drafting. It is an argument for pricing it honestly, and for putting it where the alternative was not producing the thing at all rather than where a person was already producing it well. We take the same view on our own marketing and AI work.

Maintenance is a calendar, not a percentage of the build

The common heuristic is to budget 10 to 20 percent of build cost per year for maintenance. Some sources say 15 to 25, others 20, others 30 to 40 for anything with volatile APIs. Four different numbers, none derived from anything.

There is a better source, and it is published: the deprecation schedules of the models you are calling.

Anthropic’s model deprecations page states that it notifies customers with active deployments “providing at least 60 days’ notice before model retirement for publicly released models”, and that “requests to models past the retirement date will fail”. The table carries dates. claude-opus-4-1-20250805 was deprecated on 5 June 2026 with retirement set for 5 August 2026. claude-sonnet-4-20250514 and claude-opus-4-20250514 were deprecated on 14 April 2026 and retired on 15 June 2026. OpenAI’s deprecations page works the same way: “when we announce that a model or endpoint is being deprecated, it immediately becomes deprecated. All deprecated models and endpoints will also have a shut down date. At the time of the shut down, the model or endpoint will no longer be accessible.”

That is not a risk percentage. That is a calendar you can read today and budget against.

Two details on the same pages change the bill in ways a percentage would never capture. Anthropic notes that “Claude 4.7 and later models and Claude Mythos Preview use a newer tokenizer… This tokenizer produces approximately 30 percent more tokens for the same text.” So moving to a newer model at an identical headline price bills roughly 30 percent more for the same workload. And parameters get retired alongside models: temperature, top_p and top_k now return a 400 error when set to a non-default value on Claude 4.7 and later, so code that has worked for two years stops working on upgrade for reasons that have nothing to do with the model’s output.

Budget maintenance as the migration work those dates imply, plus a standing half-day a quarter to read the deprecation pages of everything you call. That is a real number you can defend, and it is usually smaller than 20 percent of build.

What this failure actually looks like, from our own systems

We run a probe that asks ChatGPT, Perplexity and Gemini a set of questions and records who gets cited, and it calls a named model id for each engine. The OpenAI model it called, gpt-4o-mini-search-preview, was announced for deprecation on 22 April 2026 and shut down on 23 July 2026. Both dates were published in advance. Nobody read them.

The interesting part is not that it broke. It is how it broke. The call returned a 404, the script did not stop, and the ChatGPT column was written into the report as an absence of citations rather than an absence of data. Three consecutive daily reports understated coverage by a third and looked completely normal, and it was caught by a person reading the output rather than by anything in the system. Three months of notice was given and it made no difference, because the notice was published where nobody was looking and the failure disguised itself as a result.

The fix took minutes. The cost was not the fix. The cost was three days of a report that was quietly wrong in the direction that made things look worse, which is the lucky direction. Had it failed in the flattering direction we would probably still not have noticed.

That is what the maintenance line is really buying: not the repair, but somebody whose job is to notice. It is also why an automation that silently degrades is more expensive than one that crashes, and why the monitoring on your monitoring is a real line item rather than a joke.

When the answer is not to build it

Some honest disqualifiers, from the same arithmetic:

• Low volume. Under a few hundred items a month, the build and the maintenance calendar will outrun anything the automation saves, whatever the running cost is. Do it by hand and revisit at volume.
• An unstable process. If the steps change every few months, you are paying to rebuild rather than to run. Stabilise the process first; that is often the whole project, and it needs no AI.
• Checking costs as much as doing. Covered above. This is the single most common reason a pilot never reaches production.
• The task is already a rule. If the decision can be written as an if-statement, a form field or a SQL query, write that instead. It costs nothing per run, never hallucinates and never gets deprecated.
• An expensive error that nobody would notice. Where a wrong output is costly and undetectable, the only safe design is a human gate, and a human gate means you are pricing an assistant rather than an automation.

How to price your own before you ask anyone for a quote

You can do all of this in an afternoon, with no vendor involved.

1. Count the volume. Items per month, from a system you already have. Not an estimate.
2. Time the task. Do ten of them with a stopwatch. That is your T.
3. Time the check. Take ten outputs from any model, check them properly, and time it. That is your C, and it is the number everyone skips.
4. Price the tokens. Take one real item, count its input and output tokens, multiply by volume, multiply by the published rate. It will be smaller than you expect.
5. Read the deprecation pages for every model and API in the design, and write the dates in a calendar.

If T is comfortably larger than C and the volume is real, you have a case, and any quote you receive can now be argued with on the merits. If it is not, you have saved yourself the build, which is the more valuable outcome of the two.

We build AI and automation work on exactly this test, and we say so when a job does not pass it. If you want the arithmetic done on a specific process before anyone proposes anything, that is a conversation rather than a project.