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

# Models and Inference

> Choose inference providers, enable task models, and tune model roles for different kinds of Roomote work.

Models decide how Roomote thinks through a task.

The compute provider gives a Roomote agent a sandbox to work in. The inference
provider gives it access to the model that reads the prompt, reasons about the
workspace, writes code, runs tools, reviews output, and explains what changed.

Configure models from **Settings > Models**.

## Inference providers

An inference provider is the service that hosts or routes model calls. Roomote
supports providers such as OpenRouter, Vercel AI Gateway, OpenAI, Anthropic,
Moonshot AI, MiniMax, and OpenCode.

You can connect more than one inference provider in the same deployment. That
lets you mix and match models by provider instead of betting the whole
deployment on one account, one vendor, or one model family.

For example, a deployment might use:

* an OpenRouter-routed model for the default coding model
* a direct Anthropic or OpenAI model for planning or review
* a lower-cost provider model for helper work
* a vision-capable model only when visual inspection is needed

Connected providers only supply access. You still choose which provider/model
pairs are enabled for Roomote tasks.

## Model IDs

Roomote model IDs include the provider prefix, such as:

```text theme={null}
openrouter/openai/gpt-5.4
anthropic/claude-sonnet-5
openai/gpt-5.4
vercel/openai/gpt-5.4
```

The prefix matters because two providers can expose similar model families with
different routing, pricing, limits, or credentials. Keeping the provider in the
model ID makes the task history and settings clearer when you use several
providers at once.

## What Models settings controls

**Settings > Models** has two layers:

* **Inference Providers** stores the provider credentials Roomote can use.
* **Models** controls the provider/model pairs that are available, the default
  model, and specialized model roles.

Admins can enable or disable models from the task model list. The default model
must stay enabled, because Roomote uses it when a task does not request a
specific model.

Model settings affect new task starts. Running tasks and resumed snapshots keep
the model that was selected when they started.

## Model roles

Roomote can use different models for different parts of the system. You can
leave these roles on the default model at first, then split them when you know
where you want more speed, quality, or cost control.

| Role                 | What it is for                                                                           | Optimize for                                                                              |
| -------------------- | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Default coding model | Normal Roomote tasks: code changes, debugging, tests, repo investigation, and follow-ups | Strong tool use, coding quality, long-context reliability, and good instruction following |
| Helper model         | Lightweight routing, titles, summaries, and quick internal decisions                     | Low latency, low cost, and enough accuracy for short judgments                            |
| Vision model         | Visual inspection, screenshots, UI review, and image-heavy work                          | Image understanding, layout reasoning, and concise visual feedback                        |
| Code review model    | Initial PR or MR review tasks and review-sync work                                       | Careful reasoning, bug finding, security awareness, and willingness to cite evidence      |
| Planning model       | Planning steps inside longer coding tasks                                                | Deliberate reasoning, decomposition, and ability to keep constraints in mind              |

You do not need a separate model for every role. Many teams start with one
strong default model, then add a cheaper helper model or a stronger review
model after they can see real task usage.

## Reasoning settings

Some models expose reasoning controls. Roomote lets admins set reasoning levels
for the main model roles: **Low**, **Medium**, **High**, or **Extra high**.

Higher reasoning can improve planning, debugging, and review quality, but it
can also increase latency and cost. Use it where deeper thinking changes the
outcome, not everywhere by default.

A practical starting point:

* use **Medium** for the default coding model
* use **Low** for helper and vision work unless you see quality issues
* use **High** for code review and planning when you want more careful analysis
* reserve **Extra high** for models and workflows where the added cost is
  justified

If a model does not support reasoning controls, Roomote hides or ignores the
reasoning selector for that role.

## Choosing models

Start by choosing for reliability, then optimize for cost and speed once tasks
are working.

For the default coding model, prioritize:

* strong coding and debugging performance
* reliable tool use across long multi-step tasks
* enough context window for your repositories and logs
* predictable behavior with your preferred inference provider

For helper work, prioritize:

* fast responses
* low cost
* acceptable accuracy on short routing and summarization prompts

For vision work, prioritize:

* support for image inputs
* layout and screenshot understanding
* clear descriptions of what changed or what looks wrong

For code review, prioritize:

* careful reasoning over speed
* good false-positive control
* attention to tests, regressions, security, and edge cases

For planning, prioritize:

* structured reasoning
* ability to break work into practical steps
* consistency with your deployment-wide and environment-specific guidance

## Mixing providers

Mixing providers is normal. It can help when:

* one provider has better pricing for a model you use heavily
* another provider has better availability or rate limits
* you want direct-provider access for one model and gateway routing for another
* you are comparing model families before changing the default
* a specialized model, such as a vision model, only exists behind one provider

The main tradeoff is operational complexity. Each provider adds credentials,
account limits, billing, and possible regional or data-handling requirements.
Keep the enabled list focused enough that teammates can understand which models
to pick.

## Keep model metadata fresh

Model context windows, output limits, supported input types, reasoning support,
and pricing can change. **Settings > Models** can refresh model metadata so the
admin UI has current information for enabled and custom models.

Refresh metadata after adding custom models, changing providers, or upgrading a
deployment. It helps admins compare models without relying on stale defaults.

## Common issues

* **No models are available.** Connect at least one inference provider and
  enable at least one model.
* **A model cannot be selected.** Confirm its provider is connected and that
  the model is enabled in **Settings > Models**.
* **Tasks are expensive or slow.** Move helper work to a cheaper model, lower
  reasoning where quality allows, or choose a faster default model.
* **A vision task cannot inspect images.** Use a model with image input support
  for the vision role.
* **A model works from one provider but not another.** Check provider-specific
  credentials, rate limits, model availability, and model ID prefix.