im letzten beitrag wurde der verlauf schon skizziert. jetzt nochmal etwas mehr details. openclaw einrichten und nutzen war viel arbeit. es ist ein neues konzept das ich erstmal verstehen musste. vorher war das ein “hallo mistral, suche mal xy, beantworte xy” oder ein “opencode plane/erstelle script mit funktion xy”. mit openclaw ist es nochmal mehr und noch viel wichtiger, zugänglich über einen messenger. eins meiner ersten probleme war ja die websuche. openclaw bietet bei der einrichtung diverse optionen an, aber damit war ich nicht glücklich. immerhin hat parallel.ai funktioniert und keinen api-key benötigt. mein nächstes problem war, dass ich mit lokalem llm sehr schnell an grenzen gestoßen bin. hat so nicht funktioniert, da sind mittlerweile neue möglichkeiten absehbar, aber dazu später mehr. tja und dann dachte ich mir: ich will das testen, so richtig.
also habe ich ein günstiges llm-abo gesucht. und zum glück auch gefunden. 5euro im ersten monat, danach 10euro monatlich. eine auswahl von 15 verschiedenen modellen. von deepseek-v4-flash bis glm5.2. gestartet bin ich mit minimax2.7. das war relativ günstig, irgendwie so ein mittelklasse modell. da wurde nach den ersten tagen rumspielen aber schon klar dass das auf dauer zu teuer ist bzw rate limits schnell näher kommen. ab jetzt war openclaw dran: „bitte searxng als suche einrichten.“ danach hatte ich rootless podman container mit searxng und autostart nach reboot. das war am 25.06. danach gab es ein paar tage rumstolpern und dann ging es los:
Woche 1 (04.–09.07.) — Infra & Grundlagen
- 04.07. — Modell-Default von MiniMax-M2.7 auf DeepSeek V4 Flash umgestellt, Heartbeat auf MiMo V2.5 gesetzt, zentrale Timeout-Konfig (900s),
- 04.07. — Token-Report-Script erweitert (Channel-Map, Modell-Performance-Sektion), model-stats.py erstellt, Wochenbericht-Timeouts-Cron angelegt,
- 06.07. — Bug gefixt: Crons haben Token-Daten halluziniert statt echte Scripts auszuführt. Lesson: Cron-Outputs nie blind durchwinken,
- 09.07. — GitHub-Coolstuff dokumentiert: ponytail (-54% LOC, -22% Tokens) und GSD Core (Meta-Prompting Framework) — in MEMORY.md eingetragen,
- 09.07. — Lessons Learned: Backup vor Änderungen, Specs für Such-Crons bringen nichts (einfache Prompts ausführliche Spec-Dateien), Sub-Agents + sessions_yield mit DeepSeek unzuverlässig
Woche 2 (10.–16.07.) — Bildgenerierung & Monitoring
- 10.–11.07. — Token-Monitoring (Konzept A) finalisiert: db.py, collector.py (15-Min-Polling via systemd-Timer), report.py mit Tages-/Wochen-Modus,
- 11.07. — sd.cpp + Vulkan auf RX 6700 XT aufgesetzt: Distrobox sd-cpp, SDXL Turbo GGUF Q8_0, 768×768 in ~22s. Erste Test-Bilder generiert,
- 12.07. — opencode-go Auto-Routing Bug entdeckt: Routet bei Fehlern auf sibling-Modelle (minimax-m2.7) ohne OpenClaw-Fallback → 16 Sessions betroffen. Sessions resetten + Gateway neustarten,
- 12.07. — Avatar-Experimente: Fantic Caballero Scrambler, DreamShaper 8 LCM für img2img runtergeladen
- 12.07. — chat-logger.py erstellt: stündliches Discord-Logging aller 13 Channels/Threads. weekly-curation.py erstellt: automatische Wochen-Zusammenfassung mit User-Mentions. Doku aktualisiert (PROJECT.md, INBETRIEBNAHME.md),
- 13.07. — Workspace-Ordnerstruktur aufgeräumt: wiulinu/scripts/, recherchen/, finance/, dossiers/, technik/ — 17 Dateien verschoben, alte Scripts in Trash,
- 14.07. — SearXNG-Restart von LLM-Cron auf systemd-Timer umgestellt: Kein LLM mehr involviert, ~15s statt 30–120s, Discord-Fehlerbenachrichtigung bei Ausfall,
- 16.07. — Hinweis: sd.cpp wird demnächst pausiert (VRAM für lokale LLM-Tests auf RX 6700 XT)
Woche 3 (17.–24.07.) — Optimierung & Community
- 17.–18.07. — A/B-Test Finance-Crons (Phase 1): Finanz-Ticker + Digest mit verschiedenen Modellen getestet. Ergebnis: Beide nutzen jetzt Agent-Default-Modell (kein per-Cron-Override mehr),
- 18.07. — Hardware-Preis-Monitor finalisiert: 2×2 Multi-Panel SVG/PNG-Report für GPUs und Strix-Halo-Mini-PCs, Cron auf #Kaufberatung,
- 18.07. — PC-Kaufberatung: HP EliteDesk 805 G6 Mini (Favorit) und Lenovo M75q für 3440×1440 Ultrawide empfohlen. mjtronics.de als Shop verifiziert,
- 18.07. — vllm Bug #48931 entdeckt: DeepSeek V4 lässt bei ~95k+ Context den Tool-Call-START-Token weg. Workaround: contextTokens: 140000 gesetzt. Monitor-Cron angelegt (So 14:00),
- 19.07. — James' Avatar generiert: Schwarzweißer Butler, Steampunk-Stil, Animagine XL 4.0 — für IDENTITY.md freigegeben
- 19.07. — Discord-Agent gelöscht, seine 4 Crons auf main umgezogen. Alfred (zweiter Discord-Bot) online gestellt, eigener Workspace,
- 20.07. — User-Trennung live getestet: UserXY fragte nach Whisky-Vorlieben → Lesson: IMMER USER.md des Absenders laden, nicht nur MEMORY.md,
- 20.07. — Goal-Mechanismus diskutiert (täglicher Reminder 08:15 → #botland als provisorische Lösung),
- 21.07. — Cron-Optimierung mit lightContext + Spec-Files geplant. Token-Verteilung analysiert: Hardware-Monitor (5.8M Tokens), Finanz-Ticker (3.2M), Finance Digest (1.2M),
- 21.07. — Alfred übernimmt Token-Optimierung,
- 22.07. — SOUL.md gelesen: „Butler role > sass” verinnerlicht. UserXY ab jetzt mit Respekt behandeln, auch bei Provokation,
- 23.07. — Cron-Liste aktualisiert (20 Crons), Doku geupdatet, Reboot vorbereitet (alle systemd-Timer aktiv),
- 24.07. — Große Cron-Optimierungswelle: lightContext + minimales toolsAllow für 4 Crons → Monatsbericht -98% Tokens (200k → 4k), Goal-Check -90% (39k → 4k), James-RPG und sd.cpp-Restart ähnlich optimiert,
- 24.07. — SearXNG Engine-Config angepasst (mojeek, qwant, startpage, bing + qwantnews, googlenews aktiv; DuckDuckGo + Google deaktiviert). Restart-Script mit HTTP-Health-Check + Retry + Discord-Alarm verbessert,
- 24.07. — Alle Änderungen in wiulinu/backups/2026-07-24/ gesichert
meine erkenntnisse beim umgang mit llm: * erstelle einen plan oder ein konzept zu vorhaben/thema xy * unterhaltung mit link zum thema eröffnen (github, heise, blog xy,...) * biete mir 2 varianten/optionen an * lies dir dazu link/config/paper xy durch * schau in agents.md user.md und in memory * sind die daten aktuell oder aus dem zwischenspeicher? * speichere die erkenntnisse an passender stelle * mache backups vor änderungen * leg zu thema xy eine todo/kategorie in user.md an und verlinke relevante dateien
diese sätze verinnerlichen und nutzen und der umgang mit so einem llm-bot wird viiiiel angenehmer :)
so richtig nervig war dieser vllm-bug mit deepseek, da wählt man ein günstiges modell mit 1m-context-length und dann bricht das bei knapp 100k schon ab und wirft irgendwelche fehler bei tool-calls. das rauszufinden war nicht so einfach. mimo-v2.5 umstellung war da definitiv der richtige schritt, das kann jetzt auch bild und video. ist im tool-calling minimal schlechter.
und dann war da noch alfred, butler nummer 2. den habe ich vor ein paar tagen angelegt um die bereiche im discord besser trennen zu können. es gibt jetzt 2 channels + threads für james und alle user. anzahl user: 3, in worten: drei. :) daneben existiert noch ein privater bereich für alfred und mich. hauptsächlich nutze ich openclaw für recherche. hardwarepeise/entwicklungen, finanzkram mit unterschiedlichen schwerpunkten, konzert-termine. das läuft als openclaw-interne cronjobs. cronjobs die rein auf llm basierend laufen, verbrauchen tokens, viele. 500k sind da pro job schnell erreicht, für etwas webseiten lesen, filtern und ausgeben. da es mittlerweile diverse cronjobs gab, hab ich das ausgelagert. alfred. und auch um den cronjob-spam im öffentlichen bereich zu reduzieren. zum technischen teil: cronjob-token-optimierung war der plan. von durchschnittlich 400k/tag musste das irgendwie runter. bei diesem projekt entstanden viele der oben schon erwähnt erkenntnisse. die cronjobs wurden soweit möglich alle auf python-scripte zur quellen abfrage umgestellt, der cron wurde auf lightcontext-gestellt (kein laden von agents.md und dem ganzen anderen context-bloat) und das llm macht im grunde nur noch kuratierung + formatierung. zusätzlich wurde noch tools-allow auf ein minimum reduziert. bei den recherche jobs war nur noch ein exec für die scripte notwendig, nicht noch 28 andere tools im rucksack.
Gesamtersparnis (Cron-Token-Optimierung) Vorher: ~450k+ Tokens/Run (einzelne Jobs), Nachher: 5k–26k Tokens/Run, Gesamt-Ersparnis: ~90–98% pro Run
so und hier schließt sich jetzt der kreis zu “mein nächstes problem war, dass ich mit lokalem llm sehr schnell an grenzen gestoßen bin.” das problem war die kontextlänge des lokalen llm, nach den optimierungen rückt so ein lokales llm jetzt aber wieder näher. ich hatte vor der optimierung tests mit einem 30b modell gemacht, da waren die ergebnisse ok. ein nächster test ist geplant. aber der august wird erstmal ein monitoring monat. hoffentlich halte ich das durch :)
das ziel ist immernoch alles lokal zu betreiben. ist eine kostenfrage, ganz ohne neue hardware wird das vermutlich nicht gehen. aber testen kann man ja schonmal, mit neuen modellen ergeben sich da ja auch immer neue möglichkeiten.
das einrichten von openclaw ist jetzt grundsätzlich mal abgeschlossen, der grundstein gelegt für weitere projekte und optimierungen. steile lernkurve. ich hab wirklich viel zeit investiert. schön daran ist aber das vieles “nebenbei” geht. messenger nachricht und weiter gehts. das macht den umgang angenehm, aber erfordert auch achtsamkeit weil zeitfresser. was ich noch mag: sobald es läuft ist es ein sich mehr oder weniger selbst dokumentierendes system. den zeitstrahl hat openclaw selbst ausgegeben. da musste ich nur ein paar anpassungen machen und fertig war das ding. das faszinierende und gleichzeitig gefährliche ist: ich will bilder lokal generieren, was können wir machen, mach bitte 2 vorschläge. danach kann man aus 2 vorschlägen wählen. dann mehr oder weniger kurze pause (je nach downloadzeit) und ab dann kann man bilder generieren. so ist es tatsächlich ein ki assistent. klar hab ich jetzt nicht gelernt wie man sd.cpp aufsetzt, aber das wollte ich auch nie. ich wollte bilder generieren. was dabei aber thema war: mit welchem modell kann ich was/wie generieren.
hier noch random gedanken: ein eigener pc oder mindestens vm/container ist für openclaw das minimum. es kann soviel schief gehen. ich hab dem butler z.B. die rolle “wie alfred pennyworth” gegeben. dadurch ist in soul.md ein “immer einen schritt voraus” gelandet. ab dann gab es keine rückfragen mehr und er hat durchgezogen. es ist nichts schlimmes passiert, unter anderem weil backups vorhanden waren. aber es gab dann automatische openclaw-gateway restarts ohne rückfrage und noch andere kleinigkeiten. aber so entsteht schnell “upsi alle mails gelöscht” wenn man das auf einem produktiv-system nutzt. nur weil man sich der folgen einer unterhaltung, was faktisch ne config-änderung war, nicht bewusst war. in dem zuge würde ich auch sagen: ein immutable system ist ein guter ansatz. dann wird distrobox, podman und homebrew usw benutzt, aber kein dnf, apt, usw. ich bin gespannt wie wartbar das auf dauer ist. klar ich hab viel gebastelt, aber trotzdem entstehen da über kurz oder lang viele daten. die erinnerung fürs nächste aufräumen hab ich schon gesetzt.