Model accounts and failover

Agents and Chat run on models from your own model accounts, and your provider bills their use.

Which models devboxes offers

devboxes reads the model list from models.dev and refreshes it every five minutes. A model added there becomes available without a devboxes update. A model removed there becomes unavailable, including in saved model selections and for Runs that have not started.

The list leaves out models with less than 128,000 tokens of context. Chat can use any listed model. Coding work needs at least 200,000 tokens of context, so a Project's model selection refuses a smaller model, and Runs never use one.

A Run or Chat conversation summarizes its earlier messages before its context reaches 400,000 tokens, because models that accept a million tokens answer worse past that size. On a model with a smaller context, it summarizes before that model's own limit.

Claude subscriptions

A Claude subscription account runs its model requests through the official Claude Code CLI.

In a Run, Claude Code runs in the Run's container as a separate user, which the agent can't run, read or signal, so the token stays out of the agent's reach. A Docker Runner needs a current devboxes CLI for this: it downloads the pinned Claude Code version once, checks it before every Run that uses it, and keeps it for later Runs.

How a model selection picks an account

A model selection lists candidate models. devboxes spreads new tasks and new Chat threads across the weighted candidates in proportion to their weights. Candidates without a weight are used, in order, only when no weighted candidate is available. A selection without any weights uses the first candidate that is available.

When a provider refuses an account

devboxes pauses an account for an hour when its provider refuses the account's work because of its credential, quota, usage limit, or rate limit. While an account is paused, new tasks and Chat replies use another available candidate. A provider's server error does not pause the account. The account's pause ends when an owner or admin updates the account with connections.update, or when an owner signs in to it again with providers.connect-complete. devboxes renewing the account's sign-in by itself does not end it. When every candidate is paused, devboxes uses them anyway.

A running task or Chat reply stays on its account. When the provider refuses a running task's account because its usage limit or credit is exhausted, the task's Run ends with status paused, keeps its work, and does not retry, and devboxes pauses the account. Ending the account's pause does not restart the Run: continue the task to resume its work, on the same account once its limit resets or its credit is renewed, or on another account that offers the same model. When the provider refuses a Chat reply's account for the same reason, the reply fails without a retry, and the next reply uses another available candidate. A task or reply refused for its credential fails. When the task came from Chat or an issue, devboxes tells its thread once: where the work so far is, which accounts offer the same model and are not paused, and what to reply to continue on one. The Chat model writes that message on an account of the Chat policy that is not paused. When every such account is paused, or the Chat reply fails, devboxes posts a fixed message with the same content. While every account of the Chat policy is paused, Chat cannot act on a reply, so that message names sessions.continue with the account's accountId in the CLI or MCP server instead.

Which account running work keeps

A task keeps the model of its latest work Run across continuations and retries, and that Run's account even while the account is paused. It moves to another of the Organization's accounts for that model only when its account is deleted, or when a continuation names another account with accountId. Fix Runs continue the task on its model too. Review and recheck Runs review it on the Project's model selection, as an independent reviewer. sessions.inspect lists the Organization's accounts that run the task's model under accounts, with their pausedUntil. A Chat thread keeps the account of its last reply, and moves to another account when its account is unavailable, is paused while another candidate is not, or has no weight while a weighted candidate is available. On another account, the model sees the earlier messages but not the provider's own records of them, which only the first account can read.

A running task or Chat reply keeps the credential it started with. When an owner or admin replaces an account's key or sign-in with connections.update or providers.connect-complete, the task or reply that uses the account stops before its next model request: the task's Run ends with status failed, and the reply fails. Work that starts afterwards uses the new credential. Renaming an account, or devboxes renewing its sign-in, does not stop running work.