AI copilot pricing: add-on or in the base plan
AI copilot pricing is a margin and expansion decision, not a packaging fashion. A clear point of view on add-on vs included, tied to a metric you already track.
Sohanur RahmanAI Copilots & Assistants7 min read
A copilot is the first feature you have ever shipped whose cost goes up every time a customer loves it. Every other feature in your product is near-zero marginal cost. Once it is built, a hundred more users cost you almost nothing. A copilot is the opposite. Each answer it gives runs a model, and that model bills you per call. That single property is why ai copilot pricing breaks the flat-rate instinct that built your whole pricing page.
So the question lands on the roadmap as a packaging decision: do you bundle the copilot into the base plan, sell it as a paid add-on, or meter it by usage? Most advice answers with a menu of pricing models and leaves you to guess. We think the choice is simpler and harder than that. It is a margin-and-expansion decision, and the right answer depends on one number you already track. Before you price the copilot, tie it to a metric you already track, because that metric is what decides which packaging shape pays off.
Why AI copilot pricing is a different problem than feature pricing
The reason this feels hard is that a copilot has a cost of goods sold, and your other features do not. A search bar, a dashboard, an export button: each one is sunk engineering cost and then effectively free to serve. A copilot carries a real, estimable compute cost on every interaction, because each call runs inference against a model you rent.
That cost compounds at the company level. Andreessen Horowitz, looking across the financials of AI companies, found gross margins often in the 50-60% range, well below the 60 to 80 percent that comparable SaaS businesses enjoy. The gap is the inference bill.
"We have seen a surprisingly consistent pattern in the financial data of AI companies, with gross margins often in the 50-60% range, well below the 60-80%+ benchmark for comparable SaaS businesses." (Andreessen Horowitz)
If you price a copilot the way you price a feature, with a flat seat fee and no thought to usage, you have quietly signed up to subsidize your heaviest users out of the margin on your lightest ones. That works until the power users find the copilot. Then it does not.
Should an AI copilot be a paid add-on, or belong in the base plan?
The decision rule is this: package the copilot where it does the most for the metric you are trying to move, and price it so that heavy usage does not invert your margin. Those are two constraints, not one, and they pull in different directions. Coverage wants the copilot in the base plan so every customer feels it. Margin wants a usage ceiling so no single customer drains you.
Here are the three shapes and the job each one is good at.
| Packaging shape | What it serves | When it fits | The risk |
|---|---|---|---|
| Included in base plan | Adoption and retention | The copilot is core to the job-to-be-done and you want every user inside it | COGS scales with success; margin compression if usage runs hot |
| Paid add-on | Expansion revenue, clear value attribution | The copilot is a distinct capability a segment will pay extra for | Lower adoption; the people who need it most may not buy it |
| Usage-metered | Margin protection on heavy users | Cost per call is high and usage varies wildly across accounts | Pricing friction; users fear the meter and under-use a product copilot you want them to lean on |
The cleanest real-world signal comes from watching what mature products do over time. Notion launched its AI as a paid add-on, then bundled it into its Business and Enterprise plans while keeping a limited free allowance on lower tiers. That is the pattern in motion: start the copilot as an add-on to prove people will pay, then move it into the plan once it is clearly driving retention, because at that point keeping it separate just suppresses the adoption you want.
How do you price an AI feature in SaaS without killing your margin?
Start from the floor, not the ceiling. The floor is COGS. Frontier model APIs are priced per million tokens of input and output, so you can estimate, per copilot interaction, what a typical exchange costs you. Multiply that by expected interactions per active user per month, and you have the variable cost the price has to clear.
Monthly copilot COGS per user
= avg_interactions_per_user
× avg_tokens_per_interaction
× model_price_per_token
Floor price per user
= (COGS per user) ÷ (target gross margin)
Packaging rule:
IF COGS varies < 2x across users → include in plan, price for the median
IF COGS varies > 5x across users → meter the top, include a baseline
ELSE → add-on with a usage allowanceThis is not about charging more. It is about not pricing a service like a feature. A copilot for an ai copilot for saas workflow that calls the model ten times per session behaves like a metered utility, even if it looks like a button. Price it like a button and the variance in usage becomes variance in your margin.
WARNING
The most expensive copilot is a free one your power users love. A generous free tier on a high-COGS copilot does not look risky on the pricing page. It looks generous. Then a handful of accounts run thousands of calls a day, and the feature that was supposed to lift retention is now a line item your CFO asks about. Cap free usage on anything that calls a model.
Packaging for expansion, not just coverage
The trap is treating the copilot as coverage: a thing every plan should have so nobody feels left out. Coverage is a cost story. The packaging line earns its place when it tells an expansion story, when the copilot moves customers up a tier or lifts net revenue retention rather than just raising your token spend.
That is the test we apply to any AI feature before it ships, and packaging is no exception. The copilot is worth a dedicated pricing line when its projected ROI shows up as expansion, not when it shows up as usage. Usage is a cost. Expansion is the return. If you cannot draw the line from the copilot to a tier upgrade or a retention lift, you are pricing activity, not value. The same discipline that decides which features get scored against a metric and a cost decides whether a copilot deserves its own SKU, and whether you have done enough to drive adoption deep enough to matter before you put a wall in front of it.
A 4-question packaging test for your copilot
Run these four questions before you commit a packaging line. They take an afternoon, and they replace a quarter of pricing-page debate.
- What does a typical interaction cost us, end to end? If you cannot answer in dollars, you are not ready to price. Estimate the COGS first.
- How much does that cost vary across accounts? Low variance favors including it; high variance favors a meter or an allowance.
- Does the copilot move a tier or a renewal? If yes, package it where it drives that motion. If you are not sure, instrument the copilot metrics that prove it before you decide.
- What happens at 10x usage? Model the heavy account, not the average one. The average account never breaks your margin. The outlier does.
NOTE
There is no single correct answer here, and the answer changes as the product matures. An add-on at launch can become a base-plan feature at scale, exactly as Notion's path shows. Revisit the packaging line every time usage patterns or model costs shift meaningfully.
Packaging is where a copilot stops being a demo and starts being a business, or quietly stops being one. Get ai copilot pricing wrong and a feature customers love becomes the line item that erodes the margin those same customers were supposed to expand. Get it right and the copilot pays for its own inference and then some, because the packaging is pointed at the metric that funds it. The decision is not which pricing model sounds modern. It is which one keeps the copilot on the right side of your margin while it grows.
TIP
Not sure whether your copilot belongs in the plan, in an add-on, or behind a meter? How the AX Audit works. We model the COGS against the metric you already track and hand you the packaging call, including the case for not charging at all.
