How to price an AI feature in your SaaS product

Model prices below are OpenAI's API list prices on September 22, 2026, standard tier and short context; the Fast tier runs at 2× those rates and the Ultrafast tier at 6×, with Ultrafast offered only on GPT-6 Astra and GPT-6.1 Sol. Vendor prices are list prices from each vendor's own pricing page on that date, and Agno's are from agno.com/pricing. All of them change often.

Price an AI feature on the value the customer can see, in a unit they can predict, with enough margin to absorb a model-price change you didn't plan for. Four models pass that test: bundle the feature into existing seats, charge for usage on a metric your customer already counts, sell it as a separate AI tier, or charge by the end users it reaches. Pricing by token or by trace fails on all three counts and belongs in your internal dashboards, never on an invoice.

Say you sell an invoicing product with a collections agent built into it. The agent works. It answers "what does Northwind owe us?" for your customers' finance teams and drafts the overdue-invoice emails they used to write by hand. Sales wants a number for the deck by Friday. Finance wants to know what the feature costs before they'll sign off on the number. And you've never priced anything whose cost of goods moves every time a model provider edits a price list. What follows is the number and the arithmetic under it. How to build an agent for your product and serve it everywhere covers building that agent, but nothing on this page depends on having read it.

What are the pricing models for AI features and agents in SaaS?

Most teams start with bundling, because it needs no billing work. Notion, Slack, and every "AI is now included" announcement took this path. It holds when the feature's cost per seat is a small fraction of the seat price and usage across seats stays tight. It fails quietly when usage spreads: the median seat costs you $1 a month, the 95th-percentile seat costs you $40, and there's no line item to point at.

Usage on your own metric charges for the thing the customer already measures. Intercom's Fin bills $0.99 per outcome. Zendesk bills per automated resolution, with an allowance in each plan and overage beyond it, and doesn't publish the rate. Salesforce sells Agentforce on Flex Credits at $500 per 100,000 credits, and its own worked example spends 40 credits, about $0.20, on a request. The unit is a business outcome, so the buyer can forecast it and their finance team can approve it. The requirement is that you meter that unit per customer, which is covered below.

A separate AI tier puts the feature behind a plan step. It's the cleanest to communicate and the easiest to launch, since it reuses your plan machinery. Its weakness is adoption. A customer on the plan below never tries the feature, and the ones who upgrade are the heavy users, so your cost per paying customer skews high. Pair the tier with a trial or a monthly allowance on lower plans if you want the feature to spread.

End users reached charges your customer by the number of their users who used the AI feature that month. It fits products where the customer isn't the person typing: support agents, in-product assistants for a customer's own customers, agents you've published to Claude and ChatGPT. It ties your revenue to the customer's adoption, and it's the model AgentOS's per-user metrics make easy to bill. Watch for the customer with 10,000 end users and 40 active ones, and price the first tier as a low fixed fee rather than zero. And when the end users are anonymous, with no account behind them, none of the four models can bill them at all; that case is below.

Why not price per token or per trace?

Because the buyer can't forecast it and the incentives run against the customer.

A customer can estimate how many invoices they'll send next quarter. Nobody can estimate how many tokens their finance team will consume, and a quote that says "about 40 million tokens a month" gets a follow-up call instead of a signature. Per-trace pricing has the same problem one level up: a trace is a unit of your observability stack, and the customer has no way to know why one question took one trace and the next took four.

The incentives do more damage than the confusion. Bill per token and a verbose system prompt makes you money. A model upgrade that answers in half the tokens costs you revenue. A customer who learns that shorter questions are cheaper starts writing shorter questions, the agent gets worse, and the product takes the blame.

Meter tokens internally and price on something the customer can see.

How much does an AI agent cost per user?

It depends on turns per conversation, tokens per turn, and which model answers, so here is the arithmetic for the two shapes that come up in almost every pricing conversation. Model prices are OpenAI's API list prices on September 22, 2026, standard tier and short context: GPT-6 Sol at $2.00 per million input tokens and $10.00 per million output, and GPT-6 Luna at $0.10 input and $0.50 output. Swap in your provider's numbers; the structure holds.

Example 1: a support agent at 10,000 end users

