> ## Documentation Index > Fetch the complete documentation index at: https://docs.roomote.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 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: ```text theme={null} 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: ```text theme={null} 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: ```sh theme={null} 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: ```sh theme={null} R_MODEL=anthropic/claude-sonnet-4 ANTHROPIC_API_KEY=... ``` You can also split model roles with env vars: ```sh theme={null} 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: ```sh theme={null} R_MODEL_ENV_KEYS=CUSTOM_PROVIDER_API_KEY CUSTOM_PROVIDER_API_KEY=... ``` See [Environment Variables](/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. | 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 | | Advisor model | Planning turns and advisor consultations 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 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.