DEV Community: Flexprice

How to Price an AI Agent Without Wrecking Trust or Margins

Flexprice — Wed, 02 Sep 2026 09:28:39 +0000

The bill arrives and a customer who expected forty dollars owes three hundred and forty. Another one burned their entire credit balance on three runs that failed and returned nothing useful. You pull the numbers and find your heaviest users are also your worst-margin accounts.

Usually the root cause is the same. Someone picked "per API call" early because it was the easiest thing to instrument. Easy to instrument and easy to understand are different problems, and only one of them shows up in a churn report.

Why does seat-based pricing break for agents?

Because an agent does not do the same amount of work twice. A traditional SaaS tool does roughly the same thing on every login. One agent run calls three tools and finishes in seconds. The next chains fifteen steps, hits three external APIs, and burns ten times the tokens. Same product, same seat, wildly different cost to serve.

That leaves two bad options under a flat rate. Absorb the variance and watch margins erode, or price for the worst case and lose everyone who is not the worst case.

Usage-based pricing is the model that maps to how the product actually consumes resources. But choosing usage-based pricing settles almost nothing. The real decision is which unit you meter, and that is a product decision no billing system can make for you.

Choosing the usage metric

The metrics available to most agent products trade off against each other in a fairly predictable way.

Metric	Tracks cost	Customer can reason about it	Notes
Tokens	Closest to actual cost	Hardest	Customers cannot forecast token counts and do not want to learn
Messages	Loosely	Easy	Hides enormous variance between a one-line reply and a fifteen-step chain
Tasks or workflows	Moderately	Easy	Strongest alignment with what the customer is buying
API calls	Moderately	Fine for developers	Weak for business buyers who do not think in requests
Seats plus usage	Partially	Easy	Adds the predictability finance teams ask for

The test that cuts through the table: when usage goes up, can you point to something concrete that got better for the customer?

If usage rose because they automated more work, that is a healthy signal and they will not resent the invoice. If it rose because your prompts got longer, retries increased, or a model upgrade made outputs chattier, they are paying more for the same outcome. Your metric should move when customers win, not when your infrastructure gets noisier.

Decide what you will not charge for

This is a credibility decision more than a pricing one, and it is worth making explicitly and early.

Do not bill for failed retries, system errors, model warmups, or internal orchestration. If your system caused the cost, you absorb it. Customers pay for usage they intended, not for cleanup work happening behind the scenes.

The reason to draw the line early is that it is very hard to draw later. Once a customer notices they were charged for a retry storm your service caused, the conversation is no longer about pricing.

Pick a structure your buyers and your board can both live with

Three structures cover most agent products.

Pay-as-you-go suits APIs and experimentation. Revenue is unpredictable, which is a real cost you pay for the low friction.

Base plus usage gives finance a floor and makes enterprise procurement much easier. Most sales-led motions land here.

Hybrid, meaning a platform fee with a metered layer on top, is the common shape for AI SaaS.

Two questions decide it. How much invoice variance can your buyer tolerate before they stop budgeting for you, and how much revenue volatility can your own business survive? A model that is honest about cost but leaves both sides unable to forecast is not a model either side keeps.

Making it real: from product event to billable unit

Once the strategy is settled, this becomes engineering work, and the failure mode is vagueness. Every billable unit should map to one concrete event in your system.

Define events like agent.run.completed, workflow.finished, or tool.executed. Avoid units like "interaction" or "session" that nobody can define twice the same way. The rule is simple: if a customer disputes a charge, you should be able to pull the exact events that produced it.

An event carries the customer, the unit, and the dimensions you might want to price or report on later:

{
  "event_name": "agent.run.completed",
  "external_customer_id": "cust_123",
  "properties": {
    "credits": 2,
    "model": "gpt-4",
    "workflow": "invoice-reconciliation"
  },
  "event_id": "run_8f21c",
  "timestamp": "2025-08-22T07:05:49.441Z",
  "source": "worker"
}

Two details do real work here. event_id is your own identifier, so a retried send deduplicates instead of double-charging, which matters because agent workers retry constantly. And properties carries dimensions you are not pricing on yet. Recording the model and the workflow costs nothing now and is the only way to answer "which workflows are unprofitable?" in six months.

Emitting it from a worker is one call on the path that already knows the result:

import os
import requests

def record_run(customer_id, run_id, credits, model, workflow):
    response = requests.post(
        "https://api.cloud.flexprice.io/v1/events",
        headers={
            "Content-Type": "application/json",
            "x-api-key": os.environ["FLEXPRICE_API_KEY"],
        },
        json={
            "event_name": "agent.run.completed",
            "external_customer_id": customer_id,
            "event_id": run_id,
            "properties": {
                "credits": credits,
                "model": model,
                "workflow": workflow,
            },
            "source": "worker",
        },
    )
    return response.json()

Call it only on success. That is how "we do not charge for failed runs" stops being a policy in a document and becomes a property of the code.

Track cost drivers even when you do not bill on them

You may price on tasks. You are still exposed to tokens.

Track input tokens, output tokens, tool calls, embedding generation and storage, and background jobs. Then watch what happens to those numbers when you change a model or a prompt. A prompt tweak that improves quality can quietly double cost per run, and if you are not measuring at the model layer you will find out from a margin report a quarter later.

Recording cost dimensions in properties on the same event you already emit is the cheap way to do this. Flexprice's AI cost tracking documents the pattern for keeping per-model cost attached to the customer who caused it.

Guardrails before the spike, not after

AI traffic is bursty. One customer's automation loop can multiply volume overnight, and the two possible outcomes are a bill that destroys the relationship or a cloud invoice that destroys the quarter.

Layer the controls:

Soft alerts at a usage threshold, delivered by email, Slack or in-app, while the workload continues.
Hard caps that pause execution at a contracted ceiling.
Internal anomaly detection for spikes that fit no configured threshold.
Rate limits and loop-depth limits at the agent layer.

Thresholds have to be evaluated against streaming usage. A nightly job that notices an overage is a job that notices it too late. Spend alerts covers the threshold model, and configuring them per line item lets you alert on the specific workflow that ran away rather than the account total.

Entitlements and limits are different things

Entitlements define what a customer may do. Limits define how much.

Premium model access, background agents, elevated concurrency: those are entitlements, and they are product decisions enforced by billing. Monthly token caps and maximum concurrent runs are limits, and they are the safety rails.

Both need to be evaluated synchronously, before the expensive operation starts. When an agent picks up a job, the system should already know whether that customer is permitted to run it and whether they are inside budget. That means a centralized check your services call, not plan-name conditionals scattered across your codebase. Entitlement grants covers how access ties to plans without hardcoding it.

Give customers the numbers before the invoice does

If a customer first sees their usage on an invoice, you have designed a dispute into the product.

Live usage, broken down by agent, workflow or project, plus projected spend and configurable budget thresholds. AI-native buyers expect this the way they expect logs. Transparency here reduces support load and makes expansion conversations easier, because the customer already knows what they are using and why.

What the infrastructure actually has to do

Bolting usage pricing onto a subscription stack produces delayed data, confused customers, and a finance team reconciling spreadsheets at month end. The layer you need has to ingest events in real time, keep them queryable for audit and simulation, apply pricing rules that live outside your application code, enforce entitlements and limits synchronously, manage wallets and credits, and produce invoices with line items traceable to real consumption.

Vendors in this space differ mostly by how much of that list they cover. Metronome is a metering point solution built for engineers: it measures usage and leaves billing, invoicing and pricing iteration to other systems. Flexprice covers the full path, including invoicing, reporting and pricing experimentation, with pricing agility and simulations built in rather than bolted on. Orb handles straightforward self-serve usage pricing well, and the friction tends to appear once pricing and go-to-market motions get more complex, which is when teams move to an enterprise-ready billing platform.

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.

In practice it sits between your product and your payment stack. You send raw usage events, agent runs, tokens, tool calls, background jobs. It aggregates them, applies your pricing rules, manages credits and limits, and produces invoice-ready output. Your services stop carrying monetization logic and start emitting facts.

Trials are a metering problem

Worth calling out because it is usually solved badly. A trial for an agent product should be metered usage with a hard cap, not a demo mode with fake data. Prospects need to run real workflows against real cost. A prepaid credit grant with an expiry does this cleanly, and it uses the same wallet primitive you already need for enterprise commitments. Prepaid and promotional credits covers the balance types and how they stack.

The rule worth keeping

Do not ship usage pricing until you can defend every charge with a product event, explain any invoice without hedging, and state what a marginal unit of usage does to both customer ROI and your own unit economics.

Teams that get this right treat pricing as part of the product architecture. They choose metrics that move with outcomes, exclude their own inefficiency from the bill, build guardrails before the first spike, and put the usage data in front of the customer continuously.

Getting started

The metering, entitlement and invoicing path is open source, so you can model your agent's event shape against it before committing to a pricing structure: docs.flexprice.io.

Subscription Management for AI Products: What Renewal Tools Miss

Flexprice — Wed, 02 Sep 2026 09:18:38 +0000

Subscription tools manage renewals. AI products need metering, credits and quotas enforced per request. Here is where the split happens and how to build it.

A customer signs up on the 1st, pays a fixed amount, and renews on the 1st of the next month. That is the model almost every subscription tool was designed around, and it works fine until the thing you are selling is inference.

AI workloads do not consume evenly. One user runs four prompts a week. Another wires your endpoint into a batch job and burns more tokens in an afternoon than the first user will all quarter. Both are on the same plan. The renewal date is the least interesting fact about either of them.

What is the difference between subscription management and usage billing?

Subscription management answers "is this customer still paying?" Usage billing answers "what did this customer consume, what is it worth, and are they still allowed to consume more?"

The second question has to be answered while the request is in flight. That is the part renewal tooling was never built to do, and it is why teams shipping AI products end up running two systems: one that handles the card on file, and one that handles everything the product actually meters.

The three things AI billing needs that renewals do not

Metering. Every billable action becomes an event with a customer attached. Not a nightly rollup of API logs, not a counter in Postgres that someone increments in application code. An event stream you can query, audit, and replay when a customer disputes a line item.

Credits. Prepaid balances, trial grants, promotional top-ups, and expiry rules. Credits are a different primitive from a subscription. A customer can hold a balance without holding a plan, and can hold both at once with a defined order of deduction.

