marketing-overview
Limitr is an embedded usage runtime for AI products: it enforces what every user and agent can do, how much they get, and what it costs them, running in-process as WebAssembly rather than as a remote API call. This document consolidates the content of Limitr's four marketing pages — the homepage and the Monetize, Control, and Analyze pages — since those pages are built as standalone Docusaurus src/pages (custom React components with MDX-supplied copy), not docs, and are not otherwise included in generated documentation or llms.txt output.
Homepage
Positioning
Eyebrow: The usage runtime for AI products
Headline: AI becomes profitable when usage is visible and controlled.
Subhead: Limitr is an embedded runtime that enforces what every user and agent can do, how much they get, and what it costs them, giving you control over cost-to-serve and revenue capture.
Why now
"What changed?" — Margin is no longer fixed. It moves with every call.
Solutions that Limitr Offers to Customers
Usage Monetization
"Claim" - Turn usage into revenue. "Description" - Any pricing model, versioned & auditable, as a single managed config. Define entitlements, limits, credits, & prices — Limitr meters and charges every call against it, per customer, per plan, live.
Usage Control
"Claim" - Gate access. Cap usage. Control overhead. "Description" - Usage limits, access gates, and spend caps enforced where calls happen, translated into your desired units — per customer, per agent, per pipeline, per vendor, embedded & real-time.
Usage Analytics
"Claim" - Live margin and clear attribution. "Description" - Revenue, cost, and usage data captured at the same moment, with clear vendor, customer, and feature attribution and analytics — never a stale monthly export from three different tools.
Differentiators
Actually embedded
Limitr isn't a remote API — it's a WebAssembly runtime, running inside your own process. The decision happens where your code already lives (works offline, too).
Policy-as-document approach
Pricing, limits, and entitlements live in one versioned, managed, and open-source document, not scattered across servers, code, and spreadsheets.
Translate and exchange value
Limitr exchanges and translates usage — tokens, seconds, credits — into what actually matters: outcomes, USD, any currency, live, across every service and vendor.
FAQ — Start here
Q: What's the difference between a billing platform and a pricing runtime?
A billing platform records what happened and charges for it after the fact — invoices, payments, subscriptions, revenue recognition. A pricing runtime 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 owns the decision layer above it: what each customer gets, what it costs you, what you charge, enforced live. We integrate with the billing platform and workflow of choice.
Q: I just want to control usage, do I also have to monetize it?
No. Each solution — monetize, control, analyze — can be implemented together or separately. Most teams start with analytics (you can't control what you can't see), then move into controlling usage and sometimes monetizing it (or portions of it).
The usage you monetize may also not be the same raw usage that you control — most teams stack and layer entitlements to achieve their desired pricing & control models that work together (e.g. control tokens, charge only for successful runs).
Q: 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 our customers split roughly evenly. Some are metering multi-model AI pipelines. Others are legacy 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.
Q: 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.
FAQ — For engineering
Q: 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.
Q: 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 — limits, prices, tiers, per-customer overrides — is configuration that changes without touching your code.
The SDKs are each a thin wrapper over the same core WASM module, so additional languages take days rather than quarters to support. TypeScript/JS is most supported today, but tell us what you're running and we'll confirm timing before you commit to anything.
Q: Is Limitr like an AI gateway?
Dynamic model switching is a core part of AI usage control, and we are very good at that. We are also very good at putting prices to usage, so you can track and control margin-to-serve in the ways that matter, not just a general aggregate cost-to-serve which leaves a lot of blind spots.
Limitr does not, however, make LLM requests on your behalf or repackage specific vendor tokens. We do not provide a router for your AI requests — we provide a control plane around them. Limitr works with any AI vendor (including gateways).
If you're looking for spend management alone, Limitr will suffice. If you're looking for a unified endpoint, routing, & other AI-specific guardrails, a gateway may also make sense in parallel.
Q: What happens if the connection drops, or if something gets counted wrong?
On disconnect, the runtime will try reconnecting automatically and gives you the option to continue operating normally offline or block all usage until back online (the default to preserve state). If your app is offline, you typically have larger issues to contend with. 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, enabling you serve users in low or no-connectivity regions, or have a separate offline/backup usage policy for failure and testing modes of operation.
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 you won't double-count.
Q: 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. Cloud adds the managed policy dashboard, versioning and instant rollback, per-customer analytics and margin data, usage-based invoicing, live alerting, and the Stripe/billing integrations.
The enforcement API is identical either way, so moving from local to Cloud is a one-line change. Prototype against the open source engine without talking to us first — several teams have.
Q: Does the policy-as-config have validation?
Yes, our open-source runtime built on Stof contains validation rules, and can literally validate itself so that you never have an invalid policy.
Inside the npm.js package, Limitr.new(..) actually calls validate by default and will throw an error if the provided policy does not fit the spec, providing a message for where the error resides.
If you're using Limitr Cloud, the policy is fully managed and will always be validated when changes are made and before it gets used within your app or service.
FAQ — For finance and product
Q: Can non-engineers change limits and prices without a deploy?
Yes, and it's the main reason teams buy this. 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 PR, 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.
Q: Can't we just build this ourselves?
Honest answer: 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. Transparently, though, almost nobody's model stays static, and once you dive in, this critical 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, burndown 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, often brittle and expensive to maintain.
The estimates we hear from technical buyers cluster around 1-3 engineer-months for a first version, plus indefinite maintenance and additional internal projects for observability. Instead, our contracts are priced for outsized savings on your end, and because the enforcement engine is open source, you aren't betting your pricing infrastructure on our roadmap.
Q: 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.
On timing: not too early. Observe mode exists precisely for this — meter everything, enforce nothing, and set your allotments from real data instead of a guess. Implement in stages over time, when and how it makes the most sense for your specific products.
Closing statement
The embedded runtime for profitable AI.
Monetize page
Positioning
Eyebrow: Monetize
Headline: Scale your revenue. Monetize usage.
Subhead: Any pricing model, versioned and auditable. Define entitlements, limits, credits, and prices — Limitr meters and charges every call against it, per customer, per plan, live.
Why now
"What changed?" — Every feature you ship now carries a cost that moves. Pricing has to move with it.
Motivators — why teams monetize with Limitr
Ship any pricing model — flat, seat, usage, or all of them at once.
Most billing tools force a single model and make you rebuild when the market shifts. Limitr's policy is always hybrid and won't get in your way — flat fees, seats, usage meters, and credit pools live in the same document, combined however the plan actually needs.
Move at market and development speed.
Pricing and packaging live outside the codebase. A rate change, a new tier, an limit adjustment — versioned and published live the instant someone with permission makes it. No PR, no deploy, no release train to catch.
Every enterprise deal, without a special build.
Layer a custom rate, a bespoke limit, or a negotiated discount onto any customer or contract — with its own expiry and audit trail — without forking pricing logic or hardcoding a one-off exception.
Meter, price, and invoice — accurate to the moment.
Every call is accurately captured the instant it happens, not reconciled at month-end from logs and guesses. The customer invoice matches exactly what was metered, auditable and reportable in units that matter on both sides.
Get ahead of usage before you or your customer feel it.
Set thresholds once and the runtime watches continuously — a customer trending toward their cap, projected to cross a utilization target this week, whatever matters to your team. Alerts fire the moment it's crossed, in-app, configurable without waiting on engineering.
Differentiators
Policy, not code
Flat fees, seats, usage, credits — every pricing primitive lives in one open-source, versioned policy document, not scattered across code and spreadsheets. That's what makes any model possible: there's nothing to hardcode.
Runtime, not a request
What only a runtime can do is hold state — enforcing one cap across an entire pipeline, every vendor call included, because the context never leaves your process.
One exchange, real ROI
The same exchange that meters usage also translates it into what the customer actually cares about — cost avoided, outcomes delivered, value earned. Their invoice maps to their ROI, so expansion conversations explain themselves.
FAQ — Pricing & billing
Q: Can I really run flat, seat, usage, and credits in one plan, not just one model at a time?
Yes — that's the default, not a special configuration. A policy document can combine a flat platform fee, a per-seat charge, a metered usage rate, and a pooled credit balance in the same plan, applied to the same customer, at the same time.
Most billing tools treat these as separate products bolted together, which is why switching models usually means a migration. Limitr treats them as primitives inside one document — you're not choosing between flat and usage, you're deciding which primitives this specific plan needs, and changing that mix later doesn't require re-platforming.
Q: How fast do pricing changes actually take effect once someone publishes them?
Immediately, in the literal sense — a published change propagates to every connected service the moment it's saved, because the policy represents the runtime directly, not a config that gets deployed somewhere downstream.
There's no build step, no PR, no release window to wait for. The person changing the price and the person who set the deploy schedule for your application don't need to be the same team, or even know about each other's calendar.
Q: How do custom per-customer deals work in practice — is it really no special build?
A custom deal is an override layered on top of a base plan, not a fork of your pricing logic. You keep a small number of standard plans, then apply a different rate, limit, or discount to specific customer(s) or contract(s) — each override carries its own expiry and a record of who approved it.
Practically: sales negotiates a deal, someone with permission applies the override, and it's live for that account without a code change or a conversation with engineering. Nothing about the base plan changes for anyone else.
Q: How accurate is the invoice — is "priced at the moment of consumption" literal?
Literal. Every call is metered and priced against the ledger it belongs to in the same operation it happens in — not batched, not reconciled later from logs. The number on the invoice is the number the ledger recorded at the instant of consumption.
That matters most at the edges: usage right at a plan boundary, a burst right before a billing period closes, a customer who upgrades mid-cycle. Those are exactly the cases where systems that reconcile after the fact tend to drift from what actually happened — there's nothing to drift here, because there's no gap between metering and pricing to begin with.
Q: Can alerts be set up without engineering, and what can they actually trigger on?
Yes — thresholds are configured in the dashboard, not in code. You can set a rule against almost anything the runtime already tracks: a customer trending toward their cap, projected utilization over the next few days, a spend threshold crossed mid-period, a specific entitlement running low.
Who gets notified is also configurable per rule — an internal Slack channel, a customer success queue, the customer themselves. The common pattern is proactive account management: knowing a customer is about to hit a wall three days before they do, instead of finding out when support gets the ticket.
Closing statement
The pricing engine that keeps up with your business.
Control page
Positioning
Eyebrow: Control
Headline: Gate access. Cap spend. Control usage.
Subhead: Limits, access gates, and spend caps enforced where calls happen, translated into units that matter — per customer, per agent, per pipeline, per vendor, embedded and real-time.
Why now
"What changed?" — Runaway AI doesn't send a warning. It sends an invoice.
Motivators — why teams control usage with Limitr
Ship AI features without betting the company on the bill.
Start in observe mode — meter everything, enforce nothing, and watch real usage before committing to a number. Flip to soft limits when you're ready to charge for overage, then hard limits when you need a wall. Same policy, no rebuild, no re-launch.
Stop overspend before it happens.
Limits, credit balances, and rate governors — collapsed at once to provide a live generation allowance, like max_tokens, before call execution. A dynamic ceiling to support agreements and prevent sudden shutoffs.
Enforce spend controls, no matter what's running underneath.
Self-serve spend caps, overhead caps, observers, agent caps with scheduled resets — control spend in every situation, across services, vendors, and various credit exchange rates.
Place access gates for every user and agent.
Entitlements are gates with optional usage limits attached. They scope exactly what each tier, customer, or agent can do — defined as policy, enforced directly in-process where all the action happens.
Differentiators
One policy, every kind of limit
Switching a mode or scoping access is one configuration change, not two systems. An entitlement without a limit is an access gate, add a limit to charge, control, and observe any type of usage — any strategy, one open policy spec.
Enforced in-context, not outside
The runtime never leaves your application context — calculate dynamic usage allowance, cap spend over a single pipeline run, or change behavior for an agent. The complexity of dynamic controls won't get in the way of shipping.
Control units that matter
Transform and roll-up disparate credit types into a single unit for spend caps, overhead control, and observability in context. Multi-vendor pipeline spend is unified, controlled, and compared on equal ground.
FAQ — Limits & enforcement
Q: What's the actual difference between soft and hard limits?
Hard limits block the call outright once the cap is reached. Soft limits let the call through. Depending on how you configure soft limits in your policy, you can and just observe the overage usage, set a price and bill or invoice for the overage, or enable notifications to alert upon overage events.
Observe mode meters everything and enforces nothing, which is where most teams start. The three aren't separate products; they're one policy with a mode field, so moving from observe to soft to hard is a simple change within the Limitr policy.
Q: How do spend caps relate to entitlements and limits?
Spend caps sit above and outside of policy-level entitlements and limits. Plans group entitlements, and entitlements can have usage limits tied to them that define included/overage thresholds. Caps sit outside so that they can span across many entitlements at once.
This enables caps to be used for observing or enforcing spend per agent, pipeline, vendor, credit, or customer. Self-serve caps, overhead maximums, spend analysis — a versatile paradigm for all of your use cases.
Q: Can I scope access differently for different agents, or is it all-or-nothing?
Per-agent, per-customer, per-tier — however granular you need. A "customer" can be a user, account, workspace, agent, or anything else you'd like to limit, control, or analyze — facing either internally or externally.
Practically speaking, controlling one of your own agent's usage limits is no different from controlling a user's usage, the user just might get an invoice at the end of the month for it.
Q: How can I handle errors and events?
Limitr is an embedded runtime that is entirely event-driven. Therefore, you always have access directly in-process to local events like meter changes or limits being hit. The runtime is flexible, so you can always add your own rules, tooling, and custom events.
SDK-level handlers are also available for convenience, allowing your application to listen and handle the events it needs to in its native tongue. Explicit errors are also always provided.
What you do with events and errors is up to you: show the user a limit message, queue a request, fall back to a cheaper model, whatever fits your product.
Closing statement
Usage that's never outside of your control.
Analyze page
Positioning
Eyebrow: Analyze
Headline: Live margin. Clear attribution. Analyze usage.
Subhead: Revenue, cost, and usage data captured at the same moment, with clear vendor, customer, and feature attribution — always live, reported the moment usage happens.
Why now
"What changed?" — Your best customer could be your worst deal.
Motivators — why teams analyze usage with Limitr
Catch margin erosion while it's still small.
A drift in price or spike in usage caught this week can be a quick fix. Caught at quarter-end or after finance has already closed the books on it, and it's a larger problem. Margins that update with each call catches the difference while it's still small, and alerting ensures the correct team is informed, live.
Know which customers are currently profitable.
Revenue size and profitability aren't the same measurement, and they're changing minute by minute, not just month to month. See margin per customer as it happens so you know which accounts are quietly losing money.
Prioritize features that are worth building further — not just popular.
It's not enough to just know what's popular or how much you're spending on tokens. A heavily-used feature can be a margin sink if its cost outpaces what it's priced to capture. A worth-while determination is nuanced — make sure you have the right data to make decisions against.
Know what each vendor relationship is worth.
Running multiple models or vendors means cost-per-equivalent-outcome varies more than most teams realize. Minimize spend with dynamic model switching based on plan, usage, current metadata, and/or margin. Most teams seek cost-to-deliver AI, but are unable to answer margin-to-deliver outcomes — be one that can answer both.
Differentiators
One usage policy
Monetize, Control, and Analyze aren't three separate systems — they're three views into the same policy document. You can't price what you can't measure, and you can't control what you can't see.
One exchange, every dimension
Currency and credit exchange in one mechanism, enables slicing margin by customer, feature, or vendor. Ask questions from any angle, and be confident that your comparisons are correct and meaningful — USD, tokens, seconds, credits — both backward and forward.
Alerted, not just reported
The runtime evaluates every call as it happens. Notify the right team the millisecond a threshold crosses — a margin gone negative, a sudden usage spike — instead of missing it in next week's report.
FAQ — Margin & attribution
Q: Is the margin number real cost, or an estimate?
Each credit definition holds your price and an optional overhead cost. This is how margins are calculated in real-time per call while remaining flexible enough to capture custom or non-list prices.
Q: How current is per-customer profitability — actually live, or a nightly batch?
Live. Margin per customer reads from the same ledger that meters usage and prices it in real time — there's no separate batch job reconciling yesterday's data overnight, because there's no gap between when a call happens and when it's reflected in that customer's number.
Q: What if features aren't a clean, first-class concept in my product?
Features map to entitlements, and entitlements are however granular you define them — a feature, a specific model call, an internal workflow step, whatever boundary is actually meaningful in your product. There's no requirement that it map to a UI-visible feature flag or a product team's own taxonomy.
Most teams start coarse — a handful of major capabilities — and split further only once the coarse view surfaces something worth investigating. You don't need a finished feature taxonomy before this becomes useful.
Entitlements are also often stacked and used together for different purposes. The access gate, token meter, and outcome billed may all be separate entitlements used within the same operation, and the user may only get invoiced for outcomes or tokens, or not at all.
Q: Doesn't cost-per-outcome ignore that models perform differently, not just cost differently?
No — outcome is defined by you, not assumed to be a raw API call. If quality matters more than raw cost for a given use case, the outcome unit can be a resolved query, a passed eval, a customer-facing result — whatever the comparison should actually be measured against.
The point isn't always pick the cheapest vendor. It's making the real tradeoff visible — cost, quality, and reliability side by side — instead of defaulting to whichever vendor was integrated first and never revisited.
Q: Do I need a separate integration for this, or does it read the same data as Monetize and Control?
Same data, same integration. Analytics isn't a separate pipeline bolted on afterward — it reads from the identical ledger that Monetize prices against and Control enforces against, because it's the same policy document underneath all three.
Practically: if you're already metering usage for pricing or limits, the margin and attribution data is already there. There's nothing additional to instrument specifically for analytics.
Closing statement
Know what's profitable, not just what's popular.