Accounts and Auto | AGI Cockpit Documentation

AGI Cockpit account profiles isolate multiple sign-ins for the same agent provider and let tasks, Autoruns, and Fleet runs choose between them. Profiles are supported for Claude, Codex, Antigravity, Cursor, Qoder, and Grok Build.

Muse Code uses one shared login per computer (Keychain on macOS) or a Meta API key saved under Settings → Agents → Muse Code. It has no named profiles, Auto, or account switching. Changing configuration folders does not isolate its logins. See Agents and models for authentication and the freshness limits of its reported usage.

Understand default and named profiles

Each provider has a default account that uses its existing environment. You can add named profiles such as work and personal. A profile name is Cockpit's local selection label, not the AI service's plan name or email address.

An agent account profile is separate from a Browser Identity. An account profile isolates execution authentication for Claude, Codex, or another task agent. A Browser Identity isolates cookies, localStorage, and other website state in the in-app browser.

Open the target agent under Settings → Agents, add an account profile, and sign in to it. From the CLI, identify the provider with --agent-type.

cockpit accounts
cockpit accounts create work --agent-type codex
cockpit accounts login work --agent-type codex
cockpit accounts list --agent-type codex

Rename a profile

Under Settings → Agents, use the pencil button on a named profile to change its display name. From the CLI, provide the current name or profile ID and the new name:

cockpit accounts rename work "Work (EU)" --agent-type codex

Only the display label changes. The profile ID, isolated home, stored credentials, and task and Autorun assignments remain intact, and the account does not need to sign in again. A profile can be renamed while a running task or Autorun uses it. The new name must be at most 40 characters and cannot be blank, contain control characters, duplicate another profile for the same agent, equal default, auto, or an existing profile ID, or start with profile-. The default account has no Cockpit-owned profile name and cannot be renamed.

Fleet YAML is the exception because account: <name> is resolved by name when a run starts. Update any Fleet file that uses the old name, or its next run will fail the pre-run account check.

The list reports the provider, profile ID, name, email when available, authState, provider-specific usage, and the time that usage was fetched. Grok Build also reports the reason for its authentication decision as authReason. authState distinguishes usable ok, invalid expired, and credential-free signed_out accounts. The compatibility field loggedIn is true only for ok. auth_required normally means the profile must sign in again. Cursor usage is requested with the Cursor CLI’s own sign-in, but a rejected usage request alone does not invalidate the CLI login. With valid CLI credentials, the account remains available for task launches, Auto, and Fleet, and the Usage screen offers to sign in again. Missing credentials or credentials that the CLI authentication check finds expired still require sign-in. A usage state of unknown or error means Cockpit could not read the allowance; it is not an authentication verdict, and a credential with authState: "ok" remains selectable below accounts with known capacity. Expired and signed-out accounts are unavailable to Auto and the Fleet pre-run check.

Grok Build access tokens last about six hours, but an expired access token remains selectable by Auto and Fleet when a refresh token is stored: the account reports authReason: expired_refreshable and authState: ok. Merely reading models or usage does not open interactive sign-in or refresh the token, so usage remains unknown or stale until renewal. The Grok CLI attempts renewal when the next task starts. A network problem reports network_failure without requiring sign-in. refresh_refused, expired_without_refresh, and provider_rejected require manual sign-in.

For agents that expose the default account's email address, Cockpit shows it on the default row in the account switcher and in that agent's authentication settings. It never borrows a named profile's address for the default row. An address that was not reported, a signed-out account, and a failed lookup remain distinct states so the display can also help diagnose authentication.

For Codex, Cockpit retrieves usage and rate limits from the Codex CLI app server in a read-only sandbox without approval prompts. This retrieval path supports Codex CLI 0.153.

Named Antigravity profiles use browser-based Google OAuth and keep conversations, logs, cache, and usage history under a profile-specific home. On macOS, Cockpit puts a profile-specific Keychain first in the search list and verifies that order before a task starts, preventing fallback to the host Antigravity login and its quota. The OS keyring is shared on Windows and Linux, so a host login stored there still takes precedence for every profile.

Check remaining quotas