Entitlements. What a plan allows, checked before an expensive operation runs. Model access, concurrency ceilings, monthly caps. If this check lives in your application code as a series of if-statements against a plan name, every pricing change becomes a deploy.

Miss any of these and the gap gets filled with glue code that finance cannot read and engineering does not want to own.

How the tooling landscape splits

Most of the confusion in this category comes from tools solving genuinely different problems while using overlapping words. It is worth being precise about scope.

Tool	What it is scoped to
Paddle	Payment and merchant-of-record layer. Handles checkout, tax, and currency across regions. Pairs with a metering system rather than replacing one.
Lemon Squeezy	Recurring billing and checkout for small teams. Metered add-ons exist through API extensions. Good for validating a price before a metering stack exists.
SubscriptionFlow	Subscription lifecycle automation. Renewals, trials, upgrade workflows driven by events.
Orb	Strong fit for straightforward self-serve usage pricing. The ceiling shows up as pricing and go-to-market motions get more complex, which is the point where teams look for an enterprise-ready billing platform instead.
Metronome	A metering point solution aimed at engineers. Scope stops at usage measurement, so billing, invoicing and pricing iteration live in other systems.

Flexprice sits in the last row's category but with a wider scope. 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.

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.

What the request path looks like

The mechanism is simpler than the category makes it sound. Your product emits an event when something billable happens. The billing layer aggregates it, prices it, decrements a wallet if one applies, and exposes the result.

A billable event carries the feature name and your own customer identifier:

{
  "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"
}

event_name has to match the metered feature you configured. properties carries whatever the aggregation reads, so a Sum aggregation on credits adds that field across the window. The event_id is yours, which is what makes a retry safe instead of a double charge.

Sending it is one POST:

curl --request POST \
  --url https://api.cloud.flexprice.io/v1/events \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: <your_api_key>' \
  --data '{
    "event_name": "model.usage",
    "external_customer_id": "cust_123",
    "properties": { "credits": 2 }
  }'

The response confirms the event was accepted for processing rather than blocking on the full pricing path:

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

From an inference service, that becomes a call you make after the work completes, on the same code path that already knows the token count:

type Event struct {
    EventName          string                 `json:"event_name"`
    ExternalCustomerID string                 `json:"external_customer_id"`
    Properties         map[string]interface{} `json:"properties,omitempty"`
    Source             string                 `json:"source,omitempty"`
}

func sendEvent() error {
    event := Event{
        EventName:          "model.usage",
        ExternalCustomerID: "cust-test-customer",
        Properties: map[string]interface{}{
            "credits": 2,
        },
        Source: "api",
    }

    jsonData, err := json.Marshal(event)
    if err != nil {
        return err
    }

    req, err := http.NewRequest("POST", "https://api.cloud.flexprice.io/v1/events", bytes.NewBuffer(jsonData))
    if err != nil {
        return err
    }
    req.Header.Set("Content-Type", "application/json")
    req.Header.Set("x-api-key", os.Getenv("FLEXPRICE_API_KEY"))

    client := &http.Client{}
    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()

    fmt.Printf("Event transmitted with status: %d\n", resp.StatusCode)
    return nil
}

High-volume services should batch rather than send one request per inference. The bulk endpoint takes an array of the same objects. The full field reference lives alongside it in the event ingestion docs.

Where does the plan logic live?

Outside your services, if you want to change pricing without a deploy.

The pattern that holds up is a clean split. Your application knows what happened. The billing layer knows what it costs and what the customer is allowed to do. Those are separate concerns and they change on completely different schedules. Product ships a feature every week. Pricing changes once a quarter, but when it changes, it changes across every tier at once.

Concretely, that means a metered feature defines the unit and the aggregation, a plan attaches prices to it, and an entitlement decides access. Creating a Metered Feature covers the first, and entitlement grants cover the access side.

Credits are worth calling out separately because teams reach for them late and then have to retrofit. A wallet holds a balance that is independent of the subscription. Trials become metered grants with a hard cap instead of a fake demo mode, and a prepaid enterprise commitment becomes a balance with an expiry rather than a spreadsheet. Prepaid and promotional credits covers how the balance types differ.

A concrete flow

An inference API with plan-level token limits and a credit balance ends up with something like this:

Request arrives. The service checks the customer's entitlement and balance before running the model.
The model runs. The service emits a usage event with the token count in properties.
The billing layer aggregates the event, applies the plan's rate, and decrements the wallet.
A webhook fires when the balance crosses a threshold, so the customer hears about it before the invoice does.
At cycle close, usage, credits and any recurring fee resolve into one invoice.

None of those steps require billing tables in your product database. The step most teams skip is the fourth, and it is the one that prevents the support ticket.

What this is not

This layer does not replace your payment processor. It decides what a customer owes. Something else moves the money, and the two should stay separable so that a change to one does not force a change to the other.

It also does not remove the hard part of pricing, which is choosing a unit customers can reason about. Metering any unit is a solved problem. Picking one that maps to value is a product decision, and no infrastructure recovers from getting it wrong.

Getting started

Flexprice is open source. You can read the ingestion path, run it against a test feature, and see what the aggregation does to your own event shape before committing to anything: docs.flexprice.io.

Real-Time Billing Architecture for High-Traffic Applications

Flexprice — Wed, 02 Sep 2026 09:13:55 +0000

How to build billing that prices events as they arrive: idempotent ingestion, streaming aggregation, cache safety, append-only ledgers, and reconciliation.

A nightly batch job that reads yesterday's API logs and produces invoice line items is a perfectly reasonable billing system, right up until a customer can spend a month's budget in ninety seconds. Then the gap between "usage happened" and "we know about it" becomes a liability, because every enforcement decision you want to make is a decision you can only make in that gap.

This is the design problem behind real-time billing. Not payments. Payments are the easy end. The hard part is turning a firehose of granular product events into numbers that are correct enough to put on an invoice and fast enough to gate a request.

What makes a billing system "real-time"?

A real-time billing system prices each event close to when it happens, rather than aggregating raw usage on a schedule. The practical test is whether you can enforce a quota synchronously. If a customer's balance can only be known after a batch job runs, the system is not real-time no matter how quickly the dashboard refreshes.

That single requirement drives most of the architecture below.

Event-driven ingestion is the foundation

Every billable action becomes an immutable record. It is written once, never edited, and passed to a durable log such as Kafka. The product emits and moves on. Billing consumes at its own pace.

The decoupling matters more than the throughput. Your inference path should not block on a billing write, and a billing consumer falling behind should degrade into lag rather than into dropped revenue.

Idempotency is not optional

Retries are guaranteed. Networks time out after the server committed, clients replay, consumers restart mid-partition. Without a stable identifier on each event, every one of those becomes a double charge.

The fix is an idempotency key that you generate and control:

{
  "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"
}

event_id is yours to set. Derive it from something already unique in your system, like the inference request ID, so a replay of the same work produces the same key and gets deduplicated instead of billed twice. timestamp should be the time the usage occurred, not the time you got around to sending it, or your aggregation windows will quietly drift under load.

Delivery semantics, stated plainly

At-least-once means nothing is lost and some things arrive twice. Exactly-once means each event is processed once. Kafka gets close to the second with transactions and idempotent producers, but the moment you write to an external system the guarantee degrades back to at-least-once unless every step is atomic.

The usual resolution is to accept at-least-once transport and make processing idempotent at the destination. Cheaper than distributed transactions and easier to reason about at three in the morning.

Aggregation under out-of-order arrival

Usage does not arrive in order. A mobile client buffers offline. A worker retries after a delay. A region lags.

Streaming aggregation handles this with windows and watermarks. Events are grouped into tumbling or sliding windows, and a watermark declares how much lateness the system will tolerate before it closes a window and emits a result. Set the watermark too tight and you drop legitimate usage. Set it too loose and every balance check waits on stragglers.

Pick the aggregation deliberately, because it decides what your event properties need to carry. A Sum over a numeric field is a different contract from a unique count over a string field. Flexprice's aggregation reference covers the available shapes and what each one expects in the payload.

Pricing as configuration, not code

The most common failure in homegrown billing is hardcoded rates. Pricing logic gets written into application services, and then every experiment needs a sprint and a deploy.

Treat pricing as data. Your services emit units. A separate layer applies rates, tiers, discounts and overrides. That layer needs to support graduated and volume tiers, plan-level multipliers, promotional rates, and per-customer overrides, all changeable without shipping code. Volume tiered pricing is a good illustration of what that looks like when it is configuration rather than a switch statement.

Credits and entitlements belong in the same layer. A wallet balance that only resolves at invoice time cannot gate a request, which puts you back to batch behaviour with extra steps.

Caching without corrupting bills

Balance checks on the hot path need to be fast, which means caching, which means a correctness problem.

The workable design is tiered: in-process memory for the hottest counters, Redis for warm state, the database as the source of truth. What keeps it honest is that every write carries the same idempotency key used at ingestion, and the database holds a uniqueness constraint that rejects a duplicate regardless of what any cache believed. Caches are allowed to be stale. They are not allowed to be authoritative.

Storage and partitioning

Do not write everything into one wide table and hope the index holds. Partition by customer and by time. Customer partitioning stops one heavy account from degrading everyone else. Time partitioning keeps recent-window queries off historical data, which is most of what billing actually reads.

Then design the access patterns so the common queries stay inside a single partition. Computing a customer's balance or generating their invoice should not fan out across shards. Cross-shard work is where tail latency comes from, and billing is a workload where the tail is the part users notice.

Reliability patterns that protect revenue

Split the online path from the reconciliation path. The online path is fast, synchronous, and does the minimum needed to answer "can this request proceed?" Reconciliation runs behind it, recomputing from raw events and correcting drift.

Add circuit breakers on downstream calls. When a dependency starts failing, stop sending it traffic and degrade deliberately rather than cascading. Decide in advance whether a metering outage should fail open, which risks unbilled usage, or fail closed, which risks rejecting paying customers. Both are defensible. Choosing at incident time is not.

Correctness and auditability

Bills get disputed, so the system has to be able to explain itself.

