Use multiple AI accounts with automatic fallback

Can my AI accounts waterfall when one reaches its limit?

Yes. In Lyre, connect supported accounts or API keys, include the connections you want in an automatic switching list, and set their priority order. When a direct agent reports a usage limit, rate limit or authentication failure, Lyre can select the next eligible connection for that agent and model service.

On a host that includes automatic continuation, the saved Automatic setting also allows Lyre to continue the interrupted work after a successful switch. The host still checks the run's permissions and admission rules. Manual account selection keeps automatic switching and continuation off.

If you want request-level fallback through a gateway, Lyre also offers OmniRoute's separate Use key order policy. Choose the path below; connecting accounts alone does not enable either behavior.

Choose account switching or gateway routing

Direct switching keeps one model service and compatible agent adapter. It does not turn a Claude conversation into a Codex conversation or choose an arbitrary replacement model. For model routes, use the separate routing controls.

Prepare the computer that runs the agent

Select the computer that will run the agent before adding accounts. Its Connections and native sign-in flows own those credentials; another client can select its available connections without copying keys into a chat or project.

Connect and name each account

1. Open Connections on the intended host

   Go to Settings›AI & agents›Connections. Check the selected computer and install the required agent software through its existing setup if it is missing.

2. Add separate sign-in accounts

   Expand the supported provider. For Codex, use Add Codex account; for Claude, use Add Claude account. Give each profile a recognizable name, complete that account's native browser sign-in and wait for verification and a fresh model catalog. Other agents offer only the account methods advertised by that host. A saved inactive profile is not ready to use.

3. Or add named provider API keys

   Choose Add provider key (shown as Add key on compact screens), select the service and give each key a distinct name. Save it, then use Verify and enable when offered. A source with no supported check stays saved and unverified; it is not an enabled fallback. Replacing a key on an existing profile changes that profile rather than adding another account.

4. Check readiness and costs

   Confirm the connections you intend to use are enabled and have a selectable model. Open Usage for reported limits and reset windows. An unavailable report does not mean unused allowance. Including an API key can incur that key's provider charges; it does not spend a sign-in subscription's allowance.

Turn on Automatic and set the waterfall order

1. Open the conversation model picker

   Choose Automatic account switching, Automatic key switching or the combined Automatic switching entry offered for your provider. Select a shared model from that entry. Choosing a model under one individual connection selects it manually instead.

2. Choose exactly which connections participate

   Open Account order or Key order, then Edit list. Add the enabled accounts or compatible keys you want. A saved connection outside this list is not an extra fallback. A combined list can mix sign-ins and keys only when the host supports it and they use the same native agent adapter and model service. Older hosts keep separate pools.

3. Move your preferred account first

   Use the up/down controls to order, for example, Primary → Backup → API spare. Review the list, choose Done and check that the saved summary has the intended order. Adding another account later does not mean it has joined an existing explicit list.

4. Check whether you are editing a draft or existing conversation

   Before creation, the saved choice and order apply to new conversations on this device for that computer; a new Automatic conversation starts with the first eligible member. Inside an existing conversation, the changes apply to that conversation. An existing eligible connection is retained until you change it or a qualifying failure occurs.

What happens when the first account runs out?

Suppose your list is Primary, Backup, API spare. A new Automatic conversation starts on the first eligible connection. If Primary reports a recognized usage, rate or sign-in failure, Lyre announces the affected connection, attempts the next eligible one and confirms its name after a successful switch.

With Automatic enabled on a compatible host, Lyre continues the interrupted work after the connection change. You do not need to submit the same message again while it is continuing. Each run retains its host permission and admission checks; a required permission decision still needs your input. Stop or cancellation must end the work rather than start another fallback.

Continuation attempts are bounded. If the selected alternatives cannot continue, read the final recovery notice and inspect any tool results or changed files before retrying work that may already have partly run.

The order wraps to the first eligible connection after its end. It is not a promise to drain every allowance completely or switch back the moment an earlier quota resets. Disabled, removed, unselected or incompatible connections are excluded. If no alternative is eligible, Lyre reports that state and asks you to add or enable a connection.

The Lyre conversation and visible history are retained using the provider's supported continuation. A different native account may require a fresh provider context with transferred visible messages and tool results. Context size, attachments and native thread ownership can prevent a handoff; read its recovery message. Do not assume every account can reopen the same provider-native thread.

Use a gateway for request-level key fallback

In Developer mode, open Settings›AI & agents›Connections›Routing provider keys & accounts for the selected host's OmniRoute account manager. Add or sign into the gateway connections you intend to use; the multi-key setup guide explains its named-key form.

Set the provider to Use key order and arrange its connection priorities. New gateway keys establish this policy; an existing provider may need it selected explicitly. Then choose an enabled OmniRoute model in your conversation. A conversation still using a direct agent's model is not using this gateway policy.

The gateway tries the first eligible connection and can try another after a retryable authentication, quota or service error. Disabled or cooling connections are skipped. Invalid requests, provider-wide failures or an explicitly pinned connection can stop sibling retries. Its request policy is configured separately from the direct agent's Automatic setting.

Gateway sign-in is separate from native CLI sign-in. Lyre does not extract native login tokens. Supported saved API keys can be connected explicitly from the host; reusing a key sends it to that configured gateway. Check its destination before choosing this path. Inspect Routing Activity for actual request results; configuring an order alone does not prove fallback succeeded.

Check the setup without exhausting an account

First reopen the picker and confirm the saved membership, order, shared model and current Auto connection. With the accounts you intend to use, send a small read-only request in an approved project and check the reply and connection name. This uses the selected provider and may consume its allowance; a normal reply verifies the active connection, not a fallback.

You do not need to spend an account's remaining quota to configure or document the list. When a real qualifying failure happens, record the affected connection, confirmed replacement and whether the host continued automatically or reported a blocking state. For the gateway path, inspect its Activity and route details separately. An unknown result or missing report is not a passing fallback demonstration.

Recover or return to one account

Automatic or Edit list is missing

Check the selected host, supported adapter and installed version. Older hosts may keep separate key/sign-in pools or a read-only order. Use an available individual connection while checking the release owner.

There are no shared models

Check installation, authentication and catalog status for each selected connection. Resolve catalog errors or remove an incompatible member from the switching list; you can choose an individual account instead.

The order or list did not save

Read the save error. The previous saved choice remains active. Restore the host connection, review the displayed summary and save once; do not assume your unsaved order is in use.

The new account also fails

Read that account’s own error, usage and reset information. A revoked credential needs repair; a limit may need time to reset. Fallback does not add allowance, repair credentials or guarantee a provider is available.

A switch or context handoff failed

Keep the saved Lyre conversation. Read its recovery notice and check the available connections before retrying. Inspect files/tool results before repeating a request that may have partly run.

To turn off direct Automatic switching, choose an individual connection's model or Use <connection> only. Removing a connection from the automatic list keeps its saved profile. Disable retains the profile; removing an in-use native account is refused until its conversations are switched. Manage native sign-in, keys and gateway connections through their respective Connections owners.

Deleting a Lyre profile is not proof that the provider credential or a separately copied gateway key is revoked. Withdraw credentials at their issuing provider when that is your intent. Account changes do not expand project or device permissions.