The build is a one-off. An AI feature charges you every time it works.

Most of the quotes I am asked to look at have one number in them that anyone argues about: what it costs to build the thing. For conventional software that is the right argument. Once a web app is written, serving the next user costs a fraction of a cent, so the build is very nearly the whole decision.

An AI feature does not have that shape. Every case it handles sends a model some text and pays for the privilege, which means the cost does not stop at launch, does not stay flat, and is at its highest in the month you finally declare the project a success.

Conventional software taught you the wrong shape

Nearly everyone making this decision learned cost from software with no meaningful cost of goods. You pay engineers for three months, you host it for a sum that barely moves, and growth is almost free. Boards are used to technology as capital spending followed by a rounding error.

An AI feature reintroduces a per-unit cost, and per-unit costs behave differently from project costs. Doubling the usage doubles the line. A feature that is marginal at today’s volume is more marginal at ten times it, not less — the opposite of the instinct everyone brings to the meeting.

The bill has more lines than the model call

You are paying for the input, not the answer. The charge is dominated by what you send — the instructions, the document, the examples, the retrieved passages — and not by the few hundred words that come back. The same question costs several times more against a forty-page statement than against an email.

Retries are not an edge case. A low-confidence result, a malformed response, a timeout, a second pass over an awkward layout. Some proportion of cases will cost you twice, and you should decide that proportion rather than discover it.

Multi-step work multiplies. An agent that plans, calls three tools and then reviews its own output has paid for five calls, each one carrying the whole accumulated conversation with it. The step count, not the model, is usually what moved the number.

Checking is real volume. A second model grading the first, and the eval set you re-run on every change, consume as much as production work and produce nothing a customer sees. Both are worth paying for; neither is in the quote.

Hosting is small but permanent. Queues, retry workers, logs, traces and stored documents — each line modest, the total only ever going up.

Put real numbers on one feature

Take invoice processing at four thousand documents a month, and put illustrative numbers on it — yours will be different, the shape will not be.

Suppose the model work comes out at two cents a document, and one in six needs a second pass: call it S$95 a month. Suppose one in twelve goes to a person at ninety seconds each — around eight hours, or roughly S$250 at a loaded hourly cost. Add S$80 of hosting and queueing, and half a day a month for someone competent to re-run the eval set and read the failures: S$400.

Which gives you about S$825 a month, of which the model calls — the part everybody asks about first — are eleven per cent. Now multiply the volume by ten. The model and the review scale straight up; the monthly checking barely moves. Your cost per document falls, and the human line is now S$2,500 and the single biggest thing you own.

The expensive line is usually a person

The automation rate is the number that actually decides your economics, and it is a fact about your process rather than about the model. If nine in ten cases go through untouched, the people cost is small. If it is six in ten, you have bought a model and kept the team.

That rate is set long before anyone writes code, by how much of the work is genuinely specified — which is why finding the exceptions before the build is also the main lever on running cost. An exception you can detect in code is cheap. One a person has to adjudicate is the most expensive case in the system, every time it occurs.

The checking has the same character. The eval set that tells you the thing still works is a standing monthly commitment, not a build task you finish — and where it is unbudgeted, what gets dropped is the evidence, not the feature.

What actually brings the number down

Send less. Retrieve three passages instead of twenty; pass the two relevant pages, not the whole file. The fastest saving available, and it usually improves the answers too.

Do the deterministic parts in code. Dates, totals, lookups and routing do not need a model. Each one you move out of the prompt permanently cuts both tokens and variance.

Route by difficulty. Most cases are easy. A small model handling those and escalating the rest costs a fraction of sending everything to the largest model available.

Raise the automation rate, not the model size. Moving from six in ten to eight in ten untouched saves more than any model change, because it is the people line you are cutting.

Set a cap and watch the trend. A per-day spend limit, and a cost-per-case chart beside your accuracy chart. A prompt change that quietly triples the context is otherwise invisible until the invoice arrives.

None of this argues against building — these features are frequently worth several times what they cost. The point is narrower: the decision rests on a number most proposals do not contain, and you can work it out in an afternoon, before anyone writes code.