Use append-only ledgers. Nothing is deleted or overwritten, only superseded by a new entry. Every invoice line item should trace back to the events that produced it and the pricing rule that was applied. Keeping raw events queryable is what makes that possible, and it is the reason the event debugger exists as a first-class tool rather than a support escalation.

Then run continuous reconciliation. Compare what was billed against the raw event stream and flag divergence. Late events, consumer gaps and rule changes all cause drift. Reconciliation is not a launch task you complete, it is a loop you keep running.

Quotas and enforcement

Enforcement needs distributed atomic counters that update fast enough to stop a breach rather than report one after the fact.

Layer the policies. Soft thresholds send an alert at eighty percent and let the workload continue. Hard caps stop it. Internal anomaly detection catches the runaway loop that neither threshold anticipated. Soft limits protect the customer relationship, hard limits protect the business, and you generally want both rather than a choice between them.

Observability tied to money

Track ingestion rate, processing latency, queue depth and error rate, then add revenue per second alongside them. A metering consumer that stalls looks healthy on CPU graphs and costs money the entire time it is stalled.

Trace an event from the API boundary through to the invoice line, and put engineering and finance on the same dashboard. Most billing incidents are discovered by finance and diagnosed by engineering, and that handoff is much faster when both sides are reading identical numbers.

Testing that catches expensive mistakes

Property-based tests are unusually effective here. Assert invariants that must hold for any input: line items sum to the invoice total, a balance never goes negative, replaying the same event set twice yields the same bill. Rounding and edge cases surface fast under randomized input.

Before changing pricing logic, run it in shadow mode against live traffic and diff it against the current system. Cut over when the diff is explainable. Then run failure drills: drop messages, inject consumer lag, kill a broker, and confirm reconciliation actually closes the gap.

How to evaluate a platform

The questions worth asking are narrow. What is the sustained ingestion rate and the latency from event to queryable balance? Does it fit the infrastructure you already run, meaning Kafka, Postgres, ClickHouse, without an adapter layer? Can pricing change without a deploy? Are raw events retained and queryable for audit? Does cost scale with your event volume in a way you can afford at ten times current traffic?

Scope is the axis that separates most vendors, and it is worth being explicit about:

Metronome is a metering point solution built for engineers. It measures usage well, and stops there, so invoicing, reporting and pricing iteration have to come from elsewhere in your stack.
Flexprice covers the whole path: metering, billing, invoicing, reporting and pricing experimentation, all on a raw event data model, with pricing agility and simulations included rather than assembled.
Orb works well for straightforward self-serve usage pricing. Teams typically outgrow it as pricing and go-to-market motions get more complex and they need an enterprise-ready billing platform.

Against the closed-source hosted platforms generally, Metronome, Orb and m3ter are vendor-hosted. Flexprice is open source and deploys inside your own VPC or on-prem, so usage and revenue data never has to leave your infrastructure. Lago is also open source and self-hostable, and the difference there is enterprise scale: Flexprice is built for real-time metering at high event volume, with deployment across any VPC and any geography.

The shape it takes in production

Events land on Kafka. ClickHouse handles aggregation, which is a good fit because billing queries are analytical: sum this field, over this window, for this customer. The pricing engine rates each event as it arrives rather than waiting for a cycle boundary. Wallets and entitlements read from the same aggregated state that invoicing reads from, so enforcement and billing cannot disagree.

For high-volume services, batch the writes. One request per inference is a lot of connections you do not need:

curl --request POST \
  --url https://api.cloud.flexprice.io/v1/events/bulk \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: <your_api_key>' \
  --data '{
    "events": [
      {
        "event_name": "model.usage",
        "external_customer_id": "cust-test-customer",
        "properties": { "credits": 2 }
      },
      {
        "event_name": "model.usage",
        "external_customer_id": "cust-another-customer",
        "properties": { "credits": 5 }
      }
    ]
  }'

Buffer in memory, flush on a size or time trigger, and keep the per-event event_id so a flush that gets retried after a partial failure stays safe.

Getting started

The ingestion path, the aggregation logic and the pricing engine are all open source, so the fastest way to evaluate any of this is to read the code and run it against your own event shape: docs.flexprice.io.

Implementing Dynamic Pricing Without Breaking Customer Trust

Flexprice — Wed, 02 Sep 2026 09:06:37 +0000

A practical sequence for dynamic pricing: data foundations, choosing a method, piloting narrowly, and the guardrails and audit trail that keep it defensible.

Dynamic pricing reads well on a strategy slide. Prices adapt to demand, revenue goes up, nobody leaves money on the table. Most implementations stall well before that, and usually for one of two reasons.

The first is data. Teams have plenty of it, fragmented across tools and delayed by hours, so when a pricing rule fires nobody can say whether it reacted to a live signal or to last week's residue. The second is integration. The pricing logic works in a notebook, and the billing stack was never designed to accept rate changes at runtime, so wiring the two together is invasive and brittle.

Both are solvable, in a specific order.

What is dynamic pricing?

Dynamic pricing means prices adjust continuously in response to usage, value delivered or market demand, instead of being fixed at contract signing and revisited annually.

It is calibration rather than automation. The word "dynamic" leads people toward an algorithm choosing prices unsupervised, which is rarely what works. What works is a defined policy, evaluated against reliable data, adjusted on a schedule, inside limits a human set deliberately.

Start with a goal you can measure

Vague goals produce unattributable results. "Improve monetization" cannot be evaluated. "Improve gross margin by ten percent within one quarter" can.

Then isolate the variable. If you change price, feature gating and billing frequency in the same window, you will not learn which one moved the number. Change one thing, hold the rest, and give it long enough to produce a signal.

Data foundations before automation

Three pillars, and skipping any of them means the pricing engine is reacting to noise.

Internal signals. Transaction history, feature-level usage, conversion rates, churn, and cost to serve. Cost to serve is the one most often missing, and without it you can optimize revenue while destroying margin.

External signals. Seasonality, market movement, broader conditions. Less critical for most SaaS than internal usage, more critical if you resell compute.

Quality and governance. Scheduled audits and model refreshes. Pricing models drift, and a drifted model makes confident bad decisions.

The practical prerequisite underneath all three is event-level usage data that is current and queryable. Aggregated monthly rollups are too coarse to price against and too late to react to. That means a metering layer that records usage as it happens, keeps raw events for audit, and lets you query them per customer and per feature. The event ingestion overview covers what that layer has to guarantee.

Choosing a method

Match the method to your product rather than to what sounds sophisticated.

Demand-responsive pricing adjusts by time window, peak versus off-peak. It fits products with predictable demand cycles and real capacity constraints.

Elasticity-aware adjustment uses historical data to align price with willingness to pay across segments. Useful in SaaS and AI where price sensitivity varies widely and is not obvious in advance.

Hybrid combines a stable base fee with a variable metered layer. It captures upside as usage grows while leaving both sides able to forecast, which is why most AI and SaaS teams end up here.

Roll out narrowly

Pilot before you commit. Keep the scope tight: a few features, one usage band, or a single customer segment. Define the KPIs first, margin, revenue per account, churn, conversion, and set the review date before you start.

Test the policy, not only the price. Guardrail width, how often prices are allowed to change, and how changes are communicated all affect the outcome as much as the number does. A well-priced change communicated badly still costs you accounts.

Keep pricing logic, policies, approvals and audit logs in one place. When rules live in several systems, nobody can answer why a specific customer was charged a specific amount, and that question always eventually gets asked.

Guardrails that protect trust and margin

Set floors and ceilings. Set a maximum change frequency. Define who can approve an exception and how it gets recorded. These limits are what let you move quickly without a bad rule doing real damage before anyone notices.

Fairness deserves attention as an engineering constraint, not only a marketing one. Unexplained or heavily personalized pricing reads as predatory, and it damages trust in a way that is slow and expensive to repair. If you cannot explain a price change in one sentence a customer would accept, it is the wrong change.

Communicate before the invoice. A customer who learns about a rate change from a bill has learned two things, and the second one is that you were not going to tell them.

The implementation sequence

Phase 1, policy design. Define value metrics, eligible products and segments, floors, ceilings and review cadence.

Phase 2, data plumbing. Get usage, cost and conversion data into one system. Build the reporting that isolates pricing impact from everything else moving at the same time.

Phase 3, pilot. Narrow scope, defined KPIs, fixed review schedule.

Phase 4, scale with governance. Approval workflows, anomaly detection, and documented operating procedure.

Most failures come from attempting phase four sophistication on phase two data.

What this requires of your billing stack

Dynamic pricing is largely an infrastructure problem, and the requirements are specific.

Pricing has to be data, not code. If a rate change requires a deploy, your review cadence is capped by your release cadence and every experiment competes with product work for engineering time. Your services should emit usage. A separate layer should apply rates.

You need versioning and segmentation, so different rules can apply to different cohorts at the same time, and you need to be able to route a portion of traffic to a new rule while the rest stays on the old one. Price overrides covers the per-customer and per-plan variant of this.

You need an audit trail that finance and support can read without an engineer translating. Every charge should be traceable to the events that produced it and the rule version that was applied.

And you need reversibility. Some changes will be wrong. Rolling one back should be a configuration change, not an incident.

Where the tools sit

The platforms in this space are built for different buyers, which matters more than their feature lists.

Pricefx targets large B2B catalogues and price lists, with elasticity analytics, waterfall analysis, and approval workflows tied into ERP and CRM.

Zilliant serves enterprise B2B with complex quoting, using predictive models for deal scoring and price guidance inside sales workflows.

ProfitWell focuses on subscription price sensitivity analysis and automated recommendations, weighted toward churn reduction.

Perfecto Price does segment-level price optimization with competitor monitoring and real-time API integration into sales channels.

Those four optimize the pricing decision. They do not meter usage or produce invoices, so they sit alongside a billing system rather than replacing one. For usage-based and hybrid products, the billing layer is where dynamic pricing actually executes, and that is a different category.

Within it, scope is the distinguishing axis. Metronome is a metering point solution built for engineers, so it measures usage and leaves invoicing, reporting and pricing iteration to other systems. Flexprice spans the full path, metering through billing, invoicing, reporting and pricing experimentation, on a raw event data model, with pricing agility and simulations native to the platform rather than assembled around it. Orb handles simple self-serve pricing well and tends to get outgrown as pricing and go-to-market motions grow more complex, which is the point where teams move to an enterprise-ready billing platform.

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.

