Building Custom Pricing Models for AI Services

Every token generated, API call served and GPU minute consumed changes your cost of goods in real time. That is the awkward fact underneath AI pricing, and it is why tools designed around a monthly plan record struggle here. They were built to answer what a customer agreed to pay. The question you need answered is what this customer just consumed and what it cost you to serve.

Closing that gap needs a system that is programmable rather than configurable through a settings page.

What is a custom pricing model, in engineering terms?

A custom pricing model is pricing logic that lives as data outside your application code, evaluated against a stream of usage events, rather than as conditionals compiled into your services.

That definition sounds pedantic until you try to run a pricing experiment. If a rate change means a pull request, a review and a deploy, pricing moves at the speed of your release cycle. If it is a configuration change evaluated against events you are already emitting, it moves at the speed of a decision.

How the metering to invoice path works

Four stages, and most teams underinvest in the first one.

Instrumentation and events

Define the billable units first: tokens processed, inference calls, GPU seconds, workflow completions. Each becomes an event with a customer attached and an idempotency key of your own choosing, so retries after a network failure do not turn into double charges.

{
  "event_name": "model.usage",
  "external_customer_id": "cust_123",
  "properties": {
    "credits": 2,
    "model": "gpt-4",
    "region": "us-east-1"
  },
  "event_id": "evt_abc123",
  "timestamp": "2025-08-22T07:05:49.441Z",
  "source": "api"
}

The properties object is where the future flexibility lives. Fields you record but do not price on today are the fields that let you change your pricing model later without reinstrumenting your services. Recording model and region costs nothing and is the difference between being able to introduce model-tiered pricing next quarter and having to ship code across every service to do it.

Aggregation then groups these into billable units over a window. Which aggregation you choose determines what the payload must carry, since a Sum over a numeric field and a unique count over a string field are different contracts. The aggregation reference covers the available types.

Real-time rating and limits

Aggregated units get priced. Tiers apply, volume discounts apply, per-customer overrides apply. Guardrails run in the same pass so a customer approaching a ceiling is warned or stopped before the overage exists rather than after.

Rating in real time is what makes the difference between a dashboard that reports history and one a customer can act on.

Credits, wallets and commitments

Prepaid customers hold a balance they draw down. Auto top-up refills it at a threshold. Enterprise commitments carry rollover so unused balance survives the period boundary.

Wallets are a separate primitive from subscriptions, and teams that treat them as an afterthought end up rebuilding them. A trial grant, a support credit issued to resolve a complaint, and a six-figure prepaid commitment are the same mechanism with different amounts and expiry rules. Prepaid and promotional credits covers how the balance types stack and deduct.

Customer-facing visibility

Live usage and projected spend, exposed to the customer. This is the cheapest way to prevent billing disputes, and for AI-native buyers it is table stakes rather than a differentiator.

The problems teams actually hit

Bill shock. Token cost varies with prompt length and model choice, so a customer's spend can move sharply without their behaviour changing much. Detailed tracking plus visible dashboards and alerts is the mitigation. There is no pricing structure that fixes it on its own.

Metering reliability at scale. Concurrent operations, dropped events, gaps that need backfilling. Idempotency handles the duplicates. Retained raw events handle the gaps, because you cannot backfill from data you did not keep.

Hybrid models. Nearly everyone converges on subscriptions plus usage plus credits in some combination. If your billing layer treats these as separate products that cannot appear on one invoice, you will be reconciling by hand. Hybrid pricing covers the combined shape.

Outcome pricing. Charging for results rather than consumption is attractive and genuinely hard. It requires you to define an outcome precisely enough to detect it programmatically, and it moves cost risk onto you. Worth attempting only once metering is solid.

The tooling landscape

The tools in this category solve overlapping but distinct problems, and matching scope to your situation matters more than feature counts.

Togai provides usage metering and pricing with scalable event ingestion, real-time usage tracking, and revenue simulation for forecasting a price change before shipping it.

OpenMeter is open source and focused on metering. Streaming ingestion, configurable metrics, backfill for gaps. It is deliberately scoped to measurement, so a billing layer sits on top of it.

Zenskar covers subscription and usage billing with attention to the finance side, including automated revenue recognition against ASC 606 and IFRS 15.

Maxio is billing automation weighted toward accounting: invoicing, payment reconciliation, contract management, and multi-currency support.

Orb fits straightforward self-serve usage pricing well. The constraint appears as pricing and go-to-market motions get more complex, at which point teams look for a billing platform built for enterprise flexibility.

Metronome is a metering point solution designed for engineers. Its scope is usage measurement, which means complete billing functionality, invoicing and pricing iteration come from elsewhere.

Flexprice differs from that last pair mainly in scope. Where Metronome is a metering engine for developers, Flexprice is end-to-end billing and pricing infrastructure: metering, billing, invoicing, reporting and pricing experimentation, all built on a raw event data model, with native pricing agility and simulations.

Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud. All three run the same engine.

Two comparisons worth stating precisely, because they come up constantly. Lago is also open source and self-hostable, and the difference is enterprise scale: Flexprice is built for real-time metering at high event volume, with deployment across any VPC and any geography. Stripe Billing is built around subscriptions and payments, and is usually paired with a separate metering vendor for usage-based products, whereas Flexprice is the metering and billing layer itself and is not tied to any payment gateway.

What to evaluate

Narrow questions produce better decisions than feature matrices:

• Can pricing change without a deploy? If not, every experiment costs a sprint.
• Are raw events retained and queryable? Audits, disputes and backfills all depend on it.
• Do entitlements evaluate synchronously, at request time? Otherwise enforcement is advisory.
• Can subscriptions, usage and credits resolve onto a single invoice?
• Where does the data live, and can it stay inside your infrastructure? For teams with data residency, sovereignty or audit requirements, this is the constraint that eliminates most hosted-only options.
• How does cost behave at ten times your current event volume?

Sending your first event

The integration surface is small enough to test in an afternoon. Point your service at a metered feature and emit:

const response = await fetch("https://api.cloud.flexprice.io/v1/events", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "x-api-key": process.env.FLEXPRICE_API_KEY,
  },
  body: JSON.stringify({
    event_name: "model.usage",
    external_customer_id: "cust-test-customer",
    properties: { credits: 2 },
    source: "api",
  }),
});

const result = await response.json();
console.log("Event transmitted:", result);

The response acknowledges acceptance rather than blocking on the full pricing path:

{
  "event_id": "event_01K389J4M1F1NZG6XP0AMD6J52",
  "message": "Event accepted for processing"
}

High-volume services should buffer and use the bulk endpoint rather than one request per inference.

Where this leaves you

Pricing infrastructure is worth treating as part of your architecture rather than a procurement decision made once. The units you instrument constrain the pricing models available to you, and reinstrumenting a live product is expensive. Record more dimensions than you currently price on, keep pricing logic out of your services, and keep raw events.

Get those three right and most pricing changes become configuration. Get them wrong and every pricing change becomes a migration.

Getting started

Flexprice is open source, so you can read the metering and pricing engine, run it against your own event shape, and see how your usage aggregates before committing: docs.flexprice.io.