2026 OpenClaw in der Praxis: Gestufter Modell-Cache & Aufräum-Fenster

Legen Sie einen Dienst- oder Build-Benutzer fest (kein wechselndes interaktives Login), damit launchd-Umgebung und Dateirechte über SSH-Sessions hinweg identisch bleiben. Trennen Sie gedanklich zwei Ebenen: ein Hot-Tier auf schneller interner NVMe (niedrige Latenz für kleine Shard-Reads) und ein Warm-Tier auf zweitem Volume, USB4/TB-Platte oder Netz-Mount für Archiv-Gewichte. Dokumentieren Sie jede Umgebungsvariable, die Ihr OpenClaw-Stack liest – typisch ein Home-Konfigverzeichnis plus Hersteller-Caches (Hugging Face, Ollama, llama.cpp). Gleichen Sie die Namen mit dem Installations- und Fehler-Leitfaden ab, damit Kolleginnen und Kollegen dieselbe Verzeichnisstruktur reproduzieren.

Installation / Konfiguration – Kurzablauf:

1. Node 22+ und OpenClaw-Version pinnen; in internem Runbook festhalten.
2. mkdir -p ~/Library/Logs/OpenClawCache und Rechte 755 für den Dienstbenutzer setzen.
3. HF_HOME, OLLAMA_MODELS oder Äquivalente in EnvironmentVariables der LaunchAgent-Plist – keine Secrets ins Repository.
4. diskutil apfs list und stabile /Volumes/…-Namen prüfen (keine flüchtigen „Untitled“-Labels nach Reboot).

Tragen Sie OPENCLAW_HOME oder projektspezifische Pfade in dasselbe Runbook ein wie Gateway-Bindung und Token-Rotation (siehe Deployment-Überblick). Für externe SSDs: Volume-Namen in der Festplattendienstprogramm-Oberfläche eindeutig setzen; bei Scripting diskutil info mit UUID notieren, damit Mount-Reihenfolge nach Neustart nicht Ihre Symlink-Ziele verschiebt.

Wählen Sie einen kanonischen Pfad, den alle Jobs und Skripte nutzen (z. B. ~/.openclaw/cache/models). Die echten Blobs liegen unter tier-spezifischen Wurzeln wie /Volumes/FastSSD/oc-models und /Volumes/BulkDisk/oc-models-archiv. Ersetzen Sie das kanonische Verzeichnis durch einen Symlink auf das Hot-Tier, damit CI keine Mount-Buchstaben hardcodiert.

# Beispiel: kanonischer Pfad zeigt auf schnelles Tier (OpenClaw-Jobs zuerst stoppen)
mkdir -p "/Volumes/FastSSD/oc-models"
rm -rf "$HOME/.openclaw/cache/models"   # vorher sichern, falls echtes Verzeichnis
ln -s "/Volumes/FastSSD/oc-models" "$HOME/.openclaw/cache/models"
readlink -f "$HOME/.openclaw/cache/models"

Promotion vom Warm- zum Hot-Tier mit rsync -a --partial --inplace oder atomarem mv innerhalb desselben APFS-Volumes. Demotion seltener Gewichte umgekehrt – vorher Prüfsummen oder Manifeste sichern.

Löschen Sie nicht blind, solange OpenClaw mmap-Handles hält. Nutzen Sie ein Aufräum-Fenster, wenn CI ruhig ist – typisch 02:00–04:00 Ortszeit auf Remote-Mac-Pools. Auf macOS empfiehlt sich ein Benutzer-LaunchAgent mit StartCalendarInterval (Stunde + Minute) statt crontab, sofern Sie nicht ohnehin Linux-kompatibles Scheduling pflegen; LaunchAgents erben die GUI-Session des Users und sind pro Tenant leichter auditierbar.

Zur Log-Rotation: schreiben Sie datierte Dateien unter ~/Library/Logs/OpenClawCache/ und ergänzen Sie einen Eintrag unter /etc/newsyslog.d/ oder eine wöchentliche gzip-Runde in derselben Plist. Mindestens sieben Tage Cleanup-stdout aufbewahren, um plötzliche Cache-Misses zu erklären.

#!/bin/bash
set -euo pipefail
find "$HOME/.openclaw/cache/tmp" -type f -mtime +3 -delete
find "$HOME/.openclaw/cache/tmp" -type d -empty -delete

Hinweis: optional vorher mit pgrep -f openclaw oder Job-Lock prüfen, ob gerade geschrieben wird; bei Bedarf Skript mit flock absichern.

Typische Startkalender-Intervalle: Hour = 2, Minute = 15 für ein einmaliges Nachtfenster; für wöchentliche Tiefreinigung zusätzlich Weekday setzen. Nach launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/de.macpull.openclaw-cache-cleanup.plist immer launchctl print gui/$(id -u)/de.macpull.openclaw-cache-cleanup prüfen – ein Tippfehler im Label verhindert stilles Nicht-Laufen. Teams über mehrere Zeitzonen: entweder UTC in der Plist vereinbaren oder ein zentrales SSH-Skript aus der CI auslösen, damit sich Fenster nicht überlappen.

Kombinieren Sie Quota-Ideen mit einfachem df-Parsing in einem Patrol-Skript. Praktische Entscheidungsmatrix für geteilte Apple-Silicon-Runner (2026):

Unterstützt der Host Volumen-Quotas, setzen Sie Soft-Limits knapp unter der Marketing-Kapazität, damit APFS-Snapshots nicht überraschen. Immer df -h und df -i prüfen: Inode-Erschöpfung wirkt wie „Platte voll“, lässt sich aber nicht durch Löschen einer einzelnen 200-GB-Datei beheben.

Hüllen Sie Downloads in begrenzten exponentiellen Backoff (z. B. 5 s, 15 s, 45 s) mit Jitter ein, damit eine Flotte von Macs keinen Mirror flattiert. Typische Symptome und Maßnahmen:

• ENOSPC / „No space left“ — Zielvolume des Symlinks prüfen, nicht nur $HOME.
• Stale file handle — externes Volume neu einhängen; APFS-Verschlüsselung-Unlock-Reihenfolge beim Boot verifizieren.
• HTTP 429 / 5xx — Registry-Policy; Parallelität senken, Retry-After respektieren.
• Permission denied — umask vs. Dienstbenutzer; nach macOS-Updates openclaw doctor erneut ausführen.

Gateway-Stabilität mit Fehlerbehandlung, Recovery und Retry abstimmen, damit Automation nicht gegen einen flappenden Daemon arbeitet. Sicherheitskontext: Gateway-Härtung; CI-Pre-Pull: ClawHub & Pre-Pull.

• Kanonischer Symlink ist vor dem ersten Job nach Kaltstart aufgelöst.
• Patrol-Skript druckt lesbare Auslastung und beendet mit Exit ≠ 0 bei > 90 % auf dem Fast-Tier.
• Destructives Cleanup erst nach zwei grünen Dry-Runs; Logs mit Ticket-ID archiviert.
• CI referenziert ausschließlich den kanonischen Pfad – keine doppelten Mount-URLs.
• Rollback-Beschreibung: Symlink in ≤ 5 Min. zurück auf Warm-Tier oder letzte bekannte Struktur.