Two more distinctions worth stating precisely. Chargebee, Recurly and Maxio are subscription management software built for plan-based and per-seat billing, hosted only, while Flexprice is metering-first infrastructure built for usage-based and hybrid pricing. 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.

How the loop closes in practice

Track the value metric you charge for, whether that is API calls, minutes or agent actions, and attach the attributes you want to target rules on, such as plan or segment.

{
  "event_name": "api.calls",
  "external_customer_id": "cust_123",
  "properties": {
    "plan": "growth",
    "region": "eu-west-1"
  },
  "event_id": "req_7c31a",
  "timestamp": "2025-08-22T07:05:49.441Z",
  "source": "api"
}

Recording plan and region on the event is what makes segment-level pricing rules possible later without touching the emitting service. Instrument the dimensions before you need them, because retrofitting them across live services is the expensive part.

From there the rules apply against aggregated usage, guardrails constrain what the rules can do, versions let segments differ, logs stay readable to finance and support, and metered usage resolves into invoices and credits automatically.

Common pitfalls

Do not build sophistication before the data supports it. Start with one rule and one segment.

Keep humans in the loop, with manual override and a defined escalation path for outliers. An algorithm that cannot be interrupted will eventually price something absurdly.

Explain your price drivers openly. Most trust damage from dynamic pricing comes from opacity rather than from the prices themselves.

Getting started

The metering, pricing and invoicing layer is open source, so you can model your own rules and guardrails against real event data before rolling anything out to customers: docs.flexprice.io.

Building Custom Pricing Models for AI Services

Flexprice — Wed, 02 Sep 2026 08:55:29 +0000

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.

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.

Why Token Pricing Confuses Buyers, and What to Meter Instead published

Flexprice — Sat, 22 Aug 2026 05:22:48 +0000

A quote for 50,000 credits gives a buyer nothing to reason about. They cannot tell what it gets them, how long it lasts, or what happens when it runs out. The translation work gets pushed onto the person paying, and most of them will not do it.

Tokens, credits, and API calls are infrastructure units. The people signing the contract think in leads routed, contracts reviewed, and reports generated. When the two do not line up, the buyer either undervalues the product or walks away.

This is a metering problem before it is a sales problem. If your event stream only carries token counts, nobody downstream can price an outcome, because the outcome was never recorded.

What is use case based sales?

Use case based sales means pricing the outcome the customer is trying to achieve rather than the package or the compute that produces it. Credits and tokens still exist underneath. They stop being the thing on the quote.

Simon Ooley, CEO of Veles, frames the shift like this:

"5,000 tokens or 5 million tokens means nothing to a buyer, but the outcome they get with those tokens means everything."

The conversation starts from the job instead of the tier list. A buyer says they want to route inbound leads more effectively because they are losing some and leaving money on the table. That job becomes the unit the model is built around. As Ooley puts it, "The tokens are just an ancillary currency. It's not something that is our core package deliverable."

Why does packaging break for AI products?

Traditional SaaS packaging assumed a stable relationship between the product and the use case. You buy an HRIS to run payroll. The features are defined, the value is understood, and the price reflects it.

That assumption does not hold for products that can automate almost anything. Ooley describes the effect on positioning:

"It's almost impossible to tell one person what that product does for them because it could do anything."

The downstream symptom is familiar. Sales teams improvise, build one-off models per deal, and describe the product differently to every prospect. Not out of strategy. The packaging gave them nothing to anchor on.

Why outcome pricing is harder to game

Every pricing model has a workaround. Seat licenses get shared, and five seats become fifteen people behind one password. Credit systems get hoarded. Flat fees get arbitraged by heavy users.

Outcome pricing narrows the gap because spend and value move together. Ooley uses cloud compute as the reference:

"You're not going in there looking to spend $50,000. You're not setting a budget to say, okay, I'm only going to spend $50,000. If you need to compute more to deliver for your customers, you're going to spend more because that's the desired outcome."

There is no arbitrage when more spend produces more of the thing the buyer came for. Expansion stops being a negotiation and starts being a reorder. Ooley is direct that gaming never disappears entirely: "Whatever pricing model you have, you can gamify it. But I think the closer you get to the desired outcome, the harder it's going to be to gamify."

What changes in packaging, pricing, and comp

Packaging becomes use case driven
Feature flags and caps stop being the organizing idea. Ooley: "The packages are not about the feature flags and the predefined outcomes. It's more about, hey, this is why people buy it here are the use cases they look to accomplish."

On a pricing page that reads closer to a statement about what companies at a given size actually accomplish, and what that takes, rather than a column of included features.

Pricing moves off cost-plus
Tying price to model cost means every upstream price change lands on you. Ooley's advice: "Focus on the value you're providing. Make sure your margin for cost is aligning with your financial model. But essentially, don't do cost-plus." Price the outcome and a model getting cheaper improves margin rather than compressing revenue.

There is a second layer. Not every token is worth the same. "Every token spent on inbound is drastically more valuable than every token spent on outbound." Two use cases can burn identical compute and carry very different prices.

Comp rewards growth, not just the logo
Traditional comp pays on new logos. Ooley is blunt about the failure mode: "Traditional SaaS is new logo. Bang. I'm just going to throw this deal in, throw the grenade over the fence to customer success. That pays out the individual contributor, but it doesn't pay out the business in the long term."

Under use case based selling, the reps who model out five use cases and land the two most urgent have mapped the expansion path themselves. "Any use cases that you've modeled out with them that they want to accomplish that aren't top of mind right now is the clearest path to white space upsell." Tying compensation to consumption growth inside the account is what keeps that path worth walking.

What this demands from the billing layer

The framework collapses if the billing system cannot represent it. Ooley describes the fallback most teams land in:

"We were just rebuilding all that logic in a Google spreadsheet or an Excel spreadsheet and doing all pricing and packaging outside of the CPQ which of course leads to discrepancies between the spreadsheet and the source of truth."

Reps quote one number, finance sees another, and nobody trusts either. Onboarding gets worse: "here's this spreadsheet and please don't click any cells but the ones that are highlighted in yellow or else you're going to break it."

Four requirements fall out of this.

Hybrid pricing as a first-class model. Almost nobody goes pure consumption in one step. Ooley: "What's working the best today is package plus consumption or package plus usage. Hey, you're going to buy X number of seats plus you get this limit of credits, you can always buy more." A system that models seats and a credit allowance and overage as one subscription handles this. A system that needs two products stitched together does not. Flexprice documents this shape under hybrid pricing.

Real-time usage tracking. Scoping deals against credit estimates only works if both sides can see consumption as it happens. Batch metering means every expansion conversation runs on stale numbers. The event ingestion overview covers how events land and get attributed.

Flexible entitlements. Different customers buy different bundles of use cases. Each new configuration should not require an engineering ticket. Entitlement grants are the primitive that keeps access rules out of application code.

Room to change your mind. AI pricing is not settled. Testing a credit tier or an outcome metric should not mean a billing migration.

The instrumentation consequence is worth stating plainly. If you want to price a resolved ticket, your product has to emit a resolved-ticket event, not just the token count that produced it. Illustratively, that is the difference between:

{

  "event_name": "llm.call",

  "external_customer_id": "cust_4471",

  "properties": {

    "model": "gpt-4o",

    "tokens_in": 4120,

    "tokens_out": 880

  }

}

and:

{

  "event_name": "ticket.resolved",

  "external_customer_id": "cust_4471",

  "properties": {

    "ticket_id": "t_88213",

    "use_case": "inbound_support",

    "tokens_in": 4120,

    "tokens_out": 880

  }

}

The second carries the billable outcome and keeps the compute detail for margin analysis. The first can never be priced as an outcome, no matter what the contract says, because the outcome was never recorded. Custom units of this kind are defined through metered features.

Subscription-era billing tools were built around fixed seats, annual terms, and predictable revenue. 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.

Where AI pricing is going

Ooley's advice to founders is short:

"Simplicity is key. Number one. Number two, focus on the desired outcome that you're looking to solve for your customer and have candid conversations about how much that use case is worth."

That is the whole framework. Not clever packaging, not deeper credit tiers. A clear answer to what you are solving and how you price against it. Teams that get there early end up with a revenue model that grows with customer value and does not break when foundation model costs move.

The advantage is not in the tokens. It is in what the tokens accomplish, and in whether your event stream is recording it.

Read the event ingestion docs if you want to see what metering an outcome looks like end to end.

Top 5 Real-Time AI Usage Tracking and Cost Metering Tools published

Flexprice — Sat, 22 Aug 2026 05:11:33 +0000

Most AI startups do not lose money because the product is bad. They lose it because they cannot see their costs while the costs are happening. Inference-heavy workloads and third-party model APIs can double overnight, and so can the bill.

One founder on Reddit put it plainly: "We spent $12,000 in a month on tokens because we had no visibility."

That is the normal state of things. Real-time tracking turns the blind spot into control: every API call, token, and GPU second visible as it happens, spikes caught early, and spend tied back to the customer it was generated for.

This breaks down the five most effective tools for the job, starting with Flexprice, then the six-layer stack they plug into.

Read the complete piece here.

Short answer

Flexprice is the strongest option for AI startups that need metering and monetization in one system, because it converts raw usage into billable metrics in real time and enforces credits, entitlements, and quotas from the same event stream. Helicone and Lunary cover LLM observability, Amberflo covers cost allocation and forecasting, and Vayu covers event-to-metric streaming.

What to require in an AI cost tracking system

Real-time cost tracking is not about dashboards. It is about precision and control. Six things matter before you choose anything.

Granular visibility. Track usage per customer, per feature, per model. Without it you never learn which workloads drive value and which drive loss. As a developer on Hacker News noted, most startups "track total spend but not who or what caused it," which makes optimization nearly impossible.
Real-time ingestion and aggregation. Batch updates are too slow for AI workloads. Events should be processed as they occur, token by token and call by call, because enforcement and customer-facing balances are only as current as this layer.
Flexible pricing logic. Your rate model will change. The system has to support credits, entitlements, tiered usage, and hybrid plans without constant code changes.
Alerts and thresholds. Costs should never surprise you at month end. Look for live alerts when usage crosses a limit or an anomaly pattern appears.
Integration flexibility. The tool should plug into your billing systems, databases, and analytics layers without a rebuild. Compatibility with Kafka, ClickHouse, or Stripe APIs keeps the choice reversible.
Scalability. AI usage grows in steps, not curves. Pick infrastructure that handles millions of events per day without losing accuracy.

