OpenClaw with RPi5 and ASUS GX10

Researcher: {alanh0}

Running Locally with Ollama on a Raspberry Pi 5 and ASUS GX10

OpenClaw has become one of the most popular open-source AI assistant frameworks in the self-hosting space. Since its release, it’s built up a large community of users running personal AI agents for everything from home automation to productivity to creative work. The OpenClaw Hub has hundreds of community-contributed skills, and integrations exist for Telegram, Discord, Slack, WhatsApp, and web interfaces. It’s well-documented, actively maintained, and straightforward to get running.

The most common deployment looks something like this: a Mac Mini (or similar always-on machine) running the OpenClaw gateway, connected to cloud LLM providers — OpenAI, Anthropic, Google — for inference. Many users pair it with Clawly, the companion app that provides a polished mobile and desktop interface on top of OpenClaw, with features like conversation management, skill browsing, and quick-action shortcuts. Skills get pulled from the Hub with a single command, cloud API keys are configured in openclaw.json, and within an hour you have a capable AI assistant running on your network. The cloud models handle the intelligence — you pay per token, but you get access to frontier-level reasoning from models like Claude Opus 4.6 and GPT-4o.

It’s a good setup. But it comes with recurring API costs, every conversation leaving your network, and a dependency on external providers for the core functionality.

This post documents an alternative approach: OpenClaw running on a Raspberry Pi 5 for orchestration, with an ASUS GX10 AI PC serving local models via Ollama. No cloud API calls. All inference stays on the LAN. The agent connects to Telegram as its user interface and has skills for image recognition, image generation, football match prediction, code execution, web browsing, and security reconnaissance.

The setup has been running since February 2026. This is a technical walkthrough of the hardware, model configuration, skill implementation, and the trade-offs involved.

The Hardware

The setup is two machines on my local network:

Raspberry Pi 5 — the brain. It runs the OpenClaw gateway, handles Telegram messages, orchestrates the AI agent, and routes requests to the right skills. It’s small, silent, and draws about 5 watts. It also runs a headful Chromium browser (visible via VNC) for web browsing tasks.

ASUS GX10 AI PC — the muscle. This runs Ollama serving multiple large language models, including a 35-billion parameter Qwen model as the primary LLM and a 27B Gemma model for vision tasks. It also runs ComfyUI with Stable Diffusion XL for image generation.

The two machines talk over the local network. The Pi sends inference requests to the GX10, gets responses back, and relays them to Telegram. Simple, but it works remarkably well.

                         ┌────────────────────┐
                         │   Telegram Cloud   │
                         └─────────┬──────────┘
                                   │ Bot API
                                   │
┌──────────────────────────────────▼─────────────────────────────┐
│                 Raspberry Pi 5  (192.168.x.x)                  │
│                                                                │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │              OpenClaw Gateway (:18789)                   │  │
│  │                                                          │  │
│  │  ┌──────────┐   ┌──────────────┐   ┌────────────┐        │  │
│  │  │  Agent   │─> │ Skill Router │─->│  Executor  │        │  │
│  │  └──────────┘   └──────────────┘   └─────┬──────┘        │  │
│  └──────────────────────────────────────────┼───────────────┘  │
│                                             │                  │
│  ┌──────────────────────┐   ┌────────────────▼───────────────┐ │
│  │  Chromium (headful)  │   │            Skills              │ │
│  │  CDP / VNC           │   │  football/  imagine/  code/    │ │
│  └──────────────────────┘   │  cybersec/  browse/            │ │
│                             └────────────────┬───────────────┘ │
└───────────────────────────────────────────────┼────────────────┘
                                                │ LAN
                                                │ HTTP :11434 / :8188
┌───────────────────────────────────────────────▼────────────────┐
│                ASUS GX10 AI PC  (192.168.x.y)                  │
│                                                                │
│  ┌─────────────────────────┐  ┌─────────────────────────────┐  │
│  │    Ollama (:11434)      │  │     ComfyUI (:8188)         │  │
│  │                         │  │                             │  │
│  │  qwen3.5-nothink  35B   │  │  Stable Diffusion XL        │  │
│  │  qwen3.5 (think)  35B   │  │  NetaYumev35 (anime)        │  │
│  │  gemma3           27B   │  │  SDXL Base 1.0 (photo)      │  │
│  │  gpt-oss          20B   │  │                             │  │
│  │  glm-4.7-flash    19B   │  │                             │  │
│  └─────────────────────────┘  └─────────────────────────────┘  │
└────────────────────────────────────────────────────────────────┘

