Usage-Based Pricing Models for Agent-Powered Products

Software pricing has treated a user as the basic unit of value for twenty years. A seat meant one person, one login, one stream of work, and revenue scaled in step with those people. That assumption held as long as each user was the one doing the labor inside the product.

AI agents break it. The seat no longer describes the economics on either side of the transaction. It does not explain what the buyer receives, and it does not explain what the vendor spends to deliver it.

Vendor cost now tracks compute, tokens, and actions, not the number of named users. A flat per-seat fee creates winners and losers inside the same customer base. One customer running high volumes of AI queries can cost a vendor dramatically more than another customer paying the identical seat fee, and the margin leaks silently until the model stops working. Agent37 handles per-user agent isolation automatically, which makes it easier to decouple pricing from seats, because the infrastructure overhead of serving one agent per customer no longer constrains the pricing model itself.

The five dimensions that determine which pricing unit fits a given agent

Choosing a pricing model for an agent-powered product starts with five questions, and the order matters. Skipping these questions lets a product launch with a unit that either leaks margin or creates buyer friction, regardless of how reasonable the headline price looks. First, what value does the agent create? Pricing should follow value, not only activity. An agent that resolves a support ticket delivers a different kind of value than one that drafts a document the human still reviews, and treating those two as the same unit will misprice one of them.

Second, what unit of work can be reliably measured? Billing requires a unit that can be metered, audited, and explained to a buyer. Tokens work for API-heavy products, resolutions work when the outcome is binary, and actions work when workflows are well-defined. If no clean unit exists, the pricing model will fail before the product does.

Third, what cost does each unit create for the vendor? Margin depends on cost visibility. A unit that is easy to measure but loosely coupled to underlying cost, such as a per-seat fee when token consumption varies wildly across customers, will erode margins unpredictably. The unit has to tell a true story about what the vendor pays to serve it.

Fourth, can the customer predict or control their usage? Buyer trust depends on explainability. A model that produces surprise bills kills pilots even when the underlying product works well. Fifth, can finance track profitability at the unit level? A model that is commercially attractive but operationally opaque creates billing disputes and revenue complexity that compounds at scale.

Two more dimensions matter specifically for agents. Autonomy measures how much the agent acts without human supervision. Higher autonomy means the agent's own design choices, like how many tool calls it makes, how long its context window runs, and how many retry loops it enters, move the bill. Agent design becomes a cost-management lever, not just a quality lever. The autonomy dimension becomes operationally tractable when the hosting platform exposes granular metrics on agent behavior. Agent37's per-customer agent sandboxes and integrations with standard productivity and developer tools provide the observability needed to verify whether a chosen unit, per-action, per-conversation, or per-execution, is actually predictable and fair across a customer base.

Attribution asks how cleanly a result can be credited to the agent. Outcome-based models require this to be unambiguous. Usage-based models sidestep attribution entirely but push the value question back onto the buyer, who must decide whether the activity was worth paying for.

Usage-based pricing: what it actually costs, where it works, and where it breaks

Usage-based pricing has become the most widely adopted model for agent products because vendor costs genuinely scale with consumption. But its pure form carries a cost-anxiety problem that makes it commercially fragile without a floor. The unit itself varies by product type, and the choice of unit changes how the model feels to a buyer.

Per-token or per-API-call pricing is transparent and technically precise. Per-action pricing is granular, but it is hard to forecast when agent design determines the action count. Salesforce AgentForce charges $0.10 per agent action via Flex Credits, a price that is simple to state and nearly impossible for a buyer to project across a quarter.

Per-workflow execution charges for a completed workflow regardless of internal action count. Per-conversation or per-vCPU-hour pricing right-sizes cost to actual compute, but it requires buyers to understand infrastructure units. Amazon Bedrock AgentCore charges only for active consumption, at $0.1276 per vCPU-hour and $0.0169 per GB-hour on the v2 microVMs that became the default as of October 2026.

The deeper problem is that an autonomous agent decides how many actions to take, so the bill is not simply a function of traffic volume. At nine prepaid packs of $200 each, that is $1,800 per month, a figure no buyer can derive from a user count. Agent efficiency, meaning fewer tool calls, tighter context, fewer retries, is a direct margin lever. When usage-based pricing depends on a unit like per-action or per-token, the agent's own design choices become cost drivers that founders must monitor and optimize. Agent37 provides that isolation and visibility, which makes the testing step practical rather than theoretical.

Usage-based pricing works cleanly when costs are tightly coupled to consumption and buyer value scales with it, when buyers are technical enough to think in API calls or executions, and when the product has low minimum viable usage so small users pay small bills. The surprise AWS bill dynamic is real, procurement teams cannot budget for variable costs, and the model punishes effective agents that do more work even as it rewards efficient ones. Most successful usage-based products layer a subscription floor on top, which is where the next section picks up.

Outcome-based pricing: the model that sounds best and is hardest to operate