Antigravity retrieves Gemini model quota percentages and reset times from its API using the effective account credential, without requiring a running Agy session. If no usable API quota is available, Cockpit falls back to a running local Agy session when available, then that home’s usage history. The CLI reports the source in usage.account.source and isolation.quotaSource as api, local_session, history, or none. Check this source together with the credential source and quota scope; API retrieval does not change account isolation or make a shared host login profile-specific.

Open Usage in Desktop to compare the reported allowances for each provider and account. Each quota shows its remaining percentage directly below the ring. Hover over or select a quota to see its account, allowance, reset time, and Resets in countdown when a reset time is available. The details also show the data source and last update; use Refresh usage to retrieve usage again. Cockpit does not invent a percentage for an unknown quota, authentication error, observation-only status row, or the Cockpit Agent balance display.

When Claude reports limit resets, each Claude account in Desktop shows the total unused count. Expand its details to see the remaining count, label, and expiration date for each grant. The CLI exposes the same information as limitResetsAvailable and limitResets in cockpit usage and cockpit accounts list --agent-type claude. Paused and expired grants are not counted. An omitted field means the account is ineligible, Claude did not provide the data, or Cockpit could not read it; it does not mean zero. Zero appears only when Claude explicitly reports an eligible account with no unused resets. Cockpit can only read these resets and cannot spend them.

When Claude extra usage is enabled and its current monthly spend is available, Desktop and the PWA show Extra usage this month with the spend and monthly limit in the same currency. An uncapped account shows no limit. The CLI reports extraUsage.usedCredits, extraUsage.monthlyLimit, and extraUsage.currency. Do not interpret an omitted field as zero spend. This amount is separate from the regular five-hour, weekly, and model-specific windows, purchased balances, and limit resets.

When Codex reports the purchased credit balance for a ChatGPT account, Usage displays the amount as Credits or shows Unlimited credits. The CLI exposes the same value as usage.credits in cockpit usage and cockpit accounts list --agent-type codex. The field is omitted both when the account has no purchased credits and when Codex did not report a balance, so absence does not mean a zero balance. Purchased credits are separate from reset credits that clear the current rate-limit window, and cockpit usage reset does not spend them.

The Desktop and PWA new-task screens show the same allowances for the selected agent and account before creation. A fixed account shows that profile. Auto does not substitute the default account's quota; it previews the account chosen by the same selection method used at runtime and labels it Auto · account name.

An exhausted quota remains visible at 0%. An unknown value appears as unavailable, and a missing reset time has no countdown. Check the reported authentication or retrieval status before deciding that an account is exhausted. These provider allowances are separate from conversation context usage.

When an account requires authentication, its Usage card offers Sign in or Sign in again for that specific account. Follow the provider's login flow; while it runs, the action shows Signing in... and cannot be started again. After successful authentication, Cockpit refreshes the account's authentication and usage information. A usage-fetch error alone is not proof that login is required or that the allowance is zero.

Cards keep account and allowance information together. Open quota details to inspect the source and reset time rather than interpreting an unavailable measurement as an exhausted quota.

Spend a Codex reset credit

cockpit usage is read-only and reports Codex reset credits with their expiration dates. To clear the current rate-limit window for one Codex account, spend one credit explicitly:

cockpit usage reset --agent-type codex --account work --confirm

Reset credits are earned, finite, and expiring. Spending one cannot be undone or refunded, so --confirm is required. Omit --account to target the default account. The result distinguishes reset, nothingToReset, alreadyRedeemed, and noCredit; only reset consumes a credit. Read the cockpit usage reference before automating recovery.

Use Auto

When account selection is available, new tasks, Autoruns, and Fleet nodes default to Auto. Auto is a selection method, not one named profile. At runtime it compares available usage across signed-in accounts and chooses an execution account.

Auto first requires remaining capacity in every applicable window, including shorter limits. It then compares accounts by the window with the latest reset and favors the account with the most remaining percentage per minute until that reset. This helps consume an underused weekly or other long-term quota that expires sooner. Shorter windows remain an immediate availability gate; they do not override the long-term ranking.

