Upstream Management connects model providers or compatible services. Administrators manage upstream name, service address, compatibility protocol, credentials, timeouts, defaults, remote models, and circuit status.
Entry Point#
Open Upstreams in the admin console. The page lists upstreams and supports searching by name or address, plus filtering by status and compatibility.
Upstreams are the real sources behind platform models. Users choose platform models; platform models route to one or more upstream models. Upstream availability directly affects model reliability.
Upstream List#
The list shows name, address, compatible protocol, model count, timeout settings, update time, and status. Status can be active, inactive, or circuit open.
Administrators can enable or disable upstreams and delete them in bulk. Disabled upstreams no longer participate in routing. If a platform model depends on that upstream, its available sources are reduced.
Create and Edit Upstreams#
When creating an upstream, set name, service address, compatibility type, and request protocol. Depending on provider and protocol, you can also configure credentials, default headers, default parameters, timeouts, retry, model kinds, and capability scope.
Credential fields are usually not fully shown after saving. Leaving them blank while editing usually keeps the existing secret; entering a new value replaces it.
Use clear names for providers, regions, or business purposes, such as “OpenRouter Production”, “Internal Gemini”, or “Image Backup”.
Remote Model Sync#
Upstreams can sync remote models. After sync, administrators can add remote models as platform model sources or use them when managing route bindings.
Remote sync is useful when providers frequently add models or when onboarding a model catalog in bulk. Before syncing, confirm that upstream address, credentials, and protocol are working. After syncing, review model kind and capabilities.
Route Bindings#
Upstream management can show and manage route bindings for the selected upstream. Bindings decide whether a real model is one source for a platform model.
Before maintaining, disabling, or deleting an upstream, check bindings to understand the impact. When replacing a provider, create the new upstream and bindings first, test affected models, then disable the old upstream.
Circuit Management#
When an upstream has repeated failures or instability, it may enter circuit-open status. Circuit-open upstreams reduce or stop participation until the expected recovery time.
Administrators can manually open or reset the circuit. Manual circuit opening is useful during provider maintenance, credential problems, insufficient balance, or network instability. Reset only after confirming recovery.
Timeouts and Retry#
Timeouts affect user waiting time and failure detection. Chat models usually need shorter, stable timeouts. Image, video, OCR, or long-running providers may need more time.
Retry can reduce transient failures, but too many retries increase waiting time and cost risk. Set it by provider stability, model kind, and business priority.
Practical Tips#
Start with a few core upstreams and complete model sync, then configure platform model routes. Production deployments should prepare fallback upstreams for critical models. After changing credentials, address, protocol, or timeout, test affected platform models in Model Management.