Rate limits
This page lists how fast each plan can call Alvia, and how to stay under the limit. Rate limits are separate from your plan’s monthly allowances: an allowance sets how many reads and writes a plan includes each month, and a rate limit sets how quickly you can send them. See Limits and allowances.
How the limits work
Section titled “How the limits work”Alvia uses token buckets: one bucket for reads and one for writes.
- Burst is the bucket’s size: how many requests you can send at once.
- Rate is how many tokens per second refill the bucket.
Each request takes one token. While the bucket has tokens, requests go through at once. When the
bucket is empty, the request gets a 429 response. The bucket refills continuously at the plan’s
rate.
The buckets belong to your account. Every API key in every project of the account, every MCP connection and the memory requests of the dashboard draw from the same two buckets.
Limits by plan
Section titled “Limits by plan”| Plan | Read burst | Reads per second | Write burst | Writes per second |
|---|---|---|---|---|
| Free | 10 | 5 | 5 | 5 |
| Starter | 100 | 50 | 50 | 25 |
| Growth | 400 | 200 | 200 | 100 |
| Scale | 2,000 | 1,000 | 1,000 | 500 |
On every plan, reads or writes stop when their monthly allowance is used up, until it resets or you upgrade. See Limits and allowances.
Custom plans have limits set for your workloads.
Reads and writes
Section titled “Reads and writes”| Reads | Writes |
|---|---|
POST /v1/memories/context |
POST /v1/memories |
POST /v1/memories/recall |
POST /v1/memories/import |
POST /v1/memories/search |
DELETE /v1/memories/{memory_id} |
GET /v1/memories/{memory_id} |
PUT /v1/memories/{memory_id}/feedback |
GET /v1/memories/{memory_id}/inspect |
|
GET /v1/memories |
|
MCP: context, recall, search_memories, recall_by_id, inspect_memory, list_memories |
MCP: remember, forget_memory, give_memory_feedback |
Each request takes one token, whatever its size. An import of 500 messages takes one write token, and a context call takes one read token. Allowances count reads differently; see Reads in Limits and allowances.
Rate-limit headers
Section titled “Rate-limit headers”REST memory responses carry three headers:
| Header | Meaning |
|---|---|
RateLimit-Limit |
The bucket’s size: your plan’s burst for this class. |
RateLimit-Remaining |
Tokens left in the bucket after this request. |
RateLimit-Reset |
On a 429, the seconds until the next token, as in Retry-After; on other responses, 1. |
MCP tools report a rate limit in their error message instead; see below.
When you reach the limit
Section titled “When you reach the limit”A refused REST request gets a 429 response with a Retry-After header:
{ "type": "https://alvia.ai/docs/errors/#rate_limit_exceeded", "title": "Rate limit exceeded", "status": 429, "detail": "Rate limit exceeded for Write operations", "instance": "/v1/memories", "code": "rate_limit_exceeded"}Wait for the number of seconds in Retry-After, then retry. A refused MCP call gets a tool error:
Rate limit exceeded for Write operations. Retry in 1s.
A 429 response with a monthly-allowance reason means a monthly allowance is used up. Retry
after resets_at. See Limits and allowances.
Stay under the limit
Section titled “Stay under the limit”- Read
RateLimit-Remaining, and slow down before it reaches zero. - Spread batch work, such as backfills, over time.
- Import a conversation in one request instead of storing each turn on its own.
- Retry with backoff and jitter. See Production checklist.