> ## Documentation Index
> Fetch the complete documentation index at: https://aidocs.ethanbragdon.icu/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

<Note>
  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.
</Note>

<Card title="Models & routing" icon="shuffle" href="/chat/models-routing">See how capability requirements affect model selection and fallback.</Card>