Models
Browse every model your organization can use — catalog and custom — with compliance eligibility
The Models page shows every model available to your organization in one directory: the full LLM Gateway catalog plus any models defined for your own custom providers. When your organization enforces a provider compliance policy, the page also shows exactly which models are eligible to route to — and why the rest are blocked.
Every organization member can browse this page, including project-scoped developer members, so your whole team can see which providers and models are available without needing admin access. Management actions are only visible to owners and admins.
The directory
The directory is the same table you know from the public models page, with one row per provider mapping:
| Column | Description |
|---|---|
| Provider | The provider serving the model; custom providers carry a Custom badge |
| Model ID | The model id; the copy button copies the exact string to request |
| Input / Output $/M | Prices per million tokens (per-request/per-character where applicable) |
| Cache Read $/M | Cached input price where supported |
| Features | Capability icons: streaming, vision, tools, reasoning, JSON output, … |
Search matches model names, ids, aliases, and providers. The Filters panel offers the same controls as the public directory — use case, capabilities, provider, price and context ranges — plus two controls specific to this page:
- Source — show Catalog & custom (default), only Catalog models, or only Custom models. The selector appears once your organization has custom models.
- Eligible only — hide models blocked by your organization's compliance policy.
Lifecycle status
Every provider mapping carries exactly one lifecycle status, shown as a badge on the mapping and selectable from the Status chips in the filter panel:
| Status | Meaning |
|---|---|
| Deprecated | Still routes; the provider has announced a sunset, so migrate soon |
| Scheduled | Still routes, but deactivation is set for a date inside the next 90 days |
| Deactivated | No longer routes; requests return errors |
Status resolves by urgency — deactivated beats scheduled beats deprecated — so a
mapping never carries two, and a deactivation further out than the 90-day notice
window stays plain active rather than warning early. The chips are single-select
and write to ?status=, so a filtered view can be shared.
With no chip selected, the directory lists everything routable and hides mappings already past their deprecation or deactivation date.
Time-based pricing
A few provider mappings bill different rates depending on when the request arrives. Those cards carry a Time-based pricing toggle: switch between Peak and Off-peak to see each set of input, cached-input, and output prices, with the schedule that decides which one applies spelled out underneath — the peak hours, their time zone, and any days that are off-peak all day.
Billing follows the same schedule automatically at request time; there is nothing to set on your side. To pay off-peak rates, move batch or backfill work into the off-peak window.
Compliance eligibility
When your organization is on the Enterprise plan and its provider compliance policy is enabled, every row is evaluated with the same fail-closed rules the gateway enforces at request time — certifications (SOC 2, ISO 27001, GDPR), data-policy requirements (no training on prompts, no prompt logging), country restrictions, and provider/model allow and deny lists.
Rows that fail render greyed out with a red ban icon; hover it to see the exact reasons, such as "No SOC 2 Type 2 report" or "Not on the allowed-providers list". Custom providers are evaluated against their compliance attestation — without an attestation on file, all requests through them are blocked while a policy is active.
Eligibility marking requires an active compliance policy, available on the Enterprise plan. Without one, the directory simply lists all models. Configure the policy on the Compliance page.
Custom models
Models from your organization's custom-model catalog appear in the same table, addressed as <provider>/<model> (e.g. internal-vllm/llama-4-maverick) — the exact model string to send to the gateway. Their pricing, context size, and capability flags come from the catalog entries you define.
Owners and admins additionally see the Custom model catalog section below the directory:
- Custom provider — pick which custom provider key's catalog to manage
- Only allow catalog models — when on, requests through the provider are limited to the models defined in its catalog so cost and context limits are always enforced
- Compliance attestation — record the compliance posture of the infrastructure behind the provider; the policy evaluates it with the same fail-closed rules as catalogue providers
- Add / edit / delete custom models — define per-model pricing, context and output limits, and capabilities
The custom model catalog requires the Enterprise plan. Custom provider keys themselves are created on the Provider Keys page.
How is this guide?
Last updated on