How Much Does an AI Feature Actually Cost to Run?

You picked $29 a month because that is roughly what your competitors charge. Then you added the AI feature everyone kept asking for, and now you cannot tell me whether a $29 customer is making you money or quietly costing you money.

Most founders find out from the invoice. It arrives, it is four times what they expected, and it is one line item with no breakdown of which feature spent it or which customers were responsible. Then the conversation with their developer starts with "can we make this cheaper," which is the most expensive place to start.

You can know this number before you build. On Mira, an AI exam-prep product I built end to end as the sole architect and engineer, one quiz cost $0.009 in AI spend and the product broke even at seven paying users. I had both numbers before launch, because I instrumented every AI request to record its own cost as part of the build. That meant I could set a price with actual arithmetic behind it instead of a guess.

Three things get you the same number on your own product: knowing what the vendor is actually billing you for, counting the model calls honestly, and measuring them as they happen instead of waiting for the statement.

Why this is a new problem

Software has been a fixed-cost business for most of the last twenty years. Your servers cost roughly the same whether a hundred people log in on Tuesday or a thousand do. That is why SaaS pricing works the way it does: you set a price, and every additional customer is close to pure margin because the marginal cost of serving them rounds to nothing.

An AI feature breaks that. Every single use is a purchase. Someone clicks the button, your product sends text to a model, the model sends text back, and you get billed for both directions. Ten thousand uses is ten thousand purchases. The heaviest user on your free tier can cost you more in a week than a paying customer brings in for a month.

If your first version came out of Lovable, Replit, Base44, or Bolt.new, this is easy to miss, because adding AI there is one line in a prompt and the cost lands somewhere you do not look. The feature works immediately. The bill shows up thirty days later, and by then the feature is in front of customers and the pricing page is already public.

What you are actually paying for

You pay per token. A token is a chunk of text, roughly three quarters of a word, and you pay for tokens going in and tokens coming back. On the models I have worked with, output costs several times more per token than input, so a feature that writes a long answer is more expensive than one that reads a long document and answers in a sentence.

The part that surprises people is how large the input gets. What goes to the model on a single click includes far more than what the user typed. Your system prompt goes with it, which is the standing set of instructions telling the model how to behave. Whatever documents or database records your product retrieved to give the model context go with it too. And in any chat feature, the entire conversation so far goes along, resent from the beginning on every single turn, because the model has no memory between calls. Turn twelve of a chat costs meaningfully more than turn one, for the same question.

So "what does one use cost" depends on four things: how long your instructions are, how much context you attach, how long the answer is, and how many times you call the model per user action. That last one is where most of the damage happens.

Count the calls, not the features

On Mira, generating one piece of feedback meant two model calls. The first pass did the clinical analysis, working out what the answer revealed about the candidate's reasoning. The second pass rewrote that analysis in the voice and register the product needed. Two calls, one button, and a cost per use that was double what anyone would have estimated by looking at the screen.

I chose that structure deliberately. Clinical analysis and writing for a particular reader are different jobs, and I wanted each prompt to do one of them well instead of asking a single prompt to juggle both. It was the right call for quality and it doubled the unit cost, which is exactly the kind of tradeoff that should be made with the number in front of you rather than discovered afterward.

Then there are the calls nobody plans for: retries when the API times out, reruns when the model returns something your code cannot parse, and the regenerate button, which is the single most expensive UI element you can add because it invites the user to buy the same answer twice. Add the free-tier users who found the feature fun and the count climbs again.

One structural decision cuts the reruns down hard: ask the model for structured output validated against a schema, at temperature 0. Temperature is the creativity dial, and 0 means the model gives its most predictable answer. Schema validation means the response has to match a defined shape or it gets rejected. Together they make the output boring and reliable, and boring and reliable means your code does not have to ask twice. That combination is my default anywhere the output feeds another part of the system instead of being read directly by a person.

The model you pick is a pricing decision

The gap between the cheapest and most expensive model from the same vendor is often more than ten to one on the same request. That means model choice sets your margin, and it is usually being made by whoever wrote the feature, on the basis of what worked first.

On GoFixly, the fractional CTO engagement where I built an Office automation product, the model choice lived in configuration: a routing table that said which model handled which job, with the price of each model sitting right next to it. Changing the routing was a config change and a deploy, and the cost of each option was visible in the same place. That sounds like a small piece of housekeeping. It is the difference between "we could try the cheaper model on the classification step" being an afternoon and being a project nobody schedules.

Most products have at least two kinds of AI work happening. There is the work the customer reads, where quality is the product and you should pay for the good model. And there is the invisible work: classifying something, extracting fields, deciding which of five paths to take, summarizing for internal use. The invisible work is usually fine on a model that costs a fraction as much, and it is frequently the higher-volume half of your traffic.

