Beta

Limits

These are sized so that ordinary agent work never touches them. They exist to keep one runaway loop from taking the region down for everyone else.

Quotas

Every response carries X-RateLimit-Remaining and X-RateLimit-Reset, so you can watch the budget without waiting for a rejection.

Throughput

There is no published bandwidth cap. The write path is shared, so sustained ingest from several tokens at once will slow everyone down, but we would rather let a large index finish slowly than reject it.

For reference, a full index of a mid-sized repository is a few hundred megabytes. A large monorepo lands in the low gigabytes and can take an hour or more on one connection. Both are normal.

Ingest is measured on the wire, before compression. A day's 25 GB is roughly ten full re-indexes of a large project — if you are re-embedding often enough to reach it, cache your embeddings instead.

Connections

Six concurrent connections per token, and the SDKs default to four. This is a deliberate ceiling rather than a resource constraint: past four, parallel ingests mostly compete with each other for the same rate budget.

Long-lived connections are the expected pattern here, not an abuse of the service. A stream channel held open for the whole working day counts once, at the moment it opens, and heartbeats do not consume request budget.

Idle timeouts below 300 seconds on your side will cut healthy sessions. If a proxy sits between you and us, check its timeout before assuming the problem is on our end.

Retention

Losing a token means losing access to everything behind it — there is no account to recover from. Orphaned collections are pruned two weeks later.

Raising a limit

There is no form and no paid tier yet. If a limit is genuinely in your way, describe the workload to the address in security.txt — it is the only mailbox we read. We will either raise it for your token or explain why we cannot.