CoderClaw handles failures in two stages:
agents.defaults.model.fallbacks.This doc explains the runtime rules and the data that backs them.
CoderClaw uses auth profiles for both API keys and OAuth tokens.
~/.coderclaw/agents/<agentId>/agent/auth-profiles.json (legacy: ~/.coderclaw/agent/auth-profiles.json).auth.profiles / auth.order are metadata + routing only (no secrets).~/.coderclaw/credentials/oauth.json (imported into auth-profiles.json on first use).More detail: /concepts/oauth
Credential types:
type: "api_key" → { provider, key }type: "oauth" → { provider, access, refresh, expires, email? } (+ projectId/enterpriseUrl for some providers)OAuth logins create distinct profiles so multiple accounts can coexist.
provider:default when no email is available.provider:<email> (for example google-antigravity:[email protected]).Profiles live in ~/.coderclaw/agents/<agentId>/agent/auth-profiles.json under profiles.
When a provider has multiple profiles, CoderClaw chooses an order like this:
auth.order[provider] (if set).auth.profiles filtered by provider.auth-profiles.json for the provider.If no explicit order is configured, CoderClaw uses a round‑robin order:
usageStats.lastUsed (oldest first, within each type).CoderClaw pins the chosen auth profile per session to keep provider caches warm. It does not rotate on every request. The pinned profile is reused until:
/new / /reset)Manual selection via /model …@<profileId> sets a user override for that session
and is not auto‑rotated until a new session starts.
Auto‑pinned profiles (selected by the session router) are treated as a preference: they are tried first, but CoderClaw may rotate to another profile on rate limits/timeouts. User‑pinned profiles stay locked to that profile; if it fails and model fallbacks are configured, CoderClaw moves to the next model instead of switching profiles.
If you have both an OAuth profile and an API key profile for the same provider, round‑robin can switch between them across messages unless pinned. To force a single profile:
auth.order[provider] = ["provider:profileId"], or/model … with a profile override (when supported by your UI/chat surface).When a profile fails due to auth/rate‑limit errors (or a timeout that looks like rate limiting), CoderClaw marks it in cooldown and moves to the next profile. Format/invalid‑request errors (for example Cloud Code Assist tool call ID validation failures) are treated as failover‑worthy and use the same cooldowns.
Cooldowns use exponential backoff:
State is stored in auth-profiles.json under usageStats:
{
"usageStats": {
"provider:profile": {
"lastUsed": 1736160000000,
"cooldownUntil": 1736160600000,
"errorCount": 2
}
}
}
Billing/credit failures (for example “insufficient credits” / “credit balance too low”) are treated as failover‑worthy, but they’re usually not transient. Instead of a short cooldown, CoderClaw marks the profile as disabled (with a longer backoff) and rotates to the next profile/provider.
State is stored in auth-profiles.json:
{
"usageStats": {
"provider:profile": {
"disabledUntil": 1736178000000,
"disabledReason": "billing"
}
}
}
Defaults:
If all profiles for a provider fail, CoderClaw moves to the next model in
agents.defaults.model.fallbacks. This applies to auth failures, rate limits, and
timeouts that exhausted profile rotation (other errors do not advance fallback).
When a run starts with a model override (hooks or CLI), fallbacks still end at
agents.defaults.model.primary after trying any configured fallbacks.
See Gateway configuration for:
auth.profiles / auth.orderauth.cooldowns.billingBackoffHours / auth.cooldowns.billingBackoffHoursByProviderauth.cooldowns.billingMaxHours / auth.cooldowns.failureWindowHoursagents.defaults.model.primary / agents.defaults.model.fallbacksagents.defaults.imageModel routingSee Models for the broader model selection and fallback overview.