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 direct model APIs, multi-provider gateways, coding subscriptions, and self-hosted OpenAI-compatible endpoints. 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. When you connect or update an API-key provider, Roomote first checks the submitted credentials with a small live model request. If the provider rejects the key, or the account has no remaining credits, nothing is saved: fix the credential and save again. Other failures (a rate limit, a model your account cannot access, or a transient provider outage) never block the save. Self-hosted OpenAI-compatible endpoint connections are checked by listing the endpoint’s models instead. Saving again without changing any credential skips the live check.

​
API and gateway providers

These connections use metered API billing or a provider-managed gateway:

​
Subscription providers

Subscription connections consume an included plan allowance instead of a general API balance: Roomote shows plan usage for subscription providers when the provider returns usable quota data. These usage endpoints are not always documented or stable, so a missing usage line does not by itself mean the connection is broken.

​
Self-hosted and gateway providers

OpenAI-compatible endpoints let you bring any server that speaks the OpenAI /v1 API — including LiteLLM, Ollama, vLLM, and custom proxies. Models are discovered from the configured endpoint instead of Roomote’s recommended catalog. Connect the provider in Settings > Models, then select from the discovered models and choose the defaults and role mappings that fit your deployment. These endpoints must be reachable from the Roomote deployment, not merely from your laptop or an individual task sandbox. See the provider page for the expected URL, network, security, and cost behavior. 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 catalog-backed provider draws from the same list: a provider offers the subset it serves, under its own model ids, with the same names everywhere. Endpoint providers that discover models dynamically use the model list returned by their endpoint. Available Models always lists the full recommended set for every connected catalog-backed 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. Providers also carry recommended defaults for the model roles below — for example a strong model for planning and code review and a fast, low-cost model for helper and explore work. Connecting a provider in the setup wizard applies its recommended defaults automatically, so a fresh deployment starts with a sensible split instead of one model for everything. From Settings > Models, use Use a mapping preset on the Model mapping card to preview and apply a connected provider’s recommended model mapping. Confirm the preset to set the role selections and enable any missing recommended models. It is an apply-once action, not a lock: you can adjust every role afterward. Roles a provider has no specific recommendation for are set to Same as coding model, and roles managed by environment variables are left untouched.

​
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:
The provider is the first segment of the model ID. Direct-provider access uses the provider’s normal key:
You can also split model roles with env vars:
Roomote automatically makes common provider configuration available to the model runtime, including OpenRouter, Requesty, Vercel AI Gateway, OpenAI, Azure OpenAI, Azure AI Foundry, Anthropic, Google Gemini, Moonshot, Kimi for Coding, MiniMax, Z.AI, OpenCode, Amazon Bedrock, xAI, and GitHub Copilot. For gateway-supported providers, credentials stay on the control plane and model requests are proxied instead of forwarding the credentials into task workers. Use R_MODEL_ENV_KEYS when a provider key uses a custom env var name and must be forwarded:
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.
When you connect an inference provider in setup, Roomote tests the candidate credentials and selected model before saving them. Authentication, quota, model-access, endpoint, and timeout failures are reported during setup so you can correct the connection before starting a task. Providers configured through environment variables are validated by the deployment at startup instead. For subscription-based providers (ChatGPT, GitHub Copilot, Kimi for Coding, xAI Grok / SuperGrok, and Z.AI Coding Plan), the provider row also shows current plan usage when the provider reports it, such as remaining legacy Copilot premium-request quota, the percent used of the ChatGPT 5-hour and weekly limits, or Grok included-usage windows. These numbers come from unofficial provider endpoints, so the usage line is hidden whenever the provider does not return usable data. When a Slack Manager Channel is configured under Settings > Automations, Roomote also checks queryable limits every 15 minutes for OpenRouter, Kimi for Coding, OpenCode Go, Z.AI, and Z.AI Coding Plan. It posts one warning when a credential crosses 80%, 90%, or 100% usage in a limit window. The warning names the provider, credential fingerprint or label, limit window, and reported usage. A provider that does not return usable quota data is skipped. xAI can be connected with an API key, a SuperGrok or eligible X Premium+ subscription, or both. When both are configured, the subscription is preferred at runtime for xai/ models. 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. You do not need a separate model for every role. Set a specialized role to Same as coding model to inherit the default. Many teams start with one strong default model, then split out a faster orchestration or helper model, or a stronger review model, after they can see real usage.

​
Reasoning settings

Some models expose reasoning controls. Roomote lets admins set reasoning levels for the main model roles: Low, Medium, High, Extra high, or Max. 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 orchestration, helper, vision, and explore work unless you see quality issues
  • use High for code review and advisor work when you want more careful analysis
  • reserve Extra high or Max 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.

​
Per-task model switching

Deployment settings define the defaults, but each task can override them from the web task view. The model chip in the message composer shows the task’s current coding model and reasoning level; open it to switch the coding model, or expand All roles to override the planning, code review, explore, helper, or vision role for that task only. Changes apply from the next message: a turn that is already running finishes on the old settings, and the next turn (including its sub-agents) uses the new ones. Overrides persist for the life of the task, including snapshot resumes, and Reset to defaults returns every role to the deployment configuration. You can also just ask the agent — for example “switch to Fable 5 with max reasoning for the rest of this task”. The agent applies the same change through its task-management tool, subject to the same allowed-models list.

​
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.