Caps and Models

Caps and Models

How Refact resolves model capabilities, role-specific defaults, and the default model selection rules.

Refact resolves model capability data through /v1/caps by combining provider output, model metadata from the capabilities registry, and provider/runtime defaults.

Capability resolution

The capabilities endpoint is built in src/caps/caps.rs and src/caps/model_caps.rs. It loads model capabilities, then maps provider models into chat/completion/embedding records.

For a provider model, the engine resolves settings such as:

• n_ctx
• supports_tools
• supports_agent
• supports_multimodality
• supports_reasoning
• tokenizer

If a model is known to the registry, those capabilities can constrain or override the provider-reported settings. If it is not in the registry, the provider-reported values are used directly, with a fallback tokenizer of fake when needed.

Model roles

Refact treats models by role:

• Chat models: interactive conversational use and tool calling.
• Completion models: code completion, especially fill-in-the-middle models.
• Embedding models: vector search and semantic retrieval.

Provider defaults are role-specific, and the ProviderDefaults structure carries separate default settings for chat, completion, and embedding.

Default model selection

The engine keeps dedicated default model slots for each role. In the capabilities assembly path, chat defaults are not auto-filled silently; completion defaults are auto-selected only when the current default is empty or points to a missing model. The first available completion model is chosen as the fallback default.

Supported Models

Model capability data comes from the model capabilities registry and the models.dev catalog. That registry is the source of truth for which models are supported and how their capabilities should be interpreted.

Related pages

• Providers
• Supported Models