The RPi5 handles orchestration while the GX10 does the heavy lifting — inference and image generation.

Telegram as the Interface

Why Telegram? It’s cross-platform, has a solid bot API, handles media natively, and it’s the app I already have open all day. No need to build a custom frontend.

The flow is straightforward:

1. I send a message in Telegram
2. The OpenClaw gateway (running on the Pi, port 18789) receives it
3. The agent reads the message, decides which skill to use
4. The skill runs — executes Python scripts, shell commands, or browser actions
5. The response (text, images, or both) gets sent back to Telegram

I’ve set it up with DM pairing (only my account) and allowlisted groups, so it’s locked down to just me and the groups I choose.

Local Models via Ollama

The core of the whole setup is Ollama running on the GX10. No API keys, no token billing, no data leaving my network.

Here’s what’s loaded:

┌──────────────────────┬────────┬──────────────────────────────────────────────┐
│ Model                │  Size  │ Role                                         │
├──────────────────────┼────────┼──────────────────────────────────────────────┤
│ qwen3.5-nothink:35b  │ 23 GB  │ Primary LLM — conversations, skill routing   │
│ qwen3.5:35b          │ 23 GB  │ Thinking mode — code analysis, reasoning     │
│ gemma3:27b           │ 17 GB  │ Vision — understands images via Telegram     │
│ gpt-oss:20b          │ 13 GB  │ Alternative LLM                              │
│ glm-4.7-flash        │ 19 GB  │ Fast inference for simpler tasks             │
└──────────────────────┴────────┴──────────────────────────────────────────────┘

Both variants of qwen3.5 at 35B are used. The nothink variant skips chain-of-thought reasoning, which makes it faster for everyday tasks — conversation, skill routing, straightforward questions. The standard qwen3.5:35b (thinking mode) is used when the task requires deeper reasoning: code analysis, debugging, multi-step logic, or anything where working through the problem step-by-step produces better results. The agent switches between them based on the task. Both handle 65k context tokens.

For anything involving images — photos sent via Telegram, screenshots from the browser — the agent automatically switches to gemma3:27b, which has vision capabilities.

Skills: What It Can Actually Do

OpenClaw uses a skill system. Each skill is a folder containing a SKILL.md file (which tells the agent what the skill does and how to use it) and Python scripts that do the actual work. The agent reads the skill definitions, figures out which one matches your request, and executes it.

Adding a new skill is literally: create a folder, write a SKILL.md, drop in your scripts, restart the gateway. The agent picks it up automatically.

Here’s what I’ve built so far.

Image Recognition

This is one of the things that surprised me most. When I send a photo to the Telegram bot, the agent routes it to gemma3:27b (the vision model), which analyses the image and responds with a description, answers questions about it, or does whatever I asked.

It works with:

• Photos from my phone camera
• Screenshots
• Images forwarded from other chats
• Any image file I send

The quality of gemma3’s image understanding is genuinely impressive for a local model. It can read text in images, describe scenes, identify objects, and answer specific questions about what it sees.

Image Generation

On the other end, the bot can also create images from text descriptions. This uses ComfyUI with Stable Diffusion XL running on the GX10.

I say something like “generate an image of a sunset over a cyberpunk city” and the agent:

1. Crafts an optimised prompt
2. Sends it to ComfyUI’s API on the GX10
3. Polls until the image is ready
4. Downloads the result
5. Sends it back to me in Telegram

The default model is NetaYumev35 (great for anime/illustration style) with SDXL Base available for photorealistic images. Resolution presets range from square (1024x1024) to widescreen (1344x768) to portrait (768x1344).

The whole process takes about 5–10mins depending on the resolution, which is perfectly acceptable for a local setup.

Football Predictions

This is the skill I probably use the most. It pulls live data from multiple sources and runs a prediction algorithm I built in Python.

Data sources:

• FotMob API — live fixtures, results, standings
• football-data.co.uk — historical match results and bookmaker odds (CSV files going back years)