The right tracking layer is the foundation billing, pricing experiments, and long-term profitability all sit on.

Top real-time AI usage tracking and cost metering tools

1. Flexprice: real-time metering and billing for AI startups

Flexprice is built for AI teams that need full control over how usage turns into revenue. It tracks API calls, GPU hours, and token counts as they happen and converts raw usage into billable metrics instantly, rather than reconciling them after the period closes.

Teams define pricing models directly: credits, entitlements, and hybrid usage plus subscription, then enforce them in real time through built-in quota checks. Because enforcement runs off the same event stream as billing, the balance a customer sees and the balance the system gates on are the same number.

Flexprice supports aggregation types including sum, count, unique count, and latest, which covers workloads from model inference to daily active user tracking.

Integration is through SDKs or by streaming into existing Kafka and ClickHouse pipelines, so collectors attach to a queue you already run rather than asking for a second one.

Two properties separate it from the rest of this list. Because Flexprice is open source and self-hostable, usage and revenue data can stay entirely inside your own infrastructure and never reach a vendor's cloud. This is what makes Flexprice usable by companies with data residency, sovereignty, and audit requirements that hosted-only billing vendors cannot meet. And Flexprice is the metering and billing layer itself, and is not tied to any payment gateway, so switching payment providers does not mean rebuilding the meter.

If you are scaling an AI product, this covers both ends, metering and monetization, without a second system for invoicing.

2. Amberflo

Amberflo focuses on visibility and cost allocation across AI infrastructure, showing how much each model, feature, or customer costs in real time. Finance and operations teams use it most, and it is strong for forecasting and budget control even when billing runs somewhere else.

3. Helicone

Helicone offers no-code observability for LLM applications. You replace your API endpoint and it starts tracking token usage, latency, and cost per model or user. It is a fast way for early-stage teams to get visibility before standing up dedicated billing infrastructure.

4. Vayu

Vayu converts raw product events into billable metrics in real time. It is useful as a streaming layer that transforms in-app activity into pricing logic, and teams often place it between their product and a billing or analytics platform.

5. Lunary

Lunary focuses on how AI endpoints perform and what they cost, with dashboards covering prompt-level usage, latency, and error rates. It suits developer visibility and performance tuning rather than full billing workflows.

Building a real-time AI metering stack

Building an AI product without real-time cost visibility is running a data centre with no meter on the wall. Every call, model switch, and GPU cycle adds up, and the costs stay hidden until the invoice arrives. A metering stack solves that by turning raw events into pricing-ready data. Startups usually structure it in six layers.

1. Instrumentation and logging

Log every API call, model request, and GPU job with the identifiers that make attribution possible: user ID, customer ID, model name, tokens in and out, and duration. Attribution is decided here. No downstream processing recovers a field you never emitted.

{

  "event_name": "inference.completed",

  "external_customer_id": "cust_4471",

  "event_id": "evt_9f2a41c7",

  "timestamp": "2026-08-21T09:14:22.318Z",

  "source": "inference-worker",

  "properties": {

    "model": "gpt-4o",

    "tokens_in": 4120,

    "tokens_out": 880,

    "duration_ms": 1840,

    "feature": "contract_review",

    "environment": "production"

  }

}

Only event_name and external_customer_id are required. The event name has to match a configured metered feature exactly, and the customer has to exist before the event lands, or the call is rejected. Numeric property values are what Sum and Max aggregations read; string values are for Unique Count and Latest.

That last field earns its place. As one developer shared on Reddit, "We realized half our OpenAI cost came from internal test traffic we never excluded." Evaluation runs and internal testing land in the same cost bucket as customer workloads unless you tag and exclude them.

2. Real-time ingestion

Stream events through Kafka, Kinesis, or another queue so they are processed immediately. Latency at this layer determines how real-time your insights actually are. A five-minute lag is fine for a cost dashboard and useless for a quota check gating a live request.

Delivery semantics get decided here too. Retries and worker restarts mean the same event can arrive twice, so either ingestion deduplicates or every consumer downstream has to. Flexprice documents the contract under sending events and validating events.

3. Aggregation and pricing logic

Aggregate by customer or feature, then apply rate cards. The aggregation choice is a modelling decision rather than a default: summing tokens, counting requests, counting unique users, and taking the latest gauge value produce different bills from identical events.

Flexprice handles this automatically, letting you define hybrid pricing, credits, and entitlements through configuration instead of code. That distinction is what decides whether a pricing change ships on a business timeline or an engineering one.

4. Storage and dashboards

Store processed usage in a time-series or columnar database such as ClickHouse. Aggregate queries over high-cardinality event data are what this class of database exists for, and a row store holds up until roughly the moment the data gets interesting. Two audiences read from here: internal teams needing cost and margin views, and customers needing their own consumption, which is the same query with a tenant filter and a much higher correctness bar.

5. Alerts and anomaly detection

Set automated alerts for usage spikes, budget thresholds, and anomalies. This feedback loop prevents unexpected overages and keeps margins predictable, and it works in both directions, protecting your margin and protecting the customer from an invoice they did not see coming. Flexprice covers the customer-facing side through spend alerts and threshold notifications.

6. Billing and reconciliation

Connect metering to invoicing and payments. Flexprice does this natively, generating invoices, updating wallets, and supporting online and offline payments without extra integration work.

Reconciliation is the layer teams skip and then rebuild. A daily job comparing ingested events against rated usage against invoiced amounts surfaces revenue leakage while it is still small enough to fix quietly. Skip it and the discrepancy gets found by a customer instead.

A well-designed stack does not just track usage. It closes the loop between consumption, pricing, and revenue, which is what separates scaling safely from scaling blind.

Wrapping up

AI costs scale faster than most startups can monitor them. What starts as a few API calls becomes thousands of dollars of invisible spend. Tracking usage in real time gives teams something more useful than dashboards. It gives them control.

Flexprice anchors that control with metering, pricing, and billing built for AI products, so teams can see where money flows, enforce limits where they need to, and turn variable usage into predictable revenue. Every other tool here, whether for observability, analytics, or forecasting, works best paired with that foundation.

Real-time tracking is not an afterthought anymore. It is the infrastructure that keeps AI companies sustainable.

Read the architecture overview to see how the metering and billing layers fit together.

Five Pricing Models for AI Agents, and How to Meter Each One published

Flexprice — Sat, 22 Aug 2026 04:38:21 +0000

Pricing a taxi ride by the number of gear shifts would be measurable, auditable, and completely disconnected from the value of the ride. That is roughly what happens when an AI product defaults to token pricing. The metric is easy to instrument, and nobody checked whether it means anything to the person paying.

The deeper issue is framing. Price tokens and you have described your product as infrastructure, and infrastructure gets commoditized. What an AI agent actually sells is work completed: tickets resolved, contracts reviewed, leads qualified, documents processed. That is a different thing to put a price on, and it needs a different metering layer underneath.

This walks through the five models AI companies are actually running, what each one demands from billing, and where each one breaks.

Read the detailed piece on how to price your AI agent.

Short answer

Price the unit of work your agent completes, not the compute it burns completing it. Usage-based fits API and developer products, credits fit multi-feature products, outcome pricing fits agents with a clean success signal, subscriptions fit predictable workloads, and hybrid fits most companies at scale because it holds a revenue floor while letting heavy users pay for what they consume.

Why AI pricing breaks SaaS assumptions

Three assumptions stop holding.

Software access became work completed. Traditional tools help a user do a task. An agent does the task. A support agent resolves tickets, a sales agent runs outbound, a research agent analyzes documents. What the customer receives is finished work, not a login.

Near-zero marginal cost became real compute cost. Serving one more SaaS user costs almost nothing. Serving one more agent request triggers model inference, API calls, data processing, and orchestration. Cost now grows with usage, so a mispriced model does not just underperform. It inverts your margin as you grow.

Seats became units of work. Agent value is not tied to individual users. It is tied to documents analyzed, tickets resolved, workflows executed, conversations handled. Per-seat pricing has nothing to attach to.

Which leaves one question to answer before anything else: what unit of value should the customer pay for?

The four problems that show up once usage is real

Finding the value metric. Your product emits tokens, API calls, compute time, inference requests. None of those mean anything to a buyer. The work is translating infrastructure metrics into customer-facing ones that are both easy to understand and honestly correlated with the value delivered.

Usage unpredictability. A customer can send a few hundred requests one day and thousands the next. Customers want predictable bills, and AI workloads are inherently variable. Those two things are in direct tension, which is why credit and hybrid models exist.

Margin protection. Every request consumes inference, storage, orchestration, and compute. AI companies operate on tighter margins than classic SaaS, so heavy usage that is priced wrong does real damage rather than just leaving money on the table.

Billing infrastructure sprawl. The common starting point is Stripe for payments, usage tracking in internal scripts, entitlements behind feature flags, and pricing math in a spreadsheet. It holds until it does not, usually right when usage becomes worth billing carefully.

How to choose: four questions

What job does the agent do?

Start from the task being automated, not the stack underneath. Resolving support tickets, analyzing documents, generating outreach, executing workflows. That job is the foundation of the model.

What is the natural unit of work?

Translate the job into something countable that the customer already cares about. Conversations handled, documents processed, workflows executed, tasks completed. A legal tool charges per contract analyzed. A support agent charges per ticket resolved.

The gap between a bad metric and a good one is usually this stark:

Weak metric: $0.002 per 1k tokens
Better metric: $0.10 per document analyzed

Same underlying compute. Only the second one can be reasoned about by a buyer.

How predictable is the workload?

If usage swings hard between customers, pure subscription pricing will hurt. Usage-based and credit models absorb variance because price scales with activity.

What does the agent cost to run?

Model inference, infrastructure, orchestration complexity. A workflow that chains several model calls costs meaningfully more than a single prompt. Cost should not set your price, but it has to bound it.

Credit-based pricing

Credit pricing converts usage into a single virtual currency. Rather than exposing a dozen separate meters, you give the customer one balance and assign each action a credit cost.

