What a First AI Project Really Costs

AI pricing looks precise until you try to turn it into a business decision.

The provider pages are full of tidy numbers: input tokens, output tokens, cached input, batch processing, search calls, storage, extra actions. As of 9 May 2026, OpenAI lists GPT-5.4 mini at $0.75 per million input tokens and $4.50 per million output tokens, with cached input at a tenth of that. Anthropic lists Claude Sonnet 4 at $3 per million input tokens and $15 per million output tokens for prompts up to 200,000 tokens, with cheaper cache reads. Google lists Gemini 3 Flash Preview at $0.50 per million text, image, or video input tokens and $3 per million output tokens on its paid tier.

That sounds measurable. It is, technically.

It is also not the question most small businesses should start with.

The useful question is this: what repeated job are we asking AI to do, how often will it run, who checks the result, and when would we switch it off?

Until you can answer that, the model price is just a number floating around without a business underneath it.

AI service fees are only one cost

The model bill is the easiest part to notice because it arrives with a number beside it. It is rarely the whole cost.

There is the subscription or usage bill. That is the price for the model, storage, search, files, tools, or whatever else the provider bills for.

There is the setup work. Someone has to decide what the assistant should read, what it should ignore, what it should produce, and how the output should be checked.

There is the review cost. If a person spends ten minutes a day checking drafts, that is a real cost, even if the API bill is tiny.

There is maintenance. Models change. Prices change. The source material changes. The prompt that looked fine in May might need rewriting by August because the team has changed how the work is done.

There is also the cost of work nobody reads. A weekly AI report that costs pennies to generate and then sits untouched is still waste. It just arrives with a smaller receipt.

That is why the first cost question should be about the job, not the provider.

Calculate cost per reviewed result

Imagine a service business wants an AI assistant to read incoming enquiries, categorise them, and draft a first reply for review.

It receives 400 enquiries a month. Each one uses roughly 2,000 input tokens once you include the enquiry, instructions, examples, and a bit of source material. Each draft reply uses about 400 output tokens.

That is 800,000 input tokens and 160,000 output tokens a month.

On a cheaper everyday model, the model cost might be low enough that it barely registers. On a more expensive model, it is still not automatically frightening. The bigger question is whether the team actually saves enough time to justify the setup and review.

If each draft saves three minutes of writing and the team still reviews every reply, that is about twenty hours saved across the month. If half the drafts are never used because the categories are wrong, the saving collapses. If the review takes as long as writing from scratch, the model bill was never the problem.

That is the sort of calculation that should happen before anyone talks about provider choice.

Cheaper processing cannot fix an unclear job

The pricing pages are not all bad news. The providers have useful cost controls now.

OpenAI applies prompt caching automatically when long prompts reuse the same opening content, and says cached input can reduce input cost and latency. Anthropic lets developers mark parts of a request for caching, with cheaper reads after the first write. Google has implicit and explicit context caching in the Gemini API, plus batch options for work that does not need an immediate answer.

This matters when the workflow has a stable shape.

If the same instructions, policy, examples, or product data sit at the front of each request, caching can make repeat runs cheaper. If a nightly job can wait, batch processing can lower the bill. If the task only needs a smaller model, using a heavier one for every step is just expensive decoration.

But caching is a multiplier on good shape, not a substitute for it. If the prompt changes every time, the source material is messy, or the workflow keeps asking the model to solve a different problem each run, the clever pricing features will not save much.

This is one reason our own scheduled agents are written around stable jobs. One reads and classifies project information. One drafts progress summaries. One groups live software errors so a person can look at the right thing first. The prompts are not rebuilt from scratch every morning because the job is not rebuilt from scratch every morning.

Price the whole workflow

Before paying for an AI workflow, write down four things.

First, the repeated job. Not "use AI for sales". Something narrower: read new enquiries and draft a first reply, summarise yesterday's support tickets, classify new product images, check new website leads against fit rules.

Second, the expected volume. How many items per day or month. How long the inputs are. How long the outputs need to be. Whether the job runs on demand, every hour, once a day, or once a week.

Third, the review point. Who checks the output, how long that check should take, and which actions are not allowed to happen without a person.

Fourth, the stop condition. The point at which you would pause, change, or remove the workflow. That might be "if fewer than 70% of drafts are usable after four weeks", or "if the report is not read for two weeks", or "if review time is not lower than doing it manually".

That last one matters. Costs creep in because nobody decided what failure would look like. The subscription renews. The job keeps running. The report keeps arriving. Everyone quietly stops reading it. Very modern. Not very useful.

The cheapest AI can cost more to review

There is a temptation to treat AI buying like utility shopping: same thing, cheaper provider.

Sometimes that is sensible. High-volume tagging, simple classification, first-pass summaries, and low-risk drafting often suit cheaper, faster models. A good workflow can even use more than one model: a cheaper one for sorting, a stronger one for the awkward cases, and a person for anything risky.

But the cheapest model is not always the cheapest system.

If a cheaper model produces twice as many errors and every error needs a person to unpick it, the saving vanishes. If it writes in a way the team constantly rewrites, the cost has moved from the provider bill to staff time. If it cannot reliably follow the review rules, the risk has moved somewhere worse.

The practical answer is not "buy the expensive model". It is to test the cheapest model that can reliably do the job, with real inputs, against a review standard that matters.

Early cost estimates need real usage data

Any article about AI pricing dates quickly.

The numbers above are useful as a snapshot, not as buying advice frozen in time. Providers change model names, add cache options, alter search pricing, and move features between plans. A workflow that is cost-effective in May might need a pricing review in July. That is not a reason to avoid it. It is a reason to design it so the model and provider can be changed without rewriting the whole business process.

The more durable decision is the shape of the work: small, named, measured, reviewable, and easy to stop.

If that shape is clear, the pricing conversation becomes manageable. If it is not clear, even a very cheap model can become another monthly line nobody wants to talk about.