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.Managed Roomote inference
Some hosting deployments provision Roomote inference with a limited, spend-capped credit grant during setup. It is separate from your own provider connections: in particular, you can add an OpenRouter key in Settings > Models even when Roomote inference is active. If the hosting deployment does not offer it, the option is not shown. The Roomote Cloud trial includes $5 of inference, enough to complete several tasks before you connect your own provider. Trial token usage and estimated model cost appear in task details and Cost Analytics, while the remaining credit line reflects the hosted grant’s authoritative limit. Its key is stored with your other provider credentials, so deleting the Roomote inference provider in Settings > Models disables it permanently. 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
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.
GPT-6 Astra is also recommended through Vercel AI Gateway,
GitHub Copilot, and
OpenCode Zen. Connect the provider, enable Astra
in Available Models, and assign it to a role or select it for a session or
task. Adding these routes does not change existing model defaults; access still
depends on the connected provider account or plan.
DeepSeek V4.1 Flash is recommended through
DeepSeek,
OpenRouter,
Vercel AI Gateway, and
OpenCode Go. Roomote uses the provider’s
matching route and no longer recommends the older V4 Flash 0731 model. Existing
defaults do not change automatically; enable V4.1 Flash and assign it to a role
when you want to use it.
Recommended default models
GPT 5.6 Luna is the default coding model for Roomote’s default OpenRouter setup and for new Vercel AI Gateway, Requesty, OpenAI, Azure OpenAI, Azure AI Foundry, OpenCode Zen, OpenCode Go, Amazon Bedrock, GitHub Copilot, and ChatGPT subscription connections. The recommended OpenAI, ChatGPT subscription, and GitHub Copilot mapping presets also select GPT 5.6 Luna with medium reasoning. Existing saved defaults and role mappings do not change automatically. 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. You can also choose Add your own to save a private preset with a model and reasoning level for each role when that model supports reasoning. Your custom presets are available only to your account. They remain listed if a model later becomes unavailable, but cannot be applied until every unavailable role has a current model selection; deleting a preset does not change the active model mapping.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_ENV_KEYS when a provider key uses a custom env var name and must be
forwarded:
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.
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.
Coding model routing rules
Admins can add natural-language routing rules below Coding model in Settings > Models. Each rule chooses an enabled coding model, an optional reasoning level, and a condition such asComplex migrations and architecture work or Small documentation fixes where speed matters.
When a new session delegates coding work, Roomote evaluates every saved
rule independently of its list position. It applies only the single strongest
clear match. An explicit model or reasoning choice in the request takes
precedence; weak, ambiguous, failed, or unmatched decisions keep the deployment
defaults. Rules that point to a model that is no longer enabled are ignored.
Model routing is separate from environment routing:
one chooses the model and reasoning level, while the other chooses the workspace
that contains the relevant repositories and services. To verify a rule, start a
new session with a request that clearly matches its condition and check the
model shown on the delegated task.
Judgment model
The judgment model is optional. Many routing and triage steps are bounded decisions rather than text: whether a channel message should start work, which model a delegated task needs, or whether a thread reply is meant for Roomote. A judgment model answers these as typed questions with probabilities in one fast call. Roomote supports a judgment model it runs itself and TypeSafe’s Jev through these routes:
Choose it under Judgment model in Settings > Models, or set
R_JUDGMENT_MODEL to roomote, typesafe, openrouter, vercel, or off.
A TypeSafe key selects Jev via TypeSafe when Settings has no saved route.
Choose the Roomote judgment model, OpenRouter, or Vercel AI Gateway to route
decisions through those providers. To compare Jev with the Roomote judgment
model, select Jev and set R_JUDGMENT_SHADOW=on; the Roomote model scores the
same decisions for calibration while Jev remains the selected route. Many
deployments already have OpenRouter or Vercel AI Gateway keys for task
inference, and selecting those routes sends decision text to that provider.
The Roomote judgment model is an open-weight model served on
Roomote-operated infrastructure, where its decision text is processed. It
answers the same typed questions as Jev and follows the same confidence rules
for decisions in its evaluated policy. Self-hosted deployments can point
R_JUDGMENT_UPSTREAM_URL at any server that speaks the same typed decisions
request.
When a judgment model is on, Roomote asks it first for:
- Auto-respond to channels launch criteria, including whether a message repeats an incident that already launched
- whether a new task request asks a question, wants a plan, or wants an implementation
- whether an unmentioned reply in a Slack, Discord, or Teams thread is meant for Roomote after someone else spoke; it routes the reply only when confident, and otherwise Roomote still needs a mention
- dropping inbound email that is clearly an automatic reply, such as an out-of-office or bounce notice
- whether a settled session or task turn holds something worth saving to Memory that the agent did not record itself
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
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. Viewing a custom automation’s session does not grant control over its task model. Only the automation’s creator or a deployment administrator can change model selection for those tasks. Conversational sessions expose the same model and reasoning choices in their composer. New sessions show the deployment’s orchestration model by default; direct environment and repository tasks show the coding model. Leaving the session selection untouched keeps deployment-default behavior, while an explicit selection is saved before the next message can be sent, persists across page refreshes, and applies to later session turns without changing a turn that is already running.Session delegation and consultation
The session sees the exact coding models enabled for delegated tasks. When it launches repository work, it can choose one of those models for that task or omit the choice to use the deployment default. An unavailable model is rejected before launch, so Roomote can correct the selection without consuming its launch attempt. The chosen model applies to the delegated task just as if it had been selected when starting a task from the web app. For a structured pull request review, Roomote can likewise choose an enabled model and a supported reasoning effort for the review task. Ask for those choices when the review needs a particular balance of speed and depth; omitted choices use the deployment’s code review defaults. A single session turn can launch multiple independent tasks, so one request can delegate separate workstreams without waiting for each task to finish first. Roomote still posts a kickoff for every task and keeps repeated identical launch requests from creating duplicate work. Roomote can also consult the advisor and judge roles for focused planning or completion checks without launching a workspace-backed task. These consultations can read deployment integrations and task status for context, but they cannot inspect a repository workspace, post to chat, or launch, message, or cancel tasks. Roomote remains responsible for the user-facing answer and any execution it delegates. OpenCode allows two levels of subagents: the main agent can delegate to a subagent, which can make one further nested delegation or consultation. This does not permit unbounded recursion or expand a role’s permissions. Roomote consultants still cannot inspect a repository workspace or control tasks; Roomote owns any workspace-backed execution.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
- fast responses
- low cost
- acceptable accuracy on short routing and summarization prompts
- support for image inputs
- layout and screenshot understanding
- clear descriptions of what changed or what looks wrong
- careful reasoning over speed
- good false-positive control
- attention to tests, regressions, security, and edge cases
- 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
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.
- Work stops with “You seem to have run out of credits”. The provider reported that the account has no remaining credits or quota, or that a ChatGPT subscription reached its usage limit. Roomote does not retry these automatically, because retrying cannot succeed until the account changes. Add credits or wait for the subscription limit to reset, or switch to a model from another provider. Temporary rate limits are still retried automatically.