.png)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
How SaaS Founders Should Choose Between PAYG, Fixed, and Hybrid Pricing for AI Services
AI has made a familiar SaaS pricing question harder, not easier. A founder can still charge a flat subscription, sell usage, or combine the two. Yet the economic consequences now differ sharply because an AI service can create variable model costs while also taking over work that a customer once performed through seats, services, or labor.
The wrong choice can damage both adoption and margin. A fixed price may invite heavy customers to consume far more inference and support than the account can sustain. Pure pay-as-you-go, or PAYG, can make buyers hesitate before using a product that needs repeated use to prove its value. A poorly designed hybrid can create two pricing systems that customers cannot explain to finance.
Monetizely’s position is clear: founders building AI services should default to a hybrid model with one named primary meter when their product completes repeatable customer work. Fixed pricing should anchor human-led copilots, while PAYG should lead for APIs and highly variable infrastructure. Hybrid pricing is not a compromise between two models. It is a deliberate structure: a fixed fee pays for access, governance, and predictable support; a single value-linked meter captures growing usage.
AI makes the gap between customer value and delivery cost impossible to ignore
Traditional SaaS could often charge by seat because a user was both the buyer’s unit of value and a rough proxy for vendor cost. An employee signed in, used a workflow, and needed support. The vendor’s marginal cost from an additional action was usually low.
AI services break that link. A single customer request can trigger retrieval, multiple model calls, workflow routing, tools, validation, and a human escalation. The cost can vary by a factor of ten or more between a short classification request and a long, multi-step research task.
OpenAI’s API pricing, for example, separates input and output tokens and prices models differently, making vendor cost visibly variable rather than hidden inside an annual license [5, accessed March 2025]. A founder that offers unlimited use at a fixed price while relying on such services is not merely simplifying the buying process. The founder is accepting an uncapped cost commitment.
At the same time, customers do not want to purchase tokens. A legal team does not budget for millions of tokens to review contracts. A support leader does not explain model calls to the CFO. They pay for resolved cases, reviewed documents, qualified leads, or capacity to serve more customers.
The pricing task, therefore, is to translate variable technical cost into a customer-facing measure of work and value.
Exhibit 1: Public AI pricing shows that the commercial meter follows the product’s role
The following examples show how established providers separate access pricing from work-based pricing. Prices and terms were publicly listed at the dates shown.
The pattern is direct: products that assist a named human favor subscription, products that complete a defined piece of work favor a work-based meter, and infrastructure favors PAYG.
The Agentic Monetization Spectrum, or AMS, helps founders choose a metric by examining three questions that determine how an AI product creates and captures value. First, zero-human ability asks how far the product can complete work without a person directing or reviewing every step. Second, operational domain asks whether the product handles a narrow task or operates across a broader business workflow. Third, output/cost ratio asks whether the value of a completed result materially exceeds the variable cost required to produce it. As discussed in Monetizing Agentic AI, these dimensions matter because a product that assists a person should not be priced like one that independently resolves work, and a product with unstable delivery costs should not promise unlimited use at a low fixed price.
A score does not produce a price card by itself. It disciplines the founder’s choice of primary meter. The higher the autonomy, the broader the work performed, and the greater the value relative to cost, the less credible a pure seat price becomes.
Scores use a 1-to-5 scale, where 1 is low and 5 is high. The recommendations are Monetizely assessments of common AI product types, not vendor disclosures.
The AMS places most workflow agents in hybrid territory because they need both a stable access fee and a value-linked meter, with the work unit serving as the primary commercial measure.
Fixed subscriptions remain valuable. They are easy to approve, easy to forecast, and familiar to buyers. A product manager can put “$30 per user per month” into a budget without estimating future tasks or negotiating a credit pool.
For AI copilots, that clarity supports adoption. GitHub prices Copilot Business per user, while its public plan description emphasizes code suggestions, chat, and developer workflows rather than autonomous delivery [2, accessed March 2025]. The user still decides what code to accept, runs tests, and takes responsibility for the result. The seat remains connected to the buyer’s value.
Cursor follows a related logic. Its paid plans create a predictable monthly commitment while placing limits around included agent and model use [3, accessed March 2025]. The approach recognizes a practical fact: software developers want everyday access, but an AI coding product cannot promise that every user will generate unlimited high-cost work.
Founders should use fixed pricing as the primary model when all three conditions hold:
- A named user is present in nearly every workflow.
- Customer value rises mainly through personal productivity rather than completed autonomous work.
- Heavy usage does not create large differences in variable cost between customers.
A meeting-summary copilot sold to a 50-person sales team fits this model. Each seller uses the assistant, checks the notes, and follows up with a prospect. Charging $30 per seller per month is legible because the firm is buying better individual performance.
A fixed price becomes risky when the agent can do the same work for 50 sellers with only two people supervising it. The customer’s seat count may decline just as the product’s importance rises. That outcome is commercially perverse: the vendor earns less when its AI works better.
PAYG pricing has a different job. It lets a customer start small, connects revenue directly to consumption, and protects the provider where each request has materially different costs.
OpenAI’s API is the clearest example. Developers choose among models and pay according to input and output token volumes at listed rates [5, accessed March 2025]. The buyer is assembling an application and bears responsibility for how those tokens become business value. PAYG is appropriate because the provider sells capacity, not a guaranteed workflow result.
The model also fits AI data services with volatile input sizes. Consider a platform that processes images, audio files, and scanned records. One customer may submit a 30-second recording; another may submit a two-hour call with dense technical language. Charging a single flat fee for both can create margin damage before the company has enough usage data to price responsibly.
Yet PAYG should not be confused with value pricing. A customer service executive does not wake up wanting to buy 10,000 agent conversations. The executive wants fewer tickets, faster response times, or higher containment. PAYG can be the delivery mechanism, but it is rarely the most persuasive value story for an end-user workflow.
Pure usage pricing also creates behavioral friction. When every action appears to increase a bill, users may test less, automate less, and reserve the service for exceptions. That response weakens adoption precisely when an AI product needs volume to improve workflows and prove its worth.
Hybrid pricing works only when one meter leads the buyer’s conversation
Many founders hear “hybrid” and conclude that they should add a platform fee, credits, seats, overages, model tiers, and implementation fees. Such a package may cover every cost. It may also make the product impossible to buy.
A sound hybrid has a clear hierarchy. The fixed component pays for the continuing right to use the product: workspace access, integrations, security controls, administration, and support. The variable component measures the unit of work that grows with customer value and delivery cost.
Intercom’s published Fin pricing illustrates the direction. It charges per resolution rather than per user, tying the variable charge to the agent solving a customer issue [4, accessed March 2025]. Salesforce’s published Agentforce pricing similarly frames the transaction around a conversation handled by the agent [6, accessed March 2025]. Neither meter is perfect for every service, but both move the discussion beyond model inputs.
Exhibit 3: A primary-meter decision matrix separates three viable architectures
The purpose of this matrix is not to balance all models equally. It identifies the conditions under which each model can carry the commercial relationship.
For most vertical AI and agentic SaaS products, the final column offers the stronger architecture because it aligns recurring revenue with both buyer confidence and the work the agent performs.
Monetizely’s 5-Step Pricing Framework turns the choice of model into an operating decision rather than a website-pricing exercise. The five steps are goals and segmentation, packaging, pricing metric, price points, and operationalization. A founder begins by deciding which customers the product is built to win and what business goal the pricing must serve. The company then designs packages for those customer groups, chooses the meter that best reflects value, sets prices against willingness to pay and cost, and builds the product, billing, and finance processes to enforce what was sold.
The order matters. Founders often begin with a price, such as $99 per month, because it feels concrete. That shortcut can produce a plan that does not fit any real buyer, cannot be metered reliably, or rewards customers for avoiding the value-producing activity.
A revenue-operations agent provides a useful example. Suppose it researches target accounts, enriches records, drafts outreach, and logs work in a CRM. The buyer may be a sales leader seeking more qualified opportunities, not an operations manager seeking token capacity.
The five decisions would lead to a focused package:
- Goals and segmentation: Target mid-market B2B sales teams with high lead volumes and inconsistent research coverage.
- Packaging: Include CRM integration, manager controls, onboarding, and a volume of completed account-research workflows.
- Pricing metric: Charge primarily per completed, verified account workflow, not per agent prompt.
- Price points: Set tiers around expected monthly account volumes, with a committed annual amount.
- Operationalization: Log when the agent completes the required research fields, writes the output to the CRM, and passes quality checks.
A package designed this way gives the buyer a budget line and gives the vendor a measurable basis for revenue, margins, and product entitlements.
The strongest AI meters have three qualities. Customers can see the event, finance can reconcile it, and neither party can easily manipulate it.
“AI action” fails the first test. It does not tell a buyer what happened. “Credits” may be useful as an internal billing tool, but credits are usually an accounting wrapper, not a value measure. “Completed customer verification,” “resolved ticket,” or “processed claim” is stronger because a business operator recognizes the work.
The design review should test every proposed meter against four questions:
- Can the customer identify the event in the product without asking support?
- Does the event occur after meaningful customer value has been delivered?
- Does the event have a consistent relationship to model, infrastructure, and support cost?
- Can product logs, invoices, and revenue reporting use the same event definition?
A founder should avoid charging for a task merely because an agent started it. An outbound sales agent that drafts 1,000 emails but sends none has not completed a valuable workflow. A support agent that replies to a customer but immediately escalates the case may not have delivered a resolution. Event definitions need quality gates.
Exhibit 4: A three-year scenario shows why a primary meter protects both adoption and margin
Consider an AI support agent sold to a company with 25 human support representatives. The customer expects 100,000 support conversations per year and expects the agent to resolve 30% of them. The figures below compare simplified commercial approaches.
| Pricing approach | Annual customer charge | Vendor revenue over 3 years | What happens if resolved volume doubles |
|---|---|---|---|
| Fixed: $60,000 annual subscription | $60,000 | $180,000 | Revenue stays flat while AI and support costs rise |
| PAYG: $0.99 per resolved case | $29,700 at expected volume | $89,100 at expected volume | Revenue rises, but annual spend can feel uncertain |
| Hybrid: $36,000 platform fee plus $0.75 per resolved case | $58,500 at expected volume | $175,500 at expected volume | Revenue rises to $81,000 annually, while the buyer retains a known base commitment |
The hybrid structure preserves the customer’s ability to forecast a baseline budget while allowing the provider to share in adoption that creates more verified value.
Founders should choose architecture before they choose a price point
The key mistake is treating pricing as a choice between customer simplicity and vendor economics. A properly designed work-based hybrid can achieve both. The customer sees one meaningful variable unit. The provider gains a recurring base and protection from heavy, valuable usage.
Monetizely’s position is that founders should not lead with fixed pricing merely because SaaS buyers recognize it, nor lead with PAYG merely because AI costs are variable. Start by identifying whether the product assists a user, sells capacity, or completes business work. Then make that answer visible in the primary meter.
Classify the product by customer role before setting any list price. Decide whether the AI is a copilot, an infrastructure component, or an agent that completes a workflow. Make the pricing model follow that role.
Set a named primary meter for every hybrid offer. Use a completed task, verified output, resolved conversation, or case. Do not make credits the central commercial story.
Price the fixed component for enduring access, not for unlimited AI labor. Reserve the subscription for integrations, controls, support, administration, and the platform’s continuing value.
Build product telemetry around the billable event before broad rollout. The product team, finance team, and customer-success team should all be able to see the same completion record.
Treat high-cost usage as a product-design signal. If a small set of accounts creates most model cost, investigate workflow design, routing, model choice, and quality gates before raising prices across the customer base.
Footnotes
- Monetizing Agentic AI, Amazon listing: https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/
- GitHub, “GitHub Copilot pricing,” official pricing page, accessed March 2025: https://github.com/features/copilot/plans
- Cursor, “Pricing,” official pricing page, accessed March 2025: https://www.cursor.com/pricing
- Intercom, “Fin AI Agent pricing,” official pricing page, accessed March 2025: https://www.intercom.com/pricing
- OpenAI, “API Pricing,” official pricing page, accessed March 2025: https://openai.com/api/pricing/
- Salesforce, “Agentforce Pricing,” official pricing page, accessed March 2025: https://www.salesforce.com/agentforce/pricing/