OpenClaw: Building a Local AI Agent
From benchmark suite to autonomous Telegram bot — deploying Gemma 4 as an agentic pipeline on a 2017 iMac with Vulkan GPU acceleration.
Benchmarking models is inherently synthetic. It proves a machine can crunch numbers, but it doesn't prove it can do anything useful. After pushing Gemma 4 to its limits on older hardware, the natural next step was building a tangible application: a local AI agent.
OpenClaw is an orchestration engine that wires my local, Vulkan-accelerated llama-server to a Telegram bot named ClawdyDawdy. It doesn't just chat — it executes tool calls. It can search the web via DuckDuckGo, parse results, format responses in markdown, and text me the answers, all from a 9-year-old desktop.
The architecture quickly evolved past simple linear execution. To prevent long-running tasks from locking up the main thread, OpenClaw now automatically spawns headless subagents. This tiered routing lets a fast model handle the chat interface while delegating heavy background processing to larger MoE models running purely on system RAM.
Timeline
Buried a secret password ('AURORA-7742') inside 10, 50, 200, and 500 filler sentences, then asked the E4B to find it. 4/4 perfect retrieval. Zero degradation at any depth. The model also passed multi-turn coherence 4/5 — it remembered the user's name, city, and hardware across 5 conversation turns. The only failure was on turn 5 where it forgot the original city. For a 7.5B model running locally at 24 tok/s on a Vulkan GPU — this is legitimately impressive context handling. The implications for agentic workflows are clear: this model can maintain state across long conversations without losing the thread.
Hit my first major architecture roadblock with the local Telegram bot. Gave it a massive 10-source web research task. If it ran on the main thread, the bot would have been locked completely for 45 minutes, unable to answer new texts. Instead, the OpenClaw orchestration engine automatically spawned a headless 'Subagent' background process. The main bot said 'I'll get back to you', freed up the thread, and the Subagent crunched the web in the background for 42 minutes before delivering a perfect markdown report. Now looking at Tiered Routing: running a fast E2B model as the communicative router on the GPU, and delegating the heavy lifting Subagents to a 26B MoE running purely on system RAM. The iMac 2017 handles it flawlessly.
For weeks I've been running synthetic benchmarks to see if a 2017 iMac can handle 30B parameter LLMs. The answer was yes, but benchmarks are boring. Today I wired up OpenClaw to my local Vulkan-accelerated llama-server and built a Telegram bot named ClawdyDawdy. It works. The e4b model at 24 tok/s is fast enough for conversational fluid responses, and handles tool-calling flawlessly. We're no longer just testing models, we're building autonomous agents that text me from a 9-year-old desktop.
Spent the morning trying to upgrade from E4B (7.5B dense) to the 26B-A4B MoE model. Downloaded two different quants — unsloth and bartowski — and both produced the same garbage: an infinite stream of <unused50> tokens. Tried every flag combination: --cpu-moe, --jinja, custom Jinja templates, raw completion endpoints. Nothing worked. Then the breakthrough: the E4B (dense architecture) works perfectly on the exact same Vulkan binary and GPU. The bug is in llama.cpp's Vulkan compute shaders for MoE expert routing. Filed additional reproduction data on GitHub issue #21516. Different hardware (AMD vs their NVIDIA), different token IDs (<unused50> vs <unused8>), but same root cause. Sometimes the most useful contribution to open source is a well-documented failure.
Asked ClawdyDawdy to search the web for Google I/O 2026 dates. Seven minutes later, Telegram delivered: 'May 19-20, Shoreline Amphitheatre, Mountain View.' The full chain fired: Telegram → OpenClaw gateway → Gemma 4 E4B on Vulkan GPU (7.46 tok/s) → tool call → DuckDuckGo search → parsed results → formatted response → back to Telegram. This is a 2017 iMac with a 4GB AMD GPU running an autonomous agent that can search the web, reason about results, and text me the answer. Updated llama.cpp to v38 today and got a free 25% speed boost (was 6 tok/s, now 7.46). Also reclaimed 215 GB of disk by purging orphaned Ollama blobs. The machine breathes again.
The HuggingFace community said 'bartowski quants fix the <unused50> bug.' Downloaded 12 GB of bartowski's Gemma 4 26B-A4B Q3_K_M. Loaded it on a separate port (8081) so the working E4B stayed live on 8080. First test with --cpu-moe: <unused50> at 10 tok/s. Faster garbage, but still garbage. Without --cpu-moe: <unused50> at 0.5 tok/s. Even raw /completion endpoint (no chat template whatsoever): <unused50>. Seven configurations tested, zero success. The community was wrong — it's not a quant issue at all, it's a Vulkan MoE shader bug. My E4B pipeline stays as the daily driver. Sometimes the answer is: the model you have, configured well, beats the model you want.