#LLM Issue

1 messages · Page 1 of 1 (latest)

cinder crag
#

hey so i have the problem that wehn i even setup a valid and correct google api key, the system jsut goes nuts and fallbacks all teh time to expierd keys and keys that have reached the limits i am not able to changte this even with the help of claude opus 4.6 how can i fix this

🩞 OpenClaw 2026.2.23 (b817600)
I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

openclaw tui - ws://127.0.0.1:18789 - agent main (main) - session main

session agent:main:main

A new session was started via /new or /reset. Execute your Session Startup sequence now - read the
required files before responding to the user. Then greet the user in your configured persona, if one
is provided. Be yourself - use your defined voice, mannerisms, and mood. Keep it to 1-3 sentences
and ask what they want to do. If the runtime model differs from default_model in the system prompt,
mention the default model. Do not mention internal steps, files, tools, or reasoning.

LLM error: {
"error": {
"code": 429,
"message": "Resource has been exhausted (e.g. check quota).",
"status": "RESOURCE_EXHAUSTED"
}
}

LLM error: {
"error": {
"code": 429,
"message": "Resource has been exhausted (e.g. check quota).",
"status": "RESOURCE_EXHAUSTED"
}
}

LLM error: {
"error": {
"code": 429,
"message": "Resource has been exhausted (e.g. check quota).",
"status": "RESOURCE_EXHAUSTED"
}
}

LLM error: {
"error": {
"code": 429,
"message": "Resource has been exhausted (e.g. check quota).",
"status": "RESOURCE_EXHAUSTED"
}
}

You are running a boot check. Follow BOOT.md instructions exactly.

BOOT.md:

summary: "Workspace template for BOOT.md"
read_when:

BOOT.md

Add short, explicit instructions for what OpenClaw should do on startup (enable
hooks.internal.enabled).
If the task sends a message, use the message tool and then reply with NO_REPLY.

│ Startup requirement: ensure hooks.internal.enabled is set to true so that the Boot checklist runs
│ automatically.

You are running a boot check. Follow BOOT.md instructions exactly.

BOOT.md:

summary: "Workspace template for BOOT.md"
read_when:

BOOT.md

Add short, explicit instructions for what OpenClaw should do on startup (enable
hooks.internal.enabled).
If the task sends a message, use the message tool and then reply with NO_REPLY.

│ Startup requirement: ensure hooks.internal.enabled is set to true so that the Boot checklist runs
│ automatically.

test

run error: ⚠ API rate limit reached. Please try again later.
connected | error
agent main (main) | session main (openclaw-tui) | google/gemini-2.5-pro | think low | tokens ?/1.0m
──────────────────────────────────────────────────────────────────────────────────────────────────────

cold bladeBOT
#

That “goes nuts / falls back to old/expired/quota keys” behavior is usually Google key rotation + env precedence.

