Kosteneffiziente OpenClaw-Automatisierung: Nutzung von LLMs nur bei Bedarf

Ein Entwickler auf r/openclaw beschreibt eine kostensensible Automatisierungsstrategie, die den LLM-Einsatz minimiert, indem deterministische Aufgaben von nicht-deterministischer Problemlösung getrennt werden.

Der Kernansatz

Der Entwickler vermeidet die Heartbeat-Funktionalität von OpenClaw aufgrund von Kostenbedenken bezüglich LLM-Aufrufen alle 30 Minuten. Stattdessen nutzt er OpenClaw, um Python-Skripte für spezifische Aufgaben wie das Lesen von Gmail-Posteingängen, das Aktualisieren von Linux-Servern, das Scraping von Websites und das Laden von Daten in Datenbanken zu erstellen. Diese Skripte handhaben deterministische Operationen und werden als System-Cron-Jobs auf einem VPS geplant, wobei monatliche VPS-Ressourcen anstelle von pro Aufruf berechneten LLM-Guthaben genutzt werden.

Fehlerbehandlung und Selbstheilung

Jeder Cron-Job gibt eine Statusdatei mit Erfolgs-/Fehlerinformationen und Fehlerdetails aus. Ein separates Selbstheilungs-System-Cron läuft einmal täglich, um diese Statusdateien zu überprüfen. Wenn Fehler erkannt werden, sendet dieses System eine Nachricht an das OpenClaw-Gateway mit dem Skript, Fehlerinformationen und einer Aufforderung, das LLM zu bitten, den Fehler zu analysieren, das Skript zu reparieren und einen erneuten Versuch zu starten. Hier findet der LLM-Einsatz statt – nur wenn nicht-deterministisches Verständnis und Problemlösung benötigt werden.

Polling-Optimierung

Für Polling-Aufgaben wie das Überprüfen eines Posteingangs, wo normalerweise nichts zu tun ist, kann derselbe Ansatz in einem einzigen Skript implementiert werden. OpenClaw erstellt ein Skript, das das Polling handhabt, und ruft das OpenClaw-Gateway nur dann auf, wenn tatsächlich Arbeit zu verarbeiten ist. Das bedeutet, dass das LLM nur dann genutzt wird, wenn es etwas zu tun gibt, und nicht, um zu prüfen, ob es etwas zu tun gibt.

Vergleich mit Heartbeat

Der Entwickler stellt fest, dass dieser Ansatz im Wesentlichen das Gegenteil der Heartbeat-Funktionalität ist. Er funktioniert nicht für Anwendungsfälle, bei denen das LLM dynamisch die nächsten Schritte auswählen und unbegrenzt iterieren muss. Der Entwickler hinterfragt den Wert, LLM-Aufrufe 52 Mal täglich ohne disziplinierte Fokussierung zu starten, und betrachtet den ständigen LLM-Einsatz für viele Automatisierungsszenarien als potenziell verschwenderisch.