{

  "generate_image":   5,

  "process_document": 1,

  "run_workflow":     2,

  "analyze_contract": 3

}

Why it works. It collapses a multi-feature product with wildly different compute costs into one number the customer can track. It enables prepaid bundles, which improves cash flow and caps exposure to heavy workloads. And it gives customers a visible budget to monitor instead of an invoice to fear.

What it needs from billing. A per-customer wallet, a mapping from product action to credit cost, and atomic deduction as events arrive. Balances have to update as usage lands, not at invoice time, or the customer-facing number is fiction.

Flexprice implements this with credit wallets and prepaid and promotional balances, with low balance alerts wired to the same ledger.

Where it breaks. Credit-to-value opacity. If nobody can explain what 50,000 credits buys them, you have reintroduced the token problem with extra steps.

Usage-based pricing

Charge on measured activity. Tokens generated, API calls, workflows executed, requests handled.

1M tokens processed $1.50

workflow executed $0.05

document processed $0.10

When it fits. Workloads vary a lot, customers want pay-as-you-go, and the product genuinely is infrastructure or an API. Model APIs price per token because developers expect price to track compute, and in that context it is the honest metric.

What it needs. Real-time metering over a high-volume event stream, pricing rules attached to metrics rather than baked into application code, and invoices generated from metered events. The path is: agent does work, backend emits an event, the meter matches it against the customer's plan, the pricing engine rates it, usage appears in the dashboard. Aggregation choice matters here, and the aggregation types page covers sum, count, unique count, and the rest.

Where it breaks. Bill shock, and a revenue floor of zero. A quiet month is a quiet invoice.

Outcome-based pricing

Charge for the result, not the activity that produced it.

support ticket resolved $0.50

qualified lead generated $3.00

contract reviewed $1.00

invoice processed $0.20

Why it appeals. Incentives line up. More value delivered means more revenue, and the customer can justify the line item internally because it maps to a business result. Paying per resolved ticket connects cost to operational value in a way that paying per token cannot.

What it needs. Custom metrics defined against outcome events, which means your product has to emit ticket.resolved rather than only llm.call. Defining those units is a metered feature concern.

Where it breaks. Attribution and disputes. You need a defensible definition of success, and a customer who disagrees that a ticket was really resolved is now arguing about the invoice.

Subscription pricing

A recurring fee for access. Starter at $29, Pro at $99, Enterprise on request. Predictable, familiar, and still the right call for AI copilots, productivity assistants, and research tools where usage clusters tightly.

Where it breaks. Margin, at the tail. Two customers pay $99. One sends 500 requests, the other sends 50,000. Without limits, the second one is funded by the first, and eventually by you.

The fix is not abandoning subscriptions. It is bounding them with included allowances, feature entitlements, and overage pricing past the limit.

Hybrid pricing

Most mature AI products land here, because it is the only structure that answers both the revenue-predictability and workload-variance problems at once. Subscription plus usage, platform fee plus credits, or subscription plus outcomes.

A typical shape:

$199/month platform fee

includes 10,000 credits

overage billed per unit beyond the allowance

That holds a revenue floor, charges heavy users proportionally, protects margin against compute spikes, and supports customers with very different workloads on the same plan structure. What it demands is a billing system where subscriptions, credit wallets, usage metering, and overage are the same object rather than four integrations. Overage behavior turns on advance versus arrear charges, which is worth understanding before you commit to a billing period.

Four mistakes that repeat

Copying API pricing blindly. Token pricing is correct for an inference provider where usage maps directly to infrastructure. It is usually wrong for an agent completing business tasks. A support agent may burn thousands of tokens on one ticket. The customer is counting tickets.

Letting token cost define price. Cost is an input, not the model. Starting from inference cost and adding margin caps your upside at whatever the model costs this quarter and hands your pricing to your vendor's roadmap.

Ignoring compute volatility. If the model has no mechanism for usage spikes, infrastructure cost climbs without matching revenue. This is the specific reason subscriptions get paired with usage or credits.

Overcomplicating the metric. If a customer has to reason about tokens and compute units and API calls simultaneously to estimate their bill, they will not estimate it. They will hesitate. Clear units of value get adopted and get scaled.

What this means for your billing layer

Every model above is a different arrangement of the same three primitives: an event stream, a rating engine, and a ledger. The reason pricing changes feel expensive is usually that those three things live in application code, spreadsheets, and a payments provider that was never designed to hold them.

The point of separating metering from payments is that the pricing model becomes configuration rather than a migration. Price the work, not the tokens, and keep the metric simple enough that a customer can predict their own invoice.

Start with the event ingestion docs to see what metering a unit of work looks like in practice.

How to Implement Credit-Based Billing for AI Applications published

Flexprice — Fri, 21 Aug 2026 16:15:03 +0000

Credits disappear faster than users expect, and when there is no visibility connecting usage to the balance, the first thing they lose is trust in the number. The second thing they lose is trust in the invoice.

Credit billing is a ledger problem wearing a pricing costume. Get the ledger right and expiry, rollover, refunds, and live enforcement all become straightforward. Get it wrong and you are reconciling by hand every month, explaining double charges, and discovering that two concurrent requests both spent the same credit.

This covers the failure modes specific to AI workloads and the implementation order that avoids most of them.

Read the entire blog here.

Short answer

A credit system needs four things: a wallet per customer, an append-only ledger where every debit and credit is a row that is never updated, idempotency keys on every transaction so retries cannot double-charge, and a balance check before the compute starts rather than after it finishes.

What is credit-based billing?

Credit-based billing converts product usage into a single virtual currency. The customer holds a balance, each action in the product has a defined credit cost, and consumption debits the balance as events arrive. One meter the customer can watch, instead of a dozen they cannot.

Why AI workloads make this harder

Costs are not stable. Traditional subscriptions produce the same revenue regardless of usage. AI costs move with the model, the region, and the shape of the request. One call is a fraction of a cent and the next one is not, which makes a fixed credit rate card a margin decision rather than a formatting choice.

Metering happens at volume. Counting every API call and every second of inference time is the easy part to describe. Doing it accurately, in real time, and without dropping events is the part that determines whether the balance you show a customer is real.

The data starts fragmented. Usage logs, invoices, and payment records typically live in separate systems. When they disagree, billing is wrong by definition, and the resolution is manual work plus a customer who no longer believes you.

Retries are the default. Networks fail, workers restart, clients retry. Without idempotency, a single credit deduction becomes two. One double charge costs more trust than a month of correct invoices earns.

Step 1: define the credit unit and rate card

Decide what one credit represents before anything else. 1,000 tokens burns 1 credit. Processing one image takes 10. Then build the rate card from your compute cost plus the margin your financial model needs.

Keep the rate card out of application code. Pricing that lives in a config the billing layer reads can change without a deploy. Pricing that lives in a switch statement cannot.

{

  "version": "2026-08-01",

  "actions": {

    "tokens_1k":        { "credits": 1 },

    "image_generate":   { "credits": 10 },

    "document_process": { "credits": 1 },

    "contract_analyze": { "credits": 3 }

  }

}

Step 2: build the wallet and ledger

One wallet row per customer holding the current balance. One append-only ledger recording every credit, debit, and expiry as an immutable row.

CREATE TABLE wallet (

  customer_id   TEXT PRIMARY KEY,

  balance       BIGINT NOT NULL,

  version       BIGINT NOT NULL DEFAULT 0

);

CREATE TABLE ledger (

  id              BIGSERIAL PRIMARY KEY,

  customer_id     TEXT NOT NULL,

  delta           BIGINT NOT NULL,

  reason          TEXT NOT NULL,

  idempotency_key TEXT NOT NULL,

  created_at      TIMESTAMPTZ NOT NULL DEFAULT now(),

  UNIQUE (customer_id, idempotency_key)

);

Three properties matter here.

Atomicity. A credit transaction is fully recorded or not recorded at all. Partial writes are how credits get lost and how they get spent twice.

Optimistic locking. Multiple processes can read and update a balance concurrently. The version column lets a write fail rather than silently overwrite a concurrent update.

UPDATE wallet

   SET balance = balance - $1,

       version = version + 1

 WHERE customer_id = $2

   AND version = $3

   AND balance >= $1;

Zero rows affected means either someone else moved first or the balance is insufficient. Both cases need a retry or a rejection, never an assumption.

Idempotency keys. A unique identifier on every transaction, enforced by the unique constraint above. The same request arriving three times produces one ledger row and one debit.

The append-only rule is what makes auditing possible. Nothing is erased, so the balance is always reconstructible from the ledger, and any disagreement between wallet and ledger is a detectable bug rather than a mystery.

Step 3: meter usage in real time

Every API call and every GPU second is a billable event. The metering layer records them, and rating logic translates them into credits consumed.

Latency at this layer sets a hard ceiling on how honest your customer-facing balance can be. Batch ingestion means the number in the dashboard describes the past. Flexprice runs this path on Kafka and ClickHouse for real-time metering at high event volume, and the event ingestion overview covers how events are attributed and rated. When events get rejected, the event debugger is what turns a silent gap in the ledger into a visible one.

Step 4: enforce before you compute

Check the balance before starting inference, the same way you check funds before a purchase clears. Checking afterwards means you have already paid for compute you cannot bill.

For long-running work, hold credits rather than debiting at the end. A batch image job should reserve its estimated cost up front and settle the difference on completion, so a second concurrent job cannot spend the same balance.

Auto top-ups and low balance alerts belong at this layer too. Running out mid-computation is a worse experience than a threshold warning an hour earlier. Flexprice exposes both as auto top-up and low balance alerts.

Step 5: make it visible

Expose wallet and ledger data through API endpoints so customers can see their own consumption, remaining balance, and expiry rules without filing a ticket. Run a daily reconciliation job comparing metered events against ledger entries to catch revenue leakage while it is still small.

Transparency here is not a courtesy feature. A customer who can see the burn rate does not dispute the invoice, and support stops fielding questions that a wallet transactions endpoint answers directly.

Step 6: expiry, rollover, and refunds

Credits need a lifespan, and the policy needs to be explicit before the first grant, because changing it retroactively is a support incident.

Expiry. Define when unused credits lapse. Silence here reads as never, and customers will hold you to it.

Rollover. Enterprise agreements often carry unused credits into the next period. That removes the end-of-month panic buying and the end-of-month waste.

