Skip to main content
Models decide how Roomote thinks through a task. The sandbox 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, Requesty, Baseten, Together AI, OpenAI, Anthropic, Moonshot AI, MiniMax, OpenCode, Amazon Bedrock, Google Vertex AI, Google Gemini, and xAI. 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
Connecting an API-key provider that has no configured models yet automatically adds a short list of recommended models for it — enabled and including the provider’s default model — so you land on a usable model list right away, both in the setup wizard and from Settings > Models. You stay in control: you can disable or remove any of the added models, add more later, and reconnecting a provider never re-adds models you removed.

​
Amazon Bedrock

Roomote connects Amazon Bedrock through the Bedrock Mantle endpoint used by AWS’s current API-key console. Generate a short-term or long-term Bedrock API key in the AWS console, save it from Settings > Models, and set the AWS region where the key was created. Bedrock model IDs use the bedrock-mantle/ prefix, for example: 
bedrock-mantle/anthropic.claude-haiku-4-5
bedrock-mantle/anthropic.claude-sonnet-5
Short-term keys expire with the AWS console session (and after at most 12 hours), so replace the saved key when it expires.

​
ChatGPT subscription

Roomote also supports connecting a ChatGPT (subscription) provider, which runs tasks on a ChatGPT Plus or Pro subscription instead of an OpenAI API key.
  • From Settings > Models, choose Add provider, pick ChatGPT (subscription) from the provider list, and choose Connect ChatGPT. Roomote starts OpenAI’s device-code flow and shows a code plus a verification link.
  • Complete authorization in a browser. The subscription is stored encrypted for the deployment and refreshed automatically.
  • Subscription models keep the openai/ model ID prefix (for example openai/gpt-5.6-terra), so they are selected and displayed like other OpenAI models. Only models your subscription tier permits are available.
  • Once connected, the subscription’s recommended models appear in Available Models (toggled off until you enable one). You can also add any other model by entering its slug, such as gpt-5.6-terra, with ChatGPT (subscription) chosen as the provider — the model is stored with the openai/ prefix and can then be picked for the default model roles.
The recommended set is a single curated list of models that ships with each Roomote release, so it is predictable for a given version. Every provider draws from the same list: a provider offers the subset it serves, under its own model ids, with the same names everywhere. Available Models always lists the full recommended set for every connected provider: recommendations you have not enabled appear toggled off, and they cannot be deleted while their provider stays connected — turn a model off to stop using it. To go beyond the recommended set, add any model by its slug from the add-model field. If both an OpenAI API key and a ChatGPT subscription are configured, the subscription is used at runtime for openai/ models. If the subscription’s refresh token is revoked, Roomote marks the connection as errored and prompts you to reconnect from Settings > Models.

​
Model IDs

Roomote model IDs include the provider prefix, such as: 
openrouter/openai/gpt-5.6-terra
anthropic/claude-sonnet-5
openai/gpt-5.6-terra
vercel/openai/gpt-5.6-terra
baseten/moonshotai/Kimi-K2.7-Code
togetherai/deepseek-ai/DeepSeek-V4-Pro
bedrock-mantle/anthropic.claude-sonnet-5
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.

​
Env-based setup

Most deployments should configure providers from Settings > Models. Use environment variables when provider credentials are managed by your hosting platform, secret manager, or local development shell. At minimum, set a default coding model and the matching provider key: 
R_MODEL=openrouter/anthropic/claude-sonnet-4
OPENROUTER_API_KEY=...
The provider is the first segment of the model ID. Direct-provider access uses the provider’s normal key: 
R_MODEL=anthropic/claude-sonnet-4
ANTHROPIC_API_KEY=...
You can also split model roles with env vars: 
R_SMALL_MODEL=openrouter/openai/gpt-4.1-mini
R_VISION_MODEL=openrouter/openai/gpt-5.6-sol
R_CODE_REVIEW_MODEL=openrouter/openai/gpt-5.6-sol
R_EXPLORE_MODEL=openrouter/openai/gpt-5.6-luna
Roomote automatically forwards common provider keys to task workers, including OpenRouter, Vercel AI Gateway, OpenAI, Anthropic, Google Gemini, Mistral, Moonshot, MiniMax, OpenCode, Amazon Bedrock, Google Vertex AI, and xAI keys. Use R_MODEL_ENV_KEYS when a provider key uses a custom env var name: 
R_MODEL_ENV_KEYS=CUSTOM_PROVIDER_API_KEY
CUSTOM_PROVIDER_API_KEY=...
See Environment Variables for the full supported key list.

​
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
Advisor modelPlanning turns and advisor consultations 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 advisor work 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 advisor work, 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.