Migrate from OpenRouter
Move an OpenRouter client to Cortex Egress Gateway while preserving its native request shape and checking routing compatibility.
Get the organization-issued client URL, personal cct_ capture token and enabled model ID from Gateway setup. Use those values for <CORTEX_API_KEY>, <organization-issued-url-for-your-client> and <organization-enabled-model> below. The client token is separate from organization-managed provider credentials.
Switch from OpenRouter
Keep the compatible native request shape. Change the connection values and choose an explicit model on your organization's pricing sheet:
- OPENROUTER_API_KEY=<your-key>
- OPENROUTER_BASE_URL=<openrouter-base-url>
- model=openrouter/auto
+ CORTEX_API_KEY=<CORTEX_API_KEY>
+ CORTEX_BASE_URL=<organization-issued-url-for-your-client>
+ model=<organization-enabled-model>- Gateway uses separate organization-managed provider credentials for upstream calls.
cortex/autois not a built-in gateway alias.- Egress resolves the requested model through the organization's pricing sheet before Smart Router runs.
| What changes | What stays compatible |
|---|---|
| Gateway URL and capture credential | The native request shape, including model and messages |
| Model identifier and managed routing settings | Your existing OpenAI-compatible SDK |
| Anthropic's capture header | Your application's native response handling |
- OpenRouter routing extensions such as provider ordering or fallback model lists are not Cortex request controls.
- See Routing controls before migrating those settings.
Choose automatic or fixed routing
Send an explicit organization-enabled model for the forwarding baseline. An OpenRouter routing setting does not enable Cortex Auto Router: an administrator must configure managed routing for a qualified client and request path, such as Codex using Responses. The Auto Router guide covers that configuration and its decision evidence; the first-request SDK examples do not activate it.
Verify the connection
After changing the client, follow Gateway's response and capture checks with a short test request. A provider response confirms forwarding; matching activity in enabled Atlas confirms capture and account attribution separately. Shared Egress does not require a local Defender installation or an Atlas subscription.
For automatic routing on a qualified path, inspect the routing decision. Compare the requested model, selected target and captured provider response separately.
If the request fails, use Gateway troubleshooting and the API reference for the returned error and retry guidance. For Codex-specific settings, use Client-specific setup. Operating a shared gateway is a separate deployment task.