How should an AI infrastructure platform be priced?

Start with a unit that customers recognize

An AI infrastructure platform is not one cost structure. A model gateway, managed inference service, retrieval platform, agent runtime, evaluation platform, GPU-serving layer, or secure internal AI platform can all have different buyers, benefits, and cost drivers. A sound price starts by identifying what the customer is actually buying.

There are three different units that teams often confuse:

Choose a primary commercial unit that customers can predict, measure, and influence. Then keep a more granular internal cost ledger. A buyer of a model-serving platform may understand GPU-hour, request, throughput capacity, or million-token usage. A buyer of a document-intelligence product may care about a successfully processed document by size class. A buyer of an agent platform may value a governed workflow execution, provided the contract clearly defines what counts as a completed execution and what is excluded.

Raw tokens are often an appropriate internal meter and may be a good external meter for an API aimed at developers. They are less suitable as the only external price unit when the product’s value is workflow control, auditability, integration, policy enforcement, or a business result. Conversely, hiding all cost behind vague “AI credits” creates billing anxiety unless the credit definition, included work, conversion, expiry, and overage behavior are clear.

The FinOps Foundation describes unit economics as connecting technology use and management practices to organizational value, and recommends documenting the business goals, unit metrics, and cost measurements that support them. This is a useful discipline for AI pricing: first define the business unit, then allocate the technology cost needed to deliver it. FinOps unit economics

Calculate the fully loaded variable COGS floor

COGS, or cost of goods sold, should reflect the cost to deliver the customer’s service. The exact accounting treatment belongs with finance, but pricing teams need a practical contribution-cost view before they publish a rate card.

For each billable workload type, record:

For a workload unit u, use a conservative expected variable cost:

cost per unit = model and compute + retrieval and tools + attributable platform operations + attributable service and commercial cost

Estimate this by workload class, not only customer average. A short text request, a long-context request, a multimodal task, a batch job, an agent that calls tools, and a dedicated-capacity customer may have materially different costs. Capture the 50th percentile, 90th percentile, 99th percentile, and maximum observed cost. The highest-cost cases may be rare, but they decide whether an “unlimited” promise is safe.

If target contribution margin is m, a variable-cost floor is:

minimum price per unit = expected variable cost per unit divided by (1 minus target contribution margin)

This is a floor, not the value-based price. It tells you whether a proposed package can carry its variable cost. A platform fee can cover ongoing management features and some fixed delivery costs, but it should not disguise an unbounded per-customer loss.

Provider pricing changes and is heterogeneous by design. Google documents token-based billing and different token and modality tables, including batch rates. Anthropic distinguishes input, output, cache-write, cache-read, batch, and some serving-mode rates. Amazon Bedrock documents several inference and tool-related pricing categories. Review your actual contracted rate cards rather than relying on public list prices. Google Cloud pricing Anthropic pricing Amazon Bedrock pricing

Allocate shared costs honestly

Shared clusters, gateways, observability, storage, security, and support do not disappear because they serve more than one customer. Allocate them with a documented rule. Depending on the product, use measured consumption, reserved capacity, throughput share, storage share, customer tier, or a stated fixed overhead charge.

Do not pretend that allocation is perfectly objective. State the policy and update it when the workload changes. FinOps guidance emphasizes documented allocation strategy and the distinction between resource-efficiency metrics and business-unit metrics. FinOps allocation FinOps unit economics

Set the value ceiling before choosing the model

Cost determines where a platform cannot profitably price. Value determines what a customer may rationally pay. The platform does not need to capture all value created. It must leave the buyer a clear expected return after adoption, integration, change management, and risk.

Ask customers which of these outcomes the platform changes:

• Faster delivery of a production AI feature or model endpoint.
• Lower cost per request, workflow, document, or business process.
• Less engineering or operations effort to run, observe, secure, and govern AI workloads.
• Better reliability, latency, availability, throughput, or capacity planning.
• Lower compliance, audit, data-governance, or vendor-management burden.
• Higher conversion, retention, quality, or revenue from an AI-enabled product.
• A capability that avoids a credible alternative cost, such as building and operating the platform in-house.

