How to Price an AI Feature Added to an Existing Product

This post is about one specific situation: you run a SaaS product that already has a price on it, and you're adding a single AI feature to it. That's a different problem than pricing an AI product from scratch, where you're setting an entire price structure from zero with no existing customers or usage data to work from. It's also different from raising the price on an AI product you already sell, where the question is what your whole product is worth now that AI is built into it end to end.

Here we're assuming the rest of your pricing stays put. One new capability is going into the app, it costs you money to run, and you need to decide what happens to it: free, bundled, or billed separately. If you haven't settled whether to charge for it at all, that's worth resolving first, it's covered in deciding whether to charge extra for an AI feature. Once you know you're charging for it, or bundling it as a differentiator, the rest of this is about the mechanics: your cost per use, where the feature sits in your plan structure, and the cap that keeps one heavy user from costing you more than they pay.

Start with your cost per use, not your gut

Before picking a price, work out what the feature actually costs you to run per use. This is the number everything else depends on, and skipping it is how teams end up subsidizing their most active users without noticing.

• API or inference cost per call, input tokens plus output tokens, at whatever rate your model provider charges

• Any retrieval, embedding, or vector search calls the feature triggers alongside the main generation

• Compute for pre- or post-processing, if you're doing anything beyond a single API round trip

Say a document-summarization feature sends roughly 2,000 input tokens and gets back 400 output tokens per run, and your provider's rates work out to a few cents per call. If a user runs the feature 40 times a month, that's a couple of dollars in inference cost for that one user. That's the number to compare against price, not the sticker price of the model itself.

Once you have a real cost per use, set a target margin the same way you'd price anything else you sell: cost plus desired margin, not "what sounds reasonable." A common approach is pricing so the feature clears roughly 70-80% gross margin at expected usage, which leaves room for the users who use it more than average.

Decide where it lives: bundled into a tier, or a paid add-on

There are two structures, and the right one depends mostly on how much usage varies across your customers.

Bundle it into an existing tier when the feature's cost per active user is low and doesn't vary wildly, and when it functions as a reason to upgrade rather than a product on its own. Putting an AI feature exclusively in your top plan is a classic lever, it turns the feature into upgrade bait, and because everyone on that tier already pays more, the incremental cost is easier to absorb into the existing price.

Sell it as a separate add-on when usage is uneven. If some customers will run the feature twice a month and others will run it hundreds of times, bundling it flat means the light users subsidize the heavy ones, or you eat the difference. A metered or capped add-on keeps the price attached to the cost driver instead of guessing at an average. This is the same tension that shows up in usage-based versus flat-rate AI pricing, just scoped to a single feature instead of your whole product: flat and bundled is simpler to sell and support, metered and separate protects your margin when usage is lopsided.

A middle path works for a lot of teams: bundle a modest included allowance into the tier where the feature lives, then charge for usage past that allowance. That gets you the simplicity of a flat price for typical usage and the protection of metering for the outliers.

Set a usage cap before you launch, not after the first invoice

Whichever structure you pick, put a cap on usage before the feature ships. Without one, your cost is unbounded and your price is fixed, which is a bad combination.

Two ways to cap it:

• Hard cap: the feature stops working, or asks the user to wait, once they hit a set number of uses in a billing period. Simple to build, and it protects margin completely, but it can frustrate a customer mid-task if the ceiling is set too low.

• Soft cap with overage: usage past the included amount is billed per unit, similar to how cloud infrastructure or SMS pricing works. This keeps the feature available without a hard wall, and it turns your heaviest users into your highest-revenue users instead of your biggest cost center.

To set the number, work backward from the cost math above: take your target margin, figure out how many uses at your measured cost per use still clears that margin at the price you're charging, and that's roughly your included allowance. Pad it a little for the first few months, usage patterns before launch are usually a guess, and you'll want real data before you tighten the cap.

Whatever you pick, instrument it from day one. Track uses per customer against your assumed average, not just total feature usage. A single account running the feature 50 times more than everyone else will hide inside an aggregate number and quietly wreck your unit economics.

Roll it out without disturbing the price your existing customers already agreed to

The base product's price shouldn't move because you added one feature to it, that's a separate decision with its own math. What you're doing here is layering something new on top of a price that's already been agreed to, which means the rollout matters as much as the number.

• Grandfather existing customers into whatever plan structure they're already on if the feature is going into paid tiers; moving the goalposts on a plan someone already bought reads as a bait and switch, even if the AI feature genuinely makes the product better.

• Give a short free trial window of the feature, capped in scope, so customers can see the value before you turn on billing for it. A week or a fixed number of free uses works better than an open-ended freebie.

• Announce the cap and the pricing at the same time you announce the feature, not after someone hits an invoice they didn't expect. Surprise charges on a feature nobody asked to be metered are the fastest way to generate support tickets and churn.

• Watch actual usage for the first month before you finalize the cap number. Your pre-launch cost model is an estimate, real customers will use the feature differently than you expect, usually more unevenly.

A quick example to tie it together

Say your product is a project management tool at $29 per user per month, and you're adding an AI feature that auto-drafts status reports from task data. Your estimated inference cost per report is a few cents, and your data suggests an active user might generate 15 to 20 reports a month.

At roughly $0.05 per report and 20 reports, that's about $1 in monthly inference cost per heavy user. Bundling 20 reports into a $49 per user per month plan costs you roughly $1 of margin per active user, on a plan that already has $20 more headroom than your base tier. An easy trade for a feature that makes the upgrade worth it.

If you'd rather sell it on every plan instead of gating it to one tier, you could offer 10 reports a month included, with additional reports billed at $0.25 each past that. Ten reports costs you about $0.50, comfortably inside almost any plan's margin, and the overage price covers your cost on heavy users while giving you a second revenue line.

For the broader question of how AI features fit into your pricing over time, see AI monetization strategies. This post is just the mechanics for the one feature you're shipping next.

FAQ

How much should I charge for an AI feature I'm adding to an existing product?

Start from your actual cost per use, not a market benchmark. Work out inference cost per use, decide on a target gross margin, and price from there. Whether that ends up bundled into a tier or billed as a metered add-on depends on how much usage varies across your customer base.

Should the AI feature be free for existing customers or should everyone pay?

That depends on whether it's a retention feature or a monetization feature. A short, capped free trial for everyone is a common middle ground, it lets customers feel the value before you turn on billing, without giving away unlimited usage indefinitely.

How do I estimate my AI inference cost per user before launch?

Multiply your expected input and output tokens per use by your model provider's per-token rate, then multiply by expected uses per user per month. Add any secondary calls the feature makes, like retrieval or embeddings. Treat the result as a rough estimate until you have real usage data, then revisit the cap and price.

What's a usage cap and why does a single AI feature need one?

A usage cap limits how many times a customer can use the feature within a billing period, either as a hard stop or as a point where overage billing kicks in. Without one, a small number of heavy users can consume a disproportionate share of your inference budget while paying the same price as everyone else.

Should I bundle the feature into a plan or sell it as a separate add-on?

Bundle it when the cost per active user is low and fairly consistent and the feature works as an upgrade incentive. Sell it separately, usually metered, when usage swings widely between customers, since a flat bundled price will let your heaviest users cost more than they pay.