Model Management.
Automatic model discovery, metadata registry, access controls, aliases, and categorisation for every provider.
Automatic Model Inventory
On startup and periodically thereafter, Aurora queries each configured provider's/modelsendpoint to build a live inventory of available models. This inventory is stored in the model registry and exposed via the gateway's own/models endpoint. When a provider adds or removes models, Aurora picks up the changes automatically — no manual updates required.
External Model Metadata Registry
Beyond model names, Aurora maintains a rich metadata registry for each model. This data is periodically fetched from external sources (provider APIs, community registries) and includes:
Pricing
Per-token input/output costs, cached-read discounts, and batch pricing tiers.
Capabilities
Supported features: chat, responses, embeddings, function calling, vision, streaming.
Context Windows
Maximum input tokens, max output tokens, and context window size per model variant.
Local Metadata Overrides
You can override any metadata field locally for specific models. This is useful when you have negotiated custom pricing with a provider, want to enforce a lower max-token limit, or need to mark a model as deprecated internally. Overrides take precedence over auto-fetched data and are persisted in the gateway database.
Model Access Overrides
Control which users and keys can access specific models. Access overrides are defined per provider, per model, and can be scoped to a user_path:
Allow
Explicitly permit access to a model for a given provider + user_path combination.
Deny
Explicitly block access. Deny rules take precedence over allow rules.
Model Aliases
Model aliases provide stable names that abstract away provider-specific model identifiers. They enable two powerful use cases:
- Stable naming — define an alias like
fast-chatthat points to a real selector from/admin/api/v1/models. When you want to switch targets, update the alias — no client changes needed. - A/B testing via shadowing — an alias can point to multiple models simultaneously. A percentage of traffic goes to the shadow model, letting you evaluate new models in production before switching fully.
KEEP_ONLY_ALIASES_AT_MODELS_ENDPOINT
When this configuration flag is enabled, the gateway's GET /models endpoint returns only aliases — not raw provider model names. This simplifies the model surface exposed to clients, ensuring they only see the curated, stable names you control. The raw model inventory is still available via a separate admin endpoint.
Model Categories Endpoint
Aurora exposes a GET /models/categories endpoint that groups models by capability category (chat, embeddings, image generation, audio, etc.). Each category lists the available models and their metadata. This is particularly useful for client applications that need to dynamically render model selection UIs grouped by capability.