Limitr: the usage stack for AI products

Limitr is the most powerful and flexible usage stack for AI: control prices, limits, and contracts for users and agents, live. Everything a customer may do and what it costs lives in one policy file: credits, plans, limits, prices, and contracts. The open-source Limitr engine runs that file inside your application, in-process as WebAssembly, and answers every call: what's allowed, what it's worth, and what it costs you. It's a framework as much as an engine: your own pricing functions, feature rules, and tools run in the policy, your UI reads plans and usage as JSON, and your coding agent writes all of it with the Limitr skills. Limitr Cloud is the hosted service around it: edit and publish the policy to every running engine with no release, put signed contracts into force, keep every customer in sync, and bill through Stripe or your own rails. Limitr Analyst, the agent in Limitr Cloud, shows margin as it happens, simulates a change on real usage, and forecasts it before you publish. Limitr Network lets other apps and AI agents buy from your app under the same policy, with a signed voucher instead of an API key, operated by Limitr Cloud. Limitr never takes a share of your revenue, and the engine and the policy stay yours if you leave.

This page is the long-form, text-only version of the Limitr homepage (limitr.dev), written for search engines, AI assistants, and anyone who wants the whole picture in one place.

Who Limitr is for

Limitr is built for product and engineering teams at AI-native companies whose usage is hard to predict and hard to control: AI tokens across models, agent runs, compute and GPUs, vendor APIs, or any unit where serving a customer costs real money. Most sell both ways: self-serve plans paid by card, and negotiated contracts once accounts grow, so pricing differs by customer and margin depends on what each account actually costs to serve. Limitr runs both from one policy, so a self-serve customer can move onto a contract without changing systems.

Product and engineering own the engine and build on it once. Product, finance, revenue operations, and sales then run plans, pricing, contracts, and margin from Limitr Cloud, with Limitr Analyst to test changes first. It works for usage-based SaaS without AI, too, but it's designed around usage that doesn't follow the plan.

Teams usually arrive from one of two places: they built limits, credits, and billing in-house to keep control and now spend engineering time on every change, or they bought a billing platform for speed and found their pricing living in someone else's system, often priced on a share of what they bill. Limitr is the third option: own the engine, without building and maintaining it.

The four parts of Limitr

• The engine (open source, Apache 2.0). Runs inside your app and meters, limits, and prices every call, with no vendor in the request path. It's a framework you build on: pricing functions, feature rules, rollouts, and tools your agents can run live in the policy; your UI reads plans and usage as JSON; and your coding agent writes the policy and the integration with the Limitr skills. It's yours, with or without Limitr Cloud.
• Limitr Cloud (hosted). Where your team edits plans, prices, and limits, puts a signed contract into force, and publishes to every running engine with no release. Customers, meters, and balances stay in sync across every service, and usage is recorded, invoiced, and collected through Stripe or your own rails.
• Limitr Analyst (in Limitr Cloud). The agent for whoever runs pricing. It knows your policy, your customers, and what every call cost, so it shows margin as it happens, simulates a change on real usage, forecasts it, and turns a signed order form into that customer's terms, before anything is published.
• Limitr Network (early access, in Limitr Cloud). Publish your plans to the Network and other apps or AI agents buy from your app with a signed voucher instead of an API key. Your policy meters them like any customer, the spend lands on the buyer's Cloud invoice, and you're paid out through Stripe. The protocol underneath, the Limitr Network Protocol, is part of the open-source engine.

Limitr at a glance

• What it is: the usage stack for AI products: one policy file (plans, entitlements, prices, costs, limits, overrides, contract terms, and rules), an open-source engine that runs it inside your app and enforces it locally on every call, Limitr Cloud to edit and publish it live and bill from it, Limitr Analyst to test a change first, and Limitr Network so other agents can buy from your app under the same policy.
• Who it's for: product and engineering teams at AI-native companies whose usage is hard to predict, selling self-serve, through sales, or both, with usage-based, hybrid, credit-based, or outcome-based pricing. Product and engineering build on the engine once; product, finance, revenue operations, and sales run pricing from Limitr Cloud.
• Limitr Cloud (the managed platform): hosted policy editor, versioning and one-click rollback, instant publish to every engine, customer state and contracts, usage ledger, invoicing, collection, live margin analytics, alerting, usage and margin forecasting, AI guidance on pricing changes, and billing integrations. Fully managed; nothing for you to host.
• How it runs: a control plane and a data plane. Limitr Cloud is the managed control plane. The engine is the data plane, running in-process in your app as a Rust/WebAssembly library: no network call on the hot path, decisions made in-process, and it keeps working offline. Usage streams to Limitr Cloud in the background.
• Open-source engine: the engine and the policy format are open source and free to self-host, permanently, for teams that want to evaluate first, run offline, or manage the policy themselves (GitHub, npm package @formata/limitr).
• Integrations: Stripe built in; works with Maxio, Chargebee, ACH, or your own payment rails; contract terms from Salesforce, HubSpot, or a CPQ; revenue synced to NetSuite, QuickBooks, or a data warehouse.
• Languages: TypeScript/JavaScript today. Every SDK is a thin wrapper over the same WebAssembly core, so the engine runs anywhere WebAssembly runs.
• Pricing: the open-source engine is free. Limitr Cloud is free to start, pay as you go once you're live (a monthly base fee plus active customers and calls past what's included), Scale for custom deals and contracts, self-serve, and Enterprise by contract. Details: limitr.dev/pricing.
• Business model: Limitr Cloud is priced on the customers and calls it governs, never on a share of your revenue. The engine and the policy format are open source, so your pricing stays yours if you leave.
• Limitr Network: early access for a first group of teams and partners on Limitr Cloud, by request (book a call). Cloud is the operator (identity, discovery, payment); both parties are Cloud workspaces for now, with the Network opening to other operators and partners later. Listings are public or private, like repos; most teams start private. Details: limitr.dev/network.
• Company: built by Formata, Inc. Co-founded by CJ Cummings (CEO), creator of the Stof runtime Limitr is built on, and Amelia Wampler (COO).

What makes Limitr different

Most usage-based software splits monetization across three systems that don't share a brain. A billing platform records usage and invoices it after the fact. An entitlement or feature-flag service decides access. A BI tool or spreadsheet reports on margin at the end of the month. Each has its own copy of the pricing, and none of them sees what a call cost and what it earned at the moment it happens.

Limitr collapses that into one runtime running one document. If billing platforms are where usage is deployed to an invoice and observability tools are where you monitor it, Limitr is the pipeline in front of both: it decides, in real time, whether a request is allowed and what it's worth, before it ever reaches the invoice.