Use evidence rather than a generic “hours saved” claim. For example, measure the current model-routing and observability workload, the incident rate and time to detect a cost spike, the time to onboard a new model, or the cost of the existing vendor stack. If value depends on an outcome, define the baseline, attribution, exclusions, and time window before using outcome pricing.

If the value ceiling is below the COGS floor, do not solve the problem with a clever discount. Reduce the cost to serve, narrow the workload, use a different customer segment, charge for a different value unit, or decline the use case. A price with no viable space between cost and value is evidence that the package is wrong.

Compare the main pricing models

The best structure depends on cost variability, buyer predictability, the maturity of metering, and whether the value metric can be defined fairly.

Usage pricing

Usage pricing is usually the natural starting point for developer infrastructure. It works best when the customer understands the unit and can predict or limit usage. A request count is not sufficient if request cost can vary by several orders of magnitude. Use a unit that reflects the workload class, such as tokens by model class, GPU-hour, throughput reservation, document size class, compute credit, or governed workflow class.

Avoid charging for every internal technical event. Customers should not need to learn your retry topology to read an invoice. Consolidate internal events into a billable unit, but preserve a customer-accessible usage breakdown for audit and cost management.

Seat pricing

Seat pricing can cover features people use directly: prompt management, access control, dashboards, approval queues, collaboration, or a limited assistant experience. Seats should not silently grant unlimited access to expensive model routes, large contexts, or autonomous workflows unless the cost is genuinely bounded and measured.

If seats are part of the package, separate them from workload use. For example, charge for platform administrators and include a defined monthly usage pool, then price incremental consumption or capacity. This prevents a buyer from assuming every employee has unlimited high-cost capability because one plan happens to include a collaboration feature.

Tiers

Make tier differences meaningful to customers. Useful tier dimensions include governance controls, deployment options, data residency, single sign-on, retention, audit exports, service level, private networking, support response, model-routing controls, evaluation tooling, or an included workload range.

Do not create too many tiers at launch. If the sales team needs a custom explanation for every customer, the tiers are not doing their job. Start with a small number of packages and a documented path for high-volume or regulated customers.

Reservations and commitments

Reservations suit predictable capacity needs. They can take the form of committed annual spend, prepaid credits, a minimum monthly use, or a capacity reservation. These are not interchangeable. Do not label a spend commitment as “reserved capacity” unless the contract actually specifies the capacity, geography, availability, queue priority, and performance behavior the customer receives.

For enterprise commitments, define the rate card, discount, start date, ramp, unused credit treatment, overage, true-up timing, support, security terms, service levels, termination rights, and how a material provider-cost change is handled. A commitment should reward predictability for both sides, not shift every cost surprise to the customer.

A default hybrid design

For many AI infrastructure platforms, the simplest defensible starting package has three layers:

1. Platform fee. Covers the control plane that customers value regardless of workload, such as tenancy, identity, policy, observability, audit, integrations, administration, standard support, and a small included allowance.

2. Usage pool or reserved capacity. Gives the buyer a known amount of the primary workload unit each month or term. It can be prepaid credits, model-serving capacity, or a documented allocation of workload classes.

3. Overage or expansion path. Charges a published rate for extra usage, or lets the customer upgrade capacity. The contract states whether overage is automatic, capped, pre-approved, or blocked.

Example

Hypothetical example: A platform routes model requests, applies policy controls, logs activity, retrieves approved knowledge, and runs tool-enabled workflows. The company first considers pricing “per API request,” but a request can be a short cached question, a large document analysis, or a multi-step tool workflow. Request count is neither cost-reflective nor easy for a buyer to budget.

The company instead creates three customer-facing workload classes: standard routed text, large-context or multimodal processing, and tool-enabled workflow execution. Internally, each class has cost bounds and a cost distribution. The platform subscription pays for access controls, audit logs, policy configuration, dashboards, and support. A monthly included pool covers ordinary use. Usage beyond the pool is priced by workload class, with a dashboard showing consumed units, estimated current bill, budget remaining, and the factors that made a workload enter the higher-cost class.

