Limits & Availability
Every number on this page is the value the gateway actually enforces. Where a limit is not enforced, this page says so rather than leaving you to infer one.Request rate
Sliding windows over a shared cross-worker store, so the ceiling is the ceiling across the whole fleet — not per process.
The failed-authentication bucket counts only requests whose phantom token was
refused — missing, unknown, expired, revoked, or presented from outside its
allowed window or network. Successful requests never count, however many share
an address. Once an address has used its allowance, every request from it to
either plane is refused with
429 before its token is checked, until the
window drains; Retry-After says when.
These are abuse floors, not product quotas: they are the same on every plan, and a
normal integration should never meet one. Exceeding a bucket returns 429.
The rate limiter fails closed. If its store is configured but unreachable, the
plane refuses rather than admitting unmetered traffic — for a gateway whose job is
credential custody, an unmetered data plane is the worse failure. (In a local
development install with the store deliberately disabled it falls back to an
in-process window, so limits still apply while you develop.)
Concurrent MCP sessions
An MCP client picks its own
mcp-session-id, so without a cap it would pick how
many credentialed upstream connections KnoxCall holds open on its behalf. Past the
ceiling the least-recently-used session is closed, not refused: a resource
bound should not become a 503 for a client that opened one connection too many.
Sessions are also swept after 5 minutes idle and retired after 15 minutes
regardless, so a credential the upstream has revoked stops working on a schedule
we control.
16 is the number across the whole fleet. It is declared that way in the code
(MAX_SESSIONS_PER_PRINCIPAL_FLEET) and divided by the API worker count, because
the session pool is necessarily per-process — it holds real sockets — and a
per-worker figure would quietly multiply into a limit nobody had written down.
Request size
An oversized body is rejected by the body parser before any gateway policy runs.
There is no ceiling on response size — the gateway streams or buffers whatever
the upstream returns.
Tokens
A requested TTL outside
[60s, 90d] is clamped into range rather than rejected.
Guardrail bounds
Caching
What is not limited
Stated explicitly, because an unstated limit reads as an enforced one:- No per-tenant or per-plan request quota. The ceilings above are platform-wide abuse floors. Plan-based quotas are a separate piece of work.
- No token-count quota. Spend is bounded in dollars by budgets, not by a token allowance.
- No response-size ceiling.
- No cap on agents, gateways, or tokens per tenant.
Availability
KnoxCall does not publish an uptime percentage for the AI Gateway, and will not until one can be measured against a defined error budget and backed by a credit schedule. Quoting a number we cannot compute would be worth less than saying so. What we do commit to today:- Live status and incident history at status.knoxcall.com, which is where an incident is posted first.
- Degrade toward refusal, not toward silence. When a control cannot run, the gateway refuses the request rather than serving it with the control off — an unloadable firewall policy, an unresolvable PII policy, an unreachable rate-limit store and an unproven token environment all fail closed. Detection-only signals (impossible-travel geolocation) fail open, because losing one comparison costs a comparison while blocking on it costs access.
- No silent zeros. An unpriced model is recorded as
unpriced, never as $0; a missing usage figure is reported as missing. - Failover you configure. Per-agent failover chains move a 5xx to the next upstream you nominate, each hop with its own credential.