- Rotatie van auth-profielen binnen de huidige provider.
- Model fallback naar het volgende model in
agents.defaults.model.fallbacks.
Runtime-flow
Voor een normale tekstrun evalueert OpenClaw kandidaten in deze volgorde:Kandidatenketen bouwen
Bouw de modelkandidatenketen op basis van de huidige modelselectie en het fallback-beleid voor die selectiebron. Geconfigureerde standaardwaarden, primaire cronjobs en automatisch geselecteerde fallback-modellen kunnen geconfigureerde fallbacks gebruiken; expliciete gebruikerssessieselecties zijn strikt.
De huidige provider proberen
Probeer de huidige provider met regels voor rotatie/cooldown van auth-profielen.
Doorgaan bij failover-waardige fouten
Als die provider is uitgeput met een failover-waardige fout, ga dan naar de volgende modelkandidaat.
Fallback-override bewaren
Bewaar de geselecteerde fallback-override voordat de nieuwe poging start, zodat andere sessielezers dezelfde provider/hetzelfde model zien dat de runner gaat gebruiken. De bewaarde modeloverride wordt gemarkeerd als
modelOverrideSource: "auto".Nauw terugdraaien bij mislukking
Als de fallback-kandidaat faalt, draai dan alleen de door fallback beheerde sessie-overridevelden terug wanneer ze nog steeds overeenkomen met die mislukte kandidaat.
providerOverridemodelOverridemodelOverrideSourceauthProfileOverrideauthProfileOverrideSourceauthProfileOverrideCompactionCount
/model-wijzigingen of sessierotatie-updates die plaatsvonden terwijl de poging liep.
Beleid voor selectiebron
OpenClaw scheidt de geselecteerde provider/het geselecteerde model van waarom die selectie is gemaakt. Die bron bepaalt of de fallback-keten is toegestaan:- Geconfigureerde standaardwaarde:
agents.defaults.model.primarygebruiktagents.defaults.model.fallbacks. - Primaire agent:
agents.list[].modelis strikt tenzij dat agentmodelobject zijn eigenfallbacksbevat. Gebruikfallbacks: []om het strikte gedrag expliciet te maken, of geef een niet-lege lijst op om die agent model fallback te laten gebruiken. - Automatische fallback-override: een runtime-fallback schrijft
providerOverride,modelOverride,modelOverrideSource: "auto"en het geselecteerde oorsprongsmodel voordat opnieuw wordt geprobeerd. Die automatische override kan de geconfigureerde fallback-keten blijven doorlopen zonder bij elk bericht de primaire te testen, maar OpenClaw test periodiek opnieuw de geconfigureerde oorsprong en wist de automatische override wanneer die herstelt./new,/resetensessions.resetwissen ook automatisch afkomstige overrides. Heartbeat-runs zonder explicieteheartbeat.modelwissen directe automatische overrides wanneer hun oorsprong niet langer overeenkomt met de huidige geconfigureerde standaardwaarde. - Gebruikerssessie-override:
/model, de modelkiezer,session_status(model=...)ensessions.patchschrijvenmodelOverrideSource: "user". Dat is een exacte sessieselectie. Als de geselecteerde provider/het geselecteerde model faalt voordat er een antwoord wordt geproduceerd, meldt OpenClaw de fout in plaats van te antwoorden vanuit een niet-gerelateerde geconfigureerde fallback. - Verouderde sessie-override: oudere sessie-items kunnen
modelOverridehebben zondermodelOverrideSource. OpenClaw behandelt die als gebruikersoverrides, zodat een expliciete oude selectie niet stilzwijgend wordt omgezet in fallback-gedrag. - Cron-payloadmodel: een cronjob
payload.model/--modelis een primaire job, geen gebruikerssessie-override. Het gebruikt geconfigureerde fallbacks tenzij de jobpayload.fallbackslevert;payload.fallbacks: []maakt de cron-run strikt.
Skipcache voor auth-fouten
Standaard behoudt elke nieuwe beurt het bestaande fallback-herpogingsgedrag: OpenClaw probeert elke geconfigureerde fallback-kandidaat opnieuw, inclusief niet-primaire kandidaten die recent faalden metauth of auth_permanent.
Operators die zulke herhaalde auth-fouten liever onderdrukken, kunnen dit inschakelen met:
0 of een niet-ingestelde waarde schakelt de cache uit.
Positieve waarden worden begrensd tussen 1 seconde en 10 minuten.
Gebruikerszichtbare fallback-meldingen
Wanneer een sessie naar een automatisch geselecteerde fallback gaat, stuurt OpenClaw een statusmelding in hetzelfde reply-oppervlak:Auth-opslag (sleutels + OAuth)
OpenClaw gebruikt auth-profielen voor zowel API-sleutels als OAuth-tokens.- Geheimen en runtime-status voor auth-routering staan in
~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite. - Configuratie
auth.profiles/auth.orderis alleen metadata + routering (geen geheimen). - Verouderd OAuth-bestand alleen voor import:
~/.openclaw/credentials/oauth.json(bij eerste gebruik geïmporteerd in de auth-store per agent). - Verouderde bestanden
auth-profiles.json,auth-state.jsonen per-agentauth.jsonworden geïmporteerd dooropenclaw doctor --fix.
type: "api_key"→{ provider, key }type: "oauth"→{ provider, access, refresh, expires, email? }(+projectId/enterpriseUrlvoor sommige providers)
Profiel-id’s
OAuth-logins maken afzonderlijke profielen, zodat meerdere accounts naast elkaar kunnen bestaan.- Standaard:
provider:defaultwanneer er geen e-mail beschikbaar is. - OAuth met e-mail:
provider:<email>(bijvoorbeeldgoogle-antigravity:user@gmail.com).
openclaw-agent.sqlite.
Rotatievolgorde
Wanneer een provider meerdere profielen heeft, kiest OpenClaw een volgorde als volgt:
Als er geen expliciete volgorde is geconfigureerd, gebruikt OpenClaw een round-robinvolgorde:
- Primaire sleutel: profieltype (OAuth vóór API-sleutels).
- Secundaire sleutel:
usageStats.lastUsed(oudste eerst, binnen elk type). - Cooldown-/uitgeschakelde profielen worden naar het einde verplaatst, geordend op de eerstvolgende vervaltijd.
Sessiestickiness (cachevriendelijk)
OpenClaw pint het gekozen auth-profiel per sessie vast om providercaches warm te houden. Het roteert niet bij elk verzoek. Het vastgepinde profiel wordt hergebruikt totdat:- de sessie wordt gereset (
/new//reset) - een Compaction is voltooid (compaction count wordt verhoogd)
- het profiel in cooldown/uitgeschakeld is
/model …@<profileId> stelt een gebruikersoverride in voor die sessie en wordt niet automatisch geroteerd totdat een nieuwe sessie start.
Automatisch vastgepinde profielen (geselecteerd door de sessierouter) worden behandeld als een voorkeur: ze worden eerst geprobeerd, maar OpenClaw kan bij rate limits/time-outs naar een ander profiel roteren. Wanneer het oorspronkelijke profiel weer beschikbaar komt, kunnen nieuwe runs het opnieuw verkiezen zonder het geselecteerde model of de runtime te wijzigen. Door de gebruiker vastgepinde profielen blijven vergrendeld op dat profiel; als het faalt en model-fallbacks zijn geconfigureerd, gaat OpenClaw naar het volgende model in plaats van van profiel te wisselen.
OpenAI Codex-abonnement plus API-sleutelback-up
Voor OpenAI-agentmodellen zijn auth en runtime gescheiden.openai/gpt-* blijft op
de Codex-harness terwijl auth kan roteren tussen een Codex-abonnementsprofiel en
een OpenAI API-sleutelback-up.
Gebruik auth.order.openai voor de gebruikersgerichte volgorde:
openai:* voor zowel ChatGPT/Codex OAuth-profielen als OpenAI API-sleutelprofielen.
Wanneer het abonnement een Codex-gebruikslimiet bereikt,
registreert OpenClaw de exacte resettijd wanneer Codex die levert, probeert het het volgende
geordende auth-profiel en houdt het de run binnen de Codex-harness. Zodra de resettijd
is verstreken, komt het abonnementsprofiel weer in aanmerking en kan de volgende automatische
selectie ernaar terugkeren.
Gebruik een door de gebruiker vastgepind profiel alleen wanneer je één account/sleutel voor die
sessie wilt afdwingen. Door de gebruiker vastgepinde profielen zijn bewust strikt en springen niet stilzwijgend
naar een ander profiel.
Cooldowns
Wanneer een profiel faalt door auth-/rate-limitfouten (of een time-out die op rate limiting lijkt), markeert OpenClaw het als in cooldown en gaat het naar het volgende profiel.Wat in de rate-limit-/time-outbucket belandt
Wat in de rate-limit-/time-outbucket belandt
Die rate-limitbucket is breder dan alleen
429: hij omvat ook providerberichten zoals Too many concurrent requests, ThrottlingException, concurrency limit reached, workers_ai ... quota limit exceeded, throttled, resource exhausted en periodieke gebruiksvensterlimieten zoals weekly/monthly limit reached.Format-/invalid-request-fouten zijn meestal terminaal omdat opnieuw proberen met dezelfde payload op dezelfde manier zou falen, dus OpenClaw toont ze in plaats van auth-profielen te roteren. Bekende retry-repair-paden kunnen zich expliciet aanmelden: bijvoorbeeld validatiefouten voor Cloud Code Assist tool call-ID’s worden opgeschoond en één keer opnieuw geprobeerd via het allowFormatRetry-beleid. OpenAI-compatibele stopredenfouten zoals Unhandled stop reason: error, stop reason: error en reason: error worden geclassificeerd als time-out-/failover-signalen.Generieke servertekst kan ook in die time-outbucket belanden wanneer de bron overeenkomt met een bekend tijdelijk patroon. Bijvoorbeeld het kale stream-wrapperbericht van de modelruntime An unknown error occurred wordt voor elke provider behandeld als failover-waardig, omdat de gedeelde modelruntime dit uitzendt wanneer providerstreams eindigen met stopReason: "aborted" of stopReason: "error" zonder specifieke details. JSON-api_error-payloads met tijdelijke servertekst zoals internal server error, unknown error, 520, upstream error of backend error worden ook behandeld als failover-waardige time-outs.OpenRouter-specifieke generieke upstreamtekst zoals kaal Provider returned error wordt alleen als time-out behandeld wanneer de providercontext daadwerkelijk OpenRouter is. Generieke interne fallback-tekst zoals LLM request failed with an unknown error. blijft conservatief en triggert op zichzelf geen failover.SDK-caps voor retry-after
SDK-caps voor retry-after
Sommige provider-SDK’s kunnen anders gedurende een lange
Retry-After-periode slapen voordat ze de controle teruggeven aan OpenClaw. Voor op Stainless gebaseerde SDK’s zoals Anthropic en OpenAI kapt OpenClaw SDK-interne wachttijden voor retry-after-ms / retry-after standaard af op 60 seconden en geeft langere opnieuw te proberen responses direct door, zodat dit failover-pad kan worden uitgevoerd. Stem de cap af of schakel die uit met OPENCLAW_SDK_RETRY_MAX_WAIT_SECONDS; zie Retry-gedrag.Modelgebonden cooldowns
Modelgebonden cooldowns
Rate-limit-cooldowns kunnen ook modelgebonden zijn:
- OpenClaw registreert
cooldownModelvoor rate-limit-fouten wanneer de id van het falende model bekend is. - Een verwant model bij dezelfde provider kan nog steeds worden geprobeerd wanneer de cooldown aan een ander model is gebonden.
- Vensters voor facturering/uitgeschakeld blokkeren nog steeds het hele profiel over modellen heen.
- 1 minuut
- 5 minuten
- 25 minuten
- 1 uur (cap)
usageStats:
Facturering schakelt uit
Facturerings-/tegoedfouten (bijvoorbeeld “insufficient credits” / “credit balance too low”) worden behandeld als geschikt voor failover, maar zijn meestal niet tijdelijk. In plaats van een korte cooldown markeert OpenClaw het profiel als uitgeschakeld (met een langere backoff) en roteert het naar het volgende profiel/de volgende provider.Niet elke response met factureringsvorm is
402, en niet elke HTTP-402 komt hier terecht. OpenClaw houdt expliciete factureringstekst in het factureringspad, zelfs wanneer een provider in plaats daarvan 401 of 403 teruggeeft, maar providerspecifieke matchers blijven beperkt tot de provider die ze bezit (bijvoorbeeld OpenRouter 403 Key limit exceeded).Tijdelijke 402-fouten voor gebruiksvensters en bestedingslimieten van organisatie/werkruimte worden ondertussen geclassificeerd als rate_limit wanneer het bericht opnieuw te proberen lijkt (bijvoorbeeld weekly usage limit exhausted, daily limit reached, resets tomorrow of organization spending limit exceeded). Die blijven op het korte cooldown-/failover-pad in plaats van het lange pad voor uitschakeling wegens facturering.- Backoff voor facturering begint bij 5 uur, verdubbelt per factureringsfout en kapt af op 24 uur.
- Backoff-tellers worden gereset als het profiel 24 uur niet is mislukt (configureerbaar).
- Overbelaste retries staan 1 profielrotatie bij dezelfde provider toe vóór modelfallback.
- Overbelaste retries gebruiken standaard 0 ms backoff.
Modelfallback
Als alle profielen voor een provider mislukken, gaat OpenClaw naar het volgende model inagents.defaults.model.fallbacks. Dit geldt voor auth-fouten, rate limits en time-outs waarvoor profielrotatie is uitgeput (andere fouten laten fallback niet doorgaan). Providerfouten die onvoldoende details blootstellen, worden nog steeds nauwkeurig gelabeld in fallbackstatus: empty_response betekent dat de provider geen bruikbaar bericht of bruikbare status teruggaf, no_error_details betekent dat de provider expliciet Unknown error (no error details in response) teruggaf, en unclassified betekent dat OpenClaw de ruwe preview heeft behouden, maar dat er nog geen classifier op paste.
Overbelaste fouten en rate-limit-fouten worden agressiever afgehandeld dan factureringscooldowns. Standaard staat OpenClaw één auth-profielretry bij dezelfde provider toe en schakelt daarna zonder wachten over naar de volgende geconfigureerde modelfallback. Provider-bezet-signalen zoals ModelNotReadyException komen in die overbelaste bucket terecht. Stem dit af met auth.cooldowns.overloadedProfileRotations, auth.cooldowns.overloadedBackoffMs en auth.cooldowns.rateLimitedProfileRotations.
Wanneer een run start vanaf de geconfigureerde standaardprimaire waarde, een primaire waarde van een Cron-taak, een agentprimaire waarde met expliciete fallbacks, of een automatisch geselecteerde fallback-override, kan OpenClaw de bijpassende geconfigureerde fallback-keten doorlopen. Agentprimaire waarden zonder expliciete fallbacks en expliciete gebruikersselecties (bijvoorbeeld /model ollama/qwen3.5:27b, de modelkiezer, sessions.patch of eenmalige CLI-provider-/modeloverrides) zijn strikt: als die provider/dat model onbereikbaar is of mislukt voordat er een antwoord wordt geproduceerd, meldt OpenClaw de fout in plaats van te antwoorden vanuit een niet-gerelateerde fallback.
Regels voor kandidaatketen
OpenClaw bouwt de kandidatenlijst op uit de momenteel aangevraagdeprovider/model plus geconfigureerde fallbacks.
Regels
Regels
- Het aangevraagde model staat altijd eerst.
- Expliciet geconfigureerde fallbacks worden gededupliceerd maar niet gefilterd door de model-allowlist. Ze worden behandeld als expliciete operatorintentie.
- Als de huidige run al op een geconfigureerde fallback in dezelfde providerfamilie draait, blijft OpenClaw de volledige geconfigureerde keten gebruiken.
- Wanneer er geen expliciete fallback-override is opgegeven, worden geconfigureerde fallbacks geprobeerd vóór de geconfigureerde primaire waarde, zelfs als het aangevraagde model een andere provider gebruikt.
- Wanneer er geen expliciete fallback-override aan de fallback-runner wordt opgegeven, wordt de geconfigureerde primaire waarde aan het einde toegevoegd, zodat de keten kan terugvallen op de normale standaard zodra eerdere kandidaten zijn uitgeput.
- Wanneer een caller
fallbacksOverrideopgeeft, gebruikt de runner exact het aangevraagde model plus die override-lijst. Een lege lijst schakelt modelfallback uit en voorkomt dat de geconfigureerde primaire waarde wordt toegevoegd als verborgen retry-doel.
Welke fouten fallback laten doorgaan
- Gaat door bij
- Gaat niet door bij
- auth-fouten
- rate limits en uitputting van cooldowns
- overbelaste/provider-bezet-fouten
- failover-fouten met time-outvorm
- uitschakelingen wegens facturering
LiveSessionModelSwitchError, die wordt genormaliseerd naar een failover-pad zodat een verouderd opgeslagen model geen buitenste retry-lus maakt- andere niet-herkende fouten wanneer er nog kandidaten over zijn
Cooldown overslaan versus probe-gedrag
Wanneer elk auth-profiel voor een provider al in cooldown is, slaat OpenClaw die provider niet automatisch voor altijd over. Het neemt een beslissing per kandidaat:Beslissingen per kandidaat
Beslissingen per kandidaat
- Aanhoudende auth-fouten slaan de hele provider direct over.
- Uitschakelingen wegens facturering slaan meestal over, maar de primaire kandidaat kan nog steeds throttled worden geprobed zodat herstel mogelijk is zonder opnieuw op te starten.
- De primaire kandidaat kan dicht bij het verlopen van de cooldown worden geprobed, met een throttle per provider.
- Fallback-verwanten bij dezelfde provider kunnen ondanks cooldown worden geprobeerd wanneer de fout tijdelijk lijkt (
rate_limit,overloadedof onbekend). Dit is vooral relevant wanneer een rate limit modelgebonden is en een verwant model mogelijk nog direct kan herstellen. - Tijdelijke cooldown-probes zijn beperkt tot één per provider per fallback-run, zodat één provider cross-provider fallback niet ophoudt.
Sessie-overrides en live modelschakeling
Sessiemodelwijzigingen zijn gedeelde status. De actieve runner, de opdracht/model, compaction-/sessie-updates en live-sessiereconciliatie lezen of schrijven allemaal delen van dezelfde sessie-entry.
Dat betekent dat fallback-retries moeten coördineren met live modelschakeling:
- Alleen expliciete door de gebruiker gestuurde modelwijzigingen markeren een pending live switch. Dat omvat
/model,session_status(model=...)ensessions.patch. - Door het systeem gestuurde modelwijzigingen zoals fallback-rotatie, heartbeat-overrides of compaction markeren nooit uit zichzelf een pending live switch.
- Door de gebruiker gestuurde modeloverrides worden behandeld als exacte selecties voor fallbackbeleid, zodat een onbereikbare geselecteerde provider als fout verschijnt in plaats van te worden gemaskeerd door
agents.defaults.model.fallbacks. - Voordat een fallback-retry start, slaat de reply-runner de geselecteerde fallback-overridevelden op in de sessie-entry.
- Automatische fallback-overrides blijven geselecteerd tijdens volgende beurten, zodat OpenClaw niet bij elk bericht een bekende slechte primaire waarde probeit. OpenClaw probeit periodiek opnieuw de geconfigureerde oorsprong en wist de automatische override wanneer die herstelt;
/new,/resetensessions.resetwissen automatisch afkomstige overrides direct. - Gebruikersantwoorden kondigen fallback-overgangen en herstel waarbij fallback is gewist één keer per statuswijziging aan. Sticky fallback-beurten herhalen de melding niet.
/statustoont het geselecteerde model en, wanneer fallbackstatus verschilt, het actieve fallbackmodel en de reden.- Live-sessiereconciliatie geeft de voorkeur aan opgeslagen sessie-overrides boven verouderde runtimemodelvelden.
- Als een live-switch-fout wijst naar een latere kandidaat in de actieve fallback-keten, springt OpenClaw direct naar dat geselecteerde model in plaats van eerst niet-gerelateerde kandidaten te doorlopen.
- Als de fallbackpoging mislukt, rolt de runner alleen de overridevelden terug die hij schreef, en alleen als ze nog steeds overeenkomen met die mislukte kandidaat.
Sessiestore zegt nog oude primaire waarde
Sessiestore weerspiegelt nog steeds de oude primaire waarde.
Live reconciliatie leest verouderde status
Live-sessiereconciliatie leest de verouderde sessiestatus.
Observeerbaarheid en foutoverzichten
runWithModelFallback(...) registreert details per poging die logs en gebruikersgerichte cooldown-berichten voeden:
- provider/model geprobeerd
- reden (
rate_limit,overloaded,billing,auth,model_not_founden vergelijkbare failover-redenen) - optionele status/code
- menselijk leesbare foutsamenvatting
model_fallback_decision-logs bevatten ook platte fallbackStep*-velden wanneer een kandidaat mislukt, wordt overgeslagen of een latere fallback slaagt. Deze velden maken de poging tot overgang expliciet (fallbackStepFromModel, fallbackStepToModel, fallbackStepFromFailureReason, fallbackStepFromFailureDetail, fallbackStepFinalOutcome), zodat log- en diagnostische exporters de primaire fout kunnen reconstrueren, zelfs wanneer de terminale fallback ook mislukt.
Wanneer elke kandidaat mislukt, gooit OpenClaw FallbackSummaryError. De buitenste reply-runner kan dat gebruiken om een specifieker bericht te bouwen, zoals “alle modellen zijn tijdelijk rate-limited”, en het eerstvolgende cooldown-vervalmoment opnemen wanneer dat bekend is.
Dat cooldown-overzicht is modelbewust:
- niet-gerelateerde modelgebonden rate limits worden genegeerd voor de geprobeerde provider-/modelketen
- als de resterende blokkade een overeenkomende modelgebonden rate limit is, meldt OpenClaw het laatste overeenkomende vervalmoment dat dat model nog blokkeert
Gerelateerde configuratie
Zie Gateway-configuratie voor:auth.profiles/auth.orderauth.cooldowns.billingBackoffHours/auth.cooldowns.billingBackoffHoursByProviderauth.cooldowns.billingMaxHours/auth.cooldowns.failureWindowHoursauth.cooldowns.overloadedProfileRotations/auth.cooldowns.overloadedBackoffMsauth.cooldowns.rateLimitedProfileRotationsagents.defaults.model.primary/agents.defaults.model.fallbacksagents.defaults.imageModel-routering