1. One policy file you own. Credits, plans, limits, prices, vendor costs, and customer contract terms live in one versioned file (JSON, YAML, TOML, or Stof) instead of vendor configuration or application code. Changing a price is editing a line, not shipping a release. Limitr Cloud is to that file what GitHub is to git: history, diffs, one-click rollback, and instant publish to every running engine.
2. Runs in your app, managed in the cloud. The engine runs in your process as WebAssembly, with no network hop on the decision path, not even to a sidecar, while Limitr Cloud pushes the policy down and receives usage in the background. Decisions are identical in every front end, back end, and service because they run the same binary, and they keep working offline.
3. Prices the whole task, not the single call. One agent task is dozens of calls across models, tools, and vendors. Because the engine holds the running state in your process and converts raw usage through a credit exchange, it limits and bills the task as one unit (an outcome, a run, a dollar budget, a credit), against the customer's plan and your cost, as it runs. A per-event billing API sees each call alone.
4. Limits hold at the call. Checking the entitlement, applying the price, and recording the usage are one atomic operation at the moment of consumption, so a cap holds before you pay a vendor for the tokens rather than showing up on next month's invoice.
5. Margin is a live output. Every credit carries both what a unit costs you and what you charge for it, so profitability per customer, per feature, and per vendor is computed continuously, as a byproduct of the same decision that enforced the limit.
6. Open and independent. The engine and the policy format are open source, so your pricing never depends on a vendor's roadmap, and leaving means keeping the file and running it yourself.

How the Limitr engine works: in your app, with the whole picture

The full walkthrough is on the engine page (limitr.dev/engine).

The engine runs in your process, so every call is decided with the customer, their plan and deal, and what the task has spent so far. Running in-process is what makes it both flexible and powerful. Flexible, because the engine and the policy format are open source and extensible: you own the engine like code you wrote, and build your own rules, UI, and agents' tools on the policy. Powerful, because it is a complete engine, not just endpoints: allow, meter, price, limit, reserve, settle, predict, feature flags, spend caps, credits, contracts, and events all run in-process, sandboxed, with no network hop on the call, and it keeps working offline.

Who can use what, how much of it, and at what price used to be simple to decide: count the events and compare them with a plan. That is no longer enough. A single task in an AI product is now dozens of calls across models, tools, and vendors, and what that task costs, what it is worth, and whether it should keep running only add up when every call is seen together, alongside who the customer is, what plan they are on, and what this run has spent so far.

That context exists in one place: inside the product, while the task runs. Tools that sit outside the product, such as billing platforms, metering pipelines, and remote entitlement APIs, see usage one event at a time and none of that context. Limitr's position is that usage decisions belong where the usage happens.

• The engine runs inside your product. It loads like any package and shares your product's process, so it sees every call a task makes, across every vendor, the moment it happens. It limits and prices the task as it runs, against the customer's plan and what the task has cost so far, and knows its margin the moment it finishes.
• Your team still sets the course in Limitr Cloud. Plans, prices, and customer contracts are managed in Limitr Cloud, and Limitr Cloud stores every customer and their usage, so there is no customer database to run. Publishing a change updates every running copy of your product (web app, API, background workers) on its next request, with no release. Usage streams back to Limitr Cloud for billing, ledgers, and margin.
• It keeps working when the connection drops. If your product loses its connection to Limitr Cloud, the engine keeps deciding with the rules it already has, or pauses usage, depending on one setting. Usage syncs when the connection returns.
• Your UI reads the same data. Plans, limits, and each customer's usage are plain JSON inside your product, so usage meters, upgrade prompts, and pricing pages can be built any way you like and always match what the engine enforces.
• Control is turned on step by step. Every limit runs in observe (record everything, block nothing), soft (allow and bill the overage), or hard (stop at the limit). Teams start in observe and switch one limit at a time without changing code.
• It stays yours. The engine is open source under Apache 2.0, and the rules are a versioned document you can keep in your own repo. Prompts, responses, and payloads never leave your product. If you leave Limitr Cloud, your product keeps running the same rules on the self-hosted engine.

In-line, without a vendor in the line

There is a long-running debate about where usage control should sit. Out-of-band tools (billing platforms, metering pipelines, BI) sit beside the product and watch. They are safe because they can't break a request, but they can only react after the cost is incurred. In-line tools (gateways and remote entitlement APIs) sit in the request path and can act, but they put someone else's network, uptime, and logic in front of every request, which is why many teams are wary of them.

Limitr's position is that the only way to scale with flexible control logic is to own it and run it inside your product. The Limitr engine is in-line without a vendor in the line:

• It runs in your process. A decision is a local function call, with no network hop and no outside service that can slow down or take down a request.
• It is your code to read. The engine and the policy format are open source. It imports like a library and operates like a service: Limitr Cloud manages the policy, its history, and billing, and publishes changes to every running engine without a deploy.
• You choose the failure mode. If the connection to Limitr Cloud drops, you decide whether the engine keeps enforcing the local policy or denies usage until it reconnects, and usage syncs when the connection returns.
• Control is earned step by step. Every limit runs in one of three modes: observe (meter everything, block nothing), soft (allow and optionally bill the overage), or hard (stop at the cap). Teams start in observe mode, which behaves like an out-of-band tool, and move one entitlement at a time to soft or hard limits once the data supports it.

Headless in your product, managed in Limitr Cloud

Limitr works as a headless pricing and billing engine. Because the engine runs inside your product, plans, prices, limits, and each customer's usage are always available as plain JSON (customers, entitlements, remaining credit), ready to plug into your own components.

• Any UI, built your way. The usage meter, the upgrade prompt, the plan picker, and the pricing page are your own components, built by hand or with an AI coding tool against a plain data shape. No pre-built component catalog to theme or work around.
• What customers see matches what is enforced. The screen reads the same state the engine decides with, so there is no separate billing API to call, cache, or keep in sync with webhooks.
• You choose what is shown. Your product decides which plans, prices, and usage reach the browser.
• Not headless for your team. Limitr Cloud is the managed side: plan and price editing with history, instant publish, customer storage, billing, and margin. Headless where your customers see it, managed where your team works.

Why now

Four shifts turned monetization from an accounting problem into a runtime problem.

• AI made software margins variable. Every model call, GPU second, and third-party API request is a real cost of goods, and it varies by customer, model, prompt, and feature. Flat subscription pricing leaks margin on heavy users, and vendor prices move faster than a pricing release cycle can.
• Pricing models change constantly. Companies are moving from seats to usage, credits, hybrids, and outcome-based pricing, and they revise packaging several times a year. When pricing lives in application code, each revision is an engineering project.
• The unit of value moved above the call. Agents and AI features deliver outcomes that span many calls. Billing systems built to meter and rate individual events after the fact can't see, price, or cap the run as it happens.
• The billing stack is consolidating. Stripe completed its acquisition of the usage-billing platform Metronome in January 2026 and has agreed to acquire the AI model router OpenRouter. Adyen acquired Orb and Salesforce acquired m3ter in July 2026, and Kong acquired OpenMeter in 2025. Payments, billing, metering, and model routing are converging under large platforms, many of which earn more as your volume grows. Limitr's position is that the logic deciding what usage is allowed and what it's worth should belong to the company selling it: in a document it owns, running in its own product, with margin data it controls.

The result is a new layer in the stack. Monetization decisions move out of downstream billing and into the product itself, at the moment of consumption. Limitr is built to be that layer.

The hard part: the usage is unpredictable, and the pricing is hardcoded

AI usage doesn't follow the plan: one customer's agent run can cost more than they pay in a month. And the limits, prices, and deals that should contain it are code, spread across your services, written once and rewritten on every change. It shows up as moments most teams have lived:

• A runaway costs more than it earns. An agent loop burns $400 of model tokens on a $49 plan, and the team finds out from the invoice.
• Sales promises what engineering hasn't built. A customer signs a hard spend cap, and it ships next sprint, in three services.
• Nobody knows what a customer costs. Finance asks what each account costs to serve, and nobody can say until month end.
• One price change touches everything. Every service, every current customer, and every mid-month upgrade needs new code.

