AI Automation Cost: Why $0.12 Per Run Can Become $12,000 at Scale

One of the most useful lessons we learned about AI cost started with a number that looked almost too small to care about: $0.12. That was roughly what one of our AI workflows was costing to research a prospect. Twelve cents. For a workflow doing real research, that sounded perfectly reasonable, and at small volume it was.

Then we did the obvious calculation we probably should all do much earlier when building AI systems. What happens at 100,000 runs? The answer is $12,000. Suddenly, a fraction of a dollar is no longer a technical detail. It is an operating decision.

That led us to look much more carefully at what the $0.12 actually contained. The workflow was not making one simple AI request. It was carrying out six separate buyer searches, processing the findings and performing a final analysis. The interesting question was never which AI model is cheapest. It was what one completed piece of work actually costs, where that money goes, and how much can be removed before the work gets worse.

How much does AI automation actually cost per run?

There is no universally good AI automation cost per run. The useful number is the cost of producing one acceptable completed job, including model usage, tool calls, search or retrieval, external APIs, retries and other resources required by the workflow. A $0.12 workflow may be economical at 500 runs and material at 100,000. The cost only makes sense when it is viewed alongside volume, quality and the commercial value of the output.

Quick takeaways

1. 1Tiny unit costs become real budgets at volume: $0.12 per run becomes $12,000 across 100,000 runs.
2. 2Model price is only part of the cost. Search, retrieval, tools, retries and workflow design create a cost floor that changing models does not remove.
3. 3Cheaper output is not automatically better economics. If saving a few cents reduces research quality, the cheaper workflow may create less business value.
4. 4Measure before you optimise. Establish a quality baseline, calculate the full cost per acceptable job, then change one part of the workflow at a time.

The $0.12 problem: tiny number, real money

Here is what the same workflow looks like at different volumes. Nothing changed technically between the first row and the last. Only the multiplier changed.

This is one of the easiest things to miss while prototyping. During development you might test ten rows, twenty, fifty, so a workflow can feel almost free. Then someone adds a Run All button, and that button changes the economics completely. If 100,000 eligible records sit behind it, a twelve cent workflow has turned one click into roughly $12,000 of authorised usage.

The question is not whether $0.12 is cheap. It is how many times you are about to spend $0.12.

Model cost and workflow cost are not the same thing

A common way to estimate AI cost is to read the model pricing page: input tokens cost X, output tokens cost Y, multiply and you have your number. That works for a single model request. It becomes incomplete once the model sits inside a larger workflow.

• web searches and retrieval
• external APIs and database operations
• multiple model calls and reasoning steps
• validation calls and secondary models
• retries and failed attempts

OpenAI, for example, currently prices its web search tool at $10 per 1,000 calls, or $0.01 per search call, with search content tokens additionally billed at the selected model rates. That mattered in our workflow. Each prospect required six buyer searches, so six search calls alone contributed six cents before any analysis. That is half of a $0.12 run in tool call fees.

This is what we mean by a structural cost floor. If the workflow genuinely requires those six searches, switching to a cheaper analysis model does not make that six cent layer disappear.

Our 500 run test changed what we wanted to optimise

Before scaling further we ran the workflow across approximately 500 prospects, roughly $60 in operating cost. We were not testing cost alone. We wanted to know whether the searches produced useful evidence, whether the buyer questions were realistic, whether the final analysis retained the right context, whether outputs were consistent enough to use downstream, and where failures happened.

If we had optimised for price before establishing a quality baseline, we would have had no reliable way to tell whether a cheaper version was still doing the same job. We did test cheaper configurations. The cost went down and so did the quality. That told us some of the spend was not waste. It was buying information the workflow needed.

Cost per run can still hide the real number

Even after calculating cost per run, there is another level worth measuring: cost per acceptable completed job. Suppose a workflow costs $0.12 every time it starts. If only 90 percent of outputs meet the acceptance standard, you did not pay twelve cents for every usable result. You paid more.

Cost per acceptable completed job = total workflow cost divided by accepted outputs.

This is why an apparently cheaper configuration can lose its advantage quickly if it creates more failures, retries or unusable outputs. The business is not buying API calls. It is buying completed work.

The cheapest model does not necessarily create the cheapest system

Model choice obviously matters, and current model line ups reflect that trade off between frontier capability, balanced cost and high volume workloads. But a cheaper model only saves money on the work that model is responsible for. It does not reduce search calls, external API fees, duplicate retrieval, unnecessary workflow stages, poor retry logic, or calls that should never have happened.

Both matter, but the second becomes increasingly important as volume rises. If your system performs eight paid actions where four would produce the same result, changing models treats the symptom while the workflow keeps doing unnecessary work.

The better question: what is the lowest cost that preserves the job?

There is a dangerous version of AI optimisation that looks excellent on a spreadsheet. Version A costs $0.12. Version B costs $0.08. Success. Except Version B misses more evidence, produces weaker classifications, requires more human checking or sends poorer output into the next stage. The four cent saving is real. So is the quality loss.

For prospect research that influences who a business contacts and what it says to them, four cents is an absurd place to compromise when the downstream opportunity is worth hundreds or thousands of dollars. A better target is the lowest cost at which the workflow still performs its job to the required standard.

What we are optimising next

Our approximately $0.12 figure is the baseline, not the finish line. The working target we are testing towards is around $0.08 per run while maintaining the same output quality. That is not a market benchmark. Another workflow could reasonably cost $0.01, $0.40 or $4 depending on what it does.

At 500 runs the difference is $20 and easy to dismiss. At 100,000 runs the exact same engineering improvement is worth $4,000. That is why we test small but design with the larger volume in mind.

Where should you look for AI cost savings first?

