Welcome

Welcome to the Limitr docs.

This is where you'll find everything needed to integrate Limitr — the policy spec, SDK reference, and materials for both the open-source engine and Limitr Cloud.

If you already know what you're doing, jump straight into the Quickstart or Policy Reference. Otherwise, two minutes here will save you some backtracking later.

Scope of these docs

info

These docs cover the open-source enforcement engine & technical integration — the embedded runtime itself, available on GitHub. If you're looking for the Limitr Cloud web application user guides — the managed dashboard, policy editor, and analytics — that's under Guides, not here.

Integration is the same either way, and you're in the right place for it. The SDK calls you write — allow, check, createCustomer, all of it — don't change based on which one you're using. The only difference is where the policy is defined and where stored customer state lives: self-hosted, that's a file and storage you own; on Cloud, it's fully managed for you. In code, the entire difference comes down to one line — Limitr.new(...) for self-hosted, Limitr.cloud(...) for Cloud. Everything after that call is identical.

Live code examples

Our docs include live code examples — not a screenshot, not a pseudocode sketch. The actual open-source Limitr engine, running live in your browser as WebAssembly, operating just how it will inside your own applications and services.

Limitr engine uses our open-source project, Stof, to make this happen. Here's an example with just Stof to see it run, and what the text format looks like:

hello.stof

welcome: {
    message: 'Hello from Stof'
    hello: ()=>{ pln(self.message + ' — running live, right in your browser.'); }
}

#[main]
fn example() {
    self.welcome.hello();
    let sum = 0;
    for (const i in 5) sum += i;
    pln(`0 + 1 + 2 + 3 + 4 = ${sum}`);
}

Output

Do I need to know Stof to use Limitr?

No. Stof is what actually runs, however, you do not need to learn Stof to use Limitr. For policy documents, JSON, YAML, TOML, or Stof work just fine with Limitr.new(...), and the SDKs eliminate the need to use or write Stof directly. It is always available, however, for additional custom tooling, embedded & overridden business logic, and Limitr power-users.

Our SDKs are a thin wrapper around the Limitr Stof WASM module, shared between them. The behaviors of one SDK are identical to any other, because its literally the same runtime.

Where the engine comes from — CJ, Co-Founder & 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 & modern usage-based pricing actually needs, and every pricing change came with a growing product & eng 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 & 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/context 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 (in all shapes and forms, internal & external).

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 you're in this boat with me, feel free to reach out (cj@limitr.dev) — I'd love to hear how it's going.

What's in these docs

• Quickstart — install the SDK, write a policy, make your first allow() call. Start here if you're integrating today.
• Policy Spec — the full policy language and schema reference. What you'll come back to once you're past the basics.
• Guides — user guides, cloud docs, monetization strategy, and all things not integration-related.