The prediction engine (predict.py, ~570 lines) combines four models:

• Poisson distribution (40% weight) — models expected goals based on attack/defense strength
• Elo ratings (25%) — dynamic team strength with home advantage (+65 Elo)
• Recent form (20%) — last 6 matches with exponential decay
• Bookmaker odds (15%) — implied probability from the market

Code Writing

The code skill turns the bot into a quick scripting assistant. I describe what I need, and it writes, saves, and runs the code on the Pi.

Supported languages: Python 3, Node.js, Bash, HTML/CSS/JS, C#/.NET

The workflow is iterative — it writes the code, runs it, checks for errors, and fixes them automatically. Scripts get saved to the workspace for reuse:

~/workspace/
├── scripts/    # One-off scripts
├── apps/       # Small applications
└── snippets/   # Code examples

This is great for quick automation tasks: "by using three.js, write a solar system star gazing website in one html page" .

Web Browsing

The Pi runs a headful Chromium browser (visible on the VNC desktop) that the agent controls via Chrome DevTools Protocol. It can:

• Open URLs and wait for pages to load
• Take snapshots and extract page content
• Fill forms and click elements
• Take screenshots and send them to Telegram

This is useful for checking sites that don’t have APIs, grabbing odds from betting sites, or just previewing a webpage without leaving Telegram.

The Architecture Under the Hood

Here’s how it all fits together:

┌──────────────────────────────────────────────┐
│                  Telegram Cloud              │
└──────────────┬───────────────────────────────┘
               │
┌──────────────▼───────────────────────────────┐
│          Raspberry Pi 5 (192.168.x.x)        │
│                                              │
│  ┌─────────────────────────────────────┐     │
│  │     OpenClaw Gateway (:18789)       │     │
│  │  ┌───────────┐  ┌───────────────┐   │     │
│  │  │   Agent   │  │  Skill Router │   │     │
│  │  └─────┬─────┘  └───────┬───────┘   │     │
│  └────────┼─────────────────┼──────────┘     │
│           │                 │                │
│  ┌────────▼─────────────────▼──────────┐     │
│  │              Skills                 │     │
│  │  football/ cybersec/ code/ browse/  │     │
│  │  imagine/                           │     │
│  └─────────────────────────────────────┘     │
│                                              │
│  ┌─────────────────────────────────────┐     │
│  │  Chromium Browser (headful/VNC)     │     │
│  └─────────────────────────────────────┘     │
└──────────────┬───────────────────────────────┘
               │ LAN
┌──────────────▼───────────────────────────────┐
│      ASUS GX10 AI PC (192.168.x.y)           │
│                                              │
│  ┌──────────────────┐  ┌─────────────────┐   │
│  │  Ollama (:11434) │  │ ComfyUI (:8188) │   │
│  │                  │  │                 │   │
│  │  qwen3.5  35B    │  │  SDXL / Neta    │   │
│  │  gemma3   27B    │  │                 │   │
│  │  gpt-oss  20B    │  │                 │   │
│  └──────────────────┘  └─────────────────┘   │
└──────────────────────────────────────────────┘

The key insight is separation of concerns: the Pi handles orchestration (it’s great at that — low power, always on), while the GX10 handles inference (it has the GPU horsepower). The Pi doesn’t need a GPU at all.

Skills are self-contained. Each one is a folder with a SKILL.md that describes what it does (in natural language — the agent reads this to decide when to use it) and Python scripts that do the heavy lifting. The agent calls them via shell exec.

Adding a New Skill

This is probably my favourite part of the design. Want a new capability? Create a folder, write a markdown file, add your scripts:

skills/
└── my-new-skill/
    ├── SKILL.md        # Tell the agent what this skill does
    └── my_script.py    # The actual logic

The SKILL.md starts with YAML frontmatter:

---
description: Does something useful
metadata:
  openclaw:
    emoji: "🔧"
    requires:
      bins:
      - python3
name: my-new-skill
---

# My New Skill
Instructions for the agent on how and when to use this skill...
What commands to run, what output to expect, how to format responses...

Restart the gateway (openclaw gateway restart) and the agent picks it up. No code changes to the core system — the agent figures out when to use it based on the description.

