Overview
Trix uses rate limits to ensure fair usage and maintain service reliability for all users. Limits are applied per API key and reset on a rolling window basis.
Rate limits ensure all users get consistent performance, even during peak traffic.
Quotas help you predict and control your monthly usage and costs.
Rate Limit Tiers
Rate limits vary by plan. Here's what's included in each tier:
| Plan | Requests/min | Memories | Max Memory Size | Spaces |
|---|---|---|---|---|
| Free | 60 | 1,000 | 4 KB | 3 |
| Pro | 300 | 100,000 | 32 KB | Unlimited |
| Max | 1,000 | 500,000 | 128 KB | Unlimited |
| Enterprise | Custom | Unlimited | 1 MB | Unlimited |
Need higher limits? Contact sales to discuss Enterprise pricing with custom rate limits tailored to your needs.
Per-Endpoint Limits
Some endpoints have specific rate limits in addition to your plan's overall limit:
| Endpoint | Rate Limit | Notes |
|---|---|---|
POST /v1/memories | 60/min | Memory creation triggers embedding generation |
POST /v1/memories/bulk | 10/min | Up to 100 memories per request |
POST /v1/search | 120/min | Semantic search queries |
GET /v1/memories | 300/min | List operations are cheaper |
DELETE /v1/memories/:id | 60/min | Individual deletes |
POST /v1/entities/merge | 10/min | Entity merging is resource-intensive |
Rate Limit Headers
Every API response includes headers to help you track your usage:
HTTP/1.1 200 OK
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 287
X-RateLimit-Reset: 1705312800
X-RateLimit-Policy: 300;w=60| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum requests allowed per window |
X-RateLimit-Remaining | Requests remaining in current window |
X-RateLimit-Reset | Unix timestamp when the window resets |
X-RateLimit-Policy | Rate limit policy (limit;w=window_seconds) |
Handling Rate Limits
When you exceed the rate limit, the API returns a 429 status code:
{
"error": {
"code": "rate_limit_exceeded",
"message": "Rate limit exceeded. Please retry after 30 seconds.",
"retry_after": 30,
"limit": 300,
"window": 60
}
}Implement retry logic with exponential backoff:
import { Trix, TrixError } from '@trixdb/client';
async function withRetry<T>(
fn: () => Promise<T>,
maxRetries = 3
): Promise<T> {
for (let attempt = 0; attempt < maxRetries; attempt++) {
try {
return await fn();
} catch (error) {
if (error instanceof TrixError && error.code === 'rate_limit_exceeded') {
const delay = error.retryAfter || Math.pow(2, attempt) * 1000;
console.log(`Rate limited. Retrying in ${delay}ms...`);
await new Promise(resolve => setTimeout(resolve, delay));
} else {
throw error;
}
}
}
throw new Error('Max retries exceeded');
}
// Usage
const trix = new Trix({ apiKey: process.env.TRIX_API_KEY });
const result = await withRetry(() => trix.memories.create({ content: 'Important note' }));Built-in retry: The official SDKs include automatic retry logic
with exponential backoff. Enable it with { retry: true } in your client config.
Usage Quotas
In addition to rate limits, your plan includes monthly quotas for certain operations:
| Quota Type | Free | Pro | Max | Enterprise |
|---|---|---|---|---|
| Total Memories | 1,000 | 100,000 | 500,000 | Unlimited |
| Search Queries/mo | 5,000 | 500,000 | 5,000,000 | Unlimited |
| Embeddings/mo | 5,000 | 500,000 | 5,000,000 | Unlimited |
| Webhooks | 1 | 10 | 50 | Unlimited |
| API Keys | 3 | 10 | 50 | Unlimited |
Check your current usage with the CLI:
# View current usage and quotas
trix billing usage
# Output:
# Plan: Pro
# Billing Period: Dec 1 - Dec 31
#
# Memories: 42,150 / 500,000 (8.4%)
# Searches: 128,402 / 500,000 (25.7%)
# Embeddings: 43,892 / 500,000 (8.8%)
# Spaces: 12 (unlimited on paid plans)Best Practices
Follow these practices to make the most of your rate limits and avoid disruptions:
Exponential Backoff
When rate limited, wait progressively longer between retries: 1s, 2s, 4s, 8s.
Batch Operations
Use /v1/memories/bulk to create multiple memories in one request.
Cache Results
Cache frequently accessed memories locally to reduce API calls.
Monitor Headers
Track X-RateLimit-Remaining to anticipate limits before hitting them.
Queue Requests
Implement a request queue to smooth out bursts and stay within limits.
Use Webhooks
Subscribe to events instead of polling to reduce unnecessary API calls.
Monitoring Your Usage
Set up monitoring and alerts to stay within your limits:
import { Trix } from '@trixdb/client';
const trix = new Trix({
apiKey: process.env.TRIX_API_KEY,
onRateLimit: (info) => {
// Called when approaching or exceeding limits
console.warn(`Rate limit: ${info.remaining}/${info.limit} remaining`);
if (info.remaining < 10) {
// Alert your monitoring system
alertOps('Approaching rate limit', info);
}
}
});Webhook alerts: Configure webhooks to receive notifications when you're approaching quota limits. Go to Settings -> Notifications in the dashboard.
Rate Limit Error Codes
| Error Code | HTTP Status | Description | Action |
|---|---|---|---|
rate_limit_exceeded | 429 | Too many requests in the current window | Wait for retry_after seconds |
daily_limit_exceeded | 429 | Daily memory creation limit reached | Wait until midnight UTC or upgrade plan |
quota_exceeded | 403 | Monthly quota exhausted | Upgrade plan or wait for next billing cycle |
concurrent_limit_exceeded | 429 | Too many concurrent requests | Reduce parallelism, implement queuing |
Upgrading Your Plan
If you consistently hit rate limits, consider upgrading:
# View available plans
trix billing plans
# Upgrade to Pro
trix billing upgrade --plan pro
# Upgrade to Max with yearly billing (save ~2 months)
trix billing upgrade --plan max --period yearly