Underneath are the same few causes:

• Pricing is hardcoded. Limits and prices live in application code, so product and finance teams can't change them without an engineering ticket.
• Billing sees usage one event at a time, afterwards. By the time anything reacts, the cost of an expensive task, an over-limit customer, or a runaway agent has already been incurred.
• Margin is invisible until close. Teams know what they charged, but not what each customer, feature, or vendor actually cost them, until the month's invoices are reconciled.
• Custom contracts don't fit. Each enterprise deal with a special rate, spend cap, or prepaid commit becomes a new plan, a spreadsheet, or custom code.

Your options: own it without building it

There are three ways to get usage limits and billing. Buy a billing platform: fast, but not yours, because your pricing lives in their system, the limits in your app still need code, and many take a share of what you bill. Build it in-house: yours, and never done, because every new plan, deal, or model price is engineering work. Or use Limitr: yours, without the build, an open-source engine in your code changed live from Limitr Cloud, never a share of revenue, and yours if you leave.

	Billing platforms	Built in-house	Limitr
Who owns it	Their system holds your pricing	You do, and you maintain all of it	You do: an open-source engine in your code, kept in sync by Limitr Cloud
What it sees	One event at a time, with no task	Whatever each service tracks on its own	The whole picture: the customer, plan, deal, and the task so far
Changing a price	Billing changes; the limits in your app still need code	A release across every service	Publish once and it's live everywhere, no release
Custom contracts	Invoiced to the terms, not enforced in your app	One-off code for each customer	Each deal enforced as written, on the next call
Before you change	Reports on what already happened	The dashboards you build yourself	Limitr Analyst simulates the change and forecasts its margin
As you grow	Often a share of what you bill	More engineering with every plan and deal	Never a share of your revenue, and yours if you leave

Building keeps control and costs engineering time on every change. Buying a platform is fast, and puts your pricing in someone else's system. Limitr keeps the control without the build. Why we built it this way, and a vendor-by-vendor guide: Usage-based billing platforms in 2026: why your pricing should belong to you.

The fix: one policy shapes every unit of usage

A Limitr policy is a versioned document, written in JSON, YAML, TOML, or Stof, that declares plans, entitlements, prices, limits, and rules once, managed from Limitr Cloud. The engine runs it inside your process as WebAssembly, so every service reads the same policy, and a change goes live everywhere without a release.

Because the policy is a document rather than code, it can be reviewed like code, diffed, committed to your own repository, rolled back, and edited by non-engineers in the Limitr Cloud dashboard. Engineering wires up an entitlement by name once. Everything behind that name, including limits, prices, tiers, and per-customer overrides, is configuration.

The difference: priced across the task, not one call at a time

One outcome in a modern product is often dozens of calls: model calls, tool calls, retries, agent steps. A billing API sees each call alone. Limitr holds the running state in your process, so it can price and limit the whole run as it happens, against live cost and margin.

That makes it possible to tune pricing the way you would tune any other system:

• Too loose leaks margin: expensive usage goes unpriced or unlimited.
• Too tight stalls adoption: customers hit walls before they see value.
• Trimmed holds margin: limits and prices track real cost, per customer and per feature, and can be adjusted live.

