Skip to main content

​
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. 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.)

​
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.
The default is a bounded 30-day TTL, not “no expiry” — a mint without expires_in_seconds used to produce a token that never expired at all, and any key minted before that changed is still out there with a NULL expires_at. Set expires_in_seconds explicitly on every mint that is not a hand-held credential, and re-mint anything issued earlier that you cannot account for.

​
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.
If you need a contractual availability commitment, raise it with us before you build against one — we would rather negotiate a number we can hold than publish one we cannot.