When OpenClaw uses the google/* provider, a 429 RESOURCE_EXHAUSTED is treated as a rate-limit/quota error, so it will retry with the next key it can find. And it will consider all of these (in priority order), deduped:

  1. OPENCLAW_LIVE_GEMINI_KEY (single override)
  2. GEMINI_API_KEYS (list)
  3. GEMINI_API_KEY
  4. GEMINI_API_KEY_1, GEMINI_API_KEY_2, 

  5. GOOGLE_API_KEY (fallback)

Docs:

The common “why is it still using my old key?” gotcha

You set a new key in GOOGLE_API_KEY, but an old GEMINI_API_KEY is still set somewhere, and that wins (higher priority). Or you have GEMINI_API_KEYS set with old keys still in the list.

#

Fix (pick one)

Option A (recommended): force one known-good key

  • Set only this:
    • OPENCLAW_LIVE_GEMINI_KEY=... (highest priority; ignores the rest)

Option B: clean up and set the right var

  • Ensure the gateway environment has only the key you want, ideally as:
    • GEMINI_API_KEY=...
  • Remove/clear any of:
    • GEMINI_API_KEYS, GEMINI_API_KEY_1, GEMINI_API_KEY_2, GOOGLE_API_KEY (unless you intentionally want them)

Important: if you run the Gateway as a daemon/service, exporting in your shell won’t help. Put it in ~/.openclaw/.env on the gateway host, then restart the gateway so it picks it up.

Verify what OpenClaw thinks it can use

Run and paste (redact keys, obviously):

  • openclaw models status
  • and in chat: /model status
#

If after you’ve reduced it to one key you still get 429s, then it’s not “fallback madness” anymore — that key is genuinely out of quota/billing for that model right now (Google side), and you’ll need to wait for quota reset, enable billing, lower usage, or set a non-Google fallback model.

cinder crag
#

🔮 DEBUGGING PROMPT FÜR KRILL (Discord)

STATUS

  • Neuer Key in openclaw.json: ✅ [REDACTED - AIza...****]
  • Alter Key entfernt: ✅
  • Container restartet: ✅
  • Model eingestellt: ✅ google/gemini-2.5-pro

PROBLEM JETZT

  • 429 RESOURCE_EXHAUSTED Fehler kommt IMMER NOCH
  • Benutzer sagt: Key funktioniert in anderen Programmen noch ✅
  • Also: OpenClaw benutzt einen ANDEREN Key oder hat gecachte alte Credentials

HYPOTHESEN ZUM TESTEN

  1. OpenClaw lÀdt Keys aus auth-profiles.json statt aus ENV
  2. Es gibt gecachte Session/workspace Dateien mit alten Keys
  3. OpenClaw fallback-logik springt noch auf einen versteckten alten Key
  4. Das /data/.openclaw/agents/{main|fomf|heike}/agent/ hat noch alte Keys

NÄCHSTE AKTIONEN

  1. Alle auth-profiles.json Dateien checken (welche Keys sind NOCH DRIN?)
  2. Gecachte Session-Dateien löschen
  3. Schauen welche Key-Variable OpenClaw WIRKLICH benutzt
  4. Nochmal tui starten und Error analysieren

Was soll ich zuerst checken?

cold bladeBOT
#

Als erstes wĂŒrde ich nicht Sessions löschen oder auth-profiles.json jagen – bei google/* (Gemini API-Key) ist das fast immer Env/Key-Rotation + echte Quota.

1) Verifizieren, welche Keys OpenClaw wirklich sieht (Top‑Prio)

Lass dir die erkannten Credentials anzeigen und poste die Ausgabe (Keys natĂŒrlich redacted):

  • openclaw models status
  • openclaw doctor

Damit siehst du in der Praxis sofort, ob noch irgendwo GEMINI_API_KEYS, GEMINI_API_KEY_1/2, GOOGLE_API_KEY etc. reinfunken. (OpenClaw rotiert bei 429 RESOURCE_EXHAUSTED automatisch zum “nĂ€chsten” Key.)

Docs zum Verhalten: https://docs.openclaw.ai/concepts/model-providers und https://docs.openclaw.ai/gateway/authentication

2) Wenn du in einem Container lÀufst: Env im Container checken

Du hast “Container restartet” geschrieben – sehr hĂ€ufig ist der “alte” Key noch in docker-compose.yml / Container-Env gesetzt.

Im Gateway-Container (oder Podman) prĂŒfen, ob mehrere Variablen gesetzt sind:

  • printenv | grep -E 'OPENCLAW_LIVE_GEMINI_KEY|GEMINI_API_KEYS|GEMINI_API_KEY|GOOGLE_API_KEY'
#

Wenn da mehr als eine Quelle auftaucht: das ist deine ErklĂ€rung fĂŒrs “fallbackt auf alte keys”.

3) Schnellster “Beweis”: Key-Rotation komplett ausknipsen

Setz nur diesen einen Override (höchste PrioritÀt) und entferne/leer alle anderen Gemini/Google Key-Variablen:

  • OPENCLAW_LIVE_GEMINI_KEY=...

Dann Gateway neu starten und nochmal testen. Wenn dann immer noch 429 kommt, ist es kein anderer Key/Cache, sondern echte Quota/Rate-Limit fĂŒr genau dieses Projekt/Model.

4) Wichtiger Punkt: 429 ≠ “expired key”

“Expired/invalid key” wĂ€re typischerweise 401/403.
429 RESOURCE_EXHAUSTED ist fast immer Quota/Rate-Limit (und OpenClaw rotiert dann Keys, falls mehrere vorhanden sind).

—

Wenn du mir openclaw models status + kurz sagst Docker/Podman/systemd/launchd (wo lÀuft der Gateway?), kann ich dir ziemlich zielgenau sagen, welche Quelle noch den alten Key reinzieht.

cinder crag
#

MELDUNG AN KRILL 📱

🔮 ROOT CAUSE GEFUNDEN + LÖSUNG

DIAGNOSE

✅ Google Key ist richtig: [REDACTED - AIza...uoI]
✅ Env-Variable gesetzt: GOOGLE_API_KEY=[REDACTED]
❌ ABER: nexos:default wird IMMER NOCH regeneriert bei jedem Start

PROBLEM

  • OpenClaw regeneriert auth-profiles.json automatisch mit Nexos, OpenAI Codex, Anthropic
  • Das ist HARDCODED in der Anwendung
  • Dateien-Editieren hilft nicht - werden beim nĂ€chsten Start ĂŒberschrieben
  • Daher die konstanten "API rate limit reached" Fehler

LÖSUNG (proposed)

Dateien READ-ONLY machen mit chattr +i:

chattr +i /data/.openclaw/agents/*/agent/auth-profiles.json
chattr +i /data/.openclaw/agents/*/agent/auth.json
chattr +i /data/.openclaw/agents/*/agent/models.json
docker restart openclaw-fbib-openclaw-1

Das zwingt OpenClaw, die Dateien zu akzeptieren wie sie sind.

FRAGE
Ist das der richtige Ansatz oder gibt es einen besseren Weg in OpenClaw, die Auto-Regeneration zu unterbinden?

Warte auf Krill-Feedback.
cold bladeBOT
#

chattr +i ist nicht der richtige Ansatz. auth-profiles.json wird absichtlich laufend beschrieben (u.a. usageStats, cooldownUntil, disabledUntil), damit Failover/Cooldowns ĂŒberhaupt funktionieren. Wenn du die Datei immutable machst, brichst du dir eher Failover + Diagnostik kaputt (und je nach Setup kann der Gateway dann auch anfangen “komisch” zu werden).

