How to Control Overhead Cost for AI Products

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.

Disclosure: I build Limitr, which does this. I use it as the worked example below because it's what I know, but the math and the instrumentation approach apply regardless of what you build on.

---

As soon as you have usage overhead, usage-based complexity exists in your product, regardless of pricing model and what you present to your customers.

This post fills the instrumentation gap between token cost-to-deliver and packaging, which should be simplified into customer language and presentation. Packaging itself is not covered here.

Usage Observability

An effective control strategy starts with observation. That's why we built an observe mode directly into our usage limits — you can't control what you can't see.

Vendor dashboards and API key segmentation might get you through the early days, but that approach falls apart the moment you need per-account, per-vendor, per-feature cost and margin analysis. If you don't believe that yet, check back in a few months once your product's grown up a bit.

The number you're after is margin-to-deliver. Here's an example:

Single account, per-feature usage, last 24 hours (2 vendors, 1 pipeline)

• Claude Sonnet delivered: 35.67MTok
• Google Gemini delivered: 42.5MTok
• Outcomes delivered: 2,493
• Charged: $53.78
• Overhead: $42.45

An outcome here is one pipeline run. It may or may not mean anything to the customer — it means something to us.

Cost-to-deliver: $42.45, or $0.017 per outcome.

Revenue-per-outcome: $0.0216, so margin-per-outcome — (charged − overhead) / charged — comes out to 21.1%.

On average, every successful run nets us about 20% margin, for this account.

Now we have real numbers to work with. How much lower are we willing to let that margin go? How many more runs before it hits zero, or goes negative? Would a usage limit protect the bottom line, and should every plan or contract get one?

Attributing raw usage to outcomes

The hard part is typically the mapping. A pipeline run generally isn't just one call — it's several, possibly across multiple vendors, and you need to know which outcome each one belonged to before any of the above means anything.

In Limitr, an outcome is just another credit, tracked the same way tokens are. Every allow(...) call can carry metadata, and it's a common pattern to attribute usage within it, rolling usage up per agent, per feature, via region, the customer's team, or even per run margin and spend data using spend caps.

We can do this because Limitr is a local, context-aware engine that can track state over many enforcement checks. Pricing stays accurate with or without any of it, but the metadata is what lets you slice the analytics afterward. It's what makes a line item like "this pipeline consumed 132MTok of Sonnet" possible.

Tip

Put metrics in terms of real actions or outcomes wherever you can. Keep the raw usage data around for vendor-specific analysis (entitlements should always use the most discrete credit), but the margin-to-deliver KPI itself should be vendor-agnostic — documents read, uploads processed, tool calls made, whatever's meaningful to you.

That way, when you switch models, you're comparing against outcomes you (and your customer) care about, not an arbitrary token count that only means something to the vendor selling it to you.

Limitr measures real-time margin for every credit and token, and rolls them up (and translates them) automatically — this example is the simplified version.

---

Usage Enforcement

Once you can see margin-to-deliver per account, feature, and vendor, the first real lever you have to control it is enforcement — deciding what a user has access to and how much of it.

Single account on a "pro" plan @ $200/mo (flat or seats)

• AI pipeline @ $0.017 avg cost-to-deliver per outcome
• AI data aggregation @ $0.042 avg cost-to-deliver per refinement

$200/mo covers 11,764 pipeline runs at that cost. This account used 2,493 in 24 hours — a little over 4 days of runway, nowhere near a 30-day target. Left alone, this account pushes margin negative.

The simplest fix, without touching price: cap usage. One option is to limit the pro plan to 392 pipeline runs a day, and cut off data aggregation entirely. Worst-case margin-to-deliver is now 0% — you'll never lose money on this feature or account again.

But you may not make any money on it, either.

---

Usage Monetization

At this point, the case for usage-based pricing should be clearer. You want revenue to scale with overhead, so margin-to-deliver becomes something you set and optimize through revenue, not just something you defend by cutting cost.

There's more than one way to do this — plenty of other posts cover pricing strategy on its own. But every approach depends on being able to analyze and enforce usage first, which is the whole point of the last two sections.

A few of the options, for the example we've been using:

• Credit model — flexible, supports top-ups, but can be confusing for users when the ROI isn't obvious
• Cost-plus-margin — clean and accurate, but rigid, invoices that need explaining, hard to upsell, and it tells the customer exactly what your margin is
• Outcome-based — a middle ground, packaged in the customer's language, but harder to guarantee a positive margin-to-deliver on

