What Does It Cost to Run an AI Feature Every Month?

Proposals quote the build. Budgets get approved on the build. Then twelve months later somebody asks why there is a recurring line nobody planned for, and the feature gets switched off. The monthly cost of running an AI feature is knowable in advance — here is how it breaks down.

Three components

1. Model API usage

Charged by volume of text processed, in and out. For a typical internal tool used by a few dozen staff it is often a modest line, but it is the one that moves most with usage, so it needs an estimate at your expected volume rather than a guess.

What drives it:

• How much context you send per request. This is the big one. A system that stuffs twenty retrieved passages into every request costs far more than one that sends the best three, on every request. Retrieval quality is a cost lever, not just an accuracy lever.
• Request volume. Linear and predictable.
• Model choice. Capability tiers differ substantially in price. Many tasks — classification, extraction, routing — run fine on a smaller model. Using the largest model for everything is the most common source of an unnecessary bill.
• Retries. Agent loops that retry on failure can multiply cost quietly. Cap them.

2. Infrastructure

Hosting, the database, the search index, file storage, monitoring. For a business-scale internal tool it is predictable, and it scales with data volume rather than usage. Ask for it as its own line so it is not buried inside the build.

3. Maintenance

The line most often omitted, and the one that determines whether the system still works in year two. Plan a standing annual maintenance budget from day one, sized by what the system depends on, and ask every bidder to quote it separately. It covers:

• Model deprecations, which happen on real timelines and require revalidating against your evaluation set.
• Re-indexing when source documents change.
• Accuracy drift — the same prompts producing different quality as models update.
• Ordinary dependency patching and security updates.

A worked example

An internal assistant, 40 staff, ~500 questions a week. To see its real monthly cost, gather three lines from the proposal and your provider's published rates:

• API usage: questions per month, times the average tokens in and out per question, priced at the provider's published per-token rates.
• Infrastructure: the hosting, database, and search index quoted for this data volume.
• Maintenance: the annual maintenance quote spread across twelve months, so it sits beside the other monthly lines.
• Total: the sum of the three is the real monthly cost, and twelve months of it is the annual line to put in the budget.

Then set that total against the time saved. Against 40 people saving even fifteen minutes a week, the case is usually easy to make. Against 6 people saving five minutes, it usually is not. That arithmetic is worth doing before the build, not after.

Four ways to cut the bill without cutting quality

1. Retrieve less, better. Improving retrieval so three passages suffice instead of twenty is usually the largest single saving available.
2. Route by difficulty. Send simple classification to a cheaper model and reserve the capable one for genuinely hard requests.
3. Cache repeated context. If every request includes the same long instructions, providers offer prompt caching mechanisms to avoid paying for it repeatedly.
4. Set hard ceilings. Per-user and per-day caps with alerting. This does not reduce normal cost; it prevents the runaway that turns an ordinary month into an invoice nobody can explain.

Decide who owns the bill

Usage-based costs need an owner in a way that a fixed subscription does not. Without one, nobody notices a gradual climb until it is a finance question rather than an engineering one.

Three things worth putting in place on day one:

• A named owner who sees the monthly figure and is expected to explain a change in it. If you have a vCIO or fractional IT lead, it belongs on their budget.
• Alerting at a threshold, not just a monthly report. A runaway loop can spend a month's budget in a day, and you want to know that day.
• Cost attribution by feature if you run more than one. Otherwise you cannot tell which capability is worth its cost, and you will end up cutting the wrong one.

What to require in a proposal

An estimated monthly cost at your expected volume, with the assumptions stated — requests per day, average context size, model tier. If a vendor cannot produce that, they have not thought about it, and you will find out at the first invoice.

Also ask what happens if usage doubles. A cost model that is linear is fine; one that has a cliff in it is worth knowing about in advance.

What moves the build cost is covered in our guide to custom AI build cost drivers, and we scope both together under AI automation.

Want a running-cost estimate for a specific workload? Send us the volumes.