Model Management turns real upstream models into user-facing platform models. Administrators manage model name, vendor, kind, visibility, route sources, capabilities, system prompt, native tools, and display order.

Entry Point#

Open Models in the admin console. The page lists platform models and supports searching by platform model name, vendor, or description, plus filtering by status, protocol, vendor, and kind.

Platform models are what users see. Upstream models are provider models. A platform model can bind multiple upstream sources for failover, load distribution, cost control, or provider migration.

Platform Model List#

The list shows status, kind, vendor, source count, and access scope. Status can be active, inactive, or circuit open. Access scope can be public or internal task.

Public models appear in user model selectors. Internal task models are better for title generation, label generation, summary compaction, OCR fallback, and other background tasks.

Create and Edit Models#

When creating a model, first decide its purpose: chat, audio, image generation, image edit, or video generation. Then fill platform model name, display name, vendor, description, status, and access scope.

Editing a model lets administrators adjust model prompt, capabilities, native tools, source bindings, and display information. A model-level system prompt is appended after the global system prompt and can add behavior rules for that specific model.

Upstream Sources and Routing#

Platform models need one or more upstream sources. A source usually includes upstream name, real model, protocol, binding code, weight, priority, and status.

Multiple sources support failover and provider distribution. Priority decides which source class is tried first, and weight distributes traffic among sources at the same priority. Disabling one source keeps the platform model but reduces available routes.

Capabilities#

Capabilities describe what a model can do in user workflows and system tasks: text, image input, tools, reasoning, image generation, image edit, video generation, streaming, and more.

Capability settings should match the real upstream. If a capability is enabled but unsupported upstream-side, users may hit failures for that task. After capability changes, test critical paths.

Native Tools#

Model Management controls which official native tools a model may use. Only tools enabled by administrators here can appear in user-side conversation configuration.

For the full relationship between capabilities, pass-through, native tools, and tool billing, see Capabilities & Native Tools.

When users provide custom tool options, the system keeps only administrator-allowed native tools. Unknown, disallowed, or policy-filtered tools are removed, keeping tool exposure controlled.

Order and Visibility#

Display order controls the model selector order. Stable, recommended models should be near the top. Experimental or internal task models should stay internal or disabled.

When a model is no longer recommended, disable it or make it internal before deleting. Confirm route and billing dependencies before deletion.

Model Testing#

Model tests verify whether the platform model and upstream sources are available. Results show usable, error, timeout, or unsupported, with latency and source information.

After adding upstreams, changing routes, replacing credentials, changing protocol, or editing capabilities, test related models. Bulk testing is useful before release.

Practical Tips#

Start with a small set of core models and stabilize names, capabilities, and routes before opening more models. Before exposing a model to users, finish source bindings, capability checks, billing prices, and model tests. Keep internal task models separate from user models.