How much does it cost to run an AI automation?

How often have you been on a client call where someone asks what an AI automation will cost to run, and you cannot tell whether they mean two dollars, twenty dollars, or two thousand dollars a month?

In our experience, they are asking for an order of magnitude they can plan around, not an invoice. That is the time when you have to give them a defensible range, with your assumptions visible.

How much does it cost to run an AI automation?

There is no honest universal monthly price for an AI workflow. The number depends on what your workflow uses, how often it runs, how much data it sends to a model, and what happens when something goes wrong and your workflow has to retry the process.

To understand this entire process, let's take a case. Say your client receives around 10,000 support emails a month, and your workflow classifies each one and returns a short category plus summary. Your platform runs the workflow, the AI handles the classification, and other services may store data, log executions, or handle exceptions.

For the sake of really getting into this example, here is a dataset of how your emails look after the classifications are done:

So, how would you calculate the cost of this?

Technically speaking, you have to start with fixed infrastructure and platform costs, then calculate usage-based model and tool costs, add storage and operational costs, and account for human review where it exists. For the model:

monthly model cost = monthly runs × ((input tokens per run ÷ 1,000,000 × input price per million) + (output tokens per run ÷ 1,000,000 × output price per million))

If your provider charges separately for cached input, batch processing, tool calls, or long-context usage, add those as separate terms.

Then run it at low, expected, and high volumes, including realistic retries. The result is an estimate you can explain, not a universal monthly price.

Yeah, this was not supposed to make sense, yet. Keep reading.

So, how would you calculate the cost?

Looping back to the support-email example, the AI model is only one part of the system. Your monthly estimate should account for five buckets.

Workflow platform or hosting. Your n8n or Make plan may be the main fixed platform cost for a low-code workflow. If you build the same workflow in custom code, you may instead pay for an application server, database, queue, or scheduled function. Which of those you are paying for comes out of the Make, n8n, or custom code decision.

Model usage. Your model bill depends on the input and output tokens processed, along with any applicable pricing for cached input or model-specific tiers.

Tools and third-party APIs. Your model may trigger a search service, enrichment API, OCR service, email provider, CRM, payment service, or another vendor during the same run. Check each service individually.

Storage and observability. Your workflow may store files or embeddings, while logs, traces, alerts, and applicable data transfer can create additional recurring costs. These are easy to miss when you look only at the model's pricing page.

Human review and recovery. If someone reviews an exception, approves an output, or handles a failed run, that time is part of the operating cost even when it never appears on a cloud invoice. We've seen estimates become misleading when that work is treated as invisible.

What is a token, and why is model usage priced that way?

A token is the unit that a language model reads and writes. As a rough English-language heuristic, one token is about three-quarters of a word, although that is not a word-to-token conversion rule you can apply to every piece of text.

In our support-email workflow, the model is not just receiving the customer's email. Your prompt and system instructions count, as do retrieved documents, conversation history, and information passed from earlier workflow steps.

That is why context management affects cost. A 5,000-token system prompt sent on 10,000 calls represents 50 million input tokens before the actual task. Keeping prompts tight and summarising completed history instead of repeatedly appending raw transcripts makes the estimate easier to control.

How do you estimate one run?

Take the support-email example through the calculation, and make the assumptions explicit.

First, save the exact production prompt and a representative input sample. If your workflow classifies support emails, use a normal example rather than an unusually short test message.

Next, count input tokens using the provider's tokenizer or usage metadata, and measure output tokens separately where possible. In the example below, the production input is 800 tokens and the output is 60 tokens per run.

Then copy the recorded input and output prices into the formula. A model can check the arithmetic, but it cannot validate your assumptions. Keep the formula, token counts, prices, and volume visible so another person can reproduce the result.

For planning, we'd recommend this table:

Retries belong in the estimate too. If 10,000 runs are expected but some make a second model request, billable model activity can exceed 10,000 calls.

What does a worked example look like?

Take the expected case and keep the original assumptions intact: 800 input tokens per run, 60 output tokens per run, and 10,000 runs per month using GPT-4o Mini.

For this example, we use $0.15 per million input tokens and $0.60 per million output tokens (recorded prices, as of September 2026). You can find these prices for any model, from any provider (OpenAI, Anthropic, Google, and so on) by going to their respective pricing page. Look for the input price and output price per 1 million tokens.

Coming back to the example, the calculation is:

10,000 × ((800 ÷ 1,000,000 × $0.15) + (60 ÷ 1,000,000 × $0.60))
= 10,000 × ($0.00012 + $0.000036)
= 10,000 × $0.000156
= $1.56 per month

That $1.56 is estimated model usage, not the monthly cost of running the automation. Your platform, third-party services, storage, monitoring, retries, and human review can all sit outside that number.

Now change the operating conditions. Longer documents can increase input tokens, retries can increase billable model activity, and a paid tool call adds another usage-based line item. The $1.56 result remains correct for its original assumptions, but not for this larger workload.

What makes the estimate wrong?

An estimate can move in either direction once your workflow meets production traffic.

On the higher side, longer inputs, growing history, retrieved context, retries, model routing, paid tools, failed runs, higher volume, and human escalation can increase cost.

On the lower side, caching, batch pricing, smaller models, shorter prompts, deterministic preprocessing, and routing only difficult cases to a more expensive model can reduce usage.

So the number you give a client should be tied to assumptions they can understand. Make sure to compare those assumptions with provider usage data after the first 30 days, because production traffic is the point at which an estimate becomes something you can measure.

What should you tell the client?

Keep the client-facing version simple, and keep the operating cost separate from your build fee or support retainer unless those costs are explicitly included in your scope.

A useful structure is:

"Based on the expected volume and the services in scope, recurring operating cost should sit between $X and $Y per month. That includes $A in fixed platform or hosting costs and an estimated $B to $C in usage-based services. We will measure actual usage during the first 30 days and update the range before volume changes."

That gives your client an order of magnitude and shows what varies.

What questions come up most often about AI automation costs?