Model Registry

The Model Registry is the list of models a project is allowed to use. Application code should call Olyx through the SDK; the registry decides which provider endpoint, credentials, token rates, and routing tier are available behind that call.

During closed beta, start with one or two models you can reason about. Add private routes, fallback chains, and additional providers only when trace data shows you need them.

Why Use It

The registry keeps provider configuration out of application call sites.

The registry is not a pricing source of truth for every provider. Keep provider prices current in your own settings and verify them during billing review.

Registry Shape

Each registry entry describes one model endpoint.

Adding a Model

Add models from the dashboard during normal beta setup. The API reference contains the low-level create and update endpoint details for automation.

Use a small entry first.

{
  "name": "GPT-4o Mini",
  "identifier": "gpt-4o-mini",
  "provider": "openai",
  "base_url": "https://api.openai.com/v1",
  "is_public": true,
  "input_cost_per_1k": 0.00015,
  "output_cost_per_1k": 0.0006,
  "data_retention_days": 30,
  "currency": "usd"
}

After creation, responses should show whether a provider credential exists without returning the secret itself.

Public vs Private Models

Use is_public as a routing and review signal. It does not magically make a network path private; it tells Olyx how the project intends to classify the model route.

Private model routes require infrastructure setup outside the registry. For most closed-beta teams, start with public models and add private agent routes only when the workload needs that network posture.

Routing Tiers

Routing tiers map project behavior to registered model identifiers. The SDK call stays the same; project settings decide which registered model handles the request.

Example project setting:

{
  "routing_tiers": {
    "simple": "gemini-2.0-flash",
    "medium": "gpt-4o",
    "complex": "claude-sonnet-4-6",
    "secure": "private-llama"
  }
}

Each value must match a registered model identifier in the project.

Fallback Chains

Fallback chains give non-sensitive workloads a secondary path when the primary model is unavailable. Keep them short and easy to explain during beta.

{
  "additional_config": {
    "fallback_identifier": "gpt-4o-mini"
  }
}

Tool Support

Tool definitions should be written once at the SDK layer. Olyx normalizes them for the selected model path where the provider adapter supports tool calling.

For SDK examples, use MCP and Architecture. Keep provider tool differences out of application business logic wherever possible.

Recommended Beta Setup

Start small enough that each route can be explained from traces.

This keeps the registry useful without making the closed-beta setup look overbuilt.