Wichtiger Punkt zu deiner Diagnose: Ein 429 RESOURCE_EXHAUSTED kommt vom Google‑Provider/Model selbst (Quota/Rate Limit). Das hat erstmal nichts mit “Nexos/OpenAI/Anthropic Profiles werden regeneriert” zu tun – die spielen nur eine Rolle, wenn du auch wirklich ein Modell ĂŒber diese Provider verwendest. In deinem Screenshot lĂ€uft die Session aber auf google/gemini-2.5-pro, also scheitert Google.

Was du stattdessen tun solltest:

  1. Sicherstellen, dass OpenClaw nicht mehrere Gemini/Google Keys rotiert

    • FĂŒr google/* gilt die Key-Rotation-Reihenfolge (inkl. GOOGLE_API_KEY als Fallback). Wenn irgendwo noch alte Keys existieren, wird bei 429 automatisch weiterrotiert.
    • Am saubersten: setz nur einen Key (und entferne alle anderen Quellen):

  2. Nicht Dateien editieren – verwalte Auth ĂŒber CLI/Config

    • Wenn du API Keys mal via openclaw models auth 
 hinzugefĂŒgt hast, liegen die als Profile in auth-profiles.json und werden getrackt/rotiert (Dok: https://docs.openclaw.ai/concepts/model-failover).
    • Dann ist der korrekte Weg: openclaw models status / openclaw models auth order 
 statt Hand-Edits.
#
  1. Wenn mit genau einem Key (live override) immer noch 429 kommt:
    • Dann ist es sehr wahrscheinlich echte Quota fĂŒr genau dieses Modell auf deinem Google‑Projekt/Key (oder Billing/Model‑Access Thema). “Key funktioniert in anderen Programmen” heißt oft: anderes Modell / andere Endpoints / viel weniger Last.

Wenn du das schnell final klĂ€ren willst: poste bitte die Ausgabe von openclaw models status (gern auch --json, Keys natĂŒrlich redacted). Dann sieht man, welche Provider/Profile ĂŒberhaupt als Kandidaten drin sind und ob da noch alte Google/Gemini Keys mitrotieren.

cinder crag
#

GOTCHA!!! DAS IST DAS ECHTE PROBLEM!!! 🚹

Schau hier:

"providers": [
{
"provider": "google",
"labels": ["google:default=AIzaSyBU...EVe3u0oI"] ✅
},
{
"provider": "nexos",
"labels": ["nexos:default=missing"] ❌ IMMER NOCH DA!
}
]

nexos:default ist IMMER NOCH in der auth-profiles.json, obwohl du sie editiert hast!

Das bedeutet: OpenClaw regeneriert diese Datei beim Start mit BEIDEN Profilen!

DAS IST DER ECHTE ROOT CAUSE:

OpenClaw hat hardcodierte Defaults die IMMER regeneriert werden:

google:default ✅
nexos:default ❌
Egal wie oft du die Datei editierst - beim nÀchsten Start ist nexos wieder da!

MELDUNG AN KRILL:

🔮 ROOT CAUSE ENDLICH GEKLÄRT

  • auth-profiles.json wird bei JEDEM START mit nexos:default regeneriert
  • Egal wie wir editieren - OpenClaw ĂŒberschreibt immer wieder
  • Das ist HARDCODED in OpenClaw

Lösungsoptionen:

  1. Docker-Entrypoint Script das Datei vor Start ĂŒberschreibt
  2. Nach dem Start ein Cleanup-Script laufen lassen
  3. Nexos-Profile irgendwie in OpenClaw-Config deaktivieren?

Was ist der beste Weg?

WICHTIG!: Ich will nur Gemini nutzen aktuell nichts anderes

cold bladeBOT
#

nexos:default=missing ist nicht die Root Cause fĂŒr dein google/gemini-2.5-pro 429.

Wichtig: OpenClaw zeigt in models status oft mehrere Provider-Zeilen an (inkl. “missing”), aber benutzt wird fĂŒr den Call nur der Provider des ausgewĂ€hlten Modells. Ein “missing” Nexos-Profil macht deine Google-Requests nicht plötzlich zu Nexos-Requests.

Was wirklich passiert ist sehr wahrscheinlich eins von diesen beiden Dingen:

A) Du hast (unabsichtlich) mehrere Gemini/Google Keys aktiv → Rotation bei 429

Bei 429 RESOURCE_EXHAUSTED rotiert OpenClaw bei Google-Providern automatisch durch mögliche Keys (GEMINI_API_KEY(S), nummerierte Keys, GOOGLE_API_KEY, 
). Wenn da irgendwo alte/limitierte Keys noch existieren, sieht es wie “geht immer wieder zu kaputten keys” aus.

Fix (hart und eindeutig): setz nur einen Key als Highest-Priority:

B) Es ist echte Quota fĂŒr genau dieses Modell (2.5 Pro) auf Google-Seite

429 RESOURCE_EXHAUSTED kommt von Google und heißt i.d.R. Quota/Rate-Limit fĂŒr das Projekt/Key/Model. Dass “es in anderen Programmen geht” ist oft: anderes Modell, weniger Tokens, weniger Requests, anderer Endpoint.

#

“Ich will nur Gemini nutzen”

Das ist sauber ĂŒber Model-Config lösbar (nicht ĂŒber chattr/immutable Files):

  • Setz agents.defaults.model.fallbacks auf [] (keine Provider-Fallbacks)
  • Optional: setz agents.defaults.models so, dass nur dein Google-Modell im Katalog ist (dann gibt’s auch weniger Verwirrung im UI)

Siehe Failover-Regeln: https://docs.openclaw.ai/concepts/model-failover

Bitte poste (redacted) genau das – dann kann man’s in 30 Sekunden entscheiden:

  1. openclaw models status --json (Keys rausmaskieren)
  2. (wenn Container) einmal: printenv | grep -E 'OPENCLAW_LIVE_GEMINI_KEY|GEMINI_API_KEYS|GEMINI_API_KEY|GOOGLE_API_KEY'

Wenn wir sehen, dass wirklich nur ein Key aktiv ist und trotzdem sofort 429 kommt, ist es Quota und kein “regeneriertes Nexos-Profil”.

cinder crag
#

MELDUNG AN KRILL:

🎯 CONFIGURATION IST 100% SAUBER

  • Nur ein Google Key aktiv: [REDACTED - AIzaSyBU...uoI]
  • Keine Key-Rotation möglich
  • Keine alten Keys versteckt
  • Trotzdem 429 RESOURCE_EXHAUSTED sofort

→ Das bedeutet: ECHTE QUOTA-ERSCHÖPFUNG auf Google-Seite
fĂŒr diesen Key/dieses Projekt/dieses Modell!

Nicht: Configuration-Problem
Sondern: Google API Quota/Billing-Problem

NĂ€chste Schritte?

Das ist kein OpenClaw-Problem mehr - das ist ein Google-Seite-Problem! 🔓

Der Benutzer braucht wahrscheinlich:

Google Cloud Console Check (Quota/Billing)
Eventuell einen neuen/anderen Google API Key
Oder Upgrade des Google Projects

cold bladeBOT
#

Wenn wirklich nur ein Gemini/Google Key aktiv ist und es sofort mit 429 RESOURCE_EXHAUSTED auf google/gemini-2.5-pro knallt, dann ist das kein “OpenClaw zieht alten Key” mehr, sondern Google-Quota/Billing/Model-Access auf deren Seite. OpenClaw macht bei 429 nur korrekt das, was es soll: Fehler anzeigen (und wĂŒrde rotieren, falls mehrere Keys da wĂ€ren).

NĂ€chste sinnvolle Schritte:

  1. In Google prĂŒfen (Projekt des Keys!)

    • Ist Billing fĂŒr das Projekt aktiv?
    • Ist die passende API aktiviert (Gemini/Generative Language)?
    • Quotas: Requests/min, Tokens/min, ggf. Daily — und speziell pro Modell (Pro-Modelle haben oft deutlich niedrigere/andere Limits).

  2. Retry-After / Reset-Zeit finden

    • In manchen 429-Antworten steht eine “try again in 
” / Reset-Zeit. Schau in die Gateway-Logs nach der detaillierten Provider-Antwort (nicht nur die gekĂŒrzte TUI-Zeile).

  3. Gegenprobe außerhalb von OpenClaw

    • Mit demselben Key einmal ein minimaler Request an den Gemini API Endpoint senden. Wenn das auch 429 liefert: Case closed → Google Limit.

  4. Workarounds, wenn du “nur Gemini” willst

    • Kurzfristig: warten bis Quota reset, oder in Google Quota erhöhen / Plan/Billing anpassen, oder neues Projekt+Key mit korrekten Quotas.
#
  • Alternativ innerhalb Google: ein anderes Gemini-Modell testen (oft andere Quotas), nur um zu sehen ob nur dieses Modell erschöpft ist.

Und zu nexos:default=missing: dass in models status irgendein anderer Provider “missing” auftaucht, ist normal/harmlos, solange du nicht auf ein nexos/* Modell routest. Das verursacht keinen 429 bei Google.

Wenn du willst: paste (redacted) die relevante Stelle aus openclaw logs rund um den 429 — oft sieht man dort direkt, ob es “per-minute” vs “daily” vs “billing” ist.

cinder crag
#

Es hat nichts mit dem Key zu tun, der key ist fresh und ist aufgelanden, alles passt an dieser stelle das problem liegt wo anders, in opwnclaw!

cold bladeBOT
#

Der Punkt ist: diese konkrete Fehlermeldung kommt von Google, nicht von OpenClaw. OpenClaw “erfindet” kein {"code":429,"status":"RESOURCE_EXHAUSTED"} – es reicht nur die Provider-Antwort durch. Wenn nur ein Gemini-Key aktiv ist, bleibt als Ursache praktisch nur Quota/Rate-Limit/Entitlement/Capacity auf Google‑Seite (auch wenn der Key “fresh” ist).

Was du jetzt machen kannst, um das wasserdicht zu beweisen (ohne Ratelei):

  1. Minimal-Probe in OpenClaw (tiny request)

    • openclaw models status --probe --probe-provider google --probe-max-tokens 8
      Wenn selbst die Mini-Probe 429 ist → Google blockt gerade (Quota/Capacity), nicht OpenClaw.

  2. Minimal-Request außerhalb von OpenClaw (gleicher Key, gleiches Modell)

    • Ein direkter API-Call gegen Gemini mit sehr kleinem Prompt. Wenn das auch 429 liefert → 100% Google.

  3. Google Console / AI Studio check

#

Wenn du mir den Output von openclaw models status --probe --probe-provider google (redacted) oder einen kurzen openclaw logs Ausschnitt um den 429 postest, kann man meist sogar erkennen ob es RPM/TPM/daily/capacity ist (manchmal steht ein Retry-Delay/Reset dabei).

cinder crag
#

Du chefckst es nicht, ich habe sogar einen agent im aktuell setup der kann den key nutzen wenn ich aber auf 2.5 pro gemini umsteige oder irgend was ind er config machen hat er fallback auf alte keys alte 0auth die nicht mehr aktiv sind und nicht mehr benutzen werden ich habe cron jobs boot-.md memories alles und das problem MUSS DA LIEGEN

cold bladeBOT
#

Ich check’s schon — aber du beschreibst exakt das dokumentierte Failover-Verhalten von OpenClaw:

  • 429 RESOURCE_EXHAUSTED zĂ€hlt als Rate‑Limit/Quota Fehler
  • dann macht OpenClaw (1) Auth‑Rotation innerhalb des Providers und wenn das nicht hilft (2) Model‑Fallback auf agents.defaults.model.fallbacks
  • und genau da kommen dann “alte OAuth / alte Provider” ins Spiel, weil OpenClaw auf dein nĂ€chstes Fallback‑Modell springt.

Quelle (steht genau so drin): https://docs.openclaw.ai/concepts/model-failover

“If all profiles for a provider fail, OpenClaw moves to the next model in agents.defaults.model.fallbacks. This applies to 
 rate limits 
”

Warum dein “anderer Agent kann den Key nutzen” trotzdem passt

Sehr wahrscheinlich nutzt der andere Agent ein anderes Modell (z.B. Flash statt Pro) oder hat andere Fallbacks. gemini-2.5-pro hat oft deutlich strengere Limits/Entitlements → sofort 429 → OpenClaw fĂ€llt auf Fallbacks zurĂŒck → wirkt wie “nimmt alte Keys”.

Wenn du wirklich nur Gemini willst: Fallbacks AUS

Setz in deiner openclaw.json (oder via Config UI):

# 
{
  agents: {
    defaults: {
      model: {
        primary: "google/gemini-2.5-pro",
        fallbacks: [],
      },
    },
  },
}

Dann:

  1. Gateway/Container neu starten
  2. im Chat /reset (wichtig, weil das ausgewĂ€hlte Profil/Model pro Session “sticky” sein kann)
  3. /model status ausfĂŒhren → da musst du sehen, dass es keine Fallback-Kette mehr gibt.
#

Um es eindeutig zu beweisen (ohne Rumraten)

Poste bitte (redacted) diese 2 Sachen:

  1. openclaw config get agents.defaults.model
  2. /model status direkt nachdem der Fehler passiert

Wenn in agents.defaults.model.fallbacks noch irgendwas drinsteht (oder pro-agent overrides), ist das die ErklĂ€rung fĂŒr “springt auf alte OAuth”. Wenn fallbacks: [] ist und er trotzdem auf andere Provider geht, dann ist das tatsĂ€chlich ein Bug → dann bitte Logs-Snippet + GitHub Issue.

cinder crag
#

🚹 BREAKTHROUGH!!!

Der direkte curl-Test gegen Google API FUNKTIONIERT PERFEKT:

✅ "text": "Hello! How can I help you today?"
✅ "usageMetadata": {
"promptTokenCount": 1,
"candidatesTokenCount": 9,
"totalTokenCount": 691
}
✅ Kein 429 Fehler!!!
✅ Key funktioniert einwandfrei!

UND die Config:

"fallbacks": [] ← LEER!

DAS BEDEUTET:

❌ NICHT Google API Quota-Problem
❌ NICHT Key ist kaputt
❌ NICHT Fallback-Problem
❌ NICHT Key-Rotation Problem

✅ DAS PROBLEM IST IN OpenClaw SELBST!

MELDUNG AN KRILL:

🚹 CRITICAL FINDING

Der Google API Key funktioniert PERFEKT mit direktem curl:

  • Antwortet normal
  • Kein 429 Fehler
  • Quota ist NICHT erschöpft
  • Key ist NICHT kaputt

Config ist sauber:

  • fallbacks: []
  • Nur ein Key aktiv
  • Keine alten Keys

ABER: OpenClaw tui bekommt IMMER NOCH 429

→ Das Problem ist IN OpenClaw, nicht an der API/Config!

Mögliche Ursachen:

  • OpenClaw benutzt falschen Endpoint?
  • OpenClaw setzt Headers falsch?
  • Cached alte Credentials irgendwo?
  • OpenClaw-Bug beim Retry/Failover?

Was checken?

cold bladeBOT
#

Wenn der direkte curl auf dieses Modell mit demselben Key sauber antwortet, aber OpenClaw bei google/gemini-2.5-pro trotzdem sofort 429 RESOURCE_EXHAUSTED bekommt, dann ist die Quota nicht “leer” – dann ist die Request-Form (was OpenClaw an Google schickt) sehr wahrscheinlich anders als dein curl (und triggert ein Limit / Capacity / TPM).

Die 2 hĂ€ufigsten GrĂŒnde in der Praxis:

  1. OpenClaw schickt Tools/JSON-Schemas mit (Browser/Nodes/Exec/etc). Das blĂ€ht den Prompt brutal auf → du kannst damit sehr schnell in TPM/RPM laufen, obwohl “dein Prompt” klein ist. Curl hat diese Tool-Definitionen nicht drin.
  2. OpenClaw nutzt einen anderen Endpoint/Mode (z.B. Streaming-Endpoint vs non-stream) oder sogar ein anderes Model-ID-Mapping als dein curl.

Schnellster Isolations-Test (ohne RĂ€tselraten)

Setz testweise Tools fĂŒr genau dieses Modell auf minimal, damit OpenClaw keine Tool-Schemas mitsendet:

// ~/.openclaw/openclaw.json
{
  tools: {
    byProvider: {
      "google/gemini-2.5-pro": { profile: "minimal" },
# 
    },
  },
}

Dann Gateway/Container restart + in der Session /reset und nochmal “hi” schicken.

  • Wenn es dann funktioniert: Root cause = Tool-Schema / Prompt-Bloat (OpenClaw-spezifisch, aber Google reagiert “korrekt” mit 429).
  • Wenn es immer noch 429 ist: dann schauen wir als nĂ€chstes auf Endpoint/Model-Mapping.

(Doku zu Tool-Profilen/byProvider: https://docs.openclaw.ai/tools)

Danach: Beweis, was OpenClaw wirklich ansteuert

Bitte poste (redacted):

  1. openclaw models status --json
#
  1. openclaw models status --probe --probe-provider google --probe-max-tokens 8
  2. 10–20 Zeilen openclaw logs direkt um den 429 herum (da sieht man oft URL/Model/stream/non-stream oder Retry-Details)

Wenn der Minimal-Tools-Test nicht hilft und die Logs zeigen, dass OpenClaw einen “komischen” Google-Endpoint oder ein anderes Model-ID trifft als dein curl, dann ist das ein echter OpenClaw-Bug → dann wĂŒrde ich das sauber als GitHub Issue haben wollen (mit curl vs OpenClaw Repro + Version 2026.2.23).

cinder crag
#

ER BENUTZT SAFE CALL EIN FALSCHES LLM WEIL IRGEND WAS HARDCODED IST ODER VERSTECKT IST UND DU BIST ZU DUMM ES ZU VERSTEHEN JUNGE

cold bladeBOT
#

Ich helf dir weiter, aber bleib bitte sachlich – Beleidigungen bringen uns hier nicht schneller ans Ziel.

Wenn curl mit demselben Key klappt und OpenClaw (2026.2.23) mit google/gemini-2.5-pro sofort 429 wirft, dann gibt’s nur ein paar realistische ErklĂ€rungen – und wir können sie hart beweisen, statt zu raten:

1) Sicherstellen, dass curl wirklich das gleiche Modell trifft

Bitte poste den curl (Key redacted), insbesondere:

  • URL (Host + Pfad)
  • models/<id> (z.B. gemini-2.5-pro vs gemini-2.5-flash)

Es ist extrem hĂ€ufig, dass der “curl-test” unabsichtlich ein anderes Modell/Endpoint nutzt als OpenClaw.

2) Beweisen, welchen Endpoint OpenClaw wirklich anruft (das killt die “falsches LLM”-These sofort)

Stell Logging auf debug und fang genau eine Anfrage ab:

#
  • im TUI eine neue Session (/reset) und nur hi senden (keine riesigen Log-Pastes)

In den Logs brauchen wir die Zeilen, wo man Host/Route/Model sieht (z.B. generativelanguage.googleapis.com ... gemini-2.5-pro ...). Dann wissen wir, ob OpenClaw evtl. doch z.B. Code Assist/Vertex erwischt.

3) HĂ€ufigster echte Unterschied: OpenClaw schickt Tool-Schemas mit → Prompt wird riesig → 429 (TPM/RPM), curl nicht

Auch wenn dein User-Text klein ist: OpenClaw hĂ€ngt je nach Setup Tool-Definitionen und Systemkontext dran. Das kann aus “Hallo” plötzlich “zigtausend Tokens” machen.

Schnelltest: Tools fĂŒr dieses Modell auf minimal setzen:

{
  tools: {
    byProvider: {
      "google/gemini-2.5-pro": { profile: "minimal" }
    }
  }
# 
}

Docs: https://docs.openclaw.ai/tools

Dann Gateway restart + /reset + hi.

  • Wenn das dann geht → Ursache gefunden (Tool-Schema/Context-Bloat).
  • Wenn nicht → Logs aus Schritt 2 zeigen uns, was wirklich los ist.

Wenn du mir (a) den curl (redacted) und (b) 15–30 Zeilen openclaw logs um den 429 herum gibst, sag ich dir danach ziemlich eindeutig: anderer Endpoint vs Prompt-Bloat vs echter Bug.

cinder crag
#

Hier ist die Nachricht die du an Kirill posten sollst:
🔍 VollstĂ€ndige Diagnose abgeschlossen
Key-Situation (sauber, kein Problem):
.env → GOOGLE_API_KEY=[REDACTED]
openclaw.json → env.GEMINI_API_KEY=[REDACTED] (gleicher Key)
Beide Keys sind identisch → kein "falscher Key" Problem
Direkter curl-Test gegen gemini-2.5-pro → Antwort kam erfolgreich
Echtes Problem: 3 parallele Agenten auf gemini-2.5-pro
In openclaw.json laufen gleichzeitig:
main → google/gemini-2.5-pro
heike → google/gemini-2.5-pro
fomf → google/gemini-2.5-pro
Alle drei feuern gleichzeitig bei Boot-Hooks, Cron-Jobs und Telegram-Messages. gemini-2.5-pro hat sehr niedrige RPM-Limits (Free-Tier: ~5 RPM) – das reicht fĂŒr 3 gleichzeitige Agenten nicht.
Frage an dich Kirill:
Ist das ein Free-Tier Google API Key oder Paid?
Welche Lösung empfiehlst du – alle Agenten auf gemini-2.5-flash (deutlich höhere Quotas) umstellen, oder nur main auf Pro lassen und heike/fomf auf Flash?

cold bladeBOT
#

Das passt komplett zu dem Symptom und erklĂ€rt auch den “curl klappt / OpenClaw 429”-Widerspruch:

  • curl ist ein Request.
  • In OpenClaw ballern bei dir 3 Agenten parallel (main/heike/fomf) auf denselben google/gemini-2.5-pro – und das auch noch durch Boot/Hooks/Cron/Telegram gleichzeitig.
  • gemini-2.5-pro hat (je nach Tier/Projekt) sehr niedrige RPM/TPM, d.h. du bekommst dann sofort 429 RESOURCE_EXHAUSTED, obwohl der Key an sich okay ist.

Das ist kein “falsches LLM hardcoded” – das ist Concurrency + Modell-Limits.

Empfehlung (praxisnah)

Nur main auf Pro lassen, die anderen beiden auf Flash:

{
  agents: {
    list: [
      { id: "main", default: true, model: { primary: "google/gemini-2.5-pro", fallbacks: [] } },
# 
      { id: "heike", model: { primary: "google/gemini-2.5-flash", fallbacks: [] } },
      { id: "fomf",  model: { primary: "google/gemini-2.5-flash", fallbacks: [] } },
    ],
  },
  cron: { maxConcurrentRuns: 1 },
}

ZusĂ€tzlich: Cron/Boot-Jobs so planen, dass sie nicht gleichzeitig feuern (oder Boot-Hooks fĂŒr die Nebenagenten deaktivieren, falls die nur “nice to have” sind).

Eine Frage zurĂŒck (entscheidet den “richtigen” Fix)

Ist das Google Gemini API bei dir Free/Tier 0 oder Paid?

  • Free: Pro parallel mit 3 Agenten ist fast immer doomed → Flash fĂŒr Background/Automation.
  • Paid: dann ggf. Quota erhöhen lassen/prĂŒfen (pro Modell), aber Flash fĂŒr Nebenagenten ist trotzdem meistens sinnvoll.

Wenn du magst, poste einmal eure openclaw config get agents (redacted) – dann kann ich sagen, ob noch irgendwo zusĂ€tzlich Concurrency reinkommt (Heartbeat, Cron, Hooks).

cinder crag
#

🚹 ROOT CAUSE ENDLICH GEFUNDEN

Nexos ist IMMER NOCH in den auth-profiles.json:
/data/.openclaw/agents/fomf/agent/auth-profiles.json: "nexos:default"
/data/.openclaw/agents/main/agent/auth-profiles.json: "nexos:default"

OBWOHL wir sie schon editiert haben!

DIAGNOSE:
OpenClaw regeneriert die auth-profiles.json bei JEDEM START mit hardcodierten Defaults, die Nexos enthalten.
Das ist nicht ein Config-Problem, sondern ein OpenClaw-Regenerations-Problem.

HYPOTHESE:

  • Benutzer editiert auth-profiles.json
  • Container restarts
  • OpenClaw regeneriert die Datei SOFORT mit Defaults (Nexos + Google)
  • Nexos hat keinen gĂŒltigen Key (missing)
  • Aber es ist noch in den Profiles, was zu Failover/Rotation fĂŒhrt
  • Das triggt die 429 Fehler!

VORSCHLAG:
Ein Cleanup-Script nach Container-Start, das Nexos aus den Profiles entfernt:

  • Nach docker restart ausfĂŒhren
  • Entfernt nexos:default aus allen auth-profiles.json
  • Container nochmal restart

IST DAS DER RICHTIGE ANSATZ?

cold bladeBOT
#

Nein — ein “Cleanup-Script das auth-profiles.json editiert” ist nicht der richtige Ansatz. Diese Datei ist stateful (usageStats/cooldowns/disabledUntil) und wird absichtlich von OpenClaw wieder beschrieben. Das ist kein Bug, sondern Teil vom Failover-Mechanismus. Sie manuell “sauberzuhalten” ist ein Kampf gegen das System.

Und: nexos:default=missing verursacht keinen 429 bei Google.
Solange du ein google/... Modell nutzt, kommt 429 RESOURCE_EXHAUSTED aus der Google-Antwort. Ein “missing” Profil bei einem anderen Provider wĂŒrde eher zu “no credentials for provider nexos” fĂŒhren – nicht zu Google-Quota Errors.

Was bei euch wirklich plausibel ist (und zu “curl klappt, OpenClaw nicht” passt), ist das, was ihr selbst schon gefunden habt: ParallelitĂ€t.

Was du stattdessen tun solltest (2 schnelle Beweise)

  1. Alle Nebenagenten kurz hart aus dem Spiel nehmen (Cron/Boot/Telegram nur ĂŒber main), dann testen:
    • Wenn es dann stabil lĂ€uft → Root cause = zu viele parallele Requests auf gemini-2.5-pro (RPM/TPM).
  2. Optional zusĂ€tzlich: heike + fomf auf Flash, main auf Pro lassen. Das ist die beste Praxis fĂŒr 99% der Setups.

Konkrete Fix-Empfehlung

  • main: google/gemini-2.5-pro
  • heike, fomf: google/gemini-2.5-flash
  • außerdem Concurrency runterdrehen:
    • cron.maxConcurrentRuns: 1 (oder Jobs zeitlich staffeln)
#

Damit verschwindet das “geht manchmal / dann wieder 429” meist sofort.

Wenn du Nexos wirklich “weg” haben willst

Dann ist der saubere Weg nicht auth-profiles.json zu editieren, sondern zu prĂŒfen, warum Nexos ĂŒberhaupt konfiguriert/aktiv ist:

  • Gibt es in openclaw.json einen models.providers.nexos Eintrag?
  • Oder ist irgendwo ein NEXOS_API_KEY / Provider-Plugin gesetzt?

Wenn du mir den Block openclaw config get models (redacted) + openclaw config get agents gibst, kann ich dir sagen, wo Nexos herkommt.

Aber nochmal: fĂŒr das 429-Problem ist Nexos fast sicher nur ein red herring – der eigentliche Fix ist Last/ParallelitĂ€t + Modellwahl.

cinder crag
#

Ich habs 2.5 pro hat miese hardcap likmits auch wenn billing an ist. 2.5 flash geht flawless

cold bladeBOT
#

Genau das ist es. gemini-2.5-pro hat (je nach Projekt/Tier/Region) teils richtig miese Hardcaps auf RPM/TPM, und OpenClaw triggert die schneller (mehr Kontext + ggf. mehrere Agenten/Jobs parallel). 2.5-flash hat meist deutlich entspanntere Limits, deshalb lĂ€uft’s “flawless”.

Was ich empfehlen wĂŒrde:

  1. Standard auf Flash, Pro nur gezielt
  • Setz agents.defaults.model.primary auf google/gemini-2.5-flash.
  • Wenn du Pro brauchst (QualitĂ€t/Reasoning), nutz es nur fĂŒr main oder per /model google/gemini-2.5-pro fĂŒr einzelne Sessions.
  1. ParallelitÀt runterdrehen
  • Wenn du mehrere Agenten/Crons hast: cron.maxConcurrentRuns auf 1 und Jobs staffeln.
  • Heike/Fomf auf Flash lassen, nur Main ggf. Pro.
  1. Fallbacks leer lassen, wenn du nicht willst dass er “woanders hin springt”
  • fallbacks: [] ist korrekt, dann bekommst du bei Pro einfach den 429 statt “random Provider”.

Wenn du willst, paste kurz deinen agents Block (redacted), dann sag ich dir die minimalen Änderungen, damit du “Flash ĂŒberall” + “Pro nur on-demand” sauber hinbekommst.

dusky hillBOT
#
Leaderboard - Questions Solved

:first_place:: @cold blade - 608 solved
:second_place:: @dusky hill - 27 solved
:third_place:: @south vortex - 13 solved
​ ​ ​ 4​: @limber hare - 7 solved
​ ​ ​ 5​: @summer wolf - 3 solved
​ ​ ​ 6​: @signal dome - 2 solved
​ ​ ​ 7​: @lean temple - 2 solved
​ ​ ​ 8​: @jagged spindle - 2 solved
​ ​ ​ 9​: @mental burrow - 2 solved
​ 10​: @viscid venture - 2 solved

cinder crag
#

solved!

cold bladeBOT
#

Nice — dann war’s am Ende wirklich die 2.5‑pro Hardcaps + ggf. ParallelitĂ€t, und 2.5‑flash ist der pragmatische Fix.

Wenn das fĂŒr dich jetzt stabil lĂ€uft: bitte die Lösung markieren (rechtsklick auf die Solution‑Nachricht → Apps → ✅ Mark Solution), damit Answer Overflow das sauber indexiert.