Provider access stays separate from application control.
01
Expose an approved subset
OpenRouter can surface a broad and changing catalog. AI Gateway HQ places stable aliases, workload identity, budgets, and policy in front of the models an administrator has actually reviewed instead of exposing the upstream catalog directly to every application.
02
Attribute spend to the workload
Every application receives its own scoped gateway key and principal. Receipts record the selected alias, resolved provider target, token usage, cost, policy result, and failure reason so shared upstream access does not erase internal accountability.
03
Control fallback at both boundaries
The gateway evaluates health, budget, rate, policy, and protocol compatibility before sending a request. Upstream routing remains an OpenRouter concern; company-owned fallback and hard-stop behavior remain visible and testable at the gateway boundary.
Current shared controls
Status determines what can be configured.
Write-only, encrypted BYOK for implemented provider connections Stable model aliases and protocol-eligible route targets Organization and key budgets, RPM, TPM, and concurrency hard limits Observe, Shadow, Enforce, reason codes, and metadata-only evidence
Beta connections require customer validation against the exact model, payload, streaming mode, region, and provider account before production use.
Applications keep a stable gateway URL and model alias while an administrator changes eligible provider accounts and models.
Implemented boundary
Only documented protocols become eligible.
Choose OpenRouter, enter its API key in the write-only credential form, verify the current catalog without inference, and expose only reviewed model targets through company-owned aliases.
POST /v1/chat/completions OpenAI-compatible streaming GET /api/v1/models connection test
Compatibility is bounded to the provider's current published interface. Review the provider documentation before approving a production model.