# AI automation cost: the bill comes per run

> Rule-based automation charges once to build it. Put a model in the flow and the bill becomes per run, growing with the volume of your operation.

- Author: Marlon Trettin
- Published: 2026-10-15 · Updated: 2026-10-15
- Language: en
- Canonical: https://yowpi.com/en/blog/ai-automation-cost-the-bill-comes-per-run

---

Traditional automation has a fixed cost. You pay to build it once, and every run after that is close to free. Put a language model in the flow and this inverts: the cost is charged per run and grows with your volume. The bill does not change size, it changes unit.

## TL;DR

- Rule-based automation charges once to build it. Automation with a model charges on every run, in proportion to what the model reads and what it writes.
- Inference prices fell by orders of magnitude. For a model scoring 64.8 on MMLU, the 2025 AI Index recorded US$ 20 per million tokens in November 2022 and US$ 0.07 in October 2024.
- A lower price per token does not produce a lower bill per task. In OckBench, a preprint still without peer review, two models with nearly identical accuracy differed by more than 26 times in average output length.
- In the United States, AI use held between 17% and 20% of firms from December 2025 to May 2026, and it is concentrated in the larger ones.

## Why does the bill change when a model enters the flow?

Because the work stops being executed by an instruction written once and starts being produced again on every call. A script that sorts orders by rule runs ten thousand times for the cost of keeping the server on. A model that sorts orders by reading the text charges ten thousand times.

That difference never shows up in the pilot. At thirty cases a week, any design looks cheap. It shows up when the automation meets the real volume of the operation, which is exactly the moment the gain was supposed to appear.

The side effect is that the financial risk of the project flips sign. In rule-based automation, the bad case is low usage: you paid to build it and nobody uses it. In automation with a model, the expensive case is adoption. The more the operation uses it, the larger next month's invoice.

## Token prices fell. Why does the bill not follow?

Price and consumption are different things, and only the price fell.

