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 reserves 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. Limitry saves every count before it answers, so a limit stays exact even if a server fails.
• Changes reach checks at once. A new or edited limit applies to the next check. A revoked API key can keep working for checks for up to 60 seconds.

Choosing a region

Limitry keeps a workspace’s counts in one region, ready before your first check, so a new user, team or agent is decided as fast as one you have checked a thousand times. A check from far away crosses the ocean to reach them, which adds 100 to 200 ms.

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. The default, Automatic, keeps your counts in Eastern North America. One setting covers test and live. The page shows the city your live counts are in, and where most of your live checks come from.

Changing the region moves your counts there in the background: every count, balance and open reservation, with nothing lost or counted twice. Checks keep working while it moves. The counts move a part at a time, and each part pauses while it moves: usually a few seconds, at most 30, and a part that takes longer is put back and tried again later. A check that arrives during a pause gets 503 moving, and the SDKs retry it with the same idempotency key. The page shows how far the move has got. The new region is saved once everything has moved, and you can’t change it again until then. The region is a preference, not a guarantee: Cloudflare, which Limitry runs on, picks the data center in it.

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 the check were refused.

The SDK applies it for you. If Limitry doesn’t answer within 1.5 seconds, or answers a 429 or a 5xx, guard and reserve follow the fail mode of the limits they last saw: closed throws Unavailable, which is a different error from a refusal (LimitReached). 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, reserve, the SDKs and the CLI send one for you, and retry with it. Committing or releasing a reservation is safe to retry too. See Idempotency.

Work that crashes

A reservation that nobody commits or releases 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.