We Mean Runtime Literally

Everyone in usage-based pricing says enforcement has to happen at runtime. We agree. But that word is doing two different jobs, and the difference matters more than it looks like it should.

At runtime is about timing. The check happens while your code runs, instead of in a nightly job or at month-end.

A runtime is a thing. An execution environment that loads code and runs it.

We mean the second one. Your pricing policy is a document with logic in it, and that logic runs inside your process. Not a fast API call. Not a cached copy of your limits. The policy itself, running where your code runs.

What embedded actually means

Limitr policies are written in Stof, an open-source data runtime that's a superset of JSON plus one thing that matters here: a document can carry functions, not just fields.

So a policy isn't config that our engine interprets according to its own rules. It's a document holding both the numbers and the logic that acts on them.

policy: {
    plans: {
        pro: {
            label: "Pro Plan"
            entitlements: { analytics: {} }
        }
    }
    customers: { john: { plan: "pro" } }
 
    fn has_analytics(id: str) -> bool {
        const customer = self.customers.get(id);
        const plan = self.plans.get(customer.plan ?? 'pro');
        ?plan.entitlements.contains('analytics')
    }
}

The Stof runtime is Rust compiled to WebAssembly. Limitr embeds it in your application, and it executes that document — sandboxed, in-process, on every call. The policy is data that travels. The runtime is what runs it.

Which means your pricing logic sits on your side of the network, unique to you, and always under your control. As such, it's context-aware and can hold state across a sequence of calls instead of answering one question at a time.

Here's what we do with that.

Monetize: charge in units your customers understand

Vendors bill you in tokens, seconds, pages, requests. Your customers don't buy any of those. They buy documents processed, calls handled, deals closed. Sometimes they just want to know the dollar number.

Limitr converts between them while usage happens. The rates live in the policy, so a token count becomes credits becomes dollars at the moment of the call, not when the invoice runs.

That conversion has to happen in-process, because it needs the raw usage and that customer's rates in the same place at the same time. An outside service can convert numbers you send it afterward. It can't be inside the current pipeline context.

This means the invoice is built from the same numbers your product already enforced against. Nothing gets reconstructed at month-end, and the line items make sense to the customer without a footnote.

Control: one spend cap across an entire pipeline

Say an agent makes three calls in a single run — a model provider, a search API, a document parser. Three vendors, three unit systems, three prices. Now put a $2.00 ceiling on the run.

A remote service can approve each call on its own. The hard part is holding the running total for that specific run, because the state lives in your process and every check is a round trip to something that doesn't have it. You either track it yourself, which means you wrote the enforcement, or you find out after the run finished.

Embedded, the cap is just a number the policy carries as the run goes. The third call gets denied because the first two already spent. And it works across all three vendors because the exchange already put them in the same unit.

This enables caps that hold across a whole pipeline, not one call at a time. A faster API doesn't get you there.

Analyze: know what a run costs, not just what a call costs

Per-call margin is relatively easy. Report a cost and a price with every event and anything can add them up.

The questions worth asking are shaped differently. What did this run cost? What's our margin on a success versus a failure? Which agent is expensive? Is this customer actually profitable at the rate we gave them?

Those need context that only exists while your code is running — where a run started and stopped, which calls belonged to it, whether it worked, which agent made them. A reporting service receives events. It doesn't know what a run is unless you tell it, and once you've built the run boundary and the attribution chain to tell it, you've built the analytics layer and outsourced the addition.

Our runtime is already in the pipeline, so it sees the run. And the exchange already put every vendor's usage into one unit, so the run's cost is a single number instead of tokens plus seconds plus pages.

This enables us to track cost per outcome instead of just cost per call.

Why the bar should move

None of this is a speed claim. Just being fast doesn't fix it. The limit is that context doesn't survive a round trip — your pipeline state, your call sequence, your costs aren't on the other end of that request unless you sent them, and if you're sending them, you're doing the work the enforcement layer was supposed to do.

So we're picky about the word. "At runtime" tells you when a check happens. "A runtime" tells you where your logic lives. The second is a much bigger commitment, and it's the one that decides whether a pricing system can hold state across a run, convert units mid-flight, and tell you your margin before the invoice shows up.

When Limitr says runtime, we mean the noun.

If you're looking at tools that use the word, ask where the logic actually runs.