Rate Limits
KAEL applies daily request limits based on server-calculated clearance. Tenant integrations can have a separate configured daily limit.
| Field | Value |
|---|---|
| Documentation status | Active |
| Reset boundary | 00:00 UTC |
| Last source review | 2026-06-26 |
Current KAEL daily limits
| Clearance | Daily request limit |
|---|---|
| L1 | 20 |
| L2 | 50 |
| L3 | 200 |
| L4 | Effectively unrestricted |
| L5 | Effectively unrestricted |
These are runtime defaults and can change. Tenant configuration can override the per-tenant daily limit.
Limit key
KAEL derives the limit key from the strongest available identity context, such as:
- Signed-in subject.
- ARM or invite state.
- Client network identity.
- Tenant and caller scope.
Clients must not assume that changing a session ID resets a server-side limit.
Streaming behavior
POST /kael/stream starts an SSE response before all checks finish. A limit failure can therefore arrive as an event:
{ "error": "rate_limit", "clearance": 1, "limit": 20, "message": "L1 daily limit reached." }
The stream then emits [DONE].
Client behavior
- Display the server’s message.
- Do not immediately retry the same request.
- Preserve unfinished user input.
- Avoid parallel duplicate submissions.
- Do not fabricate a remaining count when the server did not provide one.
- Use exponential backoff for transient
5xxfailures, not daily limits.
Infrastructure limits
The documentation site separately limits mutation requests at nginx to reduce automated abuse. Those controls do not change KAEL’s application-level daily limits.