Model Capability Reference

Compare the capability categories Starfire uses when deciding whether a model can handle reasoning, tools, vision, structured output, research, or FORGE.

Model capability reference

Starfire models are not interchangeable. The model catalog records capability metadata so the product can decide whether a route is eligible for a specific workload.

Capability categories

Capability	What it means
Context window	Maximum context the route can accept before platform overhead and output reservation.
Maximum output	Maximum response size supported by the route/configuration.
Streaming	Response can be delivered incrementally.
Reasoning	Model supports deeper reasoning modes or reasoning-specific configuration.
Vision	Model can interpret supported image inputs.
Tool use	Model can call Starfire tools when the workflow allows it.
Structured output	Model can reliably target JSON/schema-style output when supported by the route.
Embeddings	Model/route can create vector embeddings rather than conversational output.
Research eligibility	Route is permitted for Starfire research workflows.
FORGE eligibility	Route is permitted for code/build workflows.

Effective eligibility

A model can have a capability and still be unavailable to a request because of plan, organization policy, feature rollout, provider health, or a user/resource override.

Choosing a model

For interactive writing or routine questions, prioritize responsiveness and sufficient context.

For difficult planning, complex debugging, or architecture work, a deeper reasoning-capable model can be more appropriate.

For image analysis, tools, FORGE, or research, required capabilities are non-negotiable—a fallback that lacks them is not equivalent.

Capability matrix

The exact per-model matrix should be generated from the live Starfire model catalog as that reference surface stabilizes. Do not copy a static matrix from an old release and assume it remains current.

Control Center model administration is the source of truth for operator-configured capabilities. User-visible documentation should reflect published model metadata, not private provider configuration.

Models & routing

See how capability requirements affect model selection and fallback.