Why I Wanted to Experiment with OpenClaw

I have been building AI applications for a while — MCP servers, workflow automations, fine-tuned models. Most of my work involves connecting AI models to tools and data sources, and I wanted a platform that let me run an AI agent in a persistent way: something that could browse the web, run code, read files, and handle longer-horizon tasks without me babysitting each step.

OpenClaw caught my attention because it is self-hosted, open-source, and model-agnostic. You bring your own LLM — any OpenAI-compatible endpoint — and the platform handles the agent loop, tool dispatch, and a browser-based control UI. It felt like the right fit for the kind of experiments I had in mind: model evaluation workflows, automated research tasks, and testing agent reliability across different open-source models.

I went with the chat interface provided by OpenClaw's Control UI rather than integrating channels like WhatsApp or Slack, so that I could quickly start interacting with OpenClaw without any additional setup.

The catch: I did not want to install it on my own machine. Running OpenClaw locally means keeping a Node.js service and a vLLM inference server running in the background, tying up memory and GPU. My machine is already busy. I wanted the agent to live somewhere it could run continuously, not compete with my daily work.

---

Then I Received AMD Developer Cloud Credits

The timing worked out. I received promotional credits for AMD Developer Cloud — AMD's developer program that provides access to MI300X GPU instances via DigitalOcean, billed by the hour.

What made AMD Developer Cloud the right match for this:

• AMD MI300X with 192 GB VRAM. More than enough to run a large MoE model like Qwen3-30B at full precision, with memory to spare. On my local machine I would be constrained to much smaller models.
• ROCm pre-installed. The droplet image comes with AMD's Radeon Open Compute stack already configured, so vLLM works out of the box without manual driver installation.
• DigitalOcean provisioning. Spin up a droplet, SSH in, install software, run. No Kubernetes, no complicated cloud setup. Simple enough to document as a reproducible tutorial.
• Hourly billing with destroy-to-stop. Spin it up for an experiment session and tear it down afterwards. No idle cost.

---

I Deployed Qwen3-30B-A3B as the Language Model

OpenClaw needs an LLM to power its agent loop. Since I could not use Anthropic Claude directly (more on that below), I needed an open-source model served via an OpenAI-compatible API. I chose Qwen3-30B-A3B and deployed it on the same droplet via vLLM on ROCm.

The choice was straightforward given the MI300X's hardware profile. Qwen3-30B-A3B is a Mixture-of-Experts (MoE) model: 30B total parameters but only 3B active per token, so it runs fast while matching the reasoning quality of much denser models. The 192 GB VRAM on the MI300X was more than enough to load the full model at full precision, with memory to spare.

Keeping the model on the same machine as OpenClaw meant no external API latency for every tool call the agent dispatches.

---

I Documented Every Step — You Can Follow Them

Once I had a working setup, I documented it as a step-by-step tutorial. It covers everything from generating your SSH key to accessing the OpenClaw Control UI from your local browser. Written for Windows users, but the droplet-side commands are Linux and work on any OS.

The tutorial covers 8 sections: preparing your local machine, creating the GPU droplet, setting up the droplet (Node.js, vLLM with Qwen3-30B-A3B, SearXNG, OpenClaw configuration and gateway), accessing the Control UI via SSH tunnel, and shutting down and destroying the droplet to stop billing.

Read the full deployment tutorial: Deploying OpenClaw on AMD Developer Cloud →

---

What Didn't Work — and Why

Three models were attempted before arriving at Qwen3-30B-A3B. All failures are specific to how OpenClaw interacts with the vLLM ROCm build, not issues with AMD Developer Cloud or the MI300X hardware.

---

How Claude Code Helped Me Debug During Deployment

The deployment did not go smoothly end-to-end. Several problems came up that would have taken me much longer to diagnose alone. I used Claude Code — Anthropic's terminal-based AI coding assistant — to work through them in real time.

Here are three moments where it made a real difference:

The tool call parser problem

OpenClaw was sending tool_choice: auto in every request — including requests where no tools were configured. This caused vLLM to require a working tool call parser. I had initially set --tool-call-parser gemma4 because I was running Gemma 4-31B. The container would start, then crash with a TypeError in the parser constructor.

From the Docker log output I shared, Claude Code identified the issue immediately: the gemma4 parser in the ROCm vLLM 0.19.1 image was broken. It scanned the available parsers, confirmed that hermes was the only valid one for this build, and explained that a Hermes-format model would be needed to use it. That meant abandoning Gemma entirely — Llama 3.2 was the next candidate.

The Llama processor incompatibility

I tried Llama 3.2-11B Vision-Instruct as the replacement. The vLLM container started but crashed immediately with an AttributeError — the transformers library bundled in the ROCm vLLM 0.19.1 image does not include the MllamaProcessor class that Llama 3.2 Vision requires, so the model cannot load at all.

Claude Code confirmed this was a hard compatibility mismatch, not a configuration error I could work around. It also surfaced a second barrier: the model is gated on HuggingFace and requires a Meta access request. With Llama ruled out, I turned to Anthropic Claude as a fallback.

The Anthropic authentication dead end

OpenClaw 2026.4.15 expects OAuth tokens in the format sk-ant-oat01-, which Anthropic blocks for third-party tools. My standard API key (format sk-ant-api03-) was rejected by OpenClaw's own validator before it even reached Anthropic.

From the error I described, Claude Code found the relevant OpenClaw GitHub issue and Anthropic's February 2026 Terms of Service update explaining why this path was closed. It then pointed me back to the open-source route via vLLM with a Hermes-compatible model — which is how I landed on Qwen3-30B-A3B and the hermes parser.

Claude Code is useful beyond writing code. In this deployment session it helped me diagnose errors faster than I would have alone — reading log output, surfacing relevant documentation, and pinpointing what was wrong and why.

---

What I Took Away

Getting OpenClaw running was more involved than I expected. Picking a compatible model, working through vLLM configuration, and sorting out the SSH tunnel took real time — and none of it was in the official documentation. That made it a useful exercise in its own right: the deployment itself taught me things about how OpenClaw structures its requests, how vLLM enforces tool call handling, and where the gaps are between what a project documents and what it actually requires.

Running this on AMD Developer Cloud rather than locally was the right call. The experiment stayed isolated from my daily environment, I had enough VRAM to work with larger models without compromises, and I could destroy the instance when I was done. That separation matters when you are still figuring out what a platform can do.

I now have a working OpenClaw setup I can spin back up from a snapshot. The next step is actually using it — putting the agent to work on the kinds of tasks it was designed for: multi-step research, tool-heavy workflows, model evaluation runs. That is what the deployment was for.