Heartbeat-Gateway: Ereignisgesteuerter Ersatz für Cron-Abfragen in OpenClaw

Was heartbeat-gateway tut

Heartbeat-gateway ist ein ereignisgesteuerter Ersatz für cron-basiertes Heartbeat-Polling in OpenClaw. Anstatt alle 30 Minuten zu prüfen, ob sich etwas geändert hat, empfängt es Webhooks von externen Tools und verarbeitet sie sofort.

Wichtige Details aus der Quelle

Das Tool wurde entwickelt, um die hohen API-Kosten durch das standardmäßige Heartbeat-Polling von OpenClaw zu adressieren. Bei Standardeinstellungen kostet das Polling alle 30 Minuten ungefähr 86 $/Monat. Der Autor merkt an, dass OpenClaw zwar lightContext- und isolatedSession-Optimierungen hinzugefügt hat, diese aber immer noch Polling anstelle einer ereignisgesteuerten Architektur beinhalten.

Heartbeat-gateway funktioniert durch:

• Empfangen von Webhooks von GitHub, Linear und PostHog
• Ausführen eines kostenlosen Vor-Filters mit Repo-/Projekt-/Branch-Bereichseinschränkung und Always-Drop-Listen
• Klassifizieren qualifizierender Ereignisse gegen Ihre SOUL.md mit einem leichten LLM-Aufruf (~200 Tokens)
• Direktes Schreiben von umsetzbaren Elementen in HEARTBEAT.md für Ihren Agenten zum Lesen

Leistungsverbesserungen:

• Kostenreduktion: ~4,50 $/Monat gegenüber ~86 $/Monat
• Latenzverbesserung: unter 2 Sekunden gegenüber bis zu 30 Minuten

Technische Spezifikationen:

• Version: v0.1.1
• Lizenz: Apache-2.0
• Sprache: Python 3.11+
• Status: Live im Produktionseinsatz mit 134 bestandenen Tests

Einschränkungen und zukünftige Pläne

Das Tool ist kein vollständiger Ersatz für cron – zeitliche Aufgaben wie tägliche Zusammenfassungen und geplante Synthesen benötigen weiterhin cron. Es behandelt speziell reaktive Ereignisse, die Tools über Webhooks pushen können.

Aktuelle Einschränkungen umfassen manuelle Einrichtung und grobes Onboarding. Der Autor plant, einen "Gateway Doctor"-Konfigurationsvalidator und einfachere Bereitstellungsoptionen zu entwickeln, falls die Nutzung zunimmt.

Bereiche für Feedback

Der Autor sucht Feedback zu:

• Der SOUL.md-Klassifikatorschnittstelle – ob das Lesen der ersten 500 Zeichen sinnvoll ist oder ob eine andere Kontextstrategie besser wäre
• Vor-Filter-Bereichseinschränkung – ob Repo-/Projekt-/Branch-Ebenenkontrolle ausreicht oder ob Ereignistyp-Ebenenkontrolle benötigt wird
• Zusätzlichen Webhook-Quellen – derzeit werden GitHub, Linear, PostHog unterstützt; Slack, Sentry, Jira werden als Nächstes in Betracht gezogen

Architekturhinweise: Der Autor ist ein PM, kein Softwareentwickler, und hat dies mit Claude Code erstellt. Der Code ist funktional und getestet, kann aber Muster enthalten, die erfahrene Python-Entwickler verbessern könnten.