Rate limits & quotas

Per-tier request ceilings, uniformly enforced across REST, MCP, and the CLI. Limits protect the substrate from unintentional runaway loads and give the platform predictable capacity headroom — they are not a monetisation gate.

Per-tier ceilings

Tier	Sustained	Burst (10s window)	Notes
Guest (L1 · Starter)	10 req/s	40 req/s	Reads and low-risk tool calls
Host (L2 · Team)	60 req/s	240 req/s	Writes within own org
Architect (L3 · Enterprise)	600 req/s	2,400 req/s	Substrate mutation

Bursts above the sustained ceiling are allowed for a short window (4× the sustained rate for 10 seconds). A pipeline that uses the burst window and returns to below sustained will not see any 429s.

How limits behave under load

When your operator identity hits the sustained ceiling, subsequent requests return HTTP 429 with a Retry-After header. The 429 body carries the standard error envelope, including the specific policy id that refused the call and the audit-chain entry that logged it.


{
  "code": "policy.refusal.rate_limit_exceeded",
  "message": "Sustained rate exceeded for Host tier.",
  "policy_id": "RATE-LIMIT-HOST-SUSTAINED",
  "audit_event_id": "evt_01H8YMK7ZQV3D4XCJ9RM8W2N5T",
  "retry_after_seconds": 3
}

The refusal itself lands in the audit chain — every 429 is a distinct chain entry. Repeated 429s from one operator are legible to their compliance officer.

Raising a limit

For a workload that legitimately exceeds the tier ceiling — a batch import, a migration, an integration test suite — ask enterprise@nebbos.ai for a dedicated quota. Substrate-side lifting is per-identity and per-operation-category, so a bulk read allowance does not open the door to a bulk write path.

Where limits do not apply

Local operations that never cross the wire — MCP discovery reads served from the local cache, audit-chain verification of a locally-held segment — are not rate-limited. Limits only apply to substrate-touching calls.