An e-commerce company running Intercom's Fin agent watched its bill triple as the agent got better at resolving tickets. It is the model that best aligns vendor incentives with buyer value, and it shifts operational risk onto the vendor in ways that require tight outcome definitions, reliable attribution, and cost floors, none of which are trivial to build. The structure is simple on paper. Intercom Fin charges $0.99 per resolved ticket. HubSpot moved its Breeze Customer Agent to $0.50 per resolved conversation, down from $1.00, effective April 14, 2026, citing performance data across more than 8,000 customers who had activated the agent. That price cut signals how quickly competitive pressure reaches even the resolution-fee tier. The term "resolved" is not neutral, and that is the model's first failure point. That is infrastructure work, not just pricing work. The cost-floor problem is the second failure point. At scale, a high failure rate on complex queries can make the model unprofitable even when headline resolution rates look strong. Outcome-based pricing fits when the result is binary and unambiguous, when the vendor has enough data on resolution rates and per-resolution compute cost to set a price that protects margin across the distribution of query complexity, and when the buyer is risk-averse and values the pay-for-results guarantee over cost predictability. Builders who launch on an outcome model should expect to revise it within twelve months.

Hybrid pricing: why most production agent products converge on a floor-plus-variable structure

Hybrid pricing dominates production agent products not because it is elegant but because it is the only structure that simultaneously protects vendor margin, gives buyers budget predictability, and scales with actual usage. It is the structurally correct answer for most agents in production. Hybrid takes several distinct forms. Tiered flat plans with consumption limits are simpler to sell but create the overage cliff risk, where a bill spikes sharply at a threshold rather than scaling smoothly. The e-commerce company that switched from Intercom's per-resolution model to a capped hybrid plan did so precisely to escape that dynamic. The hybrid structure has become dominant for three reasons. Once the model is chosen, the next problem is building the billing and metering infrastructure to run it, which is where most builders get into trouble.

The operational infrastructure a pricing model requires before it can be billed

Every pricing model for an agent-powered product requires a distinct metering and billing infrastructure, and that infrastructure must exist before the first invoice. Builders who underestimate this cost often discover it only after they have committed to a model they cannot operate at scale. Usage-based pricing demands metering at the action or token level, rate tables, cost-visibility dashboards for the buyer, spend limits or alerts to prevent surprise bills, and real-time cost attribution per customer instance. The operational complexity compounds.

The per-customer isolation requirement sits underneath all of it. A shared agent instance cannot attribute cost or outcome to individual customers. The billing model and the deployment architecture are not independent decisions.

For founders building agent-powered products, this is the hidden cost center. The operational labor of provisioning, monitoring, metering, and billing one agent per customer, repeatably, at scale, is the work that consumes founder time before a single dollar of revenue is recognized. Every hour spent managing infrastructure is an hour not spent refining the agent or selling to the next customer.

How managed agent hosting changes the economics of pricing model execution

A managed hosting platform that provisions isolated, persistent, per-customer agent instances eliminates most of the operational infrastructure that makes usage-based and hybrid pricing hard to run. It changes what a founder can realistically launch. One API call provisions an always-on sandbox per customer, with kernel-level isolation enforced by gVisor, and each instance keeps its own files, memory, and sessions that persist until the operator deletes it. The platform also supports one-click deployment of agents including OpenClaw, Hermes, Claude Code, Codex, OpenCode, and Grok.

That pairing of isolation and observability is what makes a pricing model executable rather than just designable. Compute meters by the minute, at $0.0011 per vCPU-hour, $0.00096 per GB-hour for memory, and $0.00012 per GB-hour for disk, with compute charges pausing when a sandbox sleeps and disk billing only while it is retained. A founder running outcome-based pricing can audit each resolution against a clean per-instance trail.

Other managed platforms address parts of this stack. Stammer AI, at $99 per month for its Pro White Label tier, offers five chat agents and five voice agents with full white-label branding and reseller controls. Lety.ai sells white-label vertical AI agents with more than 900 MCP integrations, used by agencies across multiple industries. Both are useful for their own buyers, and neither is a substitute for the isolation and metering layer that a usage-based or hybrid model needs underneath it.

Matching the pricing model to the agent's actual work: a decision framework

The right pricing model for an agent-powered product is not a preference. It is a function of what the agent does, how costs accumulate, and how buyers perceive and measure value. Matching those three variables to the right structure separates a pricing model that scales from one that erodes margins or surprises customers. The matching logic is straightforward. Consumption varies legitimately across customers, the floor prevents revenue unpredictability, and per-unit pricing captures the variable cost.

When an agent delivers a binary, auditable outcome, such as customer support resolution, lead qualification, or document review with a pass/fail decision, outcome-based or hybrid pricing with an outcome component fits. That requires tight outcome definitions and audit infrastructure before launch. A base subscription with overage, structured so the cliff is gradual rather than steep, protects margin on low-volume customers while scaling with high-volume ones. Three questions pressure-test any model before launch. If not, the billing model cannot be operated, so fix the architecture first.

The sequencing advice for founders follows from those questions. Start with a flat subscription or a usage-based model with a generous floor. It is easier to add outcome pricing once resolution rates are measured than to walk back a model that creates billing disputes from day one. Instrument the agent for cost-per-action before pricing it. Agent efficiency is a margin lever, and builders who do not track it discover the problem only after the pricing is set. Treat deployment architecture as a pricing prerequisite. Per-user isolation is not optional for a product that bills at the customer level. Audit your current model against the five questions, then look at whether your infrastructure can actually run the model you have chosen.