Skip to main content

Limitr: the monetization layer for usage-based billing

Limitr is the monetization layer for usage-based billing. Its product, Limitr Cloud, is a managed platform where product, finance, and sales teams run pricing: plans, entitlements, limits, customer contracts and overrides, a usage ledger, invoicing, collection through Stripe or your own payment rails, and live margin per customer, feature, and vendor. Limitr Cloud manages all of that as one versioned policy document and pushes every change to the Limitr engine, which runs inside your application, in-process as WebAssembly, and prices, gates, and meters every unit of usage in real time with no network call on the decision path. The result is that pricing, limits, custom contracts, and unit economics are enforced at the moment of consumption, not reconstructed after the invoice. The engine itself is open source, so the same policy can also run self-hosted.

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.

Limitr at a glance​

  • What it is: a managed monetization platform for usage-based software (Limitr Cloud), built on an engine that runs inside your app. One policy defines plans, entitlements, prices, limits, overrides, and rules; Limitr Cloud manages it and the engine enforces it locally on every call.
  • Who it's for: product, engineering, and finance teams at software companies with usage-based, hybrid, credit-based, outcome-based, or custom-contract pricing, especially where pricing changes often or varies by customer.
  • 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 in microseconds, 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 contracted annually or on custom terms.
  • 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. Managed in the cloud, decided in your app. Limitr Cloud is a fully managed service, but the decision path isn't a call to it. The engine runs in your process as WebAssembly, with no network hop on the decision path, not even to a local sidecar, while Limitr Cloud pushes policy down and receives usage in the background. You get a managed platform without a remote dependency in your hot path: decisions take microseconds, keep working offline, and are identical in every front end, back end, and service because they run the same binary.
  2. One document you own. Pricing, entitlements, limits, credits, vendor costs, customer contract terms, and real logic live in one versioned policy document (JSON, YAML, TOML, or Stof) instead of vendor configuration or application code. Limitr Cloud is to that document what GitHub is to git: history, diffs, one-click rollback, and instant publish to every running engine without a deploy.
  3. Decides before the cost is incurred. Checking the entitlement, applying the price, and recording the usage happen in one atomic operation at the moment of consumption. A limit holds before you pay a vendor for the tokens, not after the invoice shows it.
  4. Prices the whole run, not the single call. An agent task or AI outcome is dozens of calls across models, tools, and retries. Because Limitr holds running state in-process and converts raw usage through a credit exchange, it can price and limit the unit you actually sell (an outcome, a run, a dollar budget, a credit) live and across vendors. A per-event billing API sees each call alone.
  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. Usage intelligence isn't a report reconstructed from last month's invoices; it's 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 logic never depends on a vendor's roadmap and leaving means keeping the document and running it yourself.

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. Payments, billing, metering, and model routing are converging under one vendor, one that earns 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 problem: every price change is a release​

Model costs, usage mix, and contract terms shift constantly, so pricing for usage-based products needs constant adjusting. In most companies that pricing logic is spread across the front end, the back end, and the billing system. Every adjustment, whether a new tier, a changed limit, a discount for one customer, or a new AI model with a different cost, means changing all of them together and shipping a release.

The same pattern shows up in several ways:

  • Pricing is hardcoded. Limits and prices live in application code, so product and finance teams can't change them without an engineering ticket.
  • Enforcement happens after the fact. A billing system records usage and charges for it later. By the time anything reacts, the cost of an expensive call, 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.

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: margin is engineered across calls, not billed per call​

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 apply a percentage in either direction, carry an expiry date, and include an approval note. 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.

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 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.
  • Extend the runtime: custom logic and units when defaults aren't enough.

Why Limitr: a monetization layer, not just a billing API​

  • In your process (microseconds, versus 50–100+ ms per remote call). Decisions run locally, even offline. Usage syncs in the background and never blocks the hot path.
  • 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, thresholds, or anomalies are hit; usage and margin forecasting; and AI services that help you navigate pricing changes before you make them. 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 and decisions take microseconds. 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.

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 often evaluated alongside billing platforms, metering tools, real-time usage and entitlement platforms, and AI gateways. It overlaps with some and complements others. The short version: payments processors move money, billing platforms record and invoice, observability tools report, and Limitr decides what's allowed and what it's worth at the moment of use.

Downstream billing and meteringLimitr
Where it runsA hosted service that ingests usage eventsManaged in Limitr Cloud; decisions run in-process in your application as WebAssembly
When it actsAfter usage, when events are aggregated, rated, and invoicedAt the moment of consumption, before the cost is incurred
What it knows per unitWhat you chargeWhat you charge and what it cost you
What it pricesEvents, rated at invoice timeWhole runs and outcomes, live, through runtime state and credit exchange
Where pricing livesConfiguration in the vendor's systemA versioned document you own, with real logic
Access and limitsUsually a separate entitlement systemThe same policy and the same call
Custom contract termsApplied when the invoice is producedApplied on the customer's next call and enforced in the product
If you leaveMigrate data and rebuild configurationKeep the document and run the open-source engine

