Provider access stays separate from application control.
01
Use Google's documented compatibility layer
Existing OpenAI-library clients can call the gateway's conventional endpoint while the provider adapter uses Google's published OpenAI-compatible base. The selected Gemini model still has to support the exact request being sent.
02
Give each application its own boundary
Issue a separate workload key for each environment or service, then attach its route, budget, request rate, token rate, and concurrency limit. The Google API key remains outside application configuration and source control.
03
Verify access before spending tokens
The connection test reads the current model catalog rather than generating a response. Administrators can review the credential state and eligible route targets before a client is allowed to send paid inference traffic.
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 Google Gemini, enter the API key once in the write-only credential form, verify the current model catalog without generating tokens, and validate the exact chat or embedding model before production use.
POST /v1/chat/completions POST /v1/embeddings GET /v1/models connection test
Compatibility is bounded to the provider's current published interface. Review the provider documentation before approving a production model.