Model Management

--- title: "Model Management" description: "Expose stable model names, configure access rules, and manage provider model inventory from Aurora." icon: "tags" ---

Overview

Aurora separates the model name your app sends from the provider model Aurora uses upstream. This gives operators one place to manage aliases, model access, configured provider inventories, pricing metadata, and model visibility.

Use the admin dashboard at Models for the interactive flow.

Aliases

An alias is a stable model name that points to a concrete provider model. Your app sends the alias in the model field, and Aurora resolves it before sending the request upstream.

For example, after you confirm the real upstream model IDs from GET /admin/api/v1/models, you can create aliases such as:

regular -> <provider-name>/<standard model id>
smarter -> <provider-name>/<larger model id>

Your app can then send:

{
  "model": "regular",
  "messages": []
}

Shadow models

An alias can use the same name as an existing model. This lets you redirect an existing application model string without changing application code.

For example, if an app already sends a provider model ID, create an alias with that same name and point it to another real selector from the admin model list. The app keeps sending the old model string; Aurora resolves the alias before the upstream request is made.

Expose only aliases

To hide provider model inventories from GET /v1/models, set:

KEEP_ONLY_ALIASES_AT_MODELS_ENDPOINT=true

When enabled, Aurora returns enabled aliases from /v1/models instead of the full upstream model list.

Model access rules

Model access overrides can limit which callers see or use a provider, model, or alias. Rules can target:

• / for all providers and models
• {provider_name}/ for one configured provider
• {provider_name}/{model} for one model on one provider
• a model ID without a provider name

Attach user_paths to a rule to scope access to a team, service, customer, or tenant subtree.

Configured model lists

Every provider supports configured model lists with <PROVIDER>_MODELS, such as:

OPENROUTER_MODELS=openai/gpt-oss-120b,anthropic/claude-sonnet-4
ORACLE_MODELS=openai.gpt-oss-120b,xai.grok-3

By default, CONFIGURED_PROVIDER_MODELS_MODE=fallback uses configured lists only when upstream /models is unavailable or empty. Set CONFIGURED_PROVIDER_MODELS_MODE=allowlist to expose only configured models for providers that define a list.

Pricing metadata

Aurora can track model pricing metadata for usage analytics and cost reports. Keep pricing current when you add aliases or provider-specific model IDs so dashboard cost analytics stay meaningful.

Manual management

Use the dashboard at Models to inspect inventory, create aliases, edit access overrides, and update pricing overrides. For static inventory hints, configure provider model lists in YAML or environment variables:

providers:
  local-vllm:
    type: vllm
    base_url: "http://localhost:8000/v1"
    models:
      - id: my-local-chat-model
        metadata:
          display_name: "My local chat model"
          context_window: 32768
          max_output_tokens: 4096
          modes: ["chat"]
          capabilities:
            tools: true
          pricing:
            currency: USD
            input_per_mtok: 0
            output_per_mtok: 0

Set CONFIGURED_PROVIDER_MODELS_MODE=allowlist when you want Aurora to expose only configured models for providers that define a model list. Leave the default fallback mode when you want Aurora to prefer upstream /models and use the configured list only if upstream discovery is unavailable.

Server API automation

For endpoint reference see the Admin API section.

Access override example:

curl -X PUT "http://your-aurora-host/admin/api/v1/model-overrides/openai-primary%2Fmy-model" \
  -H "Authorization: Bearer $AURORA_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true,
    "user_paths": ["/team/alpha"]
  }'