Usage-based billing and metering platforms​

Examples include Metronome (now part of Stripe), Orb, Lago, m3ter, Amberflo, and OpenMeter. These platforms are built to ingest usage events, aggregate them, rate them, and invoice customers, downstream of the product. Limitr also meters, rates, and invoices usage, but it makes the decision inside the application at the moment of consumption: the same operation checks the entitlement, applies the price, and records the usage. That is what lets a limit hold before the cost is incurred, and what makes live margin and whole-run pricing possible. Teams that already run one of these platforms can keep it as the invoicing target and put Limitr in front of it.

Subscription billing and payments​

Examples include Stripe Billing, Chargebee, Maxio, Zuora, and Recurly. These systems handle subscriptions, invoicing, payments, and revenue workflows. Limitr includes a usage ledger and invoicing, integrates with Stripe out of the box, and works with Maxio, Chargebee, ACH, or your own rails. Teams with an established billing platform can keep it for collecting money and use Limitr as the layer above it that decides what each customer gets, what it costs, and what to charge.

Real-time usage and entitlement platforms​

Examples include Stigg and Schematic. These are the closest tools to Limitr: they manage plans, entitlements, credits, and usage limits and check them in or near the request path, with state synced toward the application for fast reads. Limitr differs in two ways. First, what runs locally: the entire policy (logic, prices, vendor costs, credit exchange, and contract terms) executes in your process, with Limitr Cloud pushing policy updates down and receiving usage in the background, rather than decisions being served by a vendor's service or only a cached slice of state living in the app. Second, what the policy is: a portable, versioned document with executable logic, managed in Limitr Cloud but exportable and runnable on the open-source engine, rather than configuration that only exists inside a vendor's platform. That combination is what lets Limitr price whole runs against live cost and margin, keep working offline, and leave you with your pricing if you leave.

AI gateways and routers​

Examples include OpenRouter, Portkey, and LiteLLM. These sit in the request path to route LLM calls, provide a unified endpoint, and add AI-specific guardrails. Limitr does not make LLM requests or route calls. It provides a control plane around them, whichever vendor or router they go through, for pricing, limits, spend management, and margin. The two can run side by side.

Rate limiters and API gateways​

General-purpose rate limiters and API gateways throttle requests. Limitr's limits are commercial rather than purely technical: they are tied to plans, prices, credits, customer contracts, and billing, and they can be soft (billed as overage) as well as hard.

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. Technical buyers estimate 1–3 engineer-months for a first version, plus indefinite maintenance and separate projects for observability. 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 CloudOpen-source engine
EnforcementIn-process in your app, pushed and kept in sync by Limitr CloudIn-process, local, offline-capable; same API
PolicyHosted editor, versioning, one-click rollback, instant publish to every engineA file you manage and commit
Customers and contractsCustomer state, segments, rules, and per-customer overridesManaged in your app
UsageStreamed to a managed ledgerRecorded locally
BillingInvoicing, Stripe built in, Maxio, Chargebee, ACHYour own
AnalyticsLive margin per customer, feature, and vendor; alertingYour own
OperationsFully managedSelf-hosted
CostAnnual or custom termsFree, 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.
  • 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's the difference between a billing platform and Limitr?

A billing platform records what happened and charges for it after the fact: invoices, payments, subscriptions, revenue recognition. Limitr decides what's allowed before the action executes, and meters it in the same operation.

If enforcement lives downstream of consumption, the cost is already incurred by the time anything reacts. Limitr runs at the moment of consumption, in-process, so a limit holds before you pay a vendor for the tokens rather than after.

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. Limitr integrates with the billing platform and workflow of your choice.

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 microseconds, with no network call on the hot path, compared with the 50 to 100+ milliseconds typical of enforcement systems that make a remote API call per decision.

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 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 tries to reconnect automatically and lets you choose to continue operating normally offline or block all usage until back online (the default, to preserve state). The default is configurable in the SDK, and enforcement never stops working.

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. There's no fallback mode to configure; that's just how a call is evaluated, connected or not. Usage is still recorded locally and syncs back to Limitr Cloud in the background 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 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.

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

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.

The estimates Limitr hears from technical buyers cluster around 1–3 engineer-months for a first version, plus indefinite maintenance and additional internal projects for observability. Limitr's contracts are priced for outsized savings by comparison, 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 is contracted annually or on custom terms, and scoped with you on a call rather than from a public price list, so it fits your model instead of making you fit a tier. To evaluate first, start on the open-source engine; moving to Cloud later is a one-line change.

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.

Last updated on