If an Auto task reaches a supported usage or plan limit, Cockpit selects another available account, transfers the saved session, and continues. Exhausted Claude usage credits and Codex workspace credits are included in this recovery. When no alternative is available, usage cannot be confirmed, or switching or resuming fails, the task reports the reason and waits for a person. After a recorded reset time passes, Cockpit re-evaluates that usage limit and resumes the same task when capacity has recovered. An expired credential cannot recover through a quota reset and must sign in again.

An Autorun resolves Auto again on every execution. Fleet can spread parallel nodes across available accounts instead of concentrating all work on one profile. Actual concurrency still depends on provider plans, usage limits, and machine resources.

Identify the account and limit

Mentioning a usage limit in ordinary conversation does not mark the execution account as exhausted. Tool output from another agent is also distinguished from the task's own account limit. For example, a Claude Code limit from a process started by a Codex task appears as a Claude notice and does not trigger a Codex account switch.

A Codex limit notice identifies the account, usage window, and reset time when known. If the provider did not name the window, the notice says so. usageLimitAttribution in cockpit task get <id> also identifies the restriction; explicit provider errors take precedence over cached usage data.

Terminal UI and Terminal do not overlay Cockpit's usage-limit banner on the conversation. Read the limit message from the provider CLI and inspect waitingReason, the reset time, and usageLimitAttribution in cockpit task get <id>. Limit detection, the waiting state, and Auto account recovery still run, but Cockpit's account-handoff explanation and switch-account button are not shown on a terminal surface.

Pin one account

Choose a named profile when audit, client, billing, or data-separation requirements must pin the execution account. Use --account from the CLI.

cockpit task create --instruction "Review this change" --directory /path/to/repo --agent-type codex --account work
cockpit autorun create --name "Daily review" --instruction "Review changes" --directory /path/to/repo --agent-type codex --account work --type cron --expression "0 9 * * *"

A pinned profile does not switch automatically after a usage limit. If a saved fixed profile becomes unavailable, Cockpit does not silently substitute another account. It disables the Autorun and marks it as needing attention.

Switch an active task

cockpit task account <task-id>
cockpit task account <task-id> work
cockpit task account <task-id> default

Claude, Codex, Grok Build, Antigravity, Cursor, and Qoder tasks can switch accounts while active. Cockpit stops the current runtime, transfers the saved conversation to the selected profile, and resumes the same task. A task may reject switching while it is generating a reply or immediately after startup, so wait until it can accept input.

The transfer fails safely if the source conversation is missing, busy, unreadable, or ambiguous. When the target profile already contains different history, Cockpit preserves that history as an archive before carrying the active conversation forward. A notice identifies cases where the target already had the same or newer conversation instead of silently replacing it.

After switching a task that stopped at a usage limit, send a follow-up to continue. While Auto is still switching an account, a Fleet node remains running and becomes interrupted only if recovery cannot complete. Switching does not merge provider-side billing or unrelated conversation histories.

Sign out of Antigravity

cockpit accounts logout supports Antigravity only. Without --confirm, it is a read-only preview that reports the target Keychain or keyring items and token files, shared state, and impact. Review that result before repeating the same command with --confirm.

cockpit accounts logout work --agent-type antigravity
cockpit accounts logout work --agent-type antigravity --confirm

Logging out a named profile targets only that profile's storage and does not change the host login. Logging out the default account removes the host Antigravity credential, which also signs out any other profile or ordinary terminal-launched Agy process that relied on that shared login. On Windows, Linux, or a macOS profile whose profile Keychain is unavailable, the profile preview reports the effective host item as sharedCredential and points to the default-account logout procedure. Cockpit never logs an account out automatically.

Antigravity usage reports the credential source and home, quota source, and quota scope. quotaScope: host_login means the displayed quota is not profile-specific. If an exhausted quota appears to belong to the wrong account, inspect this provenance before signing out or signing in again.

Remove a profile

cockpit accounts remove work --agent-type codex --confirm

The default account cannot be removed. Removing a named profile requires confirmation and is rejected while a task or Autorun uses it. Change those consumers to Auto, default, or another profile first. Removal makes that profile's isolated authentication and saved data unavailable, so verify both the provider and name.

See Agents and models for capability differences, Task details for stopped-task handling, the cockpit accounts reference for the exact command contract, and Security and data for credential boundaries.