Blame
|
1 | # Rate Limits |
||||||
| 2 | ||||||||
|
3 | KAEL applies daily request limits based on server-calculated clearance. Tenant integrations can have a separate configured daily limit. |
||||||
|
4 | |||||||
|
5 | | Field | Value | |
||||||
| 6 | |---|---| |
|||||||
| 7 | | Documentation status | Active | |
|||||||
| 8 | | Reset boundary | 00:00 UTC | |
|||||||
| 9 | | Last source review | 2026-06-26 | |
|||||||
|
10 | |||||||
|
11 | ## Current KAEL daily limits |
||||||
|
12 | |||||||
|
13 | | Clearance | Daily request limit | |
||||||
| 14 | |---|---:| |
|||||||
| 15 | | L1 | 20 | |
|||||||
| 16 | | L2 | 50 | |
|||||||
| 17 | | L3 | 200 | |
|||||||
| 18 | | L4 | Effectively unrestricted | |
|||||||
| 19 | | L5 | Effectively unrestricted | |
|||||||
|
20 | |||||||
|
21 | These are runtime defaults and can change. Tenant configuration can override the per-tenant daily limit. |
||||||
| 22 | ||||||||
| 23 | ## Limit key |
|||||||
| 24 | ||||||||
| 25 | KAEL derives the limit key from the strongest available identity context, such as: |
|||||||
| 26 | ||||||||
| 27 | - Signed-in subject. |
|||||||
| 28 | - ARM or invite state. |
|||||||
| 29 | - Client network identity. |
|||||||
| 30 | - Tenant and caller scope. |
|||||||
| 31 | ||||||||
| 32 | Clients must not assume that changing a session ID resets a server-side limit. |
|||||||
| 33 | ||||||||
| 34 | ## Streaming behavior |
|||||||
| 35 | ||||||||
| 36 | `POST /kael/stream` starts an SSE response before all checks finish. A limit failure can therefore arrive as an event: |
|||||||
| 37 | ||||||||
| 38 | ```json |
|||||||
| 39 | { |
|||||||
| 40 | "error": "rate_limit", |
|||||||
| 41 | "clearance": 1, |
|||||||
| 42 | "limit": 20, |
|||||||
| 43 | "message": "L1 daily limit reached." |
|||||||
| 44 | } |
|||||||
| 45 | ``` |
|||||||
| 46 | ||||||||
| 47 | The stream then emits `[DONE]`. |
|||||||
|
48 | |||||||
| 49 | ## Client behavior |
|||||||
| 50 | ||||||||
|
51 | - Display the server’s message. |
||||||
| 52 | - Do not immediately retry the same request. |
|||||||
| 53 | - Preserve unfinished user input. |
|||||||
| 54 | - Avoid parallel duplicate submissions. |
|||||||
| 55 | - Do not fabricate a remaining count when the server did not provide one. |
|||||||
| 56 | - Use exponential backoff for transient `5xx` failures, not daily limits. |
|||||||
| 57 | ||||||||
| 58 | ## Infrastructure limits |
|||||||
| 59 | ||||||||
| 60 | The documentation site separately limits mutation requests at nginx to reduce automated abuse. Those controls do not change KAEL’s application-level daily limits. |
|||||||
| 61 | ||||||||
| 62 | ## Related documentation |
|||||||
| 63 | ||||||||
| 64 | - [[API Quickstart]] |
|||||||
| 65 | - [[KAEL API]] |
|||||||
| 66 | - [[Authentication]] |
|||||||
| 67 | - [[Security]] |
|||||||