Ryan Echternacht
Metronome meters usage after it happens. Deciding whether a run can start is infrastructure you have to build, and that is a second real-time meter. Schematic replaces both, Metronome and the real-time meter you'd build next to it, and leaves invoicing and payments on Stripe.
- Metronome's own docs say entitlement state belongs in your system, and its balance alerts arrive minutes after the usage, which is after the run you wanted to stop.
- What you build to cover that, the webhook receiver, the balance store, the reconciliation job, the holds for agents, and the limit branches, duplicates the hard half of metering in real time and grows with every pricing change.
- Schematic ships that half as one system with the meter, on Stripe, so pricing changes are configuration instead of projects.
Why teams buy Metronome
Teams arrive at Metronome from one of two places. Some are moving to usage pricing and want the billing side right the first time. The rest already did it once, in-house or on a tool that wasn't built for it, and they're still paying for that. Usually that means a usage table nobody quite trusts, a month-end job that double-counts retries, and the invoice disputes that come out of both.
Metronome is built for both. It takes events at scale, deduplicates them, tolerates late and backdated usage, and turns the result into an invoice that holds up. It handles the contracts those customers sign too, with commits, per-customer rates, rollover, and price changes scheduled for next quarter. Since January it has been part of Stripe, sold as an add-on to Stripe Billing. If your worry is metering a lot of usage correctly and billing it against enterprise contracts, that's what Metronome is for.
Until recently, that was the whole job, because a customer going over their limit didn't cost you anything and you could settle it on the invoice. Features with a model behind them changed that. Every run costs real money, and agents kick them off with nobody watching, so counting usage after the fact is now only half the job. The other half happens before the run, when you have to decide whether this customer can start it with what they have left.
Metronome stops at the meter, and its docs say so. The prepaid credits guide recommends that "a customer's entitlement state is managed within your system and database." Balance alerts are evaluated and delivered on a cadence of minutes. Zero-overage pricing guarantees a customer is never billed past their commit, but "does not stop usage from being submitted." What happens after that point is left to you.
Everything past the meter is yours to build
The first thing you build is a webhook receiver, because every check your product makes reads local state you have to track, and that state is assembled from Metronome's webhooks and API reads. The receiver has to handle signature verification, retries, duplicates, and events arriving out of order. You keep a store of each customer's balance and access. You run a job that reconciles that store against Metronome, and you decide what the product does when the store is stale or the job falls behind.
Then comes the enforcement check itself, the one that sits in front of every billable action. The first version is a lookup against that store, and it holds up as long as an action has a fixed price and one caller at a time. Agents break both of those assumptions. You don't know what a run costs until it finishes, so you hold an estimate and settle the real number after. Two agents for the same customer start at once, both see 100 credits remaining, and spend 150 between them, so the holds have to be safe under concurrency. Workers die mid-run, so holds have to expire. And when the store itself is down, something has to decide whether the check allows or denies.
Credits aren't the only thing you check. Most products end up with features that are on or off by plan, usage limits that reset daily or monthly, seat counts that should block the next invite, and credits on top. Each one has its own state and its own check. Metronome will bill whatever seat count you report, but stopping the eleventh seat on a ten-seat contract is your code.
Balances also change for reasons that have nothing to do with usage. Customers buy more credits, auto top-ups fire, grants arrive, unused credits roll over or expire, and support issues refunds. Metronome's ledger records all of it. Your copy has to apply each change before the next check runs, or a customer who just paid gets told they're out of credits.
Eventually an enterprise customer asks for caps per user inside their account. Metronome can allocate credits per seat, but overages are billed at the contract level, so nothing stops one user from running past their allocation on the team's bill. So now you're building per-user counters and per-user resets, plus a check that honors both the user's cap and the company's balance.
And then the pricing changes, which it will. A new credit rate for a more expensive model, or a usage limit that becomes a credit burn. Each one means a new code path, a migration of whatever local state you kept, and tests for both. It's a project every time, and it comes around more often than anyone plans for.
Look at that list again, because it should be familiar. Deduplicate events, put them in order, keep a running balance per customer, and apply purchases and refunds in sequence. That's the list you paid Metronome for, and you've now built it a second time, in real time, under concurrent agents. Now two counts of the same usage exist, and every price change, refund, and top-up has to land in both. Pagos put building their own billing at three to four months, and that's the part you can estimate. Nobody estimates the years of keeping two meters in agreement.
Some teams should build it
Not every team needs this. If you bill seats and usage in arrears and never need to stop anyone, Metronome's alerts and invoices cover it. Same if you're deliberately generous while you learn what customers value, metering everything and enforcing nothing. One hard cap on one balance can live in a webhook-driven flag and a nightly reconciliation, and plenty of teams never build more than that. And at the scale where Metronome's ingestion is the reason you chose it, you probably have the engineering to own the rest.
What ends the waiting is usually commercial. Once a run has model cost behind it, every overage you didn't enforce is margin you gave away. Expansion happens against a limit, so a land-and-expand motion without enforcement is a land motion. And custom deals close faster when the exception sales just promised is a setting instead of a ticket. When any of those matter more than the engineering time, the build stops being optional.
The build grows with every pricing change
At one pool of credits and a seat count, the second meter is small, and you can make the case for owning it. It doesn't stay small, because the commercial side keeps moving.
Finding the right value metric takes iteration, and sales-led companies iterate one deal at a time. One customer wants a commit with overage, the next wants a flat credit pool, and a month later someone asks for seats with credits attached. Metronome can bill all three, but whether your product enforces all three depends on whether someone wrote the code for that shape.
Plan changes are where billing and access drift apart. A contract edit in Metronome changes the invoice, but access has to change at the same moment, whether that's an upgrade mid-period, a downgrade at renewal, a cohort moved to new pricing, or existing customers kept on their current terms while new ones get the new plan. A customer who goes past due needs a decision too, and it's a different decision for a free account and your largest one.
What happens at the limit is a policy per customer, and the policies multiply. The free tier gets a hard stop, mid-market gets a soft limit with overage, self-serve gets auto top-up, and the biggest account gets a negative balance and a phone call. Customers also need to see the balance in the product before they hit it, because finding out on the invoice is how disputes start. Each of those policies is another branch in your check.
Every one of those is a commercial decision that lands as engineering work. The more of them you have, the more of your engineers' time goes into the second meter instead of the product, and the longer each decision waits behind the roadmap.
Schematic ships what you'd otherwise build
Schematic is one system for the meter and the half past it. Usage events go to Schematic, the credit ledger lives in Schematic, and the check in front of every action reads from state that Schematic streams into your app. Billing stays on Stripe, where your subscriptions already are, and Schematic keeps Stripe in sync.
The sales-led contracts still have a home. A custom plan is a negotiated deal for one company, with its own entitlements, credit grants, and price, invoiced through Stripe. Credit grants carry rollover and expiry, a price change is a new plan version where you choose who moves to it, and amending a live custom plan mid-term is supported. A contract's credits can go on their own invoice line, priced per credit or in tiers. Stripe rates the usage and sends the invoice, the same as it does for your seats today. What you give up is event volume at the scale of OpenAI's API. If you need that level of volume, Metronome is likely the right choice.
Here's the build list again, with what replaces each item.
What you'd build if you pick Metronome | What Schematic ships |
|---|---|
A webhook receiver, a local balance store, and a reconciliation job | Entitlement state streamed into your app over a persistent connection, so checks evaluate locally. A self-hosted replica if you want it inside your network. |
A check per entitlement type, with your own state behind each | |
Holds that are safe under concurrent agents, expire when workers die, and settle to actual cost | Size the check for the run and reserve the credits in the server SDK, then settle on the track. Two agents can't claim the same credits, a run can't start without them, and a run that reserves its upper bound settles at or under it. |
Applying purchases, top-ups, refunds, rollovers, and expirations to your copy of the balance | A credit balance Schematic keeps, with grants, bundles, top-ups, refunds, rollover, and expiry on it, so the next check sees the new balance |
Per-user counters and resets inside an account | Usage controls that cap a company or one user per hour, day, or request |
A code branch for every way a customer can go over | Soft and hard limits, overage reported to Stripe for the invoice, auto top-up and overdraft, set per plan or per customer |
Alerts and in-product balance display | Webhooks at warning and limit, and components that show the balance as usage happens |
A new code path, state migration, and tests for each pricing change | Plan versions that migrate everyone, some, or nobody, custom plans for one customer, and overrides for one account |
Plotly went through this decision when they launched Plotly Cloud. The buying committee started out leaning toward Orb and Metronome. What settled it was their VP of Engineering pointing out that without Schematic, "enforcing feature entitlements, limits, and access logic is on us to own." They went live on Stripe plus Schematic in two weeks, shipped a quarter earlier than planned, and their product team now moves pricing changes to production in minutes without a deploy. Syrto evaluated Metronome, Orb, and Chargebee and landed in the same place, because what they were shopping for was an entitlement platform, not a billing platform.
Switching one customer from a hard stop to overage is a change to their plan rather than a deploy. Publishing a new plan version asks you whether to migrate everyone, migrate some, or leave existing customers on their current version, and raising a limit for one account ahead of renewal is an override with an expiry. None of it needs a deploy.
Questions for engineering
Before you decide, ask what you want your developers building.
- Who owns the webhook receiver, the local balance store, and the job that reconciles it against Metronome, and who's on call when they drift?
- What does the product do when the store is stale, the reconciliation job is behind, or the store is down?
- How do two agents drawing on one balance avoid claiming the same credits, and what happens to a hold when a worker dies?
- Where does the seat count get enforced, and the per-user cap inside an account?
- How many code paths exist for the ways a customer can go over, and who adds the next one?
- What does the next pricing change cost in engineering weeks, and how many of those are planned this year?
Questions for go-to-market
Then ask whether it's acceptable for each of these to wait on an engineering ticket.
- Closing a deal whose shape isn't one of the models already coded.
- Raising a limit, extending a trial, or turning on a feature for one account ahead of renewal.
- Changing what happens at the limit for one customer, from hard stop to overage or auto top-up.
- Moving a cohort to new pricing while existing customers keep their current terms.
- Giving an enterprise admin control over caps per team or per user.
- Showing customers their balance in the product instead of on the invoice.
- Testing a new value metric with a handful of customers next month.
If the answer to the second list is no, don't spend your engineers' year on the second meter.