MENU
Metronome is a usage-based billing platform for software companies with consumption pricing, credit models, enterprise contracts, and hybrid commercial structures. It receives product-usage events, converts them into billable metrics, applies pricing and contract rules, and generates invoices and reports. AI products have increased demand for these systems because model requests, tokens, tool calls, compute workloads, and completed tasks create variable costs that do not always align with conventional per-seat subscriptions.
Current reporting on AI agent pricing models shows providers testing subscriptions, prepaid credits, usage charges, outcome fees, and hybrid structures as they determine how activity should translate into customer charges.
Stripe completed its acquisition of Metronome on January 14, 2026, making Metronome part of Stripe’s billing product set for usage metering, pricing, credits, enterprise contracts, invoicing, and reporting. Billing does not cover every requirement of autonomous commerce, since an AI agent may also need controlled spending authority, payment verification before an API executes, request-level access enforcement, and settlement between software services.
Metronome is a billing platform for software providers that charge customers according to usage, subscriptions, credits, commitments, or combinations of those models.
A standard implementation connects several types of data:
The company implementing Metronome determines which product actions should be recorded and how those actions should be priced. Metronome applies the configured metrics, rate cards, and contract terms to calculate customer charges.
The platform does not build the underlying AI product or determine what qualifies as a successful customer outcome. Product teams remain responsible for defining events, pricing units, commercial rules, and the relationship between usage and customer value.
Metronome’s implementation starts with product events and ends with calculated billing records.
A typical workflow includes:
Production requirements depend on event quality, contract complexity, customer volume, historical data, finance integrations, and the existing billing stack.
Metronome receives product-usage events through its ingestion API.
An event may represent:
Each event includes identifiers and properties required for later calculations. Product teams must define how events are generated, retried, deduplicated, validated, and associated with customers.
Metronome’s standard event-ingestion process accepts backdated events within a documented time window. Teams that regularly receive older usage records should confirm whether the available correction and ingestion options match their billing process.
Usage data becomes financial input once it is connected to pricing. Missing customer identifiers, duplicated records, inaccurate timestamps, or incomplete quantities can affect the resulting charges.
A billable metric filters and aggregates usage events into a quantity used for pricing.
Examples for an AI product include:
Metronome includes a Basic Filters editor for standard metrics and a SQL editor for customized definitions.
Basic filters can cover common event filtering, counts, sums, and grouping rules. SQL can be used when the pricing calculation requires additional query logic over the raw event data.
Engineering work may still be required to design the event schema, implement ingestion, validate metrics, and connect billing data to the product and finance stack.
Metronome connects billable metrics to products and rate cards.
Documented pricing configurations include:
A rate card defines how a metric translates into a charge. A customer contract determines which rate card, credits, commitments, discounts, and billing periods apply.
The software provider remains responsible for selecting pricing units that customers can understand and that correspond to the product’s usage or value model.
Metronome records customer credits and contractual spending commitments.
Credits may represent:
Commitments represent contracted spending amounts that are reduced as billable usage occurs.
Metronome records balances, access schedules, usage rules, and associated ledger activity. Notifications can be configured when a balance reaches a particular amount or percentage threshold.
These notifications report billing status. The product application must determine whether a request should continue, be rejected, or require an additional purchase when a balance reaches its configured threshold.
Metronome represents enterprise commercial terms through customer contracts.
A contract may include:
Contract changes can be scheduled or applied through amendment workflows.
Product, finance, legal, and revenue teams should define how those changes affect invoices, credits, accounting records, revenue recognition, and customer communication.
The billing engine applies the configured commercial terms. It does not determine whether a disputed result qualifies as a completed outcome under the customer agreement.
Metronome calculates invoices from usage events, billable metrics, customer contracts, and pricing rules.
An invoice may include:
Metronome calculates the billing data. A connected payment provider can then collect payment and connect the result to tax, accounting, or revenue-recognition systems.
This distinction matters for autonomous commerce. Calculating what a customer owes does not give an autonomous buyer permission to spend or verify payment before a workload runs.
Metronome provides billing and usage records for customer, product, contract, credit, and revenue analysis.
Notifications can cover:
A receiving application can use those notifications to send customer messages, start renewal processes, request a top-up, or apply an access-control decision.
The application remains responsible for carrying out the operational action.
Metronome does not publish fixed platform prices.
Its pricing structure includes:
The exact amounts, usage metrics, and commercial conditions are defined through the customer agreement.
A pricing evaluation should request details on:
The total billing stack may also include separate payment-processing, tax, accounting, data-warehouse, revenue-recognition, and customer-management costs.
Metronome documentation covers software products that need to convert activity into invoices, credits, commitments, and billing reports.
Relevant use cases include:
The platform’s scope centers on the seller’s billing operation.
That scope differs from an autonomous agent-payment flow in which the buyer receives machine-readable payment requirements, presents authorization, pays within a delegated budget, and obtains access before a service performs work.
AI companies should distinguish usage billing from payment authorization and settlement.
A billing platform can record usage and calculate charges after product activity occurs.
This model applies when:
A request-level payment system verifies entitlement or payment authorization before the API, model, or tool creates cost.
That distinction matters when the buyer is autonomous, unknown to the seller, or operating outside a conventional subscription relationship.
Real-time usage monitoring can report that a customer has reached a balance, credit, or spending threshold.
An alert does not represent a payment credential or complete a transaction between an agent and a merchant.
The product application must decide how to respond. A payment-enforcement layer places authorization directly in the request path and can reject an unpaid request before execution begins.
Metronome’s product scope centers on sellers measuring customer usage and calculating billing amounts.
Autonomous buying introduces separate requirements:
These functions determine what an agent is permitted to buy rather than how a seller calculates a later invoice.
Metering determines how much usage occurred and what it should cost.
Settlement transfers value from buyer to seller.
A complete agent transaction can require:
Metronome addresses usage, pricing, contracts, credits, and invoicing. Agentic payment infrastructure coordinates the wider transaction.
Nevermined is building the financial rails for AI. It connects buyer-side spending authority with seller-side payment verification, metering, access control, and settlement.
An API, agent, MCP tool, dataset, or protected resource can require payment before work begins. Buyer agents receive scoped authority to pay without receiving unrestricted access to the underlying payment method.
Nevermined applies one delegation model across supported Visa, Stripe, and Braintree card flows.
A card owner can delegate a spending budget to an AI agent and define:
The agent receives scoped payment capability rather than the original card number. Transactions outside the assigned rules are rejected.
The x402 Facilitator Overview describes Nevermined’s enforcement and settlement engine for HTTP-native payments.
When an agent calls a paid endpoint, the seller returns machine-readable payment requirements. Nevermined handles payment verification and settlement around the workload.
Verification occurs before execution. Settlement occurs after the workload completes successfully. The seller can therefore reject an unpaid model request, API call, or tool invocation before it creates cost.
Nevermined supports multiple payment models for agents, APIs, tools, and protected resources.
Available structures include:
Dynamic pricing can use token count, request complexity, operation type, or another provider-defined metric.
The pricing rule determines both the amount charged and whether the caller receives access to the current request.
The Monetize Your AI workflow covers AI agents, APIs, datasets, MCP tools, and other protected resources.
The builder:
Other agents can purchase access and request work programmatically through supported fiat or stablecoin flows.
Nevermined documentation explains how to protect your MCP servers with payment validation.
An MCP handler can:
MCP defines how agents discover and invoke tools. Nevermined adds the pricing, entitlement, and payment layer around those calls.
Nevermined can track incoming requests, caller identity, credits consumed, remaining balances, settlements, and revenue.
Each interaction can be associated with:
Operators can review individual paid requests rather than relying only on aggregated invoice totals.
Nevermined’s setup guide moves from registration to a working payment integration in approximately five minutes.
The workflow covers:
The same approach applies to agent APIs, MCP tools, and protected resources.
Valory reported reducing payment and billing infrastructure deployment for the Olas AI agent marketplace from six weeks to six hours. That result is specific to Valory’s implementation rather than a guaranteed deployment time.
Nevermined’s payment infrastructure includes SOC 2 Type II auditing, ISO 27001 certification, PCI SAQ-D controls, tokenized card capture, encryption, scoped payment authority, revocation, and transaction records.
These controls apply directly to the agent’s ability to spend and the seller’s ability to verify and settle the transaction.
Nevermined charges 1% to 2% of settled transaction volume.
There are no setup fees or minimums. A free personal account includes up to 20 agents and 10 payment plans. Optional organization plans add dashboards, payment widgets, customer management, activity streams, and higher limits.
Underlying processor or network charges may still apply depending on the selected payment rail.
Usage-based billing calculates charges from measurable activity such as tokens, API requests, compute time, workflows, or completed tasks. The provider defines the billable unit and applies a price to the recorded quantity. The resulting charge may appear on a later invoice or reduce a prepaid balance. Nevermined’s multiple payment models connect usage pricing with request-level access and settlement.
Metering records how much of a service was consumed and calculates the associated price. Settlement transfers value from the buyer to the seller. An autonomous workflow may require both functions to occur around the same API call, tool execution, or agent request. The x402 Facilitator Overview explains how Nevermined verifies payment before execution and settles after successful completion.
Autonomous agents can make repeated calls, purchase services, and continue operating without a person approving every action. Spending limits restrict the amount, duration, transaction count, and credential associated with that authority. These controls reduce financial exposure when an agent behaves unexpectedly or a credential is compromised. Nevermined lets users delegate a spending budget with defined limits and revocation controls.
An API can return machine-readable payment requirements before executing a paid workload. The buyer then supplies valid authorization, and the server verifies entitlement before consuming compute, model, or data resources. This prevents unpaid requests from creating costs for the provider.
An agent payment system should retain the buyer, seller, authorization, pricing rule, request, usage amount, result, settlement, and receipt. It should also preserve failed requests, revocations, and policy rejections so disputed activity can be reconstructed. These records provide more detail than an invoice total because they document each machine transaction.
See Nevermined
in Action
Real-time payments, flexible pricing, and outcome-based monetization—all in one platform.