Before launch, the company tests whether customers prefer this structure to a simple credit bundle. It watches quote acceptance, time to procurement approval, percentage of buyers who can forecast monthly cost, contribution margin by workload class, overage disputes, and whether high-volume customers need a reservation. The result may be a hybrid plan, not because hybrid is fashionable, but because it resolves a demonstrated tension between fixed platform value, variable COGS, and buyer predictability.

Protect margins from accidents and abuse

Abuse is not only malicious. A forgotten loop, oversized context, repeated retry, unrestricted tool call, traffic spike, or integration bug can create the same margin problem as an intentional attempt to consume unlimited compute.

Build cost controls into the service:

Rate limiting and budget controls protect both parties. A company should not rely on an opaque “unlimited subject to abuse” clause as its primary margin defense. If a plan needs a hidden throttle to remain profitable under normal use, its allowance or pricing is wrong.

Abuse controls also need security review. Tool-enabled systems can be induced to make costly or unauthorized requests through untrusted inputs, and data-connected workflows may expose information if access boundaries are too broad. Apply account-level authorization, least privilege, output and action validation, audit logs, and incident response in addition to billing controls. These safeguards are part of the product’s cost to serve, not optional extras.

Make price transparent enough to build trust

The buyer should be able to answer four questions without asking support:

• What exactly is included?
• What event consumes a unit or triggers an overage?
• What is my current use, projected bill, and remaining allowance?
• What can I do before the bill rises further?

Provide a rate card, a plain-language definition of every billable unit, live or near-real-time usage data, alerts at meaningful thresholds, downloadable usage records, and a clear dispute process. If you use credits, show the underlying conversion and distinguish different workload classes. If you offer “unlimited,” state the legitimate capacity, policy, and fair-use boundaries in the order form rather than relying on fine print.

Transparency matters internally too. Tag costs by customer, workload class, model route, region, version, and contract. Use this data to examine contribution margin at the customer and product level. The FinOps Framework notes that cost and usage data may need to span public cloud, data center, SaaS, and AI to support unit economics. FinOps unit economics FinOps for AI

Run pricing experiments without confusing customers

Pricing is a product hypothesis that needs evidence. Do not roll out a new price to every customer before you know whether the unit, package, and margin behavior are viable.

Start with discovery:

1. Interview current and prospective customers about the job they hire the platform to do, the alternative they use, which cost they are trying to avoid, and which budget owns the purchase.

2. Show two or three credible packages, not an open-ended question about willingness to pay. Ask buyers to explain which unit they would budget for, which limit feels risky, and what approval or procurement evidence they need.

3. Instrument the cost and value record from the first paid pilot. Capture actual workload mix, unit cost distribution, support burden, activated capabilities, customer outcome proxy, and invoice comprehension.

4. Run a limited commercial test with comparable customer segments. Keep contract terms clear, honor quoted terms, and do not change a customer’s billing logic mid-commitment without explicit agreement.

5. Evaluate conversion, time to close, activation, expansion, churn, realized net revenue, variable COGS, contribution margin, support tickets, overage disputes, usage controls, and customer-reported predictability. Segment results by workload, company size, industry, and contract type.

Avoid treating a high price as proof of value or a low price as proof of product-market fit. A low price can attract workloads with poor margin and little retention. A high price can suppress adoption before the buyer sees the value. The point of the experiment is to find a packaging and unit that customers understand, can purchase, and use profitably.

A pricing review cadence

Review the rate card at least quarterly during rapid product or supplier change, and before making a large enterprise commitment. Inspect:

• List and contracted provider rates, discount changes, capacity commitments, and regional variation.
• Cost per workload class at median, high percentile, and maximum use.
• Contribution margin by customer, plan, feature, model route, and region.
• Usage concentration and signs of accidental or malicious cost growth.
• Customer adoption, allowance depletion, overage, budget-cap, and downgrade patterns.
• Support volume, invoice disputes, sales-cycle friction, and contract exceptions.
• Evidence that the value metric remains linked to the customer outcome.

Change price sparingly and communicate changes plainly. Model costs may fall while customer value, support demands, security requirements, or workload composition rise. A lower supplier token rate does not automatically require a price cut, and a higher rate does not justify a surprise invoice. Treat rates, commitments, and product limits as part of a long-term customer relationship.