Usage, priced and enforced at runtime.
Limitr prices, limits, and meters every unit of usage inside your app, and your team changes it live, for every plan, contract, and customer.
Pricing never sits still.
Costs, usage, and deals change every month. Every change lands on your code, your services, and the customers you already have.
- An agent loop burns $400 of tokens on a $49 plan. You find out from the invoice.
- Sales signs a hard spend cap. It ships next sprint, in three services.
- You change one price. Every service, every current customer, and every mid-month upgrade needs new code.
One policy, running inside your app.
Plans, prices, limits, and each customer’s deal live in one document. The Limitr engine runs it in every service, and a change made in Limitr Cloud goes live everywhere, with no release.
Priced across the task, not one call at a time.
One task is dozens of calls across models, tools, and vendors. A billing API sees each one alone, after it happens. Limitr runs in your app, with the customer, their plan, and what the task has cost so far, so it prices and limits the whole task as it runs.
- Too looseleaks margin
- Too tightstalls adoption
- Trimmedmargin holds
Every deal, enforced as written.
Each customer’s terms apply on their next call. Sales or finance set them up in Limitr Cloud: no new plan, no engineering ticket.
- Acme20% off outcomes through Q4
- Globex$2,400 monthly spend cap, hard stop
- Initech$50k annual commit, drawn down per call
Why not a billing API, or build it yourself?
Both work until your pricing has to change, or until a task is more than one call.
- What it sees
- Every call in a task, with the customer, plan, and spend so far
- A runaway task
- Limited mid-task, against what it has cost so far
- Changing a price
- Publish once and it’s live everywhere, no release
- Custom contracts
- Each deal enforced as written, on the next call
- Before you change
- Limitr Analyst simulates the change and forecasts its margin
- What it sees
- One event at a time, after it happens
- A runaway task
- Counted once the cost is already spent
- Changing a price
- Billing changes; the limits in your app still need code
- Custom contracts
- Invoiced to the terms, not enforced in your app
- Before you change
- Reports on what already happened
- What it sees
- Whatever each service tracks on its own
- A runaway task
- Caught only where someone wrote a check
- Changing a price
- A release across every service
- Custom contracts
- One-off code for each customer
- Before you change
- The dashboards you build yourself
The Regis Company chose Limitr to meter and enforce real-time AI avatar usage ahead of a Fortune 500 rollout covering more than 100,000 users.
- Fortune 500
- Enterprise rollout on a fixed-price contract
- 100,000+
- Users on a single contract
- 3 modalities
- Chat, text-to-speech, and real-time avatars
Let your agent write the pricing. Limitr makes it safe to change.
Vibe code your plans, limits, and the integration. Writing pricing was never the hard part; changing it once customers depend on it is. Limitr checks, tests, and versions every change, and keeps the customers you already have whole.
- Checked
Validated before it runs
Every policy is checked against the spec as you type in Limitr Cloud, and again when the engine loads it.
- Tested
Simulated first
Limitr Analyst runs made-up customers through a draft and shows you the bills and margin before you publish.
- Versioned
One click to roll back
Every published version is kept. See what changed in each, and go back to any of them.
- Current customers
Nobody gets broken
Plan changes mid-month are prorated, usage carries over, and every contract keeps its terms.
The Limitr skills teach Claude Code and other coding agents the policy format, the engine, and the SDK. Ask for a plan, the integration, or the usage meter in your UI, and your agent writes it the way Limitr works, instead of guessing.
Any other agent can read the same skills from the npm package.
Set up your agent> /plugin marketplace add dev-formata-io/limitr > /plugin install limitr@limitr
Know what a change will do before you make it.
Limitr Analyst is the agent in Limitr Cloud. It works on your real policy, customers, and usage: it finds where margin leaks, simulates a change, forecasts what it does, and nothing changes until you press Apply. No billing API can do this, because none of them hold your pricing, your costs, and your usage in one place.
YouWhich customers cost us the most to serve last month?
AnalystNorthwind, at 19% margin. Most of their usage is avatar sessions on your largest model; moving those to the standard model would bring them to about 45%. Save this view as a dashboard to keep it live.
Made-up customers and numbers, drawn to show what the Analyst hands back.
The runtime between the contract and the invoice.
Terms are agreed in your CRM or at signup, and revenue is booked in your ERP. Limitr runs them in between: in your app, managed from Limitr Cloud.
- 01Terms agreedSigned in your CRM, or picked at signup.
- 02Terms become policySet once in Limitr Cloud, pushed live.
- 03Enforced in your appThe Limitr engine runs every call locally.
- 04Recorded and invoicedUsage events land in the Cloud ledger.
- 05CollectedStripe out of the box, or your own rails.
- 06Revenue bookedSynced to your ERP or warehouse.
One document. A few lines to read it.
- DefineWrite the policyPlans, prices, and limits in one file.
- LoadRun it in-processOne call starts the engine.
- AskCall
allow()Gate, meter, and price usage in one step. - TrimChange it liveEdits publish everywhere. No deploy.
{
"policy": {
"credits": {
"seat": { "price": { "amount": 19.99 } },
"token": { "price": { "amount": 0.00004 }, "overhead": 0.000003 }
},
"plans": {
"starter": {
"entitlements": {
"seats": { "limit": { "credit": "seat", "value": 3 } },
"ai-chat": { "limit": { "credit": "token", "value": 1000,
"mode": "soft", "resets": true, "reset_inc": "1hr" } }
}
}
}
}
}Published. Every connected engine reads it on the next call.
import { Limitr } from '@formata/limitr';
const policy = await Limitr.cloud({ token });
await policy.createCustomer('acme_corp', 'starter');
if (await policy.allow('acme_corp', 'seats', 2)) {
console.log('2 seats — allowed');
}
if (await policy.allow('acme_corp', 'ai-chat', 10000)) {
console.log('10,000 tokens — allowed, 9k billed as overage');
}The same engine, free and self-hosted. Commit the policy to your own repo and run it anywhere WebAssembly runs.
View on GitHubAdds the hosted policy editor, version history with one-click rollback, billing, ledgers, margin analytics, and Limitr Analyst. Moving over is a one-line change.
Cloud quickstartEvery feature can run its own pricing model.
Attribute every AI agent’s usage, automatically.
Per vendor, feature, contract, and customer.
Enforce and bill every API call, live.
Gated, metered, and priced in one step.
Cap what agents calling your MCP server can spend.
Shared credit pools with hard ceilings.
Cut a custom rate for one enterprise customer.
Their own terms, with an end date. No new plan.
Reprice a single feature, not the whole model.
One entitlement changes. Nothing else moves.
Get alerted when a usage threshold is crossed.
Trial limits, upsell moments, runaway spend.
Pricing is part of your product. So the engine is yours.
Every business has its own units, costs, and deals, and a service outside your app can only bend so far. That’s why so many teams end up building it themselves. Limitr gives you that control without the build.
In your process, under your control
Open-source code you can read, running locally, even offline. You choose what happens if Limitr Cloud is unreachable, and usage syncs in the background.
Shaped to your business
Plans, prices, costs, limits, and every customer’s deal in one document. Review it like code; Limitr Cloud adds history, instant publish, and rollback.
Extends like code
Your own pricing functions, feature conditions, rules, and tools run in the policy, so it reflects your business, not ours.
“We’ve felt it ourselves: the only way billing scales with your business is to own it, inside your app, like your own team wrote it. That’s why we built Limitr the way we did. The engine is yours, and it reflects your business, whether you use Limitr Cloud or not.”CJ · Co-Founder & CEO
Common questions
Start here
A billing platform records what happened and charges for it afterwards: invoices, payments, subscriptions, revenue recognition. It sees usage one event at a time, on its own servers.
Limitr runs inside your app, where one task's calls across models, tools, and vendors add up in one place, with the customer, their plan, and their deal. So it prices and limits the whole task while it runs, and meters it in the same step, instead of finding out from the invoice.
Keep Stripe, Maxio, QuickBooks, or your homegrown invoicing for collecting money. Limitr is the monetization layer above it: one policy document that decides what each customer gets, what it costs you, and what you charge, enforced live. We integrate with the billing platform and workflow of choice.
It would be, if in-line meant a vendor's server in your request path. Limitr isn't that. The engine runs inside your own process, from open-source code you can read, so there's no network hop and no outside service that can slow down or take down a request. If the connection to Limitr Cloud drops, you choose what happens, and usage syncs when it's back.
Out-of-band tools avoid the risk by only watching, which means they can't act until the cost is already incurred. Limitr lets you start the same way: in observe mode, every unit is metered and nothing is blocked. Then move one entitlement at a time to soft or hard limits once the data says it's safe. You turn control on step by step instead of handing it over on day one.
It's also why the engine is open source. The logic that decides what your customers can do should be yours, in your process and working like your own code, while Limitr Cloud manages the policy, its history, and the billing around it.
Honest answer: if your pricing model is static, you're just trying to monetize, and hardcoding it is fine, then you should. The case for Limitr is a function of how often your packaging changes and how expensive it is to extend, maintain, customize, and analyze. Transparently, though, almost nobody's model stays static, and once you dive in, this critical layer of your app gets large, messy, and nuanced, quickly.
It adds up once you need to split billing across products, apply a discount to one specific tool call, burndown credit balances differently across accounts, run different budgets per model in the same pipeline, handle a mid-period upgrade without double-charging, or roll out a tier without a deploy. Together they become a permanent engineering surface that grows with every commercial decision the business makes, often brittle and expensive to maintain.
With a coding agent, a first version is fast either way, so we don't just sell speed. The hard part is every change after it, and that work comes whether you build or buy. Limitr is built for it: your agent writes the policy with the Limitr skills, and every change is checked, tested, versioned, and published without a release, with current customers handled correctly. It's free to start, and because the engine is open source, you aren't betting your pricing on our roadmap.
No. AI is the loudest version of the problem, not the whole problem. Limitr meters any unit you can define: AI tokens by model, API calls, seats, vendor connections, SMS messages, avatar minutes, GPU seconds, storage, agent runs, outcomes, or a composite credit of your own design.
In practice our customers split roughly evenly. Some are metering multi-model AI pipelines. Others are legacy SaaS companies moving off flat subscriptions: per-seat billing that keeps drifting out of sync, text-message overages reconciled by hand, or a shift from a complicated spend-based calculator to a clean per-unit price. Same infrastructure problem, no AI involved.
The open-source engine is free, permanently. Limitr Cloud is free to start: build and test your policy in the app, with a little Analyst usage to try it, no card needed.
When you go live, pay as you go is a monthly base fee plus your active customers and calls past what's included, billed to your card each month. Scale adds custom deals and contracts for your own customers, forecasting, and more included, self-serve. Enterprise is a contract: usage included, enhanced forecasting, and our team. All of it is on the pricing page.
For your team
No. The policy runs in-process as WebAssembly, colocated with your application. Every allow(), check(), and increment() executes locally, in-process, with no network call on the hot path. Enforcement systems that make a remote API call per decision put a network round trip, and someone else's uptime, in front of every request.
Usage events sync to Limitr Cloud asynchronously over a background WebSocket, and policy updates push down the same way. The hot path stays fast; your data stays current.
Yes, and it's the main reason teams buy this. Anyone with dashboard access and permission can change a limit, add a tier, adjust an overage rule, apply a discount, or gate a feature. Changes publish live and propagate to every connected service instantly: no PR, no deploy, no release coordination.
Per-customer and per-segment pricing works through rules rather than proliferating plans. Keep a small number of plans, then layer overrides on top: replace a price outright or apply a percentage in either direction, with an expiry date and an approval note attached. Sales can structure a custom deal without engineering in the loop.
Every change is versioned with full history and reverts instantly.
Less than you'd expect. Every enforcement decision runs in-process, so your requests, prompts, and responses never pass through Limitr. With Limitr Cloud, what syncs is usage: which customer consumed which entitlement, how much, and when, plus the customer IDs and any metadata you choose to attach.
Run the open-source engine on its own and nothing leaves at all: the policy is a local file and enforcement works fully offline. For Cloud customers with GDPR or similar obligations, we can put a Data Processing Addendum in place, and we're glad to walk your security team through the architecture.
You keep your pricing. The policy is a plain document (JSON, YAML, TOML, or Stof) that you can export and commit to your own repo, and the engine that runs it is open source. Leave Cloud and you can keep enforcing the same policy on the self-hosted engine, through the same API, so your integration doesn't change.
Configurations and usage records are exportable at any time, and for 30 days after an account closes.