Rate-Limits

# 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:

```json
{
  "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 `5xx` failures, 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.

## Related documentation

- [[API Quickstart]]
- [[KAEL API]]
- [[Authentication]]
- [[Security]]