Quota

Per-user and per-org caps on running instances. See Users and quotas for the 429 experience from the CLI side.

GET /v1/org/quota — read current caps and usage

Auth: bearer (any authenticated member).

$ curl -s https://api.stagdb.com/v1/org/quota -H "Authorization: Bearer $TOKEN"

Response 200 OK

{
  "max_instances_per_user": 3,
  "max_instances_per_org": 30,
  "active_in_org": 14,
  "active_owned": 2
}

• max_instances_per_user / max_instances_per_org — the current caps. 0 means unset (unlimited) — the default for a fresh org.
• active_in_org — total live instances across the whole org.
• active_owned — live instances owned by the calling user specifically.

Any member can read this — the caps are what the launch path enforces against them anyway, so there's nothing sensitive here.

PATCH /v1/org/quota — set caps

Auth: admin.

Request body

$ curl -s https://api.stagdb.com/v1/org/quota -X PATCH -H "Authorization: Bearer $TOKEN" \
    -H 'Content-Type: application/json' -d '{"max_instances_per_user":3,"max_instances_per_org":30}'

Response 200 OK

{"max_instances_per_user": 3, "max_instances_per_org": 30}

The 429 you'll see elsewhere

Quota isn't checked here — it's enforced at instance launch. POST /v1/instances (see Instances) returns exactly:

{"error": "instance quota exceeded"}

with 429 Too Many Requests — the body doesn't say which cap you hit; compare active_owned against max_instances_per_user via GET /v1/org/quota to tell. The same 429 fires whether the launch was served on-demand or fast-claimed from a clone pool — pools make clones faster, not exempt from quota.

Next

• Instances — where the 429 actually fires, on launch.
• Org — GET /v1/org/usage rolls the same quota numbers into a full org-wide dashboard.