OpenClaws Kontextverwaltung wird als tokenintensiv und architektonisch fehlerhaft kritisiert

Ein Reddit-Nutzer hat eine detaillierte Kritik an der Architektur von OpenClaw veröffentlicht, die sich speziell auf dessen Ansatz zum Kontextmanagement richtet. Der Beitrag argumentiert, dass das Framework Zustände ineffizient verwaltet, indem es das Kontextfenster des LLM durch faule, alles-oder-nichts-Kontextauslagerungen als "Mülldeponie" behandelt.

Wie OpenClaw mit Kontext umgeht

Laut der Quelle fehlt OpenClaw ein ordentliches Zustandsmanagement und die Isolierung ephemerer Zustände. Jedes Mal, wenn der Agent einen Schritt macht, wird die neue Aktion blind an den globalen Verlauf angehängt. Innerhalb von drei Runden wird der Prompt aufgebläht mit:

• Dem globalen System-Prompt
• Der gesamten Langzeitspeicherdatei des Nutzers
• Einer Liste aller verfügbaren Tools
• Der Rohausgabe des letzten Befehls
• Allen vorherigen Aktionen

Das Problem mit kleineren Modellen

Der Beitrag beschreibt, was passiert, wenn OpenClaw auf schnelleren, günstigeren Modellen wie Flash- oder Mini-Varianten läuft:

• Kleinere Modelle leiden unter dem "Lost-in-the-Middle"-Syndrom, wenn sie in 50.000+ Token alter Terminalausgaben, Tool-Protokolle und globaler Persona-Prompts ertrinken
• Diese Modelle vergessen buchstäblich das ursprüngliche Ziel
• Sie halluzinieren entweder, dass die Aufgabe bereits abgeschlossen ist
• Oder sie geraten in eine Endlosschleife, in der sie exakt dasselbe Tool mit exakt denselben Argumenten aufrufen

Die Abhängigkeit von Claude Opus

Die Kritik erstreckt sich auf OpenClaws Abhängigkeit von Spitzenmodellen:

• OpenClaw behauptet, Agenten seien "hochfähig", aber diese Fähigkeit kommt daher, dass es sich auf massive Spitzenmodelle wie Claude Opus stützt
• Claude Opus kann sich ein 80.000-Token-"Müllfeuer" ansehen und erfolgreich 79.500 Token nutzlosen historischen Ballasts ignorieren, um den nächsten Schritt abzuleiten
• Dies erweckt den Anschein, dass das Framework gut gebaut ist, obwohl in Wirklichkeit Opus architektonische Inkompetenz kaschiert
• Nutzer zahlen am Ende Opus-Preise, damit ein hochmodernes LLM als "veredelter Müllfilter" für schlecht konstruierten Kontext fungiert

Architektonische Empfehlungen

Der Beitrag plädiert für bessere Technik statt roher Gewalt:

• Eine einfache mehrstufige Browser- oder Terminalaufgabe sollte kein Billionen-Parameter-Modell erfordern
• Bei korrekter Umsetzung sollte die Schleife das Modell zwingen, die Umgebung zu beobachten und ihm genau das zu zeigen, was es jetzt sehen muss, und absolut nichts anderes
• Dieser Ansatz könnte dieselbe Erfolgsquote mit einem Bruchteil der Rechenleistung auf günstigeren, schnelleren Modellen erreichen