2 posts tagged with "usage-based-pricing"

The Regis Company builds immersive, case-based training simulations for enterprise learning programs, including AI avatars that learners talk to in real time. Ahead of a fixed-price rollout to a Fortune 500 customer covering more than 100,000 users, Regis risked carrying the cost of any AI usage the contract didn't price in. They chose Limitr to meter and enforce that AI usage inside their existing backend, and to open a path to usage-based billing on the contract.

• Industry: enterprise learning and training simulations
• Use case: metering and enforcing real-time AI avatar, chat, and text-to-speech usage across learners, authors, and facilitators
• Scale: a Fortune 500 contract covering more than 100,000 users
• Why Limitr: faster to production than building in-house, without changing how Regis's product works for its users

Every LLM call in your AI product — a chat message, a doc summary, an MCP tool call — has a non-deterministic cost attached to it. Let a customer upload 1,000 documents instead of 3, and you're getting an invoice from Big LLM you didn't budget for.

The short version of how you get that under control: measure margin per account, per feature, and per vendor — not just cost. Set enforcement limits that guarantee your worst case. Then price so revenue moves with usage instead of trailing behind it.

Cost-to-deliver is the metric most teams reach for first, and it's a good start. But it's incomplete, because it's missing revenue. Controlling cost alone only ever caps your downside. The number that actually gives you control is margin-to-deliver.

Margin-to-deliver is the share of what you charge for a unit of delivered value that you keep after the vendor cost of producing it — (charged − overhead) / charged — measured per account, per feature, or per vendor.

Optimize margin-to-deliver and you've got two levers to pull: enforcement and pricing. Here's how we think about both, and the order we'd tackle them in.