Supported Models

Supported Models

Refact supports multiple provider families, and each model is described by capability flags resolved from provider config and /v1/caps.

Supported models in Refact are not a fixed, global catalog. They come from the provider families you configure, the provider/runtime catalogs, and the capability data the engine serves from /v1/caps. That means availability, pricing, quotas, rate limits, and data-policy are inherited from the provider you connect, not from Refact itself. See BYOK, Caps and Models, and Code Completion (FIM).

Provider families supported by the engine

The engine and GUI code show these provider families in the current registry and default-provider templates:

• OpenAI
• OpenAI Responses
• OpenAI Codex
• Anthropic
• Claude Code
• OpenRouter
• Groq
• DeepSeek
• Google Gemini
• LM Studio
• Ollama
• vLLM
• xAI
• Qwen
• Kimi / Moonshot AI
• Z.AI / Zhipu
• MiniMax
• Doubao / Volcengine
• GitHub Copilot
• Custom provider / OpenAI-compatible endpoint

The provider registry also includes dynamic and OAuth-backed flows for some of these families. The GUI names come from the Providers feature constants, while the engine’s registry and YAML templates define the actual provider behavior.

How capabilities are represented

Refact models carry capability metadata such as:

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

The caps layer also includes related fields used by chat and routing logic, such as completion support, cache control, thinking-budget/reasoning controls, and per-model default selections.

Important distinction: a model can be available in a provider catalog without being suitable for every task. The capability flags tell Refact how to route it.

Common capability meanings

• supports_tools: the model can participate in tool-using chat/agent flows.
• supports_agent: the model is appropriate for agent-style workflows.
• supports_multimodality: the model accepts non-text input modalities when enabled.
• supports_reasoning: the model is treated as reasoning-capable by the capability resolver.
• n_ctx: the model context window used for budgeting and UI defaults.
• tokenizer: the tokenizer identifier used by the engine/UI for token counting and related model behavior.

Chat vs completion vs embedding

Refact treats the roles separately:

• Chat: ordinary conversational models, tool use, and agent workflows.
• Completion: code completion, especially FIM-style models.
• Embedding: vector models for search / retrieval.

A provider may support one, two, or all three of these roles. The default provider YAML files make this explicit with fields like supports_completion, chat_endpoint, completion_endpoint, and embedding_endpoint.

Completion and FIM

Completion models are especially important for inline code completion. The engine’s completion scratchpad uses FIM (Fill-in-the-Middle) conventions, and the default configs include FIM-oriented model settings for providers such as Ollama.

Embeddings

Embedding support is configured independently. The engine’s embedding transport expects OpenAI-style embedding requests for supported providers, and the default provider templates show providers such as OpenAI, OpenAI Responses, Google Gemini, and OpenRouter with embedding endpoints.

How the engine resolves capabilities

Capability data is surfaced through the engine’s /v1/caps endpoint. The /v1/caps response is loaded by the IDE clients and is used to drive model selection, model defaults, and feature availability.

Under the hood, the engine loads provider configs, merges default model selections, and computes model capabilities from provider/runtime metadata. For some providers, model lists are dynamic and are matched against caps data at runtime.

That means the model capability you see in the UI is a resolved result, not just a static label.

Model selection and defaults

Provider configs can set different defaults for different roles. The caps model config includes fields such as:

• completion_default_model
• chat_default_model
• chat_model_2
• task_planner_agent_model
• reasoning_default_model
• embedding_model

These defaults let each provider choose a preferred model per role without hard-coding a universal model ID into the docs or UI.

What is not fixed by Refact

Because model availability comes from the configured provider, Refact does not define:

• provider-side pricing
• quota limits
• per-provider data retention policies
• account access rules
• whether a specific vendor model is available in your region or plan

Those properties come from the provider you configure.

Related pages

• BYOK
• Caps and Models
• Code Completion (FIM)