Control
Gate access. Cap spend.Control usage.
Limits, access gates, and spend caps enforced where calls happen, translated into units that matter — per customer, per agent, per pipeline, per vendor, embedded and real-time.
What changed?
Runaway AI doesn't send a warning. It sends an invoice.
Why teams control usage with Limitr
Ship AI features without betting the company on the bill.
Start in observe mode — meter everything, enforce nothing, and watch real usage before committing to a number. Flip to soft limits when you're ready to charge for overage, then hard limits when you need a wall. Same policy, no rebuild, no re-launch.
Stop overspend before it happens.
Limits, credit balances, and rate governors — collapsed at once to provide a live generation allowance, like max_tokens, before call execution. A dynamic ceiling to support agreements and prevent sudden shutoffs.
Enforce spend controls, no matter what's running underneath.
Self-serve spend caps, overhead caps, observers, agent caps with scheduled resets — control spend in every situation, across services, vendors, and various credit exchange rates.
Place access gates for every user and agent.
Entitlements are gates with optional usage limits attached. They scope exactly what each tier, customer, or agent can do — defined as policy, enforced directly in-process where all the action happens.
One policy, every kind of limit
Switching a mode or scoping access is one configuration change, not two systems. An entitlement without a limit is an access gate, add a limit to charge, control, and observe any type of usage — any strategy, one open policy spec.
See the spec
Enforced in-context, not outside
The runtime never leaves your application context — calculate dynamic usage allowance, cap spend over a single pipeline run, or change behavior for an agent. The complexity of dynamic controls won't get in the way of shipping.
Experience the runtime
Control units that matter
Transform and roll-up disparate credit types into a single unit for spend caps, overhead control, and observability in context. Multi-vendor pipeline spend is unified, controlled, and compared on equal ground.
Credit exchange
Common control questions
Limits & enforcement
Hard limits block the call outright once the cap is reached. Soft limits let the call through. Depending on how you configure soft limits in your policy, you can and just observe the overage usage, set a price and bill or invoice for the overage, or enable notifications to alert upon overage events.
Observe mode meters everything and enforces nothing, which is where most teams start. The three aren't separate products; they're one policy with a mode field, so moving from observe to soft to hard is a simpple change within the Limitr policy.
Spend caps sit above and outside of policy-level entitlemens and limits. Plans group entitlements, and entitlements can have usage limits tied to them that define included/overage thresholds. Caps sit outside so that they can span across many entitlements at once.
This enables caps to be used for observing or enforcing spend per agent, pipeline, vendor, credit, or customer. Self-serve caps, overhead maximums, spend analysis — a versitile paradim for all of your use cases.
Per-agent, per-customer, per-tier — however granular you need. A "customer" can be a user, account, workspace, agent, or anything else you'd like to limit, control, or analyze — facing either internally or externally.
Practically speaking, controlling one of your own agent's usage limits is no different from controlling a user's usage, the user just might get an invoice at the end of the month for it.
Limitr is an embedded runtime that is entirely event-driven. Therefore, you always have access directly in-process to local events like meter changes or limits being hit. The runtime is flexible, so you can always add your own rules, tooling, and custom events.
SDK-level handlers are also available for convenience, allowing your application to listen and handle the events it needs to in its native tongue. Explicit errors are also always provided.
What you do with events and errors is up to you: show the user a limit message, queue a request, fall back to a cheaper model, whatever fits your product.