Refunds. Cancellations need a defined workflow, not an engineer running a manual debit.

Promotional credits. Trial and goodwill grants usually want different rules: shorter expiry, no rollover, spent before paid credits. That means grants need their own priority ordering, not one pooled balance.

Once grants can differ in expiry and priority, a single balance integer stops being sufficient and you need per-grant balances with a deduction order. Flexprice separates these as balance types and prepaid and promotional credits.

Practices worth adopting early

Append-only ledgers. Every usage, credit, debit, and expiry is an insert. Auditing becomes a query instead of an investigation.

Real-time balances with event-driven cache invalidation. Refresh cached balances off the event stream so a debit is reflected immediately rather than at the next poll.

Deduplicate with idempotency keys. A retry after a network error or a worker restart counts once.

Externalize pricing config. Rate changes and new plans should not require a redeploy of your product.

Where a billing layer saves the work

Credit systems are unpleasant to build in-house because the hard parts are not the happy path. Real-time balance checks, atomic debits, wallet consistency under concurrency, expiration, top-ups, previews, entitlements, and behavior under load are all failure-mode engineering, and none of it is your product.

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. Because Flexprice is open source and self-hostable, usage and revenue data can stay entirely inside your own infrastructure and never reach a vendor's cloud. This is what makes Flexprice usable by companies with data residency, sovereignty, and audit requirements that hosted-only billing vendors cannot meet.

Each wallet supports prepaid credits, pay-as-you-go debits, bundled allowances, expirations, and package renewals. Credits are deducted atomically, so balances stay accurate under concurrent load. Consumption can be simulated with usage previews before a pricing change goes live, which is the difference between testing a plan rule and discovering it on a customer's invoice. The credit system feeds invoicing, entitlements, and reporting from the same ledger, so what the customer sees and what finance sees are the same numbers.

The design principle underneath all of it is unglamorous. Treat the ledger as the source of truth, make every write idempotent, and check the balance before you spend the compute.

Read the wallet documentation to see how the pieces fit together.

Why Flexprice Picked Go From Day One And Never Looked Back

Flexprice — Thu, 14 Aug 2025 13:38:41 +0000

When you're building the backbone of usage-based billing, pricing, and metering, the language you select isn't just syntax. It’s the speed, and trust baked into your product.

At Flexprice, we didn’t stumble into Go.
We chose it deliberately before a single line of code was written.

Here’s why we picked Go over the more familiar paths, how it powers our architecture today, and why we’re glad we never defaulted to Python.

We needed something production-grade from the first commit.

1. The Problem We Were Solving

From day one, we knew what we were building wasn’t a toy:

APIs that would meter high-frequency usage events in real time
Pricing engines that needed to be deterministic, fast, and scalable
Billing infra that integrates deeply with CRMs, Stripe, analytics, and internal ops
A system that could handle thousands of events per second, without choking

We didn’t want to “move fast and break things.”
We wanted to “ship fast, scale clean, and sleep well.”

2. What Were the Available Options?

We considered the usual suspects:

Python: Familiar, flexible, and widely used — but not built for concurrency at scale
Node.js: Lightweight and async-friendly, but not ideal for CPU-bound operations
Java/Kotlin: Powerful, but verbose and heavy for a fast-moving startup
Go: A compiled, modern systems language designed for cloud-scale infrastructure

Despite being less familiar to some of us, Go stood out for its simplicity and power.

We ran tests. We built a few core modules. We profiled latency, deployment, and developer experience.

The results were clear.

3. Why We Chose Go

💡
Go was everything we needed — and nothing we didn’t.

✅ Compiled performance: Near-C-level speed
✅ First-class concurrency: Goroutines and channels made parallelism feel natural
✅ Dead-simple deployment: Static binaries, no runtime issues
✅ Readable and enforced syntax: The same formatting across every file, every repo
✅ Robust tooling: Built-in race detectors, benchmarks, linters
✅ Minimal memory footprint: Runs smoothly on small container instances

Go didn’t just check boxes. It rewired how we think about backend design.

4. What It Powers Today

Here’s what we’re handling today on production:

1M+ usage events/day per customer (batch and real-time ingestion)
Pricing workflows that respond in under 50ms, even on minimal compute
High-volume API traffic integrated with Stripe, customer portals, and sales workflows
Rapid iteration across entitlements, billing logic, and packaging — with confidence

Even on 0.2 vCPU instances, Go performs like a beast.

5. How We Structured Our Go Backend

Flexprice is open source and built in Go with a modular, scalable architecture designed for high performance and easy extensibility.

You can explore the codebase here.

We’ve kept the structure intentionally clean so developers can read, adapt, and contribute with minimal friction.

Building something similar? Fork it. Want to improve it? Open a PR.

We’re building in public, and we’d love your input.

But what we got in return?

Peace of mind with every deploy
Confidence that scale won’t require rewrites
Codebases that any dev can read and extend in minutes * * *

6. The Tech Deep Dive — For Developers Who Care About the Guts

We’ve talked about why we chose Go.
Now here’s a peek into how it actually runs under the hood.

Architecture Highlights

Event Ingestion Layer
- Uses goroutines for parallel processing of incoming usage events.
- Kafka + Go consumers with backpressure handling to keep ingestion smooth at millions of events/day.
Pricing Engine
- Deterministic pricing logic, no floating-point surprises — all billing calculations are done with Go’s math/big for precise decimal handling.
- Config-driven rules so business teams can tweak pricing without touching code.
API Layer
- Built with net/http + middleware stack for logging, auth, and rate limiting.
- gRPC endpoints for high-throughput internal communication between services.
Storage & Persistence
- Postgres as the source of truth for billing and pricing configs.
- Redis for caching entitlements, pricing tiers, and in-flight usage aggregates.
Deployment
- Each service is a single static binary — no dependency hell, no runtime surprises.
- CI/CD with GitHub Actions → container builds → K8s deploys.
- Health checks + metrics exposed via Prometheus.

Performance Practices We Swear By

Pre-allocating slices and avoiding unnecessary memory allocations
Using worker pools for predictable goroutine lifetimes
Benchmarking every pricing rule with Go’s built-in testing.B suite
Leveraging Go’s pprof for real-time profiling in staging and production

TL;DR — We treat performance as a feature, not an afterthought.

Final Thoughts

We didn't just pick Go for the hype. We picked it for the long game.
Flexprice isn’t just a billing product — it’s the backbone of revenue for companies shipping AI, infra, and complex usage-based products.

And Go gives us the confidence to say:

Bring on the scale. We’re ready.

OpenAI Just Open Sourced Two New AI Models And Here's Why It Matters For AI And Agentic Companies

Flexprice — Wed, 13 Aug 2025 13:30:37 +0000

When OpenAI finally made parts of its GPT-4-class technology available as open-source models, it wasn’t just another AI release, it was a shift that the developer community had been anticipating for years.

For companies that build AI-first products, this move opens doors that were previously locked. Instead of relying solely on API calls to a black-box service, you can now run high-performing language models in your own environment, with full control over costs, compliance, and customization.

This post walks through what the new OpenAI open-source models are, why the release has spiked interest worldwide, how they perform against industry benchmarks, and how AI-first companies can deploy them efficiently.

Whether you’re exploring them for experimentation or production workloads, the goal here is to give you a practical guide to make an informed decision.

What are the OpenAI Open-Source Models?

As of August 2025, OpenAI has released two models under its open-weight program:

gpt-oss-20B: 20 billion parameters
gpt-oss-120B: 120 billion parameters

These are part of OpenAI’s open-weight initiative, meaning the trained weights are publicly available, so anyone can download, host, and run them locally. This is different from API-only access, where you rely on OpenAI’s servers and pricing. With open weights, you control deployment, cost, and compliance.

It’s also a notable shift in policy. OpenAI hasn’t released anything this large since GPT-2 in 2019 (1.5B parameters), which was a fraction of today’s scale.

Check the model card by OpenAI.

Technical highlights:

Architecture: Transformer-based, GPT-4 lineage, optimized for local and cloud hosting
Context length: Up to 128k tokens, supporting long-form reasoning and multi-document workflows
Quantization: Pre-quantized 4-bit and 8-bit versions to reduce GPU memory requirements
License: Apache-2.0, allowing commercial and non-commercial use (with OpenAI’s usage policy caveats)

Community pulse: what developers are saying

1. gpt-oss-20B

Runs well on consumer hardware (16 GB+ VRAM) “40 tokens/s on my RTX card, totally usable.”

Great for local-first workflows, but logic reasoning is weak without fine-tuning (failed classic puzzle tests, low accuracy on 11+ exam).

Non-English performance is hit-or-miss; some report slower outputs in early builds.

Benchmarks can vary. Some bloggers compare it to o3-mini, others say results depend heavily on prompt engineering.

2. gpt-oss-120B

Strong instruction following and coding capabilities: “best I’ve run locally for writing clean code.”

Can hit 30–35 tokens/s on a single 80 GB GPU; some even run CPU-only demos on high-RAM machines.

Mixed benchmark reception, certain threads show modest Simple-Bench scores (~22%), while others argue its MoE (Mixture-of-Experts) design makes it efficient for the scale.

Analysts frame it as near-parity to o4-mini on core reasoning while being deployable on a single high-end GPU

20B	Ideal Use Case	Watch-Outs
20B	Teams wanting a fast, locally-hostable model for experimentation, chatbots, summarization, or lightweight reasoning tasks.	Reasoning accuracy is noticeably lower than leading frontier models (e.g., GPT-4, Claude 3 Opus); multilingual outputs can be inconsistent without fine-tuning.
120B	Teams with 80 GB+ GPUs looking for strong instruction following, solid coding assistance, and faster inference speeds than dense models of similar size.	High hardware requirements; benchmark scores vary widely, so test on your own workloads before committing to production.

Key Features & Benchmark Highlights

Benchmark Comparisons: How gpt-oss Stacks Up

gpt-oss-120B

Reasoning & Coding: Matches or beats o4-mini; competitive with larger dense models.

HealthBench: Close to o3; outperforms GPT-4o in multiple categories.
SWE-bench Verified: 62.4% (GLM-4.5 scores 64.2%).
MMLU-Pro & AIME: Strong performance, ahead of many full-parameter models in this size class.

