Request rate limiting #11

New issue

Open

opened 2026-08-26 04:49:55 +00:00 by jlxq0 · 0 comments

jlxq0 commented

2026-08-26 04:49:55 +00:00

Owner

Migrated from Plan.md's "Deferred (do not drift into these)" section when that file was retired; open work belongs in issues, not in a file with no state. Nothing here is scheduled and no decision has been taken. Do not start it without an explicit go.

There is no per-tenant or per-principal request rate limit. What exists instead is TYPST_MCP_MAX_CONCURRENT_COMPILES, a compile timeout, worker RLIMIT_AS, per-tenant storage quotas with entry counts, an MCP session admission cap, and a 32 MB request guard at the edge.

So the resource exhaustion routes that were actually found are closed by bounds rather than by rate. A rate limit would be a different control for a different threat (a credentialled tenant being merely expensive), and no one has asked for it.

Migrated from `Plan.md`'s "Deferred (do not drift into these)" section when that file was retired; open work belongs in issues, not in a file with no state. **Nothing here is scheduled and no decision has been taken.** Do not start it without an explicit go. There is no per-tenant or per-principal request rate limit. What exists instead is `TYPST_MCP_MAX_CONCURRENT_COMPILES`, a compile timeout, worker `RLIMIT_AS`, per-tenant storage quotas with entry counts, an MCP session admission cap, and a 32 MB request guard at the edge. So the resource exhaustion routes that were actually found are closed by bounds rather than by rate. A rate limit would be a different control for a different threat (a credentialled tenant being merely expensive), and no one has asked for it.

jlxq0 added this to the Deferred — needs a decision milestone

2026-08-26 04:49:55 +00:00

jlxq0 added the

deferred

label

2026-08-26 04:49:55 +00:00