7 posts tagged with "ai"

For a usage-based product, billing isn't the last step anymore. Who can use what, how much, at what cost, and under which deal: those decisions are the product. They decide whether a heavy customer is profitable, whether a new model can launch, whether the contract sales just signed is honored on Monday.

Somewhere along the way, our industry decided those decisions should live in someone else's system, and that the system should take a cut of everything you bill. We think that's backwards, and we built Limitr to fix it.

This post is two things. First, what we think went wrong and what we believe instead. Second, an honest guide to the platforms you're probably comparing, written to help you choose well even if you don't choose us. If you're here for the comparison, skip to the guide.

The new Limitr Cloud is live at cloud.limitr.dev. It's a rebuilt app and a rebuilt server, running the 0.7 engine, with Limitr Analyst, the agent in Limitr Cloud, working beside you on every page. It also comes with new plans, including Pay as you go.

When we shipped Limitr 0.7, the engine could price every call at its real cost, predict a call's size before it runs, roll features out, and carry custom deals per customer. Cloud is where your team sees all of that and changes it: one policy, every customer, and what each of them costs you and earns you.

Limitr 0.7 is out (0.7.5 as of Oct 27). It's the biggest release of the open-source engine so far, and most of it came straight from conversations with teams putting AI features in front of paying customers.

Three questions kept coming up:

• What did this call actually cost us? Not an average, this call, on this model, at today's provider prices.
• How much room should a call get before we know its size? An LLM call's usage is only known after it finishes.
• Who gets this feature right now? Plans decide most of it, but launches, betas, and custom deals don't fit neatly into plans.

0.7 answers all three inside the same policy, running in your process, with no network call on the hot path.

npm i @formata/limitr

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.

If you're building an AI product in 2026, you're likely managing a cost structure that your pricing model was never designed for.

Traditional SaaS pricing — flat tiers, per-seat subscriptions — was built for near-zero marginal cost software. It made sense when the cost to serve a new user was effectively nothing. AI and agentic products don't work that way. Every model inference costs money. Every API call has a price. Your most active customers might cost you 10x what your least active ones do.

We hear a version of the same story over and over in customer calls.

A founder has a usage-based product in the market. They have some customers. Their pricing "works" — in the sense that money is coming in and the product is shipped. But when you ask how they're tracking usage, enforcing limits, or calculating margins? The answer is almost always some version of: "We build an in-house solution that works for now".

That's not a failure. That's just how early-stage companies survive. You hack things together. You make it work. But at some point, usually right before a major product launch or a new set of features hits the roadmap, that manual scaffolding starts to crack.

This post is about how to think through pricing before it becomes a crisis. What the data says. What we're seeing from companies in the field. And what it actually takes to build a model that can grow with you.