Ask your developer one question: which model are we calling for each AI feature, and why that one? If the answer is that the same model handles everything because it was the one in the example code, you have found margin.

You cannot price what you cannot see

A monthly invoice tells you what you spent. It does not tell you which feature spent it, which customers drove it, or whether it is getting worse.

On both AI products I built, every request records its own cost. The token counts come back in the API response, the code multiplies them by the current per-model price, and that number gets attached to the request as a measurement along with the account it belonged to, so it can be added up per customer. I use OpenTelemetry for this, which is the open standard for instrumenting software, along with PostHog for tracing the AI calls specifically. On GoFixly that same per-request metering fed Stripe usage billing, so the customer's invoice and my cost for serving them came from the same measurement.

Tag each measurement with the feature as well and you can answer things that are otherwise guesswork: what your average customer costs you this month, which feature is eating the margin, whether last week's prompt change made the product more expensive to run. The one I care about most is what the top 1% of usage looks like, because that is the customer who tells you whether your pricing survives growth.

Having built this twice, my estimate is that a developer who knows the codebase can add it to an existing AI feature in a day or two. It is far easier to build in at the start than to retrofit after you have six features and a pricing problem. If you are about to ship your first AI feature, put it in the same ticket.

Doing the arithmetic

The calculation itself is arithmetic you can do on a napkin once you have real token counts, and getting real token counts should not take more than an afternoon. Your developer calls the feature the way a normal user would, prints the input tokens, output tokens, and number of calls, and multiplies by the published price per million tokens. Do it for the three heaviest paths through your product, not the lightest one.

Then the founder-side math:

Cost per use, times uses per customer per month, gives cost per customer per month. Compare that to your price. Subtract your other per-customer costs, hosting, payment processing, email, support tooling, and see what is left.

Run it three times: for your average customer, for a heavy customer at the top of your usage range, and for a free-tier user who never converts. The average tells you whether the business works at all. The heavy user is the one who tells you whether a single enthusiastic customer can make a month unprofitable, and the free user tells you what your funnel costs before anyone has paid you a dollar.

What comes out of that exercise is bigger than a price. It settles a handful of structural questions you are otherwise going to answer by accident: whether the AI feature belongs on the free tier at all, whether you need a usage cap and where it goes, whether the expensive model is earning its place on the high-volume path, and whether unlimited is a promise you can afford to make.

Anti-patterns to avoid

Pricing unlimited AI usage. Flat-rate pricing on a variable-cost feature works right up until you get a customer who really likes the feature. If unlimited is important to your positioning, at minimum set a technical ceiling per account so a runaway integration or a scripted user cannot generate a five-figure bill overnight.

Hardcoding the model name in the code. When the model is written into the code in a dozen places, switching to a cheaper or newer one becomes a code change with a review and a regression risk, so it never happens. Put it in configuration with the price next to it, and the experiment becomes trivial.

Estimating from the happy path. The honest cost includes retries, reruns from unparseable responses, the regenerate button, chat history growing on every turn, and the users who hammer the feature. Estimates built on one clean call usually come in low by a multiple.

Leaving the feature open to unauthenticated visitors. If anyone who loads your marketing page can trigger a model call, you are paying for traffic that has not even given you an email address, and eventually for a bot that finds it. Put the expensive paths behind a login and a rate limit.

Waiting for the invoice. The feedback loop on a monthly bill is thirty days long, arrives as a single number, and gives you no way to attribute it. You would not run your product's uptime that way.

How to start, gently

Pick your single most-used AI feature, the one customers actually touch. Ask your developer for three numbers on a real call: input tokens, output tokens, and how many model calls happen behind that one click. That should be an afternoon of work, and the third number is the one that surprises people.

Multiply it out and find your cost per use. Then multiply by however many times a typical customer does that thing in a month, and put the result next to your price. If those two numbers are uncomfortably close, you have found something worth knowing this week rather than next quarter.

Then ask for two small pieces of work. First, record the cost of every AI request as it happens, tagged by feature and by account, so the number stays current instead of becoming a one-time estimate that ages badly. Second, set a per-account ceiling so no single customer can run past what you are willing to spend on them.

You do not need to understand how the models work to do any of this. Treat the AI feature as a cost of goods sold, because that is what it is, and the rest follows.

What does one use of your AI feature cost you today? If you cannot answer that in dollars, that is the next thing to fix, and it is a smaller job than it sounds.

#FractionalCTO #StartupTech #BootstrappedStartup #CTOInsights