Skip to main content
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: 
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.
RoleWhat it is forOptimize for
Default coding modelNormal Roomote tasks: code changes, debugging, tests, repo investigation, and follow-upsStrong tool use, coding quality, long-context reliability, and good instruction following
Helper modelLightweight routing, titles, summaries, and quick internal decisionsLow latency, low cost, and enough accuracy for short judgments
Vision modelVisual inspection, screenshots, UI review, and image-heavy workImage understanding, layout reasoning, and concise visual feedback
Code review modelInitial PR or MR review tasks and review-sync workCareful reasoning, bug finding, security awareness, and willingness to cite evidence
Planning modelPlanning steps inside longer coding tasksDeliberate 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.