Skip to main content

Welcome to Limitr

The control plane for usage-based software.

Limitr is the intersection between what your product delivers and what your business captures. You define your pricing model once — in a policy document, not in code. Limitr enforces limits at the point of consumption, meters usage in the same operation, and feeds margin data back to your team in real time.

Every limit enforced. Every customer tracked. Every deal profitable.

When pricing needs to change, it changes in one place where everyone understands it, and gets enforced everywhere, instantly. No PR. No deploy. No coordination.

How it works​

A Limitr policy is a document — created in Cloud or written in YAML, JSON, or Stof — that describes your entire pricing structure: plans, entitlements, credits, exchange rates, reset schedules, real-time notifications, invoicing, and overage behavior.

The event-driven policy runs locally inside your application via WebAssembly. There is no remote enforcement API. Every allow(), increment(), and check() executes in-process, in microseconds — before cost is incurred, and before any network call is made.

// Enforce a limit
if (await policy.increment('org_123', 'seats')) {
  await db.addMember(userId, orgId);
}

// Track AI usage against a monthly allowance
if (await policy.allow('user_456', 'ai_tokens', estimatedTokens)) {
  const response = await callLLM(prompt);
}

// Gate a feature
const canExport = await policy.check('user_789', 'pdf_export');

One check. Limits enforced. Usage metered. Margins visible.

How it's different​

Limitr was built to provide accuracy, clarity, and fine-grained control for usage-based software within scaling organizations, across the entire business.

Instead of a large, shared, remote API that lives in someone else's system, your Limitr policy is uniquely yours, enforces usage limits inside your app, and is easy to maintain, audit, or change for the entire team.

Limitr is different:

  • Runs inside your app. Policies execute in WebAssembly, colocated with your application. Enforcement is microseconds, not milliseconds. No network dependency on the hot path, even with Cloud.
  • The policy is a document. Version it, ship it with self-hosted deployments, load it from a database, or send it over the wire. Your pricing model is yours.
  • COGS mapped to delivery. Credits connect what you deliver to what it costs. A discrete credit carries both overhead cost (what you pay your provider per unit) and what you charge. Credits can be mapped into one another via the exchange table and can be as abstract as you and your users need.
  • Margin-aware by design. Because your costs and prices are defined in the same policy that drives enforcement, Limitr knows exactly what each customer's consumption costs and what it generates in revenue — per entitlement, per credit, per billing period, in real time.
  • Live alerting. Define alert conditions against any dimension of your policy — customer, plan, entitlement, usage — and react to them in your product or route them to your team via email or Slack.

Stripe knows: "User paid for Pro."
Limitr knows: "User can add 6 more seats, use 1.2M more tokens, and export ∞ PDFs — here's what they're costing you in real time, and you'll be emailed when they cross 90% token utilization."

Where to start​

If you're new, start here:

Quick Start →
Get enforcement running in your app in under 10 minutes.

Concepts →
Understand credits, entitlements, plans, and how they compose into a policy. Worth reading before you design your pricing model.

Policy Reference →
The full reference for every field in a policy document — credits, exchange, plans, entitlements, limits, margin, notifications.

Cookbook →
Working patterns for common scenarios: AI token metering, seat-based SaaS, API call limits, storage, time-based usage.

Limitr Cloud →
Connect to the managed platform. Managed policies, per-customer analytics, Stripe integration, live alerting — same enforcement engine, one-line SDK swap.

The enforcement API​

Limitr exposes a deliberate, minimal API surface that covers even the most complex usage-based billing scenarios:

// allow — consume `amount` if within limit. Returns true/false.
await policy.allow('user_123', 'ai_tokens', 4200);

// increment — consume one unit. Returns true/false.
await policy.increment('user_123', 'seats');

// decrement — release one unit.
await policy.decrement('user_123', 'seats');

// check — read-only. Does not consume. Returns true/false.
await policy.check('user_123', 'pdf_export');

// remaining — how much is left, including grants.
await policy.remaining('user_123', 'ai_tokens');

// value — how much has been used, raw or as a percentage.
await policy.value('user_123', 'ai_tokens');

// customerMarginSnapshot — revenue, cost, and margin for one customer.
await policy.customerMarginSnapshot('user_123');
// → { revenue: 87.20, cost: 38.30, margin: 48.90 }

Units are respected throughout. If you define mb_storage with stof_units: MB, you can pass 500MB, 1GB, or '2000000bytes' — Limitr converts.

Local and Cloud​

Limitr ships as two things that share the same core:

Open source enforcement engine — runs entirely in-process via WebAssembly. No network calls, no external dependencies. Define a policy in YAML, JSON, or Stof and load it directly.

const policy = await Limitr.new(policyDoc);

Limitr Cloud — same enforcement engine, managed platform. Your policy lives in the Cloud dashboard, versioned, auditable, editable without a redeploy. Adds per-customer analytics, Stripe integration, usage-based invoicing, real-time alerting, and Limitr Network.

const policy = await Limitr.cloud({ token: 'limitr_...' });

The enforcement API is identical. Start local, move to Cloud when you're ready — it's a one-line change.

Resources​

  • GitHub — source, issues, and contributions
  • Discord — questions and community
  • Stof — the open-source data runtime powering the policy engine
  • Limitr Cloud — the managed platform
  • Book a demo — talk to us directly