How Limitry works

Where Limitry decides a check

Your check reaches Limitry at the location nearest the server that sent it. Each subject’s counts live in one place, so Limitry decides every check for that subject against the same numbers. When a check also draws from a shared pool (a team’s, say), Limitry first holds the cost on every subject, and charges them all only if every limit fits.

Two things follow from this:

• Counts are exact. Two requests racing for the last unit can’t both get it, and a pool shared by many users is never overspent.
• Changes take up to a minute. A new or edited limit reaches checks within a minute. A revoked API key can keep working for checks for up to 60 seconds.

Choosing a region

Limitry creates a subject’s counts the first time it checks that subject, close to where that check came from, and they stay there. If the first check with a live key comes from your laptop and your servers are on another continent, every later check for that subject crosses the ocean, which adds 100 to 200 ms.

To avoid that, an owner or admin sets Settings → Region to where your servers run: Western or Eastern North America, Western or Eastern Europe, Asia-Pacific, or Oceania. Limitry then creates new subjects’ counts there. The default, Automatic, places each one near its first check. A change applies to subjects created afterwards; existing ones stay where they are. The region is a preference, not a guarantee: Cloudflare, which Limitry runs on, picks the data center closest to it that can take the subject.

When your code can’t reach Limitry

Every limit has a fail mode, which you choose per limit:

• open, the default: your code goes ahead as if allowed.
• closed: your code refuses, as if denied.

The SDK applies it for you. If Limitry doesn’t answer within 1.5 seconds, guard and hold follow the fail mode of the limits they last saw. Choose closed where overspending would hurt more than refusing, such as an agent’s spending budget.

Retries

A check with an Idempotency-Key header counts once: for 24 hours, the same key gets the same answer and counts nothing again. guard, hold, the SDKs and the CLI send one for you, and retry with it. Settling a reservation is safe to retry too. See Idempotency.

Work that crashes

A reservation that nobody settles gives itself back when it expires, after 5 minutes by default. A worker that crashes mid-job never leaves a user blocked or a concurrency slot taken.

What Limitry stores

• Your limits, and every change to them in the workspace’s audit log.
• Counts per limit, per subject, per hour, kept for 13 months. Your plan sets how far back you can look: 7 days on Free, 90 days on Pro, 13 months on Growth.
• The subject kinds and ids you send. Limitry attaches no meaning to them, so send your own opaque ids (usr_123), not names or email addresses.

Limitry never sees the work itself: no prompts, model output or files. A check carries a subject, an action name and a number.

Test and live

Every workspace has a test environment and a live environment, each with its own limits, counts, balances, reservations and usage. The API key decides which one a check uses: lim_test_… or lim_live_…. Test checks can’t move live counts, and they have their own allowance that isn’t billed. See Test and live.

Access

API keys belong to a workspace and one environment, and carry scopes: checks:write to check, limits:read and limits:write to read and manage limits. Give each service the narrowest key it needs. Personal access tokens act as the person who created them. See Authentication.