3 posts tagged with "engine"

Limitr puts pricing inside your app. Every allow() is checked in your process, and a policy can carry logic of its own: a cost function per model, a rule for who gets a feature, a capability your agent can call. That's what makes it fast and flexible, and it raises the questions any security review should ask: what can that logic touch, who can change it, and what happens when something goes wrong?

Here are the answers, as of engine 0.8.3. The Security model page keeps them current.

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

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.