Your customer runs a product with 10,000 users. Twenty percent contact support in a given month, so the agent handles 2,000 conversations. A conversation averages six turns, and each turn carries the growing history plus retrieved help-center content, so call it 4,000 input tokens and 300 output tokens per turn.

Per conversation, on Sol:

• Input: 6 × 4,000 = 24,000 tokens × $2.00 / 1M = $0.048
• Output: 6 × 300 = 1,800 tokens × $10.00 / 1M = $0.018
• Model cost: $0.07 per conversation

Add retrieval, a guardrail pass, and the occasional retry, and a realistic all-in cost is about $0.15 per conversation, or $300 a month for this customer.

Now price it three ways:

• Per outcome at $0.99 (the Fin benchmark), with the agent resolving 70% of conversations: 1,400 × $0.99 = $1,386 a month, a 78% gross margin on the feature.
• Per end user reached at $0.25 per active user: 2,000 × $0.25 = $500 a month, a 40% margin. Easy to sell and thin to run.
• Bundled into a plan with 20 agent seats at $50: the $300 costs $15 per seat, 30% of the seat price. Bundling only works here if the seat price rises.

What breaks it: a customer whose users send 20-turn conversations doubles input cost, because history grows with every turn. Session summarization, which AgentOS runs for you, caps that growth. A switch to GPT-6 Astra at $10.00 and $50.00 per million takes the per-conversation cost from $0.15 to about $0.75, and both the per-outcome and the per-end-user price go underwater.

Example 2: an in-product copilot at 500 seats

Your customer has 500 seats on a $50 plan. The copilot sits in the sidebar and answers questions about what's on screen, so each request carries the page context: 6,000 input tokens and 400 output tokens. An active seat makes 30 requests a working day, about 660 a month.

Per request:

• On Sol: 6,000 × $2.00 / 1M + 400 × $10.00 / 1M = $0.012 + $0.004 = $0.016, or $10.56 per seat per month
• On Luna: 6,000 × $0.10 / 1M + 400 × $0.50 / 1M = $0.0006 + $0.0002 = $0.0008, or $0.53 per seat per month
• Routed, 80% Luna and 20% Sol: $2.53 per seat per month

Now price it:

• Bundled into the $50 seat on Sol: $10.56 is 21% of seat revenue gone before anything else is counted. On the routed mix it's 5%, which a seat price can carry.
• AI tier at $20 per seat: an 87% margin on the routed mix, 47% on Sol alone.
• Usage on your metric doesn't fit. There's no business unit the customer counts; a question answered isn't one.

What breaks it: the spread. If 5% of seats make 150 requests a day instead of 30, those 25 seats cost $53 each on Sol. Bundled pricing has nowhere to put that. An AI tier absorbs it, because the heavy users are the ones paying the $20, and a per-seat monthly allowance with overage handles the outliers without touching the base price.

Across both costed examples, model choice moves cost by 20×, and it's the one variable you still control after launch. How to choose a model for each agent task covers how to send the cheap calls to the cheap model.

When there is no end user to bill

Some agents serve the public, and then none of the four pricing models apply. Agno's own docs agent is one: it replaced the Mintlify assistant on the docs site, runs on AgentOS, and answers anyone who arrives, anonymously, with no seat, no tenant, and no invoice to attach the cost to. The bill is set by traffic you don't control, hour to hour, so the only levers left are the ones inside the runtime: a rate limit per IP or per session, a cache for the questions that repeat, a cheap model on the default path, and a ceiling you enforce rather than hope for. Budget it as a marketing cost with a hard cap, and set the cap deliberately, because on a public agent that number is the pricing decision.

How do you price with headroom when costs move?

Your cost of goods for an AI feature depends on three things you don't control and one you do: the provider's price list, the model's verbosity, your customers' usage patterns, and which model you route to. Price for the version of all four that's worse than today.

Assume a 2× cost swing within the year on the model you've chosen; the gap between tiers is wider still. Provider price lists move in both directions, and a flagship tier at $10.00 and $50.00 sits next to an efficient tier at $2.00 and $10.00 on the same page. Your launch margin has to survive the feature running on the expensive one for a quarter.

Set the price on value first, then check the margin. Fin's $0.99 per outcome didn't come from token math; it came from what a human resolution costs. Start from what the customer pays today for the outcome, then confirm the arithmetic above leaves room.