Every credit in a Limitr policy carries both what a unit costs you (for example, a vendor's per-token price plus overhead) and what you charge for it. That is what makes per-customer, per-feature, and per-vendor margin a live output instead of a month-end report.

Built for custom contracts: every contract, enforced as written

Each customer's terms live in the same policy and apply on their next call. Sales or finance can set them up in Limitr Cloud with no new plan and no engineering ticket. Examples:

• A custom rate: Acme gets 20% off outcomes through Q4.
• A spend cap: Globex has a $2,400 monthly spend cap with a hard stop.
• A commit drawdown: Initech has a $50k annual commit, drawn down per call.

Overrides can replace a price outright, or add or take off a percentage or a flat amount, with an end date for a temporary deal. Teams keep a small number of plans and layer customer-specific terms on top, instead of multiplying plans for every deal.

Where Limitr fits in the stack

Limitr is the runtime between the contract and the invoice. Terms are agreed in a CRM or at signup, and revenue is booked in an ERP. Limitr, inside your app and managed in Limitr Cloud, is the piece in between that actually runs them.

1. Terms agreed. Negotiated deals come from Salesforce, HubSpot, or a CPQ. Self-serve plans, product-led signups, and AI agents skip this step and go straight to policy. A CRM is optional.
2. Terms become policy. Plans, rates, limits, and per-customer overrides are set once in Limitr Cloud, versioned, and pushed live to every engine.
3. Enforced in your app. The Limitr engine enforces the policy locally on every call and streams usage events to Limitr Cloud.
4. Recorded and invoiced. Usage events land in the Limitr Cloud ledger, are charged securely, and roll up into an invoice. The invoice can also feed a custom downstream process.
5. Collected. Stripe is built in. Maxio, Chargebee, ACH, or your own payment rails also work.
6. Revenue booked. The ledger and invoices sync to NetSuite, QuickBooks, or your data warehouse.

The local engine is event-driven: enforcement decisions happen in your process, and the ledger lives in Limitr Cloud, not in the engine.

In your code: one document, a few lines to read it

The integration surface is deliberately small.

1. Define: write the policy. Plans, prices, and limits in one file.
2. Load: run it in-process. One call starts the engine.
3. Ask: call allow(). Gate, meter, and price usage in one step.
4. Trim: change it live. Edits publish everywhere, with no deploy.

import { Limitr } from '@formata/limitr';

// Open source: load a local policy document
const policy = await Limitr.new(policyJson, 'json');

// Limitr Cloud: the only line that changes
// 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 example plan, "starter," includes 3 seats at $19.99 and 1,000 ai-chat tokens per hour at $0.00004 per token in soft mode, so usage over the allotment is allowed and billed as overage. In Limitr Cloud, the same plan appears as an editable table; changing the seat price from $19.99 to $24.99 publishes a new version, and every connected engine reads it on the next call.

Open source: the same engine, free and self-hosted. Commit the policy to your own repo and run it anywhere WebAssembly runs. (View on GitHub)

Limitr Cloud: adds the hosted policy editor, version history with one-click rollback, and billing, ledgers, and margin analytics. Moving over is a one-line change. (Cloud quickstart)

Every feature can run its own pricing model

Each feature in a product can have its own monetization strategy, all in the same policy. Limitr supports:

• Usage-based pricing: per token, per API call, per message, per GPU second, per agent run, or any unit you define.
• Seat-based pricing: per user or per seat, with seats resolved at the right level (org, workspace, team).
• Hybrid pricing: a subscription or seat fee plus usage, or included allotments with overage.
• Credits and top-ups: prepaid credit balances, composite credits, and customer top-ups before a balance runs out.
• Prepaid commits and drawdowns: annual or monthly commitments drawn down per call.
• Free trials: time- or usage-limited trials with hard limits.
• Rollovers and expirations: unused allotments that roll over, reset on a schedule, or expire.
• Outcome-based pricing: charge for successful runs or completed outcomes while controlling the underlying usage separately.
• Enterprise deals: custom rates, discounts, spend caps, and terms per customer.
• Feature flags and rollouts: kill switches, percentage rollouts, beta lists, and rules per request, next to the plans that decide who pays for what.

Limits run in three modes that can be switched without a code change: hard blocks the action at the cap, soft allows overage and optionally bills it, and observe tracks everything while enforcing nothing.

What the open-source engine does

The engine is the same in Limitr Cloud and self-hosted. As of version 0.8 it includes:

• Real cost per call. Each model's input and output tokens can be their own credits, with their own price and cost, so invoices match the provider line for line. Or a credit can carry a cost function that prices each call from its own data, or take the exact cost a provider reports. Rates live in the policy, so a provider price change is a policy change, not a deploy. (AI costs per model)

• Margin in every event. Every usage event carries what the call is worth at list price and what it cost, so margin is known per call, per customer, and per feature as it happens. (Cost functions and margin)

• Reserve before, settle after. For calls whose size is only known afterwards, like LLM calls, the engine holds room before the call so concurrent calls can't overspend together, then records what the call really used. (Reserve and settle LLM calls)

• Usage prediction. The engine learns how big calls are, per model or kind of call, and predicts the next one from its input: the size of a hold, a max_tokens, or a quote before the call runs. (Predict output tokens)

• Feature flags and rollouts. Kill switches, stable percentage rollouts, beta lists, and rules per request, on any entitlement. Rules can only narrow what a plan gives, so a bad rollout rule can't give away a paid feature. (Feature flags and rollouts)

• Custom deals per customer. Give one customer a feature their plan doesn't have, take one away, or change their limits, with expiry, without a new plan. (Trials and custom deals)

• Spend caps. Budgets in any currency or credit, per customer or shared across an org and its teams, on spend or on cost, with warnings before they're reached. (Budgets)

• Prepaid credits and top-ups. Credit packs with expiry, monthly resets, and rollover, spent across features at their own rates. On a plan change, included packs top up to the new plan's amount and never shrink on a downgrade. (Prepaid credits, Change plans)

• A sandbox by default. Logic in a policy has no network, file, or environment access unless the host allows it (and never the host's private network unless it's listed), every policy call has time and memory limits, and the engine is sealed so a policy can build on it but can't change it. (Runtime and sandbox)

• Extensible in the policy. Your own functions and rules, connections to your app and APIs, and capabilities your app, services, and AI agents can run, all in the sandbox. (Extend Limitr, Capabilities)

• Made for AI coding agents. The npm package ships skills (the policy reference, every engine function and event, and the SDK) so a coding agent can write and review policies and integrations correctly. (Introduction)

• Rules and contract terms. Versioned rules in the policy change what a plan gives, a limit, or a price for one customer or a segment, for a period; Limitr Cloud assigns them as contracts with renewals, fees, commitments, and price step-ups as phases. Subscription entitlements bill on increment and prorate a mid-period plan change. (Custom deals)

• The Network module. An optional module that lets one policy use another's services and pay for them: a provider publishes plans and routes from its policy, a consumer connects with a signed voucher, and every request and receipt is signed. Loaded only by policies that use it. (Limitr Network, the module on GitHub)

What teams use Limitr for

• 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, with shared credit pools and hard ceilings.
• Cut a custom rate for one enterprise customer. An override with an expiry, not a new plan.
• Reprice a single feature, not the whole model. One entitlement changes; nothing else moves.
• Get alerted when a usage threshold is crossed, for trial limits, upsell triggers, and runaway spend.

Other common scenarios:

• Tracking LLM token costs and margin per customer across multiple AI models and vendors.
• Setting per-customer or per-agent AI spend budgets across all vendors, for example capping an AI agent at a fixed dollar amount per month.
• Moving a SaaS product from flat subscriptions to usage-based or hybrid pricing.
• Replacing per-seat billing that drifts out of sync, or SMS and messaging overages reconciled by hand.
• Monetizing an API or MCP server with metered access and credit packs.
• Metering usage in observe mode first to set pricing and limits from real data, before enforcing anything.

What you get

Combine what fits, skip what doesn't.

• No-deploy price changes: change a price or tier live. Nothing to ship.
• Custom deals and overrides: one-off rates, discounts, and rules per customer.
• Any customer type: orgs, users, agents, and workflows, governed the same way.
• Live alerting: notified the moment a limit or anomaly hits.
• Credit top-ups: customers buy more before they run out.
• Headless, any UI: plans, limits, and usage as JSON for any screen you build.
• Observe before you enforce: meter everything first. Turn on limits when the data says so.
• Extend the runtime: custom logic and units when defaults aren't enough.
• Limitr Analyst, the agent in Limitr Cloud: ask in plain words; review every change before it applies.

Why Limitr: imports like a library, operates like a service

• In your process, under your control (no vendor in the request path). 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.
• A document you own (versioned, diffable, committable). Review pricing like code. Limitr Cloud adds history, instant publish, and one-click rollback.
• Margin, live (cost and price on every credit). Profitability per customer, feature, and vendor, continuously, not once a month at close.

Further properties of the engine:

• Nothing to operate. Limitr Cloud is fully managed, and the engine is a library in your own process, so there's no new service for your team to deploy, version, or fail over.
• Deterministic everywhere. One WebAssembly binary makes the same decision in every front end, back end, and service.
• Works through failure. A decision is a local function call, so enforcement keeps working offline and doesn't inherit someone else's outage.
• Extensible. Rules can be customized and extended with real logic, not just configured. The engine emits events locally and can drive custom behavior such as model switching.
• No lock-in. The runtime and the policy format are open source. You can self-host indefinitely.

"We wanted a config document for all things usage and pricing: something we could just version and commit. That's why we built Limitr. That philosophy doesn't exist in the other products, even when their marketing sounds the same."

CJ Cummings, Co-Founder and CEO

Why teams choose Limitr

Five reasons come up when teams pick Limitr over billing platforms, entitlement tools, or building it themselves.

1. An experienced team, not just a platform

Limitr works alongside your team on the pricing strategy itself, not only the integration: modeling unit economics, structuring enterprise deals and custom contract terms, deciding what to meter and what to charge for, and tuning limits and prices once real usage data comes in. Buying Limitr means getting people who work on usage-based and hybrid pricing every day, in addition to the software that runs it.

2. Flexible monetization, feature by feature

Most features can share a plan. When one needs its own model, it can have one: a single feature can move from flat to usage-based, add credits or an outcome price, or get a custom rate for one customer, without a new plan, a new system, or a deploy. Every pricing model lives in the same policy document, so a change to one feature leaves everything else untouched.

3. Usage intelligence, built in

Limitr Cloud includes live alerting when limits and thresholds are crossed; margin per customer, feature, and vendor; and Limitr Analyst, an agent in the app that drafts pricing changes, simulates them before you publish, and builds dashboards on request. Because every credit carries both cost and price, this intelligence is computed from the same data that enforced each decision, not reconstructed from invoices at month end.

4. Durable in real-world conditions

Enforcement runs inside your application as WebAssembly, so a burst of usage never queues behind a network call. If the connection to Limitr Cloud drops, the engine keeps making decisions locally; how it behaves offline is configurable (keep serving and enforcing against the local policy, or block usage until reconnected), and recorded usage syncs to Limitr Cloud when the connection returns. Periodic outages, usage spikes, and dynamic load don't take your monetization layer down with them.

5. You never outgrow it

The engine and the policy format are open source, and the policy is a document you own. When the built-in behavior isn't enough, you can override the built-in rules, add custom logic, units, events, and thresholds, and wire in your own tooling, while Limitr Cloud continues to track usage, manage customers, and invoice. There is no ceiling where you have to replace Limitr with something custom, and no lock-in if you ever leave.

Limitr Analyst, the agent in Limitr Cloud

Naming: Limitr Analyst on first mention, then "the Analyst". "Agent" is only the lowercase description ("Limitr Analyst, the agent in Limitr Cloud"), never a second name. (Renamed from Dot on Oct 26, 2026, after OpenAI launched Dots.)

Limitr Analyst works inside Limitr Cloud on your real policy, customers, and usage. Ask it in plain words. It tests changes on made-up customers before it says they work, shows you what it found, and nothing changes until you press Apply.

What teams ask the Analyst for:

• Simulate usage: "Simulate a heavy user on Pro for a month." The Analyst runs made-up customers through the draft and reports when each one reaches a limit, what overage it pays, and the margin that's left.
• Add a trial or a plan: "Add a 14-day trial to Pro." The Analyst writes the change into the draft, checks it on made-up customers, and says what it checked. You review it and publish.
• Credits and overrides for one account: "Give Acme 500K more chat tokens a month, until December." The Analyst proposes the change on a card with each value's before and after, for you to apply or discard.
• Margin by customer, with attribution: "Which customers cost us the most to serve last month?" The Analyst breaks down revenue and cost to serve by customer, feature, model, and vendor, and shows it as a view you can save as a dashboard.
• Forecasting (Scale and Enterprise; enhanced on Enterprise): "Forecast our margin through January." Usage, revenue, and margin ahead, with the range they could land in.
• Replay a price change (Scale and Enterprise): "What would last month have looked like at the new Pro price?" The Analyst runs real past usage through the proposed price and shows what each customer would have paid and the margin, before anyone sees it.
• Contract creation (Scale and Enterprise): "Turn Globex's signed order form into their terms," or "Write a contract for Initech from their usage and our margin goal." The Analyst drafts a customer's terms into the policy as their own terms, not a new plan, from a signed order form or from usage, goals, and a forecast, ready to review.
• Build a dashboard: "Show margin by model for our top ten customers." The Analyst builds the view and you save it for the team (saved dashboards on Scale and Enterprise).

The Analyst applies changes only through a card you approve. A change applies as you, with your permissions checked again, and only if nothing it depends on has moved since the Analyst proposed it. History and the event log record it as "Analyst for" your name. The Analyst can't delete customers, charge anyone, change how a customer is billed, or touch API keys, the team, or integrations, and it never sees secrets.

By plan: Free includes $1 of Analyst usage, once, to try it. Pay as you go includes $5 of Analyst usage each month, then passes the Analyst's model cost through at cost plus 20%. Scale includes $50 a month, plus $50 of the largest model for deep work, with saved dashboards, forecasting, and contract creation. Enterprise includes the Analyst's usage in the contract, with the largest model for all deep work and enhanced forecasting. Full details: limitr.dev/guides/cloud/agent.

Limitr Network: let agents buy from your app

Limitr Network is how other apps and AI agents become customers of your app without an API key, an integration, or a contract. It's in early access for a first group of teams and partners on Limitr Cloud; book a call to get in (limitr.dev/network).

• From the provider's side. Turn the Network on in your Cloud workspace and list the plans you already have, publicly or privately to the workspaces you name. A consumer signs a voucher ("this plan, this much, until then"), your policy meters it like any customer with the voucher as a hard cap, and the consumer gets your routes as tools its agents can call. Every request is signed and checked for replay; every response carries a signed receipt, so both sides see the same spend.
• From the consumer's side. limitr.network().connect(url, plan, spend, until) does manifest, voucher, and grant in one call. The provider's routes become ordinary tools in the consumer's agent loop: claudeTools() lists them, and each tool_use is handed to claudeToolUse(), which signs the request, meters it, checks the receipt, and returns the tool_result. A refusal comes back as a result the agent can read, and the consumer can cap each request and hold one budget across many providers.
• Limitr Cloud is the operator. Identity (every provider and consumer is a Cloud workspace, and Cloud vouches for each key), discovery (public and private listings found with signed searches), shared state (one voucher across all of a provider's instances), and payment (a consumer's spend goes on its Cloud invoice; the provider is paid through its connected Stripe after that invoice is paid, less a network fee; test keys never bill).
• An open protocol. The Limitr Network Protocol (LNP) is part of the open-source engine: two policies and HTTP make a working network, and operators are an optional, modular layer with separate roles (state, identity, discovery, payment). For early access both parties are Limitr Cloud workspaces; the protocol keeps the roles separate so the Network can open to other operators and partners later. The spec, wire format with test vectors, and a two-process demo are in the repo: src/network.

Agentic by design: built for coding agents

We think integration should be agentic. Limitr is an open-source engine and usage stack that ships with skills, so a coding agent (Claude Code and others) learns the policy format, the SDK, and the patterns and does the work: it writes the policy from a plain brief and tests it, wires allow() at the call and reserve/settle around the model, builds usage views, plan pickers, and billing settings in your own UI from the policy's JSON, and answers the hard questions (margin per customer, what a price change would do, where a cap should sit) from the engine's own events. In Limitr Cloud, Limitr Analyst answers integration questions too and can write the change for you. Writing the first version was never the hard part; changing it once customers depend on it is, so Limitr checks, tests, and versions every change:

• Validated before it runs. Every policy is checked against the spec as you type in Limitr Cloud, and again when the engine loads it.
• Simulated first. Limitr Analyst runs made-up customers through a draft and shows the bills and margin before you publish.
• Versioned. Every published version is kept; see what changed in each, and go back to any of them.
• Current customers stay whole. Plan changes mid-month are prorated, usage carries over, and every contract keeps its terms.

Limitr Cloud pricing

Free to build. Priced as you grow. Limitr Cloud is priced on the customers and calls it governs, never a share of revenue. Current prices are at limitr.dev/pricing.

	Free	Pay as you go	Scale	Enterprise
Price	$0, no card	$49 a month, plus usage	$499 a month, plus usage	An annual contract
For	Building and testing your pricing before anything is live	Going live: connect your app, publish, and bill your customers	Selling custom deals, self-serve	Volume, procurement, and hands-on help from the Limitr team
Included	The code and no-code policy editor, templates, drafts, validation, and $1 of Analyst usage, once	Everything in Free, plus publishing and version history, SDK keys, customers, segments, notifications, accounts, invoicing and collection with Stripe, credits and refunds, dashboards, and the Analyst with your data and the web	Everything in Pay as you go, plus rules and per-customer prices, contracts (renewals, fees, commitments, recognition) with contract creation by the Analyst, forecasts and replays, saved dashboards, and the largest model for deep work	Everything in Scale, plus usage included by contract, enhanced forecasting (the largest model, a year of history), the largest model for all deep work, direct support on pricing, usage control, and margin, an uptime SLA, and a security review
Usage	None billed	50 active customers, 2,000 calls per active customer, and $5 of Analyst usage included each month; then $0.50 per active customer, $0.02 per 1,000 calls, and the Analyst at cost plus 20%	1,000 active customers, 2,000 calls per active customer, $50 of Analyst usage and $50 of the largest model included each month; then $0.40 per active customer, $0.02 per 1,000 calls, and the Analyst at cost plus 20%	Included by contract, invoiced, never limited

• Active customer: a live customer with at least one governed call in the month. Each counts once, however many calls it makes.
• Governed call: a call your engines meter for a live customer. Checks that meter nothing don't count.
• Test mode: never counts and is never billed.
• Budget alert: pay as you go and Scale email you at 80% and 100% of a monthly budget you set ($1,000 to start, $5,000 on Scale). Nothing pauses.
• Price changes: any change comes with 30 days' notice and never applies to a month already used.
• When Scale costs less: past about 950 active customers, or as soon as you sell custom deals.
• When Enterprise costs less: past roughly $1,700 a month on Scale (around 4,000 active customers at typical call volumes), or when you want usage included, an annual invoice, and our team.

The team and the technology

CJ Cummings, Co-Founder and CEO, is the creator of Stof, the open-source data runtime Limitr's engine is built on, which he has developed since 2024. Before Limitr he was a software architect in Siemens R&D, where he led WebAssembly adoption across the FIN Framework smart-building and IoT platform. Earlier roles: distributed systems at Lockheed Martin, including work on space programs; 3D graphics, rendering, and parametric modeling formats at Anark; and solid modeling, rendering, and animation at Configura. That background in portable, executable data formats is where Limitr's architecture comes from.

Amelia Wampler is Limitr's Co-Founder and COO.

Stof (stof.dev) is a superset of JSON in which documents carry their own executable logic, in a sandboxed, portable format. The runtime is written in Rust and compiled to WebAssembly, so the same document runs identically in a browser, on a server, or at the edge. Its design draws on parametric graphics formats, solid modeling, and scene graphs: data structures that describe behavior, not just values.

This is why a Limitr policy can be a real program instead of a configuration screen. Most pricing and billing tools store settings in their own service and run the logic there. A Limitr policy is a portable document with its own logic, validated by the runtime that executes it, which is what makes it versionable like code, executable in-process, and independent of any one vendor, including Limitr.

How Limitr compares to other tools

Limitr is evaluated alongside billing platforms, enterprise quote-to-cash suites, entitlement and credit platforms, AI cost tools, and building in-house. The useful comparison is by the kind of solution, not feature by feature: who owns the decisions, how the cost grows, where contracts are enforced, who can iterate on pricing and how safely, and what happens if you leave. The full guide, checked November 2026: Usage-based billing platforms in 2026: why your pricing should belong to you.

The market consolidated in 2025 and 2026. Stripe owns Metronome (closed January 2026), Adyen owns Orb (closed July 2026), Salesforce owns m3ter (closed July 2026), Kong owns OpenMeter (now Konnect Metering & Billing), and Zuora was taken private by Silver Lake and GIC. Independent options include Chargebee, Lago, Flexprice, Stigg, Schematic, Paid, Amberflo, and Limitr.

On revenue share. Several platforms price on billing volume, including Stripe Billing, Metronome, Orb, Chargebee, and Flexprice. Stigg and Schematic charge flat platform tiers, Zuora and m3ter are contract-priced, and Lago and OpenMeter can be self-hosted. Limitr Cloud is priced on the customers and calls it governs, never on what you bill.

Billing and invoicing platforms

• Stripe Billing and Metronome. Stripe calls Metronome its primary usage-based billing platform: metering, rating, and enterprise contracts, with Stripe's payments, tax, and revenue recognition. Usage goes to the hosted service, and alerts reach your app by webhook. Best when you want metering, invoicing, and payments from one provider at very high volume.
• Orb (Adyen). Hosted billing computed from raw usage, with re-rating, enterprise contracts, contract-PDF ingestion, and simulations that replay past usage under proposed prices. Best when invoicing accuracy across complex, high-volume contracts is the core problem.
• Chargebee. Mature subscription and recurring billing with usage, credits, CPQ, revenue recognition, and a credit-hold API. Best when subscriptions, dunning, and finance workflows matter as much as usage.
• Lago. Open-source (AGPLv3) metering and billing, self-hosted or cloud, with entitlements, wallets, commitments, and forecasting. Best when you want open-source billing you run yourself.
• Flexprice. Open-source (AGPLv3) usage billing for AI and API companies, with cost sheets and on-premises deployment; early-stage.
• OpenMeter (Kong). Open-source (Apache 2.0) metering, sold as Kong Konnect Metering & Billing, with entitlement enforcement at the Kong gateway. Best when you already run Kong.

Enterprise quote-to-cash

• Zuora. The deepest enterprise quote-to-cash suite: CPQ, flexible commitments, revenue recognition, and AI agents including a pricing simulator; enforcement happens in your systems.
• m3ter (Salesforce). Metering and rating in front of your CRM and ERP, moving into Salesforce Agentforce Revenue Management. Best when Salesforce is the center of your revenue process.

Entitlement and credit platforms

• Stigg. Plans, entitlements, credits, and budgets, checked through a cached sidecar next to your app, with billing, CRM, and CPQ integrations; contract management in beta. Best when you need entitlements in the product quickly and already have billing.
• Schematic. Credit-based pricing, plans, and entitlements with strong developer experience. Its SDKs check flags against its API with a short local cache by default, and an opt-in mode evaluates flag and credit checks locally while usage is processed on its servers; its billing product is in early access. Best when you want credits and entitlements live fast.

AI cost and margin

• Paid. Cost tracking, margin, and outcome-based billing for AI agents. Best when you sell agents and proving value per outcome is the main need.
• Amberflo. AI cost attribution and billing, with a gateway in your VPC and customer-level cost and margin.

AI gateways, rate limiters, and feature flags

AI gateways and routers (OpenRouter, Portkey, LiteLLM) route model calls; Limitr doesn't make or route LLM requests, and the two run side by side. Rate limiters and API gateways throttle requests; Limitr's limits are commercial, tied to plans, prices, credits, contracts, and billing, and can be soft as well as hard. Feature flag tools handle rollouts; Limitr's flags are part of the same policy that prices and limits usage.

Where Limitr is different

Limitr is the engine you own, not a system you send your pricing to. The whole policy, including prices, vendor costs and overhead, limits, contract terms, and the running state of each task, runs in your process, and usage is counted in the same step as the decision. You can override built-in rules and add your own logic, so it fits your business as it grows. Limitr Cloud keeps every engine in sync with your team, enforces contracts in the product on the customer's next call, and shows live margin by customer, feature, and vendor. Limitr Analyst lets finance, revenue operations, and product simulate and forecast a change before it ships. Limitr never takes a share of your revenue, and if you leave Limitr Cloud, the policy keeps running on the open-source engine.

When to choose something else: if you need tax, revenue recognition, dunning, and payments in one vendor today (Stripe with Metronome, Chargebee, or Zuora; Limitr bills through Stripe or your own rails and can sit alongside them); if your pricing is simple and stable and you only need to invoice it; or if you only need feature flags.

Building it in-house

If a pricing model is static and hardcoding it is fine, building in-house is reasonable. Most models don't stay static. Splitting billing across products, discounting one specific tool call, burning down credits differently across accounts, running different budgets per model in the same pipeline, handling mid-period upgrades without double-charging, and rolling out tiers without a deploy add up to a permanent engineering surface. A coding agent makes the first version quick; the changes after it are the lasting work, and they come either way. Limitr is built for those changes, and because Limitr's engine is open source, adopting it doesn't mean betting pricing infrastructure on a vendor's roadmap.

Limitr Cloud and the open-source engine

Limitr Cloud is the product most teams buy: the managed platform for running pricing, contracts, billing, and margin. The open-source engine is the same enforcement core, offered free for teams that want to evaluate before talking to anyone, run fully offline, or manage the policy themselves.

	Limitr Cloud	Open-source engine
Enforcement	In-process in your app, pushed and kept in sync by Limitr Cloud	In-process, local, offline-capable; same API
Policy	Hosted editor, versioning, one-click rollback, instant publish to every engine	A file you manage and commit
Customers and contracts	Customer state, segments, rules, and per-customer overrides	Managed in your app
Usage	Streamed to a managed ledger	Recorded locally
Billing	Invoicing, Stripe built in, Maxio, Chargebee, ACH	Your own
Analytics	Live margin per customer, feature, and vendor; alerting; Limitr Analyst	Your own
Operations	Fully managed	Self-hosted
Cost	Free to start, pay as you go, or Enterprise by contract	Free, permanently

Moving from the open-source engine to Limitr Cloud is a one-line change (Limitr.new(...) to Limitr.cloud({ token })), and moving back is the same.

Key concepts

• Policy: the versioned document that defines everything: credits, plans, entitlements, limits, rules, and overrides.
• Credit: a priced unit, independent of any plan. A credit carries what the unit costs you and what you charge. Changing a credit's price updates every plan that references it.
• Entitlement: lives inside a plan and references a credit, saying how much of it the plan includes and how it's enforced (limit, mode, reset).
• Limit modes: hard (block at the cap), soft (allow and optionally bill overage), observe (track only).
• Customer: any object you meter: an org, workspace, user, agent, project, or workflow. Customers can reference each other, so shared meters resolve at the right level and group invoices roll up.
• Override: a customer-specific change to one entitlement or price, optionally with an expiry, without changing the plan.
• Spend cap: a budget across calls, entitlements, and credits, in any currency, per customer or shared across an org. Caps only restrict.
• Feature rule: an optional rule on an entitlement that decides per call whether it's on: a kill switch, a percentage rollout, or a condition on the request. Rules only narrow what a plan gives.
• Give and take: a per-customer change to whether a customer has an entitlement, using a plan's definition of it, optionally with an expiry.
• Reservation: room held for a call before it runs, settled with the real usage after. The engine predicts how much to hold.
• Cost function: a function on a credit that prices one call's cost from the call's data, such as tokens per model.
• Stof: the engine's native document format (JSON plus functions). JSON, YAML, and TOML are fully supported; Stof is only needed when a policy has to compute something, like a custom formula or conditional discount.

Frequently asked questions

Start here

What is Limitr Network?

A way for other apps and AI agents to buy from your app under the policy you already have. You list your plans from Limitr Cloud; a buyer connects with a signed voucher instead of an API key; your policy meters it like any customer; the spend lands on the buyer's Cloud invoice and you're paid out through Stripe. It's in early access for a first group of teams and partners on Limitr Cloud, by request, and the protocol is open source. See limitr.dev/network.

How is Limitr different from other billing platforms?

Most billing platforms record what happened and charge for it afterwards: invoices, payments, subscriptions, revenue recognition. They see usage one event at a time, on their own servers, and your pricing lives in their system, often priced on a share of what you bill.

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. The engine is open source and the policy is a document you keep, so your pricing is yours.

Limitr meters, invoices, and collects too, through Stripe or your own rails, and it never takes a share of your revenue. If you already run invoicing you're happy with, keep it for collecting money and let Limitr decide what each customer gets, what it costs you, and what you charge, enforced live.

Isn't it risky to put Limitr in-line with every request?

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.

Why does Limitr decide inside my product instead of in a hosted service?

Because that is where the context is. One task in your product can be dozens of calls across models, tools, and vendors, and its cost, its margin, and whether it should keep running depend on all of those calls together, plus who the customer is and what the run has spent so far. A hosted billing or entitlement service sees each call as a separate event without that context. The Limitr engine runs in your product's own process, so it limits and prices the task with the whole picture as it runs, and Limitr Cloud manages the rules, billing, and analytics around it.

I just want to control usage. Do I also have to monetize it?

No. Limiting access and charging for usage are separate decisions your policy can make independently. Most teams start by just watching usage, since you can't control what you can't see, then add limits, and monetize only the parts that make sense.

The usage you charge for doesn't have to be the same usage you control. Most teams layer a few entitlements together to get the pricing and access model they actually want (for example, control tokens, but charge only for successful runs).

Can Limitr actually handle our pricing model, whatever it is?

Yes: usage-based, seat-based, hybrid, credits, trials, rollovers, custom enterprise deals. One policy format expresses all of it, so if you can describe the model, you can ship it without rebuilding your billing logic for the next one. Pricing models keep changing; the format doesn't have to.

Is Limitr only for AI companies?

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 Limitr's customers split roughly evenly. Some are metering multi-model AI pipelines. Others are 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.

Does Limitr just track usage, or does it actually enforce and bill it?

All three. Plenty of tools will tell you what your customers consumed after the fact. Limitr enforces the limit at the moment of consumption, meters usage in that same atomic operation, and feeds the result straight into invoicing.

Limits run in three modes, switchable without a code change: hard blocks the action at the cap, soft allows the overage and optionally bills on it, and observe tracks everything while enforcing nothing. Most teams start in observe, learn what their usage actually looks like, then turn on enforcement once the data supports the decision.

For engineering

Will this add latency to my product?

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.

How much code is this, and what languages do you support?

The integration surface is deliberately small. You call ensureCustomer at login or first touch, then policy.allow at the point of consumption with an entitlement name and an amount. That's the core of it.

Engineering wires up the entitlement by name and passes in usage quantities (optionally gating access, too). Everything behind that name, including limits, prices, tiers, and per-customer overrides, is configuration that changes without touching your code.

The SDKs are each a thin wrapper over the same core WebAssembly module, so additional languages take days rather than quarters to support. TypeScript/JavaScript is the most supported today.

Is Limitr a headless billing engine? Do you provide UI components?

Yes, Limitr is headless in your product. It doesn't ship a catalog of pre-built UI. Plans, limits, and each customer's usage are available inside your product as plain JSON, so usage meters, upgrade prompts, and pricing pages are your own components, built by hand or with an AI coding tool, and they always match what the engine enforces. You decide what reaches the browser. Your team's side is not headless: Limitr Cloud handles editing, publishing, customer storage, billing, and margin.

Is Limitr like an AI router?

Dynamic model switching is a core part of AI usage control, and Limitr supports it. Limitr also puts prices on usage, so you can track and control margin-to-serve in the ways that matter, not just an aggregate cost-to-serve that leaves blind spots.

Limitr does not make LLM requests on your behalf, switch models for you, or repackage specific vendor tokens. It doesn't sit in the request path routing calls; it provides a control plane around them, whichever vendor or router they go through. Limitr works with any AI vendor, including alongside a router.

If you're looking for spend management and margin control, Limitr covers it on its own. If you also want a unified endpoint, model routing, and other AI-specific guardrails, a router can run alongside it.

What happens if the connection drops, or if something gets counted wrong?

On disconnect, the runtime reconnects automatically. While it is disconnected, you choose what happens: keep enforcing the local policy as normal, or deny usage until it is back online (the default, which keeps customer state consistent across your servers). The choice is one SDK option (denyUnconnected), and either way decisions are made in-process, without waiting on the network.

The open-source engine also runs fully offline against a local policy file, so you can serve users in low- or no-connectivity regions, or keep a separate offline or backup usage policy for failure and testing modes.

For bad data, meters move in both directions. If a runaway process inflates a counter, decrement it through the SDK or set the value directly in the dashboard. Counting happens locally and serializes to the server, where operations are atomic, so usage isn't double-counted.

Does the engine actually work offline, or does it just cache the last known policy?

It works offline in the literal sense. The runtime evaluates your policy locally and doesn't need to reach Limitr's servers to make a pricing or access decision; that's how every call is evaluated, connected or not. The open-source engine needs no connection at all. With Limitr Cloud, you choose whether a disconnected engine keeps enforcing the local policy or denies usage until it reconnects (above), and usage recorded locally syncs back to Limitr Cloud once connectivity is available.

How does the open-source engine relate to Limitr Cloud?

Same core. The open-source enforcement engine runs in-process, is fully self-hostable, and is free permanently. Limitr Cloud adds the managed policy dashboard, versioning and instant rollback, per-customer analytics and margin data, usage-based invoicing, live alerting, and the Stripe and billing integrations.

The enforcement API is identical either way, so moving from local to Cloud is a one-line change. You can prototype against the open-source engine without talking to Limitr first.

Does Limitr work with AI coding agents?

Yes. The npm package ships two skills in node_modules/@formata/limitr/skill/: one covers the policy format, every engine function, and every event, and the other covers the TypeScript SDK. The Stof language skill ships with Stof, in node_modules/@formata/stof/skill/stof/. A coding agent pointed at them writes and reviews policies and integrations against the real spec instead of guessing. These docs are also published for agents at limitr.dev/llms.txt.

Can Limitr predict usage before a call runs?

Yes. The engine learns how big calls are from the calls you already make, per model or kind of call, and predicts the next one from its input. It uses that to decide how much room to hold for a call before it runs, and you can ask for a prediction directly, for example to set max_tokens or quote a price before an AI call.

Does the policy-as-config have validation?

Yes. The open-source runtime, built on Stof, contains validation rules and validates the policy itself, so you never run an invalid policy. In the npm package, Limitr.new(...) calls validate by default and throws an error that points to where the problem is if the policy doesn't fit the spec. In Limitr Cloud, the policy is fully managed and always validated when changes are made, before it's used in your app or service.

What's the difference between a credit and an entitlement?

A credit defines a price: what a unit costs, independent of any plan. An entitlement lives inside a plan and references a credit to say how much of it that plan includes and how it's enforced (limit, mode, reset). Splitting them apart means changing a price once updates every plan that references it.

Can I extend or override the policy logic, or is it fixed to what Limitr ships?

You can extend it. A policy isn't limited to the primitives Limitr ships out of the box; it's built to be extended and overridden for whatever your product needs, which is the point of a real engine rather than a fixed set of billing rules. A policy can carry your own functions and rules, call your app, load data from your APIs, and expose named capabilities that your app, your services, and AI agents can run, all in the engine's sandbox. (Extend Limitr)

What is Stof, and do I have to use it?

Stof is the engine's native format. JSON, YAML, and TOML are fully supported, and you don't need Stof for a typical plan. Stof earns its place when a policy needs logic: real functions inside the document for pricing or limits that can't be expressed as static numbers, such as a custom formula, a conditional discount, or a computed tier.

What data leaves our environment?

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 Limitr Cloud customers with GDPR or similar obligations, Limitr can put a Data Processing Addendum in place.

For finance and product

Can non-engineers change limits and prices without a deploy?

Yes, and it's the main reason teams buy Limitr. 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 pull request, 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 add or take off a percentage or a flat amount, with an end date for a temporary deal. Sales can structure a custom deal without engineering in the loop.

Every change is versioned with full history and reverts instantly.

Can't we just build this ourselves?

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. Almost nobody's model stays static, and once you dive in, this 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, burn down 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.

With a coding agent, a first version is fast either way, so Limitr doesn'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 enforcement engine is open source, you aren't betting your pricing infrastructure on Limitr's roadmap.

Our setup is complicated: multiple products, orgs and users, several vendors. And we haven't finalized our model yet. Is it too early?

Complexity is the use case. Customer objects are arbitrary: an org, a workspace, a user, an agent, a project, whatever you need to meter. They reference each other, so a shared meter like seats resolves to the right level automatically, and group invoices roll up from individual ones. Credits carry both what you pay a vendor and what you charge, per model and per vendor, so margin resolves per customer, per feature, and per provider without extra instrumentation.

It's not too early. Observe mode exists for exactly this: meter everything, enforce nothing, and set your allotments from real data instead of a guess. Implement in stages, when and how it makes the most sense for your products.

Can I see margin, not just usage?

Yes. Margin is a first-class output, not something reconstructed after invoices close. Because Limitr already knows what a call costs you and what you charge for it, it shows profitability per customer, per feature, and per vendor continuously, not once a month at close. The same policy that enforces limits live also prices your unit economics live.

How is Limitr priced?

The open-source engine is free, permanently. Limitr Cloud has four plans. Free is for building and testing a policy in the app (the editor, drafts, validation, and $1 of Analyst usage to try it, once, which covers the Analyst writing the policy and testing it on made-up customers), with no card. Pay as you go adds publishing, SDK keys, customers, notifications, dashboards, and the Analyst with usage included: $49 a month with 50 active customers and 2,000 calls per active customer included, then $0.50 per active customer and $0.02 per 1,000 calls, billed monthly to a card. It's never a share of revenue. Scale adds custom deals for your own customers (rules, per-customer prices, and contracts with renewals, fees, and commitments), forecasts and replays, saved dashboards, and the largest model for deep work: $499 a month with 1,000 active customers included, then $0.40 each, self-serve. Enterprise is a contract: usage included, enhanced forecasting, the Analyst on the largest model for all deep work, and direct support from the Limitr team. Current prices: limitr.dev/pricing.

What happens if we stop using Limitr?

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 Limitr 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.

Get started

Turn usage into decisions, not just invoices.

• Book a demo: calendly.com/d/ctjd-5gm-qqc/limitr-demo-with-founders
• Start free in Limitr Cloud: cloud.limitr.dev
• See pricing: limitr.dev/pricing
• Read the quickstart: write a policy and make your first call in about five minutes: limitr.dev/docs/quickstart
• Try it in your browser: see the engine evaluate a real policy live, as WebAssembly, with nothing to install: limitr.dev/docs/demo
• Limitr Cloud quickstart: limitr.dev/guides/cloud/quickstart
• Limitr Network early access: limitr.dev/network, then book a call at the link above
• Source code: github.com/dev-formata-io/limitr (npm: @formata/limitr)