Strengths: Balanced across reasoning, coding, and domain-specific tasks; efficient for size due to MoE.

Limitations: Requires 80 GB+ GPU for optimal speed; benchmark gains may not translate 1:1 to all workloads.

gpt-oss-20B

Overall Performance: Comparable to o3-mini in many standard benchmarks.
Specialty Tasks: Excels in competition math and health-related reasoning.
Logic Testing: Low accuracy on UK 11+ exam (9/80 correct) without tuning.
Knowledge QA: Weak SimpleQA score, improves significantly with better prompts.

Strengths: Runs well on consumer-grade GPUs (16 GB VRAM+); ideal for local-first projects.

Limitations: Lower raw reasoning power vs. top-tier models; multilingual output inconsistent.

Key Architectural Features

Mixture-of-Experts (MoE) design: Only a subset of the total parameters is active at any given time, reducing compute cost while retaining capability.
128k token context window: Allows for very long conversations, large document processing, or multi-step reasoning chains.
Quantization options: Pre-quantized 4-bit and 8-bit weights for lower VRAM usage without a big performance hit.
Optimized attention mechanisms: Techniques like grouped query attention improve speed and efficiency for large context handling.

Analogy for Benchmarks

Think of the benchmarks like testing a car:

AIME/HealthBench scores = Top speed (peak reasoning ability)
Context window = Fuel tank size (how long it can handle complex input without running out of context)
MoE efficiency = Fuel efficiency (how much compute is needed for each “trip” of reasoning)

Reality Check

Benchmarks are controlled conditions, real-world workloads can vary.

20B may fall short on multi-step reasoning or nuanced logic without tuning
120B offers higher accuracy and more robust performance, but demands high-end GPUs (80 GB+ for optimal speed)

Business value for AI and Agentic companies

OpenAI’s gpt-oss-20B and gpt-oss-120B aren’t just research curiosities; they create practical, measurable advantages for companies building AI-first products. The biggest shift is in control: cost, compliance, and customization now sit in your hands rather than behind an API paywall.

1. Cost efficiency

API vs. Self-Hosting: Running inference locally or in your own cloud can cut per-million-token costs by 30–70% depending on GPU availability and utilization
Example: A high-traffic chatbot processing 500M tokens/month could save thousands of dollars in API fees if inference moves in-house
20B advantage: Lower hardware footprint means faster ROI for smaller teams
120B advantage: Higher accuracy per token processed means fewer retries and corrections

2. Compliance & data control

Self-hosting means sensitive data never leaves your infrastructure
Meets stricter requirements for sectors like finance, healthcare, and government without complex vendor contracts
Open-weight Apache-2.0 licensing (with OpenAI usage policy) simplifies legal review vs. closed, API-bound services

3. Customization and fine-tuning

Both models can be fine-tuned for domain-specific language, terminology, or compliance filters
Custom embeddings and retrieval-augmented generation (RAG) pipelines can be integrated without third-party API constraint.

Bottom line: For AI and agentic companies, these models lower the unit economics of running advanced LLM features, improve compliance posture, and unlock pricing flexibility, without sacrificing core capability.

Deployment and compliance checklist

If you’re planning to deploy gpt-oss-20B or gpt-oss-120B in production, treating them like any other enterprise-grade software stack will save you time.

1. License & Policy Review

Apache-2.0 license: Permissive for both commercial and non-commercial use
OpenAI usage policy: Certain applications (e.g., generating misinformation) remain prohibited even with open weights
Action: Get legal confirmation that your intended use aligns with both

2. Hardware Requirements

gpt-oss-20B: Runs on GPUs with ≥16 GB VRAM; suitable for a single workstation or small cloud instance
gpt-oss-120B: Requires an 80 GB GPU or multi-GPU setup for real-time performance
Action: Decide between local deployment, cloud GPUs, or hybrid infrastructure

3. Data Residency & Privacy

Ensure all processing happens in approved geographic regions for compliance (e.g., GDPR, HIPAA)
For sensitive data, deploy in a private VPC or on-prem hardware

4. Observability & Monitoring

Log prompt/response pairs for auditing
Track token usage, latency, and failure rates
Set alerts for unusual activity (e.g., rapid token spikes from one client)

5. Security Hardening

Isolate model servers from public networks
Use API gateways or auth layers for access control
Regularly patch hosting environment and supporting libraries

Wrapping up

OpenAI’s gpt-oss release signals a broader shift, one where high-performance models aren’t locked behind API gates but can be run, adapted, and monetized on your own terms. The move also sets a precedent: after years of partial openness, OpenAI has now shown it’s willing to bring frontier-adjacent capability into the public domain.

Looking ahead, expect three trends:

Multimodal open weights, future releases may integrate text, image, and audio processing in a single package.
Specialized domain variants, healthcare, finance, and legal-tuned versions optimized for compliance-heavy industries.
Ecosystem tools, better fine-tuning kits, quantization methods, and observability frameworks to accelerate real-world adoption.

For AI-first companies, this is a moment to test and embed these models into workflows before the next release cycle reshapes the playing field.

The first movers here will gain not just cost and control advantages, but also the credibility that comes from delivering cutting-edge AI without reliance on opaque third-party infrastructure.

The Complete Guide to ElevenLabs Plans Overages and Usage Based Pricing

Flexprice — Fri, 08 Aug 2025 12:29:38 +0000

ElevenLabs is a leading AI audio platform known for its lifelike voice generation, real-time cloning, and multilingual dubbing. Whether you're a solo creator or an enterprise team, it offers the infrastructure to generate and scale voice-based content.

In this guide, we will break down the full pricing model: plan comparisons, overage logic, voice model differences, and how to choose the right tier (or replicate this pricing system for your own SaaS).

What is ElevenLabs?

ElevenLabs is an AI audio platform offering hyper-realistic text-to-speech (TTS), voice cloning, dubbing, and transcription.

It is used by creators, developers, and enterprises looking to generate or manipulate voice content at scale.

Key capabilities include:

High-fidelity TTS across 29+ languages
Instant and professional-grade voice cloning
Multilingual dubbing and conversational AI
Developer-friendly APIs and usage-based pricing
Audio enhancement tools like Voice Isolator and Voice Changer

Who is ElevenLabs Built For?

ElevenLabs supports a wide range of users across creative and technical workflows:

Creators: Narrators, YouTubers, podcasters, and indie game devs
Developers: API-first teams building apps with voice integration
Agencies: Managing dubbing, client content, and production at scale
Enterprises: Building multilingual content and support flows
Platforms: Embedding voice features into SaaS or marketplaces

Each of these groups benefits from ElevenLabs’ flexible plans and real-time performance.

ElevenLabs Pricing Plans (Monthly Overview)

Plan	Price	Characters (TTS)	Overages	Voice Cloning	Audio Quality	Seats	Concurrency
Free	$0	10k (Multilingual) / 20k (Flash)	N/A	❌	128 kbps	1	2
Starter	$5	30k / 60k	N/A	Instant Clone	128 kbps	1	3
Creator	$11 (50% off month 1)	100k / 200k	$0.30 / 1k chars	1 Pro Clone	192 kbps	1	5
Pro	$99	500k / 1M	$0.24 / 1k chars	1 Pro Clone	192 kbps	1	10
Scale	$330	2M / 4M	$0.18 / 1k chars	1 Pro Clone	192 kbps	3	15
Business	$1,320	11M / 22M	$0.12 / 1k chars	3 PVCs	192 kbps, SLAs	15+	15
Enterprise	Custom	Custom	Negotiated	Custom	Custom	Custom	Custom

Is ElevenLabs free?

Feature	Free Plan
Characters	10k (Multilingual) or 20k (Flash)
Voice Cloning	Not available
Commercial Use	Forbidden (attribution required)
Audio Quality	128 kbps
STT Access	2.5 hours (API), 12 mins (UI)
Projects	3
Custom Voices	3
Concurrency	2 requests max

How ElevenLabs Prices Across Models and Features

ElevenLabs doesn’t just charge by output—it charges by model type and feature usage. Each product category—like Text-to-Speech or Dubbing—has its own pricing logic based on characters, minutes, or hours. And within each, there are two pricing levers:

→ Included quota (per plan)
→ Overage cost (per unit after quota)

Here’s how pricing breaks down by model and feature:

1. Text-to-Speech (TTS)

Models: Multilingual v2 and Flash
Billing unit: Characters and minutes

Speech-to-Text (STT) Interfaces:

API- used for large-scale, automated transcriptions
UI- manual uploads with waveform preview and editing Metered by: Hours Available on: All plans

Other details:

Quotas tracked separately for API and UI
UI access comes with significantly lower included volume
Optimized for dev vs creator workflows respectively

3. Conversational AI

Use case: Interactive text+voice agents
Metered by: Minutes
Additional meter: Text messages sent
Other details:

Includes concurrency limits (up to 30)
Designed for real-time voice agent applications
Available across all plans, scaling with usage

4. Voice Changer & Voice Isolator

Metered by: Minutes
Available on: All plans
Other details:

Both tools accessible via Studio & API
Intended for enhancing, isolating, or transforming audio post-generation
Concurrency limits increase with plan

5. Sound Effects

Metered by: Number of generations
Available on: All plans
Other details:

Sound FX feature is generation-based (not duration-based)
Useful for creative workflows and post-processing
Scales with concurrency and generation limits

6. Voice Cloning

Types of cloning:

Instant Clones – lightweight, accessible to all paid plans
Professional Voice Clones (PVCs) – gated to Creator+ plans Other details:
Access includes voice design slots and custom voice limits
Plan tiers increase allowed PVCs and total voice slots
Custom voices can be stored, designed, and reused across projects

7. Dubbing

Automatic Dubbing – real-time multilingual audio generation
Dubbing Studio – advanced interface for post-editing and alignment Metered by: Minutes Other details:
Audio quality scales by plan
Both models available from Starter upwards
Ideal for creative, education, and international content workflows

8. Studio Projects

Metered by: Number of projects
Other details:

Quotas range from basic project folders to enterprise-scale workflows
Enables large-scale voice asset management and production workflows
Feature-rich access in Creator+ plans and above

Read the detailed breakdown of ElevenLabs pricing and also how you can replicate it within minutes with Flexprice.