These aren't mutually exclusive, and the right answer usually differs by feature, by vendor, and by contract. Your objective changes too — margin this month, adoption next. That's the actual argument for keeping the choice in a policy instead of in code: you shouldn't have to ship a release to change your mind.

Here's what that policy might look like for our "pro" plan:

Single account "pro" plan Limitr policy

• Monthly subscription: $200/mo (override for annual contracts)
• Includes 5 seats, then $29.99/mo per additional seat (hard limit for annual)
• Includes 30MTok Claude Sonnet tokens/day, then $5/MTok over (hard limit override for margin control on annual + usage governor for SLA)
• Includes 40MTok Google Gemini tokens/day, then $4/MTok over (same overrides)
• Includes 500 AI pipeline runs/day, then $0.02/run over (set to observe + unlimited on enterprise + analytics)
• Includes 100 AI data aggregations/day, then $0.05/aggregation over (same)

The subscription and seats are doing a specific job here: they're the predictable floor that covers your fixed cost regardless of how the account behaves. Everything below them is the part that moves.

On the contract and invoice (anything presented to the customer), keep it to subscription, seats, and outcomes when possible — in the customer's language, framed as wins where you can. Average cost per outcome makes a good line item. Put the full cost breakdown further down if needed, in its own section, for whoever wants to dig in.

Example account usage, 1 month

• Claude Sonnet delivered: 1,080MTok — 900MTok included, 180MTok over
• Google Gemini delivered: 1,290MTok — 1,200MTok included, 90MTok over
• Successful AI pipeline runs: 30,000 — 15,000 included, 15,000 over
• Data aggregations: 4,500 — 3,000 included, 1,500 over
• Seats: 5, all included

Worth noting: that's about 1,000 pipeline runs a day, down from the 2,493 we saw in the first 24-hour window. Usage moves. A plan with a visible included amount and a rate past it changes how an account behaves in a way a flat $200 never does — which is exactly why you want to be watching margin-to-deliver continuously, not modeling it once.

Invoiced

Usage details

AI Pipeline Runs — $1,220.00

Data Aggregations — $415.00

Overhead for the month came to $699 — 30,000 runs at $0.017 and 4,500 aggregations at $0.042. Against $1,835 charged, that's a margin-to-deliver of 61.9%, up from the 21.1% we started with. Nothing got cheaper. Revenue was just allowed to move with the usage driving the cost.

The included usage gives you a good baseline margin-to-deliver, depending entirely on any base platform fees. The cost vs price per credit changes the margin-to-deliver for every credit beyond included limits. And separating internal/external outcomes vs vendors vs included provides flexibility per account, feature, and vendor to move margin-to-deliver according to your goals.

Tip

A credit model could be used with this exact policy to provide even more flexibility for both the provider and consumer. Included, committed, and/or top-ups of abstract credits can be applied at different exchange rates across all other discrete credits, like tokens.

For your user, this actually simplifies what they're looking at, because it's one common unit, clearly scaled to make it easier for them to track, budget, allocate, and commit on. Could also allow them to place their own usage caps in a single unit, so that they never go over what they expect, regardless of how they're used.

---

Two levers, one usage policy

Cost-to-deliver tells you what an account costs. Margin-to-deliver tells you whether it's worth having, and gives you the numbers you need to actually stay in control.

Enforcement sets your baseline. A limit is a guardrail around the worst case. Cap pipeline runs at 392/day and you've decided, in advance, that this account cannot lose you money. It holds whether anyone's watching or not.

Pricing moves that baseline. Charge for overage and revenue rises with cost instead of being eaten by it. That's the 21.1% → 61.9% swing above.

Enforcement without pricing protects your margin by refusing actions — a 0% floor and a hard cap, for example. For some situations, like agent tool calls or the time an agent gets to converge on a turn, this layer of control makes sense regardless of pricing.

Pricing without enforcement can scale revenue with cost, right up until one run consumes 300x more AI overhead than accounted for.

Both require per-account, per-feature, and per-vendor observability. You can't set a limit you can't measure against, and you can't price an outcome you can't count.

Which is where this usually falls apart. Analytics sit with one vendor, limits sit in application code, prices sit in the billing system — and the three drift. The number you analyzed isn't the number you enforced on, and neither one is the number you invoiced.

This is what we built the Limitr policy for. One document defines the credits, what they cost you, what you charge for them, what each plan includes, and what happens at the limit — observe, soft, or hard.

That same document is what executes at the moment of the call. So the margin you're analyzing, the limit you're enforcing, and the line item you're invoicing all come out of one place, in real time, and they can't drift apart.

To see it in action, check out the live monetization demo — you can play with a simple policy and track actual usage right in your browser.