Limitr

Usage-based billing, limits, and feature flags that run inside your app.

Limitr is an open-source engine for usage-based pricing. It meters usage (API calls, AI tokens, seats, storage, anything you count), enforces plans and limits, prices every call, and tells your code what to bill. One policy holds all of it, and the engine that runs it lives in your process, in Node, Bun, Deno, or the browser, with no service to run and no network call in the middle of a request.

This is the real engine, running in your browser:

policy: {
    credits: {
        ai_token: {
            label: 'AI token'
            price: { amount: 0.00002 }      // you charge $20 per million tokens
            overhead_cost: 0.000008         // the model costs you $8 per million
        }
    }
    plans: {
        pro: {
            default: true
            entitlements: {
                export_pdf: {}                                  // a feature flag
                chat: { limit: { credit: 'ai_token', mode: 'soft', value: 100_000, resets: true, reset_sch: 'monthly:1' } }
            }
        }
    }
}

first-look.stof

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

const limitr = await Limitr.new(policy);
await limitr.ensureCustomer('ada');

limitr.addHandler('billing', (name, value) => {
    if (name !== 'meter-overage') return;
    const event = JSON.parse(value as string);
    console.log(`  bill ada $${event.overage_price} for ${event.overage} tokens (the call cost you $${event.meter.overhead_diff})`);
});

console.log('export a PDF:', await limitr.allow('ada', 'export_pdf'));
console.log('use SSO:', await limitr.allow('ada', 'sso'));

console.log('80k tokens:', await limitr.allow('ada', 'chat', 80_000));
console.log('40k more:', await limitr.allow('ada', 'chat', 40_000));
console.log('used this month:', await limitr.value('ada', 'chat'));

Output

That's a plan with a feature flag and a monthly AI token allowance: the first 100,000 tokens are included, and the rest are billed, with the margin of every call known as it happens. The Stof tab is what runs here; the TypeScript tab is the same program with the SDK.

Why it's different

Most usage-based billing is a metering API, a billing provider, and a lot of code in your app deciding what's allowed. The rules spread across services, every check is a network call, and changing a price means changing code in several places. Limitr works differently:

• It runs in your process. The engine is a small WebAssembly runtime inside your app. Checking a limit and recording usage happens in-process, with nothing to call and nothing to fall over.
• Pricing is one document. Plans, limits, credits, prices, costs, caps, feature rules, and top-ups live in one policy you can read, review, diff, and commit, in JSON, YAML, TOML, or Stof. Change the policy and every check follows it.
• Margin is known on every call. The policy knows what you charge and what each call costs you, even when the cost changes per call, like an AI model priced by input and output tokens. Every event carries both.
• It decides before the work runs. Allowed or not, how much room is left, what the call is worth. For AI calls whose size you only know afterwards, it reserves room up front and predicts how big the call will be.
• It grows with you. When pricing needs a rule that data can't express, the policy carries the code: your own functions, feature rules, cost functions, and connections to your app and APIs, all running in a sandbox. See Extend Limitr.

What you can build with it

• Any pricing model in one policy: usage-based, seats, credits, flat plans, or a hybrid, per plan and per feature. See Map your pricing.
• AI features that stay profitable: per-model costs, per-call margins, usage predicted before the call, and spend caps.
• Feature flags and rollouts: kill switches, percentage rollouts, and rules per call, next to the plans, with events to measure them.
• Custom deals: give one customer a feature their plan doesn't have, take one away, or change their limits, with expiry.
• Prepaid credits: credit packs with expiry, resets, and rollover, spent across features at their own rates.
• Org budgets and seats: seats and budgets shared by every user in a team or org.
• Rate limits next to paid usage: protect your infrastructure without touching what customers pay for.
• Billing events: overage, limits hit, and thresholds crossed, sent to your code as they happen. See Bill from events.
• Your own rules and tools: functions and capabilities in the policy that your app, your services, and AI agents can run, including ones that load data from your APIs.

Made for AI coding agents

The npm package ships two skills in node_modules/@formata/limitr/skill/:

• limitr: the policy reference, every engine function, and every event.
• limitr-ts: the TypeScript SDK.

Point your coding agent at them and it can write, review, and debug policies and integrations correctly, instead of guessing. They're also packaged as zips in the repo's content/ folder for uploading to an agent, and this whole site is available to agents at /llms.txt.

Open source and Limitr Cloud

These docs cover the open-source engine and integrating it. The engine is open source (Apache 2.0) and free to run on your own: keep the policy in your repo, save customer state in your database, and bill from the events.

Limitr Cloud runs the same engine with the parts around it: versioned policies you edit and publish to every running server without a deploy, shared customer state, ledgers and invoicing, and usage, cost, and margin analytics across your customers. Moving to Cloud is one line, Limitr.cloud({ token }) instead of Limitr.new(policy), and every check still runs in your process. User guides for the Cloud app are under Guides.

Where to start

• Quickstart: install, write a policy, and gate your first call, in a few minutes.
• How Limitr works: the pieces of a policy and how a call is decided.
• Tutorial: 15 short chapters, each one a program you can run, from a first policy to AI calls, org budgets, and feature flags.
• How-to guides: recipes for common pricing problems.
• Reference: every policy field, engine function, SDK method, and event.
• Live demo: watch the engine allow, deny, and price usage as you change the policy.

Where the engine comes from

CJ Cummings, co-founder and CEO

Before Limitr, we were building an AI product that was usage-heavy, and monetizing it became a real limiting factor in our ability to become profitable and ship features at the pace our market demanded.

Nothing on the market gave us the fine-grained visibility and control that AI and modern usage-based pricing actually need, and every pricing change came with a growing product and engineering overhead.

The vision I had was a config document to define packaging, prices, credits, token limits, overhead costs, and everything that's needed for reasonable and dynamic decisions about what every user and agent can do, how much usage they get at every moment, and what it should cost them (and us). Easy to reason about, and quick to change.

I'd already built Stof (the runtime under Limitr) for a different reason, a smart AI context layer, out of a background in graphics, parametric file formats, and language runtimes. It enables us to put usage control logic directly into each config, and sandbox it to the local config that contains it. Customer state and all of the rules that dictate it are isolated, local, extensible, and yours, forever.

Many iterations and projects later, that pricing-as-config is what became Limitr. And it's the single config that enables us and all of our users to monetize, control, and analyze usage across every product and customer.

The vision has expanded, but our mission remains the same: to provide flexible, reliable, and secure usage infrastructure for profitable software products, the teams behind those products, and the users of those products.

If this resonates, book a call. I'd love to hear how it's going for you.