Give every plan an allowance and an overage. The allowance keeps the base price simple. The overage keeps the 95th-percentile customer from eating the margin of the other nineteen.

Keep the unit stable and the price movable. If you bill per resolution, you can adjust the rate later without a conversation about what a resolution is. If you bill per token, every change reopens the definition.

And route before you raise prices. The routed mix in Example 2 cut cost 76% with no change the customer could see. Do that first.

How do I meter AI usage per customer for billing?

Record every run with the user, session, tenant, tokens, and cost, and aggregate by tenant on the billing cycle. All four pricing models need this, because bundled pricing without metering is how the 95th-percentile problem stays invisible until your provider's invoice arrives.

AgentOS records this on every run: token counts and cost per model call, tied to the user_id and session_id the run was made for, in the session metrics. Because the runtime authenticates each request with a JWT that carries the tenant, per-customer cost is a query over the runs table. The same records answer the adoption question: distinct user_id values per tenant per month is your end-users-reached count, and it belongs on the renewal deck whether or not you bill on it.

For the usage-on-your-metric model, meter the business unit too. A resolution or an invoice sent is a tool call the agent makes, so count successful calls of that tool per tenant. AgentOS's run history holds the tool calls, and the count is another query.

Bill only on what the customer can see in their own dashboard, and never on something the agent decided by itself. A customer who can see their 1,400 resolutions won't dispute the invoice. A customer told they used 41 million tokens will.

How do I control LLM cost per end user?

Set a monthly allowance per user or per tenant, route routine requests to the cheap model, cap history growth with session summarization, and alert on runs whose cost lands outside the normal range. Those four controls turn the 95th-percentile problem from a surprise on the provider invoice into a number you chose. On a public agent, where there is no account to hold an allowance, rate limiting per IP or per session and caching the answers that repeat do the same job.

The allowance is the pricing-side control: it's the line in your plan that says what's included, and it's what makes an overage possible. The other three are cost-side controls that run inside the agent. Routing moved Example 2 from $10.56 to $2.53 per seat. Summarization keeps a 20-turn conversation from carrying 20 turns of history into every call. Per-run cost alerts catch the loop that calls a tool forty times before anyone notices. AgentOS records cost per run, so the alert is a threshold on a number you already have, and the per-user allowance is a comparison against the same records you meter billing from.

Runaway cost in production almost always comes from one of three places: history that never gets summarized, a tool loop with no stop condition, or a heavy user on a bundled plan. The first two are agent configuration. The third is pricing, and it's why this page and the cost controls belong together.

How much does Agno cost?

Agno's platform pricing, as listed on agno.com/pricing on September 22, 2026:

• Free: $0 per month. Unlimited usage and retention, a local control plane for AgentOS, sessions, traces, memory, knowledge, metrics, evaluations, approvals, scheduling, and MCP integration with Claude Code, Codex, and Cursor.
• Pro: $150 per month. Adds a live control plane, one live AgentOS connection, three team seats, basic role-based access control, and email support. Additional seats are $30 per month each, additional live connections $95 per month each, and SAML SSO $300 per month.
• Enterprise: custom pricing. Adds end-user management and identity, end-user audit logs, custom RBAC with per-resource scoping, a service SLA, security reviews, and a self-hosted control plane option.

There are no per-event charges and no compute, storage, retention, or egress fees. You pay model costs to your provider directly; Agno doesn't resell tokens. It's the same choice this page recommends for your own product: a stable unit the buyer understands, with the variable cost kept internal.

How do you communicate a price change for an AI feature?

Lead with the unit, then the number, then the date, and give existing customers a runway.

Customers argue about the unit more than the number, so if the unit isn't changing, say that first: "You'll still be billed per resolution." If it is changing, explain the new unit before the new price, and show each customer their last three months restated in the new unit so they see the effect before it lands. Give at least one full billing cycle of notice, honor annual contracts to term, and give the reason in one true sentence: the model behind the feature costs more, or the feature now does more.

The change that goes badly is the one that arrives as a line item. If usage-based billing is new for a customer, ship the usage dashboard a month before the first usage invoice. Nobody disputes a number they've been watching.