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.
Related pages
- Scope and Limits — full coverage and non-claim model
- API Guarantees — public-API stability commitments
- Quickstart
- API Reference
- Security
- Trust & Integrity