Skip to main content

​
Models & routing

Starfire AI presents multiple AI models through one product layer. The goal is to let the platform evolve across providers without forcing users to understand provider-specific infrastructure for every request.

​
Model catalog

A model entry can describe capabilities such as:
  • provider and route
  • display name and API model identifier
  • context window and maximum output
  • reasoning support
  • streaming support
  • vision support
  • tool use
  • structured/JSON output
  • embeddings
  • research eligibility
  • FORGE/build eligibility
Administrators can also associate a model with pricing metadata, plan availability, health state, and routing behavior.

​
Direct selection

When direct selection is enabled, choose a model based on the workload rather than assuming the newest or largest option is automatically best. A fast model can be better for short interactive work. A deeper reasoning model can be better for difficult planning or analysis. A model without the required tool or context capability may be ineligible even if it is otherwise powerful.

​
Platform routing

Starfire can route requests using platform configuration. Routing can consider observable factors such as:
  • whether the account can access the model
  • required tools or modalities
  • context size
  • requested workload or mode
  • provider health
  • configured fallback routes
  • operational limits
The product docs describe the inputs and observable behavior of routing, not Starfire’s proprietary route-selection algorithm.

​
Fallbacks and retries

A model or route can become unavailable because of provider errors, timeouts, rate limits, maintenance, or capability mismatches. Starfire’s gateway can use configured retries or fallback routes where doing so preserves the request contract. Fallback should not silently change a request in a way that removes a required capability. For example, a request that requires vision or tools should not be transparently moved to a route that cannot perform that work.

​
Model availability

Model access can be controlled at several levels:
This is why two users can legitimately see different model lists.

​
Reasoning and cost

Reasoning depth, output size, context, and tool use can all affect compute consumption. The exact relationship is controlled by the current metering system and model configuration.

​
For administrators

Control Center provides deeper model and provider controls, including capability metadata, availability, routing, fallback, health, and cost configuration.

Model administration

Manage the model catalog and capabilities.

Routing & providers

Understand provider health, fallbacks, and routing administration.