1. Establish the quality baseline

Take a representative sample and run the version you currently trust. Define what a good output means before changing anything. Accuracy alone may not be enough. Depending on the task you may also care about evidence quality, completeness, consistency, format compliance, latency or human review time.

2. Break the run into cost components

Do not leave yourself with one number called AI cost. Separate model input, model output, tool calls, retrieval and search, external APIs, retries, failures and infrastructure. Now you know what is actually worth optimising.

3. Find the structural floor

Ask which costs remain even if you changed the model tomorrow. In our case, six paid buyer searches immediately exposed a meaningful part of the floor, which changes where engineering effort should go.

4. Remove duplicated work before reducing intelligence

Could a result already collected in step two be reused in step five? Is static context being repeatedly sent? Could deterministic code handle filtering, joining, ranking, deduplication or validation instead of another model call? Current OpenAI guidance recommends bounded programmatic processing for predictable operations rather than forcing every intermediate step through a model.

5. Use cheaper models where the task genuinely allows it

Classification does not need the same model as final synthesis, and extraction does not need the same reasoning level as strategic analysis. Current guidance recommends evaluating model tiers and reasoning levels against representative tasks. The key word is evaluating. Do not downgrade and assume equivalence. Test it.

6. Make prompts leaner, not merely shorter

A shorter prompt only helps if it still contains the instructions that affect the result. Remove repeated instructions, irrelevant tools and unnecessary examples, while retaining guidance that corrects measured quality gaps. The goal is not prompt minimalism. It is removing instructions that are not earning their cost.

7. Use caching where repeated context makes it worthwhile

If large parts of the prompt stay identical across runs, prompt caching can reduce the cost of reprocessing the same input. Measure actual cache hits. A feature being available does not mean your workflow is structured to benefit from it.

8. Consider batch processing where the workload fits

For asynchronous work that does not need an immediate response, the OpenAI Batch API currently offers a 50 percent discount within a 24 hour completion window. That can be meaningful at volume, though tool heavy workflows should be tested for compatibility rather than moved wholesale.

9. Control retries and stopping conditions

Retries are useful when something genuinely failed. They are expensive when nobody told the system when to stop. Define what counts as success, recoverable failure, permanent failure and stop. This matters even more when the workflow can run without anyone watching.

What the Run All button really means

A button labelled Run All Empty Rows looks operational. Financially it is closer to: authorise every eligible row to consume the resources required to finish. Two hundred rows at $0.12 is about $24. Ten thousand is about $1,200. One hundred thousand is about $12,000.

This is not an argument against automation. It is an argument for attaching economics to automation. Before enabling large autonomous queues, a production system should know how many records are eligible, the expected cost per record, the likely failure rate, the maximum acceptable spend and how execution can be stopped.

Four numbers we now want before scaling an AI workflow

1. 1Cost per acceptable completed job, not just the model request or the tokens.
2. 2Structural cost floor, meaning the costs inherent in the current architecture.
3. 3Expected volume, because a unit cost without volume is almost meaningless.
4. 4Value of the output, because cost must be judged against the value created.

A four cent saving on an internal classification task could matter enormously across millions of runs. A four cent saving on high value B2B research may matter far less than preserving the quality of the research.

What people often misunderstand about AI cost optimisation

The biggest misunderstanding is treating optimisation as a race towards the cheapest possible model. Sometimes the model is the problem and sometimes it is not. The useful question is which part of this workflow is expensive without improving the final result. That could be a model, a redundant search, duplicated context, excessive reasoning, a needless intermediate summary, poor retry logic or a human review step caused by unreliable output upstream.

Removing useful intelligence is cost cutting. Removing unnecessary work is optimisation. They are not the same thing.

When cost optimisation may not be worth doing yet

If a workflow runs 200 times per year and costs a few dollars in total, spending days redesigning it to save two cents per run is poor economics. Likewise, if a workflow is still changing dramatically, premature cost engineering may optimise architecture that disappears next week. Prove the job works, measure it, understand the cost, then optimise what survives.

High volume repeatable workflows are different. At 100,000 runs, a one cent reduction is worth $1,000 and a four cent reduction is worth $4,000. Now the engineering conversation changes.

Questions to ask before scaling an AI workflow

• What does one acceptable completed job cost?
• Which part of that cost comes from models, and which from tools, search, APIs or retrieval?
• What is the unavoidable cost floor?
• What percentage of runs produce acceptable outputs, and what happens when something fails?
• Can the workflow retry indefinitely?
• Is repeated information being fetched or processed more than once?
• Could simpler steps use cheaper models or deterministic code?
• How much quality can change before the optimisation stops being worthwhile?
• What is the expected monthly or annual volume, and what is a successful output worth commercially?

If those answers are unknown, Run All is still partly a guess.

How should businesses think about value, not just API price?

An AI workflow is economically useful when the value of the work it produces comfortably exceeds the cost of producing and operating it. Model pricing makes it easy to become obsessed with decimal places. If high quality research costs twelve cents and materially improves a high value sales process, twelve cents may be excellent economics. If a workflow performs a low value task ten million times, twelve cents may be completely unacceptable.

The lesson from twelve cents

The important thing we learned was not that our workflow costs $0.12. That number will change. Models change, pricing changes and the architecture will change. The more useful lesson is how we now think about scaling: we test before we multiply, we establish what good output looks like, we measure where the money is actually going, then we optimise the system without quietly removing the things that made it useful.

An AI demo only has to work. A production AI system has to work repeatedly, economically and at the quality the business actually needs. That is how we approach the systems we build with clients at Soluma: start with the business problem, test the workflow under real conditions, measure the economics, then improve the architecture before volume magnifies every unnecessary decision.