Skip to Content
Known Limits

Known Limits

This page is a quick index of the boundaries developers most often need to plan around. The full coverage and non-claim model lives on Scope and Limits.

Provider coverage

Provider operation coverage is not uniform. OpenAI has the broadest operation coverage; other providers focus on text generation and streaming with narrower coverage for advanced operations. See Provider Support and Scope and Limits § Provider coverage.

Routing

Routing is explicit and recorded; Keel does not perform autonomous fleet-wide selection. See Routing and Scope and Limits § Routing scope.

Replay and idempotency

Replay and idempotency guarantees are route-dependent — proxy routes have the strongest same-key replay binding; other routes are narrower. See Idempotency and Scope and Limits § Replay and idempotency.

Permit-first observation

When the caller executes downstream of POST /v1/permits, Keel records the decision but does not directly observe the provider call. Use the verification track to attach receipt evidence, or use a Keel-managed execution route when execution-bound enforcement matters. See Scope and Limits § Permit-first observation boundary.

Accounting precision

For complex multimodal traffic, pre-dispatch budget decisions can rely on heuristic token estimates and reconciliation closes the gap. When provider-final usage is missing, terminal accounting can remain estimated. See Scope and Limits § Accounting precision.

Content inspection

The Prompt Firewall is a deterministic detection layer for well-defined risk patterns, not a semantic prompt-injection defense. Coverage is route-scoped. See Prompt Firewall and Scope and Limits § Content inspection.

Trust tier differences

Audit and integrity features have a plan-tier ladder. See Trust & Integrity and Plans & Entitlements.

Out of scope today

  • Realtime session APIs.
  • Operator deployment internals.

See Scope and Limits § Out of scope today.

What to rely on

  • Permit-first governance is the core Keel model.
  • Public routes and request contracts documented on this site are the supported integration surface.
  • Route-specific guarantees are intentional; do not generalize across surfaces.
  • Undocumented behavior should not be treated as stable.
Last updated on Edit this page on GitHub