Providers, routing & fallbacks
Model administration defines what a model is. Routing administration defines how Starfire reaches it and what happens when a route is unavailable.Provider console
A provider view can expose operational signals such as:- health state
- request volume
- latency
- success rate
- rate-limit responses
- server-error rate
- token throughput where applicable
- current and monthly provider cost
Routes
A model can have a primary route and one or more fallback routes depending on platform configuration. Route configuration can include concepts such as:- provider
- provider model identifier
- timeout
- retry policy
- circuit-breaker/health behavior
- capability constraints
- plan or workload eligibility
Capability-preserving fallback
Fallback is only valid when the alternate route can still satisfy the request. For example, a request that requires tools, vision, a large context window, research eligibility, or FORGE support should not be sent to a fallback that lacks those capabilities merely to avoid an error.Routing simulator
The Control Center architecture includes a routing-simulation concept: an operator can provide a hypothetical request context and inspect which route Starfire would select without actually sending the model request. A simulation can consider inputs such as:Health and incidents
If a provider or route becomes broadly unhealthy, use the incident system rather than applying random per-user changes.Costs
Provider cost information belongs in privileged administration. Cost visibility can help operators manage model availability and plan economics without exposing internal vendor pricing to ordinary users.Model administration
Configure model capabilities, availability, and metering metadata.
Incidents
Track broader provider or routing degradation through an incident timeline.
