stichpunkte zur aktuellen entwicklung – multiuser-testbetrieb “abgeschlossen” – alfred übernimmt nahezu alle aufgaben – llm-test abgeschlossen – cronjobs auf lokales llm umgestellt – cronjob llm – 12b 8b 4b? – llm-abo “bug” gefixt, baseUrl notwendig – openclaw fluxer extension (wird eigener beitrag)
zum multi-user-betrieb von openclaw kann ich sagen: es funktioniert nicht. openclaw ist für eine person gedacht. hauptproblem ist meiner meinung nach das logging bzw session-übergreifende themen/unterhaltungen. in der standardeinstellung speichert openclaw alles als “user”. egal wer im gruppenchat schreibt. habe ich versucht mit settings anzupassen und ordner pro user anzulegen und noch bisschen mehr feintuning. damit wurde das verhalten besser, aber es war immernoch nervig. und irgendwie hat der bot dann auch immer vergessen wie er sich verhalten soll. ich denke das liegt am context-rot.
das alles wäre vielleicht benutzbarer gewesen hätte ich bessere modelle als deepseek-v4-flash oder mimo-v2.5 verwendet. aber das war mir openclaw dann doch nicht wert. ich nutze ein sehr limitiertes opencode-go-abo für 10euro/monat. wenn man damit etwas recherche betreibt und keine optimierten crons hat, dann reicht ein modell wie minimax2.7 gerade so über den monat. nur mit mimo-v2.5 (unglaublich günstig) oder deepseek (mittlerweile nicht mehr so günstig, aber ok) komme ich gut über den monat. da ist auch noch etwas luft für opencode-projekte.
mit dem ende vom multi-user-betrieb habe ich also umstrukturiert. überblick über cronjobs verschafft, entsprechende channels angelegt. cronjobs von james zu alfred. cronjobs angepasst.
zwischendurch dachte ich noch ein brauche einen weiteren cron-runner agenten, aber das war nicht so einfach umsetzbar wie ich im ersten moment dachte. weil der austausch zwischen agenten/channels/sessions in openclaw erstmal gut getrennt ist. könnte man aufheben, führt dann aber zu context-length problemen die ich auch nicht austesten wollte.
also llm-test:
| # | Modell | Typ | Größe | Context | Preis (Input/Output) | | 1 | Laguna S 2.1 | MoE | 118B (8B aktiv) | 1M | $0.09 / $0.18 | | 2 | Ling 3.0 Flash | MoE | 124B (5.1B aktiv) | 262K | $0.021 / $0.063 | | 3 | Gemma 4 31B | Dense | 31B | 256K | $0.10 / $0.34 | | 4 | Laguna XS 2.1 | MoE | 33B (3B aktiv) | 262K | $0.06 / $0.12 | | 5 | Qwen3.7 Flash | MoE | ~14-30B | 1M | $0.03–$0.20 / $0.13–$0.80 | | 6 | Qwen3.6-35B-A3B | MoE | 35B (3B aktiv) | 256K | $0.15 / $1.00 |
laguna s: gutes modell, war als 2. referenz zu mimo gedacht. hat erwartungsgemäß funktioniert ling: testabbruch, openrouter ratelimits, lief einfach nicht gemma4 31b: gut für crons, chat notfalls auch, seeeeehr laaaangsaaam. lief auch über openrouter laguna xs: für crons ok, doppelt so schnell wie gemma4 qwen3.7-flash: für cron ok, günstig qwen3.6-35-a3b: aus kostengründen gestrichen
der test hat ca 5euro gekostet. alle kleineren modelle in der 30b kategorie waren überraschend teuer. war aber auch nicht mehr so wichtig, ich wusste ja gemma4-31b läuft. dann habe ich ein handvoll cronjobs auf https://huggingface.co/unsloth/gemma-4-12B-it-qat-GGUF umgestellt. was bedeutet umgestellt: ramalama pull, ramalama-gemma.servce anlegen, passend dazu den systemd-timer für den täglichen restart und dann auch noch etwas rumspielen mit den settings.
ramalama serve \ —backend vulkan \ —image ghcr.io/ggml-org/llama.cpp:full-vulkan \ —runtime-args=“—cache-ram 0” \ hf://unsloth/gemma-4-12B-it-qat-GGUF:UD-Q4KXL \ —port 8080 \ —threads 4 \ —ctx-size 84000 \ —host 0.0.0.0 Restart=always RestartSec=30 TimeoutStartSec=300
dann noch eine überwachung ob der dienst auch läuft und nicht mehrere container gleichzeitig. lief soweit gut, war langsam und meine 12gb vram immer mit 10.8gb belegt. also nochmal einen blick auf die cronjobs geworfen. im grunde brauche ich nur ein modell das tool-use kann, wissen, mathe oder was auch immer spielt bei den cronjobs kaum eine rolle. so die theorie. und schon war das nächste projekte entstanden. läuft auch schon mit einem 4b modell, aber dazu in einem anderen beitrag mehr.
wie oben erwähnt, ich nutze das opencode-go-abo. openclaw hat ein opencode-plugin damit der provider einfacher eingerichtet werden kann. mein openclaw läuft auf extended-stable. vielleicht sehr ihr schon in welche richtung das geht :) ich wollte also neue modelle testen. im august gab es ja so einiges. glm-5.3-flash, lingcat-2.0 und qwen3.8-flash waren auf meiner wunschliste. im august hat opencode go auch eine option im webinterface eingeführt mit “in china gehostete llm zulassen”. das problem war für mich, dass ich immer unterschiedliche fehlermeldungen bekommen habe. bei glm sowas wie... glm5.2 wird automatisch auf 5.3-flash, aber 5.3flash ist ein reasoning modell, da muss reasoning aktiviert sein, bei longcat fehler 402 bei qwen anfangs “modell nicht verfübar” (hat der wiu typo gemacht), danach dann auch 401 oder api-key geht nicht. die sehr einfache erkenntnis: neue modelle brauchen einen custom-config eintrag mit baseUrl bei openclaw. das opencode-go plugin ist nicht aktuell genug und es fehlt die config.