The [2025 AI Index, from Stanford](https://hai.stanford.edu/assets/files/hai_ai-index-report-2025_chapter1_final.pdf), measured the drop: for a model scoring 64.8 on MMLU, inference cost US$ 20 per million tokens in November 2022 and US$ 0.07 per million in October 2024. On a harder exam, GPQA, the same report records US$ 15 per million in May 2024 and US$ 0.12 in December of the same year. Epoch AI, cited there, estimates declines of between 9 and 900 times per year depending on the task.

Consumption went the other way. Models that reason before answering produce intermediate tokens, and you pay for them. [OckBench](https://arxiv.org/abs/2511.05722), a preprint from November 2025 revised in June 2026 and still without peer review, evaluated 37 model and effort level combinations across 200 problems in mathematics, software engineering and science. The result that matters here: two models with nearly identical accuracy, 82.5% against 82.0%, averaged 83.6 thousand and 3.2 thousand tokens.

Elsewhere in the same table, a configuration with a much lower price per token landed slightly below on accuracy and still cost more over the full run, US$ 12.60 against US$ 9.50, because it wrote far more.

The authors call this the Overthinking Tax: a model can look efficient by parameter count or price per token and still turn out expensive, because it generates long, low-yield reasoning traces.

Anyone who compares models professionally has already changed units. [Artificial Analysis](https://artificialanalysis.ai/methodology) publishes cost per task and explains why in its own methodology: because cost reflects actual token usage, models that produce longer answers or more reasoning tokens have a higher cost per task, even at identical per token prices.

For whoever signs the budget, the practical reading is short. The list price is not the cost of your process, and picking a model is an engineering decision with a monthly financial consequence.

## How many times a month does this process run?

That is the question that decides the project, and it is almost never in the budget.

Rule-based automation improves with volume, because the cost to build it is diluted across every run. Automation with a model dilutes nothing, since the cost is linear. Both can carry the same contract value and behave in opposite ways financially the following month.

This changes the arithmetic of [automation payback](/en/blog/does-process-automation-pay-off). Payback in months describes an investment that happens once. Here the useful unit is different: cost per case processed against human cost per case, with a written ceiling for the first. Without a ceiling, the success of the project is what breaks the budget.

And there is the cost that is not inference. Someone checks the output, someone handles the case the model refused, someone notices when quality slips. That work belongs to [what it costs to keep a system running](/en/blog/what-it-costs-to-keep-a-system-running) and it rarely appears on the approval sheet.

## What this looks like at a distributor

A scenario, to make the arithmetic visible. The numbers below are a working hypothesis, not a client measurement.

A distributor receives orders by email and PDF attachment, in free form text. Two people retype them into the ERP. That is 300 orders a day, around 6,600 a month.

In the first design, the model receives the whole email, the customer history, the full price list and the commercial rules, and returns an order ready to post. It works in the demo.

In the second, the system already knows who the customer is from the sender address, which price list applies and what they bought on the last twelve occasions. The model receives the order text and resolves only what is ambiguous in it.

Both deliver the same result, and the difference in cost per order is not in the model. It is in how much context has to be resent on every run because the system stored nothing. You can run the arithmetic with your own prices: multiply the context size of each design by your provider's price per token, then by the monthly volume, which here is 6,600. In the first design, the distributor pays 6,600 times a month for the model to rediscover what its own records should already know.

## How companies are actually putting the model in the flow

Outside the scenario, the measurement exists. The [Business Trends and Outlook Survey](https://www.census.gov/library/stories/2026/05/ai-use-businesses.html), run by the US Census Bureau, found overall AI use holding between 17% and 20% of firms from December 2025 to May 2026.

The distribution says more than the average. On May 3, 2026, 37% of firms with at least 250 employees reported using AI, and 32% of those with 100 to 249. Fewer than 20% of firms with four or fewer employees did. Use rose among firms with at least 20 employees and did not change significantly below that line.

Those are the companies with enough volume for cost per run to matter, and they are adopting fastest. Volume is exactly what turns a per run charge into a line item somebody has to explain.

## Four decisions before the model goes in the flow

1. Separate rule from judgment. Price tables, approval thresholds by amount, delivery terms by region and discount policy are rules, and a written rule does not charge per run. [How much autonomy to give the model](/en/blog/ai-in-operations-how-much-autonomy) is a decision that comes after this one.
2. Define the billing unit of the process: per order, per document, per ticket. Write the acceptable cost ceiling per unit before approving, and treat an overrun as a defect rather than commercial success.
3. List what has to travel with every call and ask why it is not stored. Resent context is a record that is missing.
4. Write down what happens when volume doubles. Who gets told, what the daily limit is, what degrades first.

## Frequently asked questions

**How do you calculate the return on an automation that charges per run?**

Measure today's human cost per case, using the real time of the people doing it, and compare it with the automation's cost per case, adding inference, checking and exception handling. Run the calculation on the busiest month of the year, never on the average. If the return only exists while volume stays low, there is no return.

**If model prices fall every year, is it worth waiting?**

Waiting on price does not fix what drives your bill. On the same task, the difference between an expensive automation and a cheap one comes from the design of the flow and from what the system stores, and token prices fall for everyone at the same time. Separating rule from judgment and organizing your records takes months of work and does not go obsolete.

**I do not have a qualified team to implement this. Does that change the arithmetic?**

It does, at the point that usually gets underestimated: deciding where the model enters the flow matters more than choosing the model. Buying off the shelf covers the basics and keeps the unit cost invisible, which works while volume is small. If the process is your differentiator and runs thousands of times a month, someone has to own the architecture, in house or hired.

## The next step

If you are about to put a model inside a process that runs thousands of times a month, it is worth looking at the flow before the budget: the [Operational Architecture Diagnostic](/en/contact) is a 30-minute conversation about exactly that.