Usage metering
Know what each customer earns you — after the bill to serve them.
If you charge by usage, your revenue and your biggest cost both move with consumption. Economico meters both sides on the same ledger — customer usage becomes revenue, the vendor usage that served it becomes cost — so your true margin per customer and per unit falls out of the books instead of a quarterly spreadsheet.
You sell by the unit, you pay by the unit, and the two never meet
If your product is metered — API calls, inference tokens, enrichment requests, compute — then the number that decides whether you have a business isn't revenue and isn't cost. It's the gap between them, per unit and per customer. And it's the number almost nobody has cleanly. Your metering vendor tracks what customers consumed on the revenue side. The AI and infra bills that consumption ran up land somewhere else entirely — a stack of invoices you reconcile by hand. So "what is this customer actually worth to us, after what it costs to serve them?" becomes a quarterly guess, right when you're trying to set prices and decide who to keep.
Meter both sides on one ledger
Record usage against the customer and it becomes revenue. Record the vendor usage that served it — the tokens you resold, the calls you passed through — and it becomes cost of goods, on the same books, in the same period. Because the two are linked, the ledger already knows which customer's revenue a given slice of vendor cost supported. That's the whole trick: revenue and its true cost of service live together instead of in two silos that only get reconciled after the quarter closes.
Nova ran 1.2M API calls this month — record it against their usage plan. We paid the model provider for the tokens those calls used; record that as the cost of serving Nova. What's my gross margin on this account?
Prepaid credit pools draw themselves down
Sell a customer a block of usage up front — a hundred thousand calls, a pack of credits — and it lands as a balance they draw against as they consume, with the remaining amount always current. The same works when you prepay a vendor for capacity you'll use. No manual decrementing, no month-end true-up: the pool is just the granted amount minus what's been metered, and it's right every time you look. When a pool runs low, it shows up in your inbox before your customer hits the wall.
Your true unit economics fall out of the books
Because usage is booked as it happens — revenue recognized as the customer consumes, cost recognized as you incur it — margin isn't something you reconstruct at quarter-end. It's already on the ledger, per unit and per customer, the moment the usage lands. Ask what a thousand calls actually earn you after the model bill, or which customers are underwater at your current price, and you get an answer grounded in the real numbers — the input a pricing change or a renewal decision actually needs.
Across all customers this quarter, what's my revenue, my usage cost to serve it, and my gross margin per unit? Which accounts are below 40%?
"My metering tool already does this"
It meters one side. Metronome, Orb, and the rest are built to turn usage into invoices — the revenue side — and they're good at it. What they don't do is book the cost that usage ran up, so they can't tell you your margin; for that you're back in a spreadsheet, matching model bills to customer revenue by hand. Economico meters both sides into the same double-entry ledger, so the revenue, the cost of service, and the margin between them are one connected picture — kept current by the agent you already use, with no dashboard to log into and no vendor standing in your books.
Get started
See your real margin, per customer, in real time.
Connect the agent you already use and it meters both sides of your usage — revenue and the cost to serve it — so your unit economics are a number you read, not a spreadsheet you rebuild.