Limits

One limiter sits in front of everything the server serves: the eight MCP tools and the traps API share the same counters. Each call runs one Redis script that checks three things in order, so a refusal tells you which of them tripped.

The numbers

Team starts at five seats. Every seat bought beyond that adds 20,000 calls to the monthly cap and leaves the burst alone.

Anonymous calls are counted against the calling address. Every other scope is counted against the organization, not the key: ten keys in one organization draw down one monthly counter, which is what makes per-service keys safe to hand out. Revoking a key stops that key; it does not give the organization more calls.

Which counter refuses you

The script checks the subnet throttle, then the window cap, then the burst, and only increments the window counter when all three pass. Two consequences worth knowing:

• A burst refusal does not spend a call. The minute counter is incremented, the window counter is not, so hitting the burst wall costs you nothing but time.
• A window refusal does not touch the burst counter at all.

The minute counter is a plain counter with a 60-second expiry set on its first increment, not a sliding window. It resets 60 seconds after the first call of a burst, not 60 seconds after the last.

The subnet throttle

Anonymous callers get one more check, and it is the one that surprises people on shared infrastructure. Whenever an address reaches the daily cap, it is added to a set for its subnet, keyed by the first three dotted parts of the address and expiring with the day. Once that set holds more than ten distinct addresses, every anonymous call from that subnet is refused for the rest of the UTC day, whatever each individual counter says.

The refusal looks like an ordinary cap refusal; the line does not say "subnet". If a fresh address on a CI network is refused on its first call, this is why. A key is the fix: keyed traffic is counted per organization and never touches the subnet set.

The limit line

A refusal replaces the whole answer with one line, and it is the same string on the MCP and on the traps API:

limit reached: no-key 60/60 today (resets 2026-09-09T00:00:00.000Z). Free key or plans: https://wellworn.dev/pricing

The shape is fixed:

Over MCP the line arrives as a normal tool result with isError unset, so an agent that only checks for errors will read it as an answer. Over the traps API it arrives as the 429 body. Match on the limit reached: prefix rather than the status.

When each counter resets

resets in the limit line is the exact instant, in UTC, so a client can sleep until it rather than poll.

Plans that lapse

A subscription that is cancelled or past due keeps its allowance until the period it has already paid for ends, then the organization falls back to the free allowance: 2,000 calls a month at 30 a minute. The key itself keeps working the whole time; it just buys less. Burst and cap are read from the organization's plan row through a cache with a 60-second life, so a plan change can take up to a minute to reach the limiter.

The limiter reads the plan's monthly call limit. Past it, a paid organization draws one credit from its ledger per call and the response ends with remaining: 0; when the balance reaches zero the limit line returns. Free and no-key scopes stop at the cap.

Raising the ceiling

A free key at wellworn.dev/keys is the largest single jump available: 60 calls a day becomes 2,000 a month, the burst triples, the subnet throttle stops applying, and submit_trap starts working. Paid plans are on wellworn.dev/pricing.

Before buying more calls, spend fewer. Best practices covers which tool answers which question in one call instead of three.