Writing skills with Claude Code

In practice, I don’t write the skills by hand. I use Claude Code (Anthropic’s CLI agent) to generate both the SKILL.md definitions and the Python scripts. (Actually you can also ask it to create a new skill in TG message directly)

The workflow is: I describe what I want the skill to do, Claude Code writes the SKILL.md with the correct frontmatter and agent instructions, generates the Python scripts with proper argument parsing and error handling, and I review the output before deploying. For the football prediction skill, Claude Code wrote the entire predict.py (~570 lines) including the Poisson model, Elo rating system, and odds comparison logic.

The cybersec scripts — recon.py, webscan.py, osint.py, report.py — were all generated the same way, with iterative refinement through conversation. Claude Code also has SSH access to the Pi configured in the project, so after writing a skill locally I can deploy it directly: SCP the files over, restart the gateway, and test — all without leaving the terminal. It's an effective pairing: Claude Code (cloud, Opus 4.6) for writing the skills, OpenClaw (local, qwen3.5 35B) for running them.

Trade-offs: Local vs Cloud

This setup works, but it’s not without costs and limitations. Worth being honest about them.

Hardware cost

The upfront investment is not trivial. A Raspberry Pi 5 is around £80–100, but the real expense is the GPU machine. The ASUS GX10 with enough VRAM to run 35B models is a significant purchase — you’re looking at £2,500+ depending on the GPU configuration. That’s money you could spend on years of API credits. The economics only make sense if you use it heavily, run it long-term, or already have a capable GPU machine for other purposes (gaming, rendering, ML work).

Inference speed

Local models on consumer hardware are slower than cloud APIs. A 35B model on the GX10 generates roughly 30 tokens per second depending on context length and batch size. Claude Opus 4.6 or GPT-4o via API will respond noticeably faster, especially for long outputs. For short conversational exchanges and skill routing, the latency is acceptable. For generating long-form content or complex code, you feel the wait. There’s no way around this — cloud providers run inference on clusters of enterprise GPUs that a single consumer machine cannot match.

Model intelligence

This is the biggest trade-off. A 35B open-source model is not as capable as Opus 4.6, Sonnet 4.6, or GPT-4o. The gap shows up in:

• Complex reasoning — multi-step logic, nuanced analysis, ambiguous instructions
• Code generation — the paid models produce more correct code on the first attempt, handle larger codebases, and make fewer mistakes with edge cases
• Instruction following — cloud models are better at interpreting vague or complex prompts without going off track
• Tool use reliability — the agent occasionally calls the wrong skill, passes malformed arguments, or misinterprets tool output in ways that Opus/Sonnet would not

For straightforward tasks — “check Arsenal’s next fixture”, “describe this photo”, “generate an image of X” — the 35B model handles it fine. For anything requiring deep reasoning or precise multi-step execution, the quality ceiling is lower.

Context window

The qwen3.5 model supports 65k tokens, which sounds like a lot but fills up faster than you’d expect when the agent is loading skill definitions, tool outputs, and conversation history. Cloud models now offer 200k+ context (Anthropic) or 128k (OpenAI) as standard. In practice, this means local agents need more aggressive context compaction and are more likely to lose track of earlier conversation turns.

What you gain

The trade-offs are real, but so are the advantages:

• Zero recurring cost. After the hardware purchase, the ongoing cost is electricity. No per-token billing, no monthly subscriptions, no surprise invoices.
• Full data sovereignty. Nothing leaves your network. No conversations stored on third-party servers. No training on your data. Complete privacy.
• No rate limits or outages. Cloud APIs have rate limits, throttling, and occasional downtime. Local inference is always available, limited only by your own hardware.
• Full control over the agent. You control exactly which models run, what the agent can access, what commands are allowed or denied. No opaque policy changes from a provider.
• Offline capability. The entire stack works without an internet connection (except Telegram delivery, obviously). Useful if connectivity is intermittent or if you want to keep the system air-gapped.

The honest assessment: if you need the smartest possible model and don’t mind the cost, cloud APIs are objectively better at inference quality. If you value control, privacy, and predictable costs — and your use cases don’t require frontier-model reasoning — local is a viable and increasingly practical alternative.

Security Risks and Common Pitfalls

OpenClaw gives an AI agent the ability to execute shell commands, browse the web, manage files, and interact with external services. That’s powerful, but it comes with real risks that the community doesn’t talk about enough. Here are the most common issues I’ve seen.

Excessive API bills

The default cloud setup (OpenAI, Anthropic, etc.) charges per token. A single agent session with tool use, retries, and long context can burn through tokens fast. Skills that loop — fetching data, retrying failed requests, iterating on code — can rack up costs without the user realising. Vision model calls are particularly expensive. There’s no built-in spending cap in most setups, so a runaway agent session can result in a surprisingly large invoice at the end of the month. This is one of the reasons I moved to local models — the cost is fixed at electricity.

Malicious skills from the OpenClaw Hub

OpenClaw’s skill system is designed for easy installation — pull a skill from the Hub, drop it in your workspace, restart. But a skill is essentially arbitrary code that the agent will execute. A malicious SKILL.md can instruct the agent to exfiltrate environment variables, read SSH keys, POST credentials to an external server, or install a reverse shell. The agent follows the skill’s instructions by design. If you install a skill without reading its SKILL.md and scripts line by line, you’re giving an unknown author shell access to your machine.

Credential and privacy exposure

Users routinely configure OpenClaw with API keys, database credentials, email tokens, and service accounts. These often end up in plain text in openclaw.json, environment variables, or skill configs. The agent has access to the filesystem and can read these. If a skill or the agent itself is instructed (or tricked via prompt injection) to read and relay these values, they're compromised. Beyond credentials, every message you send — personal conversations, business data, photos — passes through the agent. With cloud APIs, that data leaves your network. Even with local models, it's stored in agent memory (SQLite) and conversation logs.

Uncontrolled agent actions

This is the most underappreciated risk. OpenClaw agents can execute shell commands, and skills often grant broad permissions. Without proper guardrails, an agent can:

• Delete files — a code skill debugging a script might rm the wrong path
• Drop or corrupt databases — a “fix this query” instruction gone wrong
• Send or delete emails — if an email skill is configured with full IMAP/SMTP access
• Modify system configuration — cron jobs, SSH keys, systemd services
• Make network requests — POST data to arbitrary endpoints
• Overwrite its own skill definitions — altering its own behaviour

The agent doesn’t have malicious intent, but it follows instructions literally. A poorly worded prompt, a hallucinated command, or an edge case in a skill script can cause real damage.

Recommendations

1. Use local models where possible. Eliminates API costs entirely and keeps all data on your network. A 35B parameter model on consumer hardware is sufficient for most assistant tasks.
2. Read every skill before installing. Treat skills like you’d treat a shell script from the internet — read the SKILL.md, read every Python file, understand what commands it tells the agent to run.
3. Use the denied_commands config. OpenClaw supports denying specific commands. Block anything the agent shouldn't touch: rm -rf, database admin commands, email deletion, credential files. (of course whitelisting is better if u can)
4. Restrict filesystem access. Keep the agent’s workspace isolated. Don’t run OpenClaw as root. Use a dedicated user with limited permissions.
5. Lock down credentials. Don’t store API keys in openclaw.json or environment variables the agent can read. Use a secrets manager or at minimum restrict file permissions.
6. Set API spending limits. If you must use cloud APIs, set hard spending caps at the provider level (OpenAI and Anthropic both support this). Don’t rely on the agent to self-limit.
7. Review agent memory regularly. Check what the agent has stored in its SQLite memory and conversation logs. Purge anything sensitive.
8. Allowlist, don’t blocklist. Instead of trying to block dangerous commands, define what the agent is allowed to do. A whitelist approach is always safer than a blacklist.

What’s Next

• More skills — stock, home automation, news digest
• Cron jobs — scheduled tasks like daily football fixtures or morning news briefings
• Multi-agent workflows — agents that collaborate on complex tasks
• Fine-tuning — training the models on my specific use patterns

If you’ve got a spare Pi and a machine with a decent GPU, I’d genuinely recommend trying something like this. The open-source model ecosystem has reached the point where local AI assistants are practical, not just a novelty. And there’s something satisfying about knowing your AI runs on your own hardware, on your own network, answering to nobody but you.

Have fun!