Models and Routing

Models and Routing control how application requests choose an upstream model.

Optiak separates this into two layers:

• Organization model catalog - Admins enable the models the organization allows.
• Application model selection - Admins choose which organization-enabled models a specific application may use.

An application API key can only use models enabled at both layers.

Model Catalog

Admins manage the shared catalog in Company Setup -> Models.

The catalog is filtered by organization availability. Builtin models appear when the organization has a valid key for their provider. Enabled models from configured custom providers can also appear without an Optiak provider key.

Only models returned by the organization catalog are shown. The catalog does not expose builtin models that the organization cannot use or custom models that are not enabled.

Each catalog row shows user-facing model metadata such as:

• Provider
• Model name and description
• Context window
• Data residency
• Input and output cost per million tokens
• No-training support
• Smart Router eligibility
• Endpoint and capability labels, such as Chat Completion, Responses API, Streaming, Structured Output, Tool Calling, or Reasoning

Custom models may not provide context-window or pricing metadata; those values are shown as unavailable when the provider does not supply them.

The catalog can be searched, filtered, and sorted so admins can choose models that match cost, residency, and capability requirements.

Application Model Selection

Applications select from the organization-enabled catalog in Modules -> Models.

Use application model selection to keep different applications on different model sets. For example, a production customer-facing app can use a narrower set than an internal testing app.

The public GET /models endpoint returns the final model list available to the application API key. Use the id values from that response in Gateway API requests.

Direct Model Selection

Direct model selection is the simplest mode. The request names a public model ID:

{
  "model": "openai/gpt-5-nano"
}

The model must be returned by GET /models for the same application API key.

Smart Router

Smart Router lets a request use:

{
  "model": "smart"
}

When Smart Router is enabled, Optiak chooses from the application's enabled models that are also marked as smart-routing eligible.

Available strategies:

• Balanced - Balance cost and quality.
• Cost - Prefer lower cost per token.

If Smart Router is enabled but no eligible models are enabled for the application, the UI shows a warning and smart requests cannot be routed. Enable at least one smart-routing-eligible model or use a direct public model ID instead.

Governance Effects

Governance settings can affect which models are appropriate for the organization.

For example:

• Data residency can restrict processing to the EU when eligible models support it.
• Block providers for training on your data helps admins prefer models that do not use customer data for training.

Application model settings can narrow access further, but they cannot override organization governance or enable models that are disabled at the organization level.