MENU
AI products create a billing problem that conventional seat-based SaaS pricing does not always capture well. Agent workloads can vary significantly from one request to another, and recent research into AI agent token consumption found substantial variation in the resources agents use even when performing comparable tasks. Accurate usage measurement therefore matters for AI companies trying to connect infrastructure costs with what customers actually consume.
OpenMeter addresses this problem from the metering and billing side. Its current product covers usage measurement, product catalogs, pricing, entitlements, subscriptions, limits, invoicing, and integrations with payment systems. For teams building autonomous AI agents, however, metering customer usage is only one part of the payment workflow. Agents that need to spend, purchase access, or transact with other services introduce additional requirements around delegated payment authority, settlement, and programmable spending controls.
OpenMeter is an open-source usage metering and billing platform now operated by Kong. Its core purpose is to turn application usage events into billable usage and connect that activity to pricing, entitlements, subscriptions, and invoices.
The platform can meter resources such as API requests, LLM tokens, data transfer, compute time, transactions, and other application-defined events.
Its current billing model is built around several connected objects:
This makes OpenMeter broader than a standalone event counter. It provides a seller-side commercial layer for defining what customers receive, how usage is measured, and how that usage turns into an invoice.
The distinction becomes important when evaluating it for AI applications. Usage metering determines what a customer consumes. An agent payment system must also address cases where autonomous software needs permission to spend or pay another service while a workflow is running.
Usage metering remains one of the platform's central functions.
Applications send usage events into the system, and meters aggregate those events according to rules defined by the business. The current implementation uses CloudEvents-compatible event structures and allows teams to decide which event fields should be measured or grouped.
OpenMeter currently supports several aggregation types:
That flexibility supports different usage models.
A generative AI application could sum tokens consumed. An API provider could count requests. A cloud service could track the latest resource quantity or calculate average request duration.
Meter queries can also apply time windows rather than requiring every meter to use a fixed aggregation period.
Event-based metering is relevant to AI services because inference and tool execution frequently generate variable costs.
A single customer interaction might involve several model calls, database queries, search operations, or external tools. Measuring those events individually provides a more detailed foundation for usage-based pricing than simply counting active users.
The billing system still needs a policy explaining how measured consumption becomes a charge. Metering answers how much was used. Pricing determines what that usage is worth.
OpenMeter's current billing product supports more than straightforward per-unit billing.
Plans can combine metered and non-metered features, and rate cards define how individual features are priced. Businesses can also attach usage limits or access rules to those features.
Usage-based rate cards connect a meter to a price.
This structure can support use cases such as charging by API request, token volume, storage, compute, or another measured unit. Tiered and volume-based approaches can also change the unit economics as consumption increases.
For AI companies, the underlying concept is straightforward: collect usage events, aggregate them, apply the rate card, and generate the resulting billing line items.
Not every product component needs to depend on consumption.
OpenMeter also supports recurring subscriptions and flat-fee components. A company could therefore combine a recurring platform fee with usage-dependent AI charges.
That reflects a broader shift toward hybrid AI pricing, where predictable baseline fees and variable consumption charges can exist in the same commercial model.
Current billing functionality also includes customer-specific pricing, discounts, minimum-spend commitments, maximum-spend commitments, trials, and phased pricing.
These capabilities are useful for B2B SaaS and API businesses that negotiate enterprise contracts rather than exposing one public price to every customer.
The system therefore functions as both a usage-metering layer and a configurable billing catalog.
Billing and payment collection are related, but they are not the same operation.
OpenMeter calculates usage, applies pricing, manages subscriptions, and creates invoices. Its documented Stripe integration can then synchronize invoices and use Stripe for payment collection, taxes, and payment-method management.
For a paid subscription, the customer completes a Stripe checkout flow to provide payment details. OpenMeter can then provision the subscription and synchronize subsequent invoices based on recorded usage.
This is a conventional seller-side billing architecture. The business determines what its customer owes, while an integrated payment provider handles the transfer of funds.
That architecture is different from autonomous buyer-side payments, where software itself needs a controlled spending budget and authority to initiate transactions against external services.
Kong announced its acquisition of OpenMeter on September 3, 2025.
The acquisition brought OpenMeter's usage metering and billing functionality into the Kong API ecosystem. Current OpenMeter documentation now identifies OpenMeter Cloud as Kong Konnect Metering & Billing.
The open-source project continues alongside that transition.
Within Kong Konnect, the metering and billing product is positioned around monetizing APIs, AI workloads, and data streams.
The integration brings usage information closer to API infrastructure, which can be useful for organizations that already manage traffic through Kong products.
Current functionality covers areas such as:
The acquisition does not change the fundamental category of the product. It remains centered on measuring and monetizing services that customers consume.
The OpenMeter project remains available under the Apache 2.0 license.
Organizations can self-host the open-source system, while managed billing capabilities are available through Kong's commercial platform.
OpenMeter also exposes REST APIs and client SDKs. Current documented SDK options include Node.js, Python, and Go.
This deployment model gives engineering teams options when deciding how much billing infrastructure they want to operate themselves.
Self-hosting also introduces operational responsibilities. OpenMeter's documented architecture includes components such as Kafka, ClickHouse, PostgreSQL, workers, and optional Redis infrastructure, depending on deployment configuration.
For teams already operating data-intensive backend systems, that architecture may fit existing infrastructure practices. Other teams may prefer managed deployment to reduce operational ownership.
OpenMeter can measure AI consumption and attach pricing to it.
For example, an AI service could record token usage as application events, aggregate those events by customer, associate the meter with a rate card, and generate usage-based invoice charges.
This is relevant when the business remains the seller and customers consume its AI product through an established commercial relationship.
Billing AI services also requires deciding how much access a customer receives.
Entitlements can connect features and limits to a subscription. That makes it possible to define product access separately from the raw billing calculation.
A product could provide a certain level of included usage, apply limits, and meter additional consumption according to its pricing model.
Usage data can also support customer dashboards and internal reporting.
Showing customers what they have consumed is particularly useful for variable-cost AI products where usage can change considerably between billing periods.
For agent products, however, usage visibility should not be confused with payment authority. Knowing how much an agent consumed and allowing that agent to independently purchase a third-party service are separate capabilities.
The distinction between these categories becomes clearer when following the direction of a transaction.
A usage-billing platform primarily answers questions such as:
Agent payment infrastructure must answer additional questions:
These functions become relevant when an AI agent moves from consuming an internal service to making purchasing decisions on behalf of a user or organization.
A payment and entitlement layer can connect both sides by validating access, tracking usage, applying pricing, and settling the resulting payment as part of the request lifecycle.
Autonomous spending introduces risks that ordinary customer billing does not need to solve.
Giving an agent unrestricted access to a card or wallet would expose the account owner to unnecessary financial risk. Payment authority therefore needs explicit boundaries.
A delegated spending model can specify:
With card delegation controls, users authorize a defined budget without giving the agent raw card details.
The card is tokenized, and the agent receives scoped payment capability tied to the delegation rather than unrestricted access to the underlying payment credential.
This converts payment permission into a programmable policy.
Payment infrastructure also needs to account for how money actually moves.
Seller-side billing commonly connects to established payment providers for invoicing and card collection. Agentic commerce can introduce additional settlement requirements because agents may encounter services using different payment methods or machine-readable payment protocols.
Nevermined supports payment plans using card and crypto paths. Current documentation describes card-funded flows through providers such as Stripe, Braintree, and Visa, as well as USDC and EURC settlement for crypto payment plans.
The payment model configuration remains separate from the funding method. Teams can define how access is priced and then select the appropriate settlement path for the workflow.
That separation matters when the same AI product serves both conventional customers and autonomous software clients.
Usage data becomes more useful when teams can connect it to cost and revenue.
Nevermined's observability and monitoring capabilities track AI API calls, token usage, cost information, performance metrics, and custom properties. Those measurements can then feed into credit redemption and pricing logic.
Organizations can also track revenue and usage analytics across agents and plans.
Current organization analytics cover:
This connects metering to the operational side of running an agent payments business rather than treating usage as an isolated billing dataset.
Any platform involved in payments or billing needs to be evaluated according to the data and financial operations it actually handles.
A usage-metering deployment may require controls around customer data, access, event infrastructure, and invoice records. A payment platform that handles delegated spending also needs controls around card tokenization, payment authorization, credentials, and transaction records.
Nevermined maintains a SOC 2 Type II report, ISO/IEC 27001:2022 certification, and PCI SAQ-D compliance for its payment infrastructure.
Its payment certifications documentation explains that raw card numbers are tokenized before reaching Nevermined's systems. The platform does not store raw PAN data.
For procurement teams, certification scope matters. Security requirements should be evaluated against the exact product, deployment model, and payment flow being considered rather than assumed from a parent company or integration partner.
The right infrastructure depends on the transaction model.
Teams focused on metering their own SaaS or API usage should evaluate:
Teams building autonomous agents should add another set of questions:
Organizations running many agents may also need group spending budgets so separate teams can operate against centralized payment methods without receiving unrestricted access to organizational funds.
The important distinction is architectural. Metering customer consumption and authorizing autonomous spending are complementary functions, not interchangeable ones.
Nevermined combines the measurement side of AI monetization with the ability to move money under programmable controls.
For sellers, the platform attaches payment plans to AI agents, APIs, MCP tools, and other monetizable resources. Each request can be validated against entitlement, tracked for usage, and settled according to the configured payment model.
For buyers, delegated payment authority allows agents to transact within a defined budget. The payment credential remains scoped to the permissions established by the user or organization.
The platform supports several commercial structures, including prepaid access, pay-as-you-go plans, dynamic pricing, time-based access, and outcome-oriented models. Fiat and stablecoin payment paths can operate within the same broader payment infrastructure.
Nevermined also provides a documented five-minute payment setup for agent APIs, MCP tools, servers, and protected resources, with TypeScript and Python SDK paths.
For a production example, Valory reduced deployment of payments and billing infrastructure for the Olas AI agent marketplace from six weeks to six hours using Nevermined.
The result is infrastructure that connects usage, access, pricing, payment authority, and settlement instead of treating those functions as separate systems.
Usage metering measures what a customer or agent consumes and converts those events into billable quantities. Agent payments also require the ability to authorize, initiate, and settle a transaction when autonomous software needs to spend. A payment and entitlement layer can connect consumption with access and settlement inside the same workflow.
Yes. AI services can charge according to tokens, API requests, compute, tool calls, or other measurable events. The pricing system still needs rules for translating those events into charges, and dynamic payment models can adjust pricing according to the workload. Usage-based pricing is particularly relevant when different agent requests consume materially different resources.
The user can delegate a bounded payment capability rather than provide raw card credentials. Spending rules can define a maximum budget, validity period, and other controls before the agent transacts. Current card delegation controls tokenize the underlying card and keep the agent's authority scoped and revocable.
Enterprise deployments commonly need budget limits, expiration rules, credential scoping, transaction records, access controls, and revocation. Teams may also need centralized payment methods with separate budgets for different departments or agent groups. Group spending budgets provide one way to enforce those boundaries across an organization.
Revenue tracking should connect transactions with the specific agent, customer, plan, and underlying usage. This makes it possible to compare consumption with what each service earns instead of viewing usage in isolation. Nevermined's revenue and usage analytics include per-agent revenue, MRR, plan consumption, customer spend, and conversion metrics.
See Nevermined
in Action
Real-time payments, flexible pricing, and outcome-based monetization—all in one platform.
