Post-Mortem: Claude Max + OpenClaw Abrechnungsfehler durch veraltete OAuth- und isolierte Cron-Jobs

Ein selbst gehostetes OpenClaw-Setup mit Claude Max gab plötzlich billing error — API key has run out of credits zurück, obwohl das Kontingent bei Weitem nicht ausgeschöpft war. Zwei Tage Debugging zeigten zwei Ursachen und eine Kill Chain, die den Fehler zufällig erscheinen lassen.

Ursache 1: Veralteter OAuth-Token vergiftet gesamten Anbieter

Die Datei auth-profiles.json enthielt zwei Einträge: ein gültiges OAuth-Profil anthropic:claude-cli und ein anthropic:manual-Profil mit einem sk-ant-oat01-...-Token. Als der manuelle Token abgelaufen war, scheiterte OpenClaw nicht nur bei diesem Profil – es klassifizierte ihn als Anbieter-Abrechnungsfehler und setzte den gesamten anthropic-Anbieter auf die Blacklist, sodass alle Modelle (einschließlich des gesunden OAuth-Profils) übersprungen wurden. Die Logs zeigten:

reason: "billing" errorPreview: "Provider anthropic has billing issue (skipping all models)" chain_exhausted

Das gesunde OAuth-Profil mit einem gültigen Refresh-Token wurde nie versucht.

Behebung: Entfernen Sie anthropic:manual vollständig aus auth-profiles.json und openclaw.json. Behalten Sie nur anthropic:claude-cli.

Ursache 2: Isolierte Cron-Jobs treffen ein separates Abrechnungskontingent

OpenClaw hat zwei Ausführungspfade:

• Hauptsitzungen – führen die Binärdatei /usr/bin/claude aus, die auf das Max/Pro-Abonnement abgerechnet wird ✅
• Isolierte/eingebettete Ausführungen – direkte HTTP-Anfragen an die Anthropic-API, die auf den Extra Usage-Bucket abgerechnet werden ❌

Cron-Jobs mit sessionTarget: isolated starten einen eigenständigen eingebetteten Agenten, der die Anthropic-API direkt per HTTP aufruft – ohne die Claude-Code-Header, die die CLI sendet. Anthropic leitet dies an den Extra Usage-Bucket, ein völlig separates Kontingent. Wenn Extra Usage deaktiviert ist, gibt jeder isolierte Cron-Job einen 400-Fehler zurück. OpenClaw verschlimmert die Situation: Ein Abrechnungsfehler setzt in auth-state.json disabledUntil auf etwa 24 Stunden in der Zukunft und blockiert alle Anfragen – einschließlich normaler Chats – bis die Abklingzeit abläuft. Die Sperre überlebt Gateway-Neustarts.

Die vollständige Kill Chain

1. Gateway-Neustart → verpasste Cron-Jobs werden für Nachholung eingereiht
2. Isolierter Agent startet über eingebetteten Runner → direkter HTTP-Aufruf an die Anthropic-API (keine CLI-Header)
3. Extra Usage-Bucket → 400-Fehler
4. OpenClaw sperrt das Auth-Profil für ~24 Stunden → alle Anfragen blockiert, einschließlich normaler Chats

Behebungen

1. Abrechnungssperre sofort löschen:

   python3 -c "
   import json
   with open('/home/USER/.openclaw/agents/main/agent/auth-state.json') as f:
       d = json.load(f)
   if 'usageStats' in d:
       for profile in d['usageStats']:
           d['usageStats'][profile].pop('disabledUntil', None)
           d['usageStats'][profile].pop('failureCounts', None)
           d['usageStats'][profile].pop('errorCount', None)
           d['usageStats'][profile].pop('disabledReason', None)
           d['usageStats'][profile].pop('lastFailureAt', None)
   with open('/home/USER/.openclaw/agents/main/agent/auth-state.json', 'w') as f:
       json.dump(d, f, indent=2)
   print('Gelöscht.')
   "
   openclaw gateway restart

2. Alle Cron-Jobs von isolated nach main verschieben:

   python3 -c "
   import json
   with open('/home/USER/.openclaw/cron/jobs.json') as f:
       d = json.load(f)
   jobs = d if isinstance(d, list) else d.get('jobs', [])
   for j in jobs:
       if j.get('sessionTarget') == 'isolated':
           print(f'Behoben: {j["name"]}')
           j['sessionTarget'] = 'main'
   with open('/home/USER/.openclaw/cron/jobs.json', 'w') as f:
       json.dump(d, f, indent=2)
   print('Fertig.')
   "

Für wen das relevant ist: Alle, die OpenClaw mit Claude Max oder Pro selbst hosten und trotz ausreichendem Kontingent zufällige Abrechnungsfehler sehen.