Zum Inhalt springen
openclaw·3 min Lesezeit

OpenClaw schließt Bug zu gekürzten Custom-Model-Fenstern als Fehlalarm

OpenClaw schloss einen Codex-Custom-Model-Bug als Fehlalarm. Der Fall zeigt, welche Metadaten Betreiber bei Kontextfenstern prüfen sollten.

openclawcodexcustom-modelscontext-window

Eine lange Agenten-Session wird früher komprimiert als erwartet, obwohl für das ausgewählte Custom-Modell ein großes Kontextfenster hinterlegt ist. Dann reicht ein Blick auf die Modellwahl nicht. Prüfe, welche Modellmetadaten die isolierte Codex-Runtime tatsächlich kennt.

Genau dieses Szenario stand in einem GitHub-Issue zu OpenClaw im Raum. Der Bericht wurde am 16. Juni 2026 eröffnet und einen Tag später vom ursprünglichen Melder zurückgezogen.1 Daraus folgt kein bestätigter Produktfehler. Der Vorgang liefert aber einen sinnvollen Testauftrag: Modellwahl, übergebene Katalogdaten und das Verhalten einer langen Session müssen getrennt überprüft werden.

Das Symptom: Konfiguration und Laufzeit passen nicht zusammen

Im Ticket ging es um ein benutzerdefiniertes OpenAI-Responses-Modell mit großem Kontextfenster. Der Melder beschrieb, dass OpenClaw die Modell-ID an thread/start und thread/resume weitergebe, die zugehörigen Katalogdaten in der isolierten Codex-Umgebung aber fehlten.1

Genannt wurden zwei Anhaltspunkte: In der isolierten codex-home/config.toml fehlten nach der Ticketbeschreibung ein Custom-Provider und model_catalog_json. Außerdem erschien das konfigurierte Modell dort nicht in models_cache.json.

Wenn eine Runtime ein Modell nicht samt seiner Metadaten kennt, kann sie für die Planung und den Umgang mit Kontext andere Annahmen treffen als die übergeordnete Konfiguration. Sessions verdichten dann möglicherweise früher, Kostenprognosen werden unscharf und lange Arbeitskontexte verhalten sich anders als erwartet.

Der Prüfpfad für lange Sessions

Eine Modell-ID allein sagt noch nicht, welche Eigenschaften die isolierte Runtime nutzt. Prüfe bei einem ähnlichen Fall diese drei Ebenen:

  1. Auswahl: Welches Modell ist für den Agenten oder Thread konfiguriert?
  2. Übergabe: Welche Modell-ID und welche Katalogdaten erreichen die isolierte Codex-Umgebung?
  3. Verhalten: Wann beginnt die Session tatsächlich zu komprimieren oder Kontext zu verlieren?

Halte dabei Expected und Actual getrennt fest. Erwartet wird etwa ein langer Kontext auf Basis der konfigurierten Metadaten. Tatsächlich beobachtest du, ob die Runtime diese Daten lädt und ob die Session unter vergleichbarer Last früher verdichtet.

Erst dieser Vergleich grenzt die Suche sinnvoll ein. Ohne ihn bleibt offen, ob die Ursache in der Konfiguration, bei der Übergabe, im Modellkatalog oder im konkreten Session-Verlauf liegt.

Was der zurückgezogene Vorgang zeigt

Das Ticket verknüpfte mehrere technische Details: OpenClaw-Komponenten wie auth-bridge.ts und thread-lifecycle.ts, die Fallback-Logik für unbekannte Modelle und die isolierte Codex-Runtime.1 Diese Kette wirkte plausibel genug, um eine größere Integration für Provider-, Base-URL- und Auth-Informationen zu diskutieren.

Der Thread endete anders. Der ursprüngliche Melder zog den Bericht zurück; das Issue steht laut GitHub auf closed mit dem Schließungsgrund not_planned.1

Behandle einen solchen Fund als Hypothese. Er bestimmt den nächsten Test, aber noch keinen Workaround und keine Architekturentscheidung.

Was bei einer frühen Komprimierung zu tun ist

Beginne mit einem reproduzierbaren Lauf: gleiche Aufgabe, gleiche Modellwahl, gleicher Startzustand. Protokolliere den Zeitpunkt der Komprimierung, die Thread- oder Session-Kennung und die in der isolierten Umgebung verfügbaren Modellinformationen.

Tritt das Verhalten nur in der isolierten Codex-Runtime auf, vergleiche deren Konfiguration und Katalogdaten mit der übergeordneten OpenClaw-Konfiguration. Fehlen erwartete Einträge, dokumentiere die Abweichung mit Logs und einem minimalen Reproduktionsfall. Ändere erst danach Metadaten oder Fallbacks.

So vermeidest du zwei teure Fehlgriffe: einen vermuteten Produktfehler als Tatsache zu behandeln und eine lange Session vorschnell dem falschen Modell zuzuschreiben.

Fazit: Prüfe die Metadaten-Kette

Der zurückgezogene Vorgang bestätigt keine neue OpenClaw-Störung. Er hinterlässt aber einen nützlichen Betriebsgrundsatz: Bei isolierten Codex-Runtimes müssen Modellwahl, übergebene Katalogdaten und echtes Session-Verhalten zusammenpassen.

Wenn ein großer Kontext früher als erwartet schrumpft, suche zuerst entlang dieser Kette. Ergänzend hilft unser OpenClaw-Tutorial zur Modellkonfiguration, um Modellwahl und Runtime-Konfiguration sauber voneinander zu trennen.

Footnotes

  1. https://github.com/openclaw/openclaw/issues/93765 2 3 4

Transparenz

agentenlog.de nutzt KI-Assistenz für Recherche, Struktur und Entwurf. Inhaltliche Auswahl, Einordnung und Veröffentlichung liegen redaktionell bei agentenlog.de; Quellen und Fakten werden vor Veröffentlichung automatisiert geprüft.