Model Administration

Virtual models are stable client-facing names compiled from Git-managed provider deployments. catalog.read authorizes ordinary catalog access; organization.settings.manage authorizes the model administration page, Provider routes and connection diagnostics. Organization membership alone grants neither. A Team allowance and the actual virtual-key policy together make a model callable; see Enable models and tools in a team.

Each row on Models & tools shows the logo for its primary route when that route resolves to OpenAI, Anthropic, or DeepSeek. If Mission Control does not recognize the provider model, provider ID, or official provider hostname, the row shows the first letter of the virtual-model name instead. This visual marker does not change route priority or fallback behavior.

Use Native providers for Anthropic, AWS Bedrock, Azure OpenAI and Google Vertex AI configuration, cloud credentials and operation-specific profiles. The instructions below continue to describe existing OpenAI-compatible routes. Model guardrails apply at the canonical model boundary.

Register or change a model

1. Add or update provider and model deployment entries in organization YAML.
2. Ensure every provider credential reference resolves in the gateway environment.
3. Have the operator validate the files and restart gateway and Console.
4. Open Access → Models & tools and select the virtual-model name.

The model page displays model:<virtual-name> from loaded configuration. If absent, confirm the organization, provider reference and virtual name in the files used to start the services.

Upgrading to vendor profiles

A provider that names no profile is generic. Name openai, anthropic-compat, or deepseek when the provider's base URL is that vendor; otherwise leave it generic, which sends the output limit as max_tokens and forwards neither metadata nor store. A direct caller that sends metadata or store: false to a generic deployment now receives capability_unavailable instead of having the field silently forwarded, so name the vendor profile before such callers upgrade. The profile table lists what each one changes.

Restart the services after changing profiles. Historical connection checks remain evidence; they do not become current-process results or route eligibility after restart.

Review routing

Every authorized model viewer can inspect Guardrail policies on the model page: inherited Organization baseline, model additions, rule categories and streaming behavior. Full rule definitions remain settings-manager-only. Configure policies through reviewed YAML; the model page is read-only. Provider profile in the route table is the provider protocol dialect, separate from content policies.

The Provider routes table shows:

• deployment ID and provider model;
• priority and weight;
• provider ID and base URL;
• vendor profile;
• credential Resolved or Unresolved state;
• Test connection for each route.

Lower priority values are considered first. Weight participates among eligible routes with the same priority. Fallback IDs must resolve to deployments for the same virtual model and cannot contain cycles.

The profile decides which request fields reach the provider and how the output-token limit is named; see Providers and models.

Test a deployment

Select Test connection on the desired route. The gateway performs the provider's configured non-inference model-list request, authenticates it with the environment-resolved credential, confirms that the route's exact provider model is present, and records a diagnostic health check with its checked time. It does not generate model output or incur inference-token charges. The result appears next to the button as Healthy · n ms or Unhealthy · category · n ms; if the gateway itself cannot run the check, the message says so.

The organization YAML controls the model-list path and whether the credential is sent as Bearer or x-api-key; see Providers and models. Redirects are not followed. A non-2xx response, including a redirect, is recorded as provider_status_<status>. A successful response that exceeds 1 MiB, is malformed, or does not list the configured provider model is recorded as provider_model_unavailable. Correct the provider path, authentication mode, required default headers, workspace, key, or provider model; restart the gateway after changing an environment credential, then retry the explicit check.

The Connection checks history shows Probe passed or Probe failed, Provider route, latency, safe error category and checked time; an empty history reads Not tested. It displays the latest 20 checks across this virtual model’s current routes, restricted to the currently loaded configuration hash before the row limit is applied. Returning to an earlier configuration can therefore show its matching checks even after many newer checks under another hash. These are historical diagnostics, not a current-process readiness claim; unsupported probes remain unknown. Request outcomes and financial usage are in Observe, not a separate model Usage pane. A healthy model-list test does not prove generation works. Model checks are manual and use no paid inference probes. Stored health never excludes a route for generation, embeddings or reranking; actual calls use configured capabilities, bounded attempts and fallback. Normal calls still require the model to be enabled in the caller's team, an allowed key operation/resource policy, current budgets and loaded configuration.

Inspect request outcomes and usage

Use Observe → Requests for canonical decisions and physical attempts, filtered by the model/resource. Usage summarizes ledger known/estimated/unknown amounts under usage.read. A provider error may contain request fragments, so any captured error detail requires separate observability.content.read and capture policy; settings permission alone is not a content grant.

Each physical provider attempt records its own outcome, including provider rejection, account rejection, rate limit, unavailable transport or invalid response. Local decision/accounting failure never authorizes another provider retry. Keep the safe correlation ID and reconcile uncertain work before retrying.

Organization, Team, member/service, key and customer caps are managed under Budgets. Finite spending caps reserve priced bounded liability before dispatch. Each physical attempt settles once; unknown work retains its debit until confirmed/recovered. Prices affect future attempts after a YAML restart and do not rewrite historical facts.

Visibility for everyone else

A viewer with catalog.read can open Models & tools and inspect virtual model identifiers. Provider routes remain restricted to Organization settings managers. GET /v1/models independently filters by the actual key's Team allowance, selected resources and operations; seeing a catalog entry is not permission to invoke it.

Evaluation readiness evidence

Credential configuration, gateway resolution, connection probes and successful invocation are separate facts. Connection checks reports Probe passed or Probe failed; it does not certify tool continuation or structured judge output, and stored probe health does not determine routing. Evaluation users can inspect gateway-local readiness without receiving credential references or Organization administration rights. For catalog changes, validate the configuration and restart both gateway and Console before repeating readiness. Use the paid smoke procedure for actual governed execution evidence.

Case reasoning support requires an explicit per-provider or per-deployment capabilities.reasoningEfforts declaration for an actually supported upstream model. Only the OpenAI profile with Chat Completions upstream currently supports it. Managed evaluations require the effort on every route, without silently selecting another model. See configuration fields and case authoring.