Quotas

Two quotas bound what a hosted tenant can do in v1, and no others. They look similar — both are plain numbers on your plan — but they are enforced in two deliberately different places, and that difference is the actual thing worth understanding.

The concurrent-Run cap

Bounds how many Runs your Stack's own Dispatcher will admit at once — the v1 default is 1. It is enforced entirely on your Stack itself, at the same admission gate that already governs starting any Run: raising or lowering the cap never interrupts a Run already in flight, it only moves the ceiling the next admission checks against.

This one is enforced locally because it only protects your own Stack's own resources and your own connected Provider's own concurrency — there is nothing to protect by enforcing it anywhere else.

The watched-Projects cap

Bounds how many GitHub repositories you can register for your Stack's Dispatcher to watch — the v1 default is 3. Unlike the Run cap, this one is enforced entirely by the control plane, at the moment a Project is registered, and never reaches your Stack at all.

This one is enforced centrally on purpose: it is a plan limit that has to hold regardless of anything running on your own Stack, so it lives at the one place nothing on your Stack could ever bypass it.

What neither quota is

Neither is a spending cap. Your Runs' token and cost usage is tracked and reported for visibility — so you and, in aggregate, operators can see what a Stack is actually using — but nothing anywhere reads that usage data to decide whether your next Run is allowed to start. A quota here is always a plain, static number compared against a plain count (Runs in flight, Projects registered), never against how much you've spent.

Related

• Work model — where the Run cap actually applies, in the drain loop.
• Two surfaces — why "enforced on your Stack" and "enforced by the control plane" are meaningfully different guarantees.