> ## Documentation Index
> Fetch the complete documentation index at: https://docs.knoxcall.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Limits & Availability

> The concrete ceilings the AI Gateway data plane enforces — request rates, body sizes, token TTLs, scan and hold-back bounds — and an honest statement of what we do and do not promise about availability.

# 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.

| Plane             | Bucket                                          | Ceiling            |
| ----------------- | ----------------------------------------------- | ------------------ |
| `/v1/ai/<agent>`  | per phantom token                               | **300 / minute**   |
| `/v1/ai/<agent>`  | per agent (all of that agent's tokens together) | **1,200 / minute** |
| `/v1/mcp/<slug>`  | per phantom token                               | **600 / minute**   |
| `/v1/oauth/token` | per (client IP, issuer, subject)                | **30 / minute**    |
| `/v1/oauth/token` | per client IP                                   | **60 / minute**    |

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`.

<Note>
  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.)
</Note>

## Request size

| Plane             | Maximum request body |
| ----------------- | -------------------- |
| `/v1/ai/<agent>`  | **1 MB**             |
| `/v1/mcp/<slug>`  | **4 MB**             |
| `/v1/oauth/token` | **32 KB**            |

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

| Limit                                   | Value                                                                                          |
| --------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Phantom-token TTL, minimum              | **60 seconds**                                                                                 |
| Phantom-token TTL, maximum              | **90 days**                                                                                    |
| Phantom-token TTL, default              | **30 days** — a mint without `expires_in_seconds` gets this bounded TTL, not a permanent token |
| Federated token TTL (`/v1/oauth/token`) | the binding's `access_token_ttl_seconds`, default **900 seconds**                              |
| DPoP proof `iat` tolerance              | **±60 seconds** of server time                                                                 |

A requested TTL outside `[60s, 90d]` is clamped into range rather than rejected.

<Warning>
  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.
</Warning>

## Guardrail bounds

| Limit                                               | Value                                 | What it means                                                                                                                                                              |
| --------------------------------------------------- | ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Prompt-firewall scan window                         | **64,000 characters**                 | The firewall scans the first 64 KB of extracted prompt text. Text past it is not scanned.                                                                                  |
| Streaming hold-back window                          | **96 characters** minimum, 96 default | The sliding tail the streaming redactor holds back. Values below the floor are raised to it, because a smaller window silently loses detection of anything longer than it. |
| Streaming hold-back ceiling                         | **8 KB**, or 8× the configured window | A pattern that never completes is redacted rather than held for ever.                                                                                                      |
| Content blocks tracked per stream                   | **64**                                | One redaction window per block (`n>1` completions, multi-block messages). Past 64 the extras share a window: still redacted, only their interleaving degrades.             |
| MCP sessions per token, per server, per environment | **4**                                 | The least recently used is closed when a fifth is opened.                                                                                                                  |
| MCP session idle timeout                            | **5 minutes**                         | Swept every 60 seconds.                                                                                                                                                    |

## Caching

| Limit                         | Value                                                                      |
| ----------------------------- | -------------------------------------------------------------------------- |
| Cache TTL                     | `cache_ttl_seconds` on the agent, default **0** (no expiry-based eviction) |
| Semantic similarity threshold | `cache_similarity_threshold`, default **0.95**                             |
| What is cacheable             | buffered `2xx` responses only — streaming responses are never cached       |

## 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](/ai-gateway/budgets-finops), 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](https://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](/ai-gateway/budgets-finops#failover-chains-a-different-kind-of-fallback)
  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.
