OpenClaw turned out to be a costly autonomous agent: 81 million tokens and server conflicts

OpenClaw looks like a universal AI agent that can be quickly deployed on your own server and integrated into familiar workflows. But personal installation experience showed the opposite: the agent easily conflicts with neighboring services, is demanding on models and hardware, and token consumption quickly spirals out of control.

Monster on the Server

The author started with a typical scenario: took a working VDS where sites on React, PostgreSQL, n8n and several simple Telegram bots already lived, and deployed OpenClaw there. The first problem arose almost immediately after a Telegram token configuration error. Instead of a painless reinstallation, the system left behind "tails" in systemd, configurations, and the `.openclaw` folder. Old parameters continued to affect new runs, so the familiar approach of "deleted and reinstalled" simply didn't work.

It then became clear that OpenClaw doesn't feel good as a neighbor on an already occupied server. It requires free ports, a clean environment, and predictable configuration. Sorting out what exactly breaks the installation took hours of correspondence with other AI tools and about a million tokens just for diagnostics.

The main conclusion here is simple: deploying OpenClaw on a production server with already-running services is a bad idea. It needs a separate circuit, otherwise debugging quickly turns into manual cleanup and endless reinstalls.

Doesn't Like Orchestrators

The next step seemed logical: turn OpenClaw into one of the tools within an already configured setup with Docker, PostgreSQL, and n8n. The idea was clear — call the agent through webhooks, skills or scripts and integrate it into existing chains. But instead of a subordinate component, OpenClaw behaved like an autonomous system that doesn't want to follow someone else's rules and handles external control poorly.

Even when the request formally arrived, it didn't turn into a normal response for the scenario.

• MCP required a dynamic token that the orchestrator couldn't obtain
• Webhooks accepted requests but didn't pass them to the agent itself
• Direct Python script invocation launched the command but didn't return the result
• Creating your own skill ran into an authentication error

Instead of a flexible task executor, a self-contained "director" emerged that reluctantly integrates into external processes. The author calls it a ninja: the agent receives a task, disappears into the shadows and acts on its own. For solo work this might be a plus, but for integrations such autonomy quickly becomes a problem. If you need a quiet module inside a large orchestra, OpenClaw is more of a hindrance than a help.

In other words, the agent's strength turned out to be its main limitation.

"OpenClaw is not an assistant. It's a ninja."

Hardware and Tokens

Another unpleasant surprise emerged when connecting local models through Ollama. Light options like `phi3:mini`, `gemma2:2b` and `gemma3:4b` didn't fit because they don't support tools or function calling, without which the agent can't work properly.

Compatible models were found, but already at a different weight: `qwen2.5:7b`, `llama3.1:8b` and similar solutions require noticeably more resources. On a VDS with 32 GB RAM, responses took five to ten minutes each, and parallel execution of other services led to memory errors.

From this grew the second tier of costs. For stable local OpenClaw operation, according to the author's assessment, you need a separate server with a GPU like V100 or RTX 4090 and at least 12 GB of VRAM, which is already tens of thousands of rubles per month in rental. Trying to escape this problem via API didn't help either.

The 5 million tokens purchased from DeepSeek were consumed by the agent in one night with almost no useful tasks: it checked models, cycled through profiles, made mistakes and hit the API again. After switching to OpenRouter, three sessions over a few hours burned another 76 million tokens.

In total over three days, consumption reached approximately 81 million tokens, with a significant portion going not to text for the user, but to internal checks and repeated API calls.

What This Means

OpenClaw looks not like "another bot" but like a heavy autonomous layer between the model and real actions in browsers, messengers and other services. For enthusiasts this might be justified if you need an agent that works on its own.

But the promise of "deploy and forget" doesn't work here: without a dedicated environment, compatible models, monitoring and a clear budget, the project quickly shifts from the category of experiment to a permanent line item in expenses.