A 22-upvote r/openclaw thread about quitting OpenClaw after 3.5 months, 1,300 hours, nearly 5 billion tokens, and $700 isn’t really one complaint. It’s two: OpenClaw gets fragile as agents become longer and more stateful, and per-token pricing gets ugly fast when agent runtimes burn 8k-18k tokens before doing much useful work.
A post on r/openclaw hit 22 upvotes and 49 comments with a title that felt less like a bug report and more like a breakup letter: “THERE.... I gave up on OC.... It is too fragile for any real work...”
That title is dramatic. The numbers are worse.
The original poster wrote: “I have spent 3.5 month, 1300 hours, almost 5 billion tokens and 700 usd on it... it works okay for light and shorter tasks, but one will eventually be running in circles repairing same thing over and over and over again as the tasks grow.”
I’ve read enough agent threads to know when a complaint is just somebody having a bad weekend. This one wasn’t that. It opened a much more interesting argument: when people say OpenClaw is “fragile,” are they talking about OpenClaw itself, or are they really describing the cost and chaos of long-running agents?
The answer, after reading the thread and the surrounding discussions, is: both. And lumping them together is exactly why these debates get confusing.
The post says “fragile,” but the comments are describing two different failures
The first failure mode is operational.
OpenClaw seems to work best when the task is short, narrow, and easy to recover from. Once you add long context, multiple tools, MCP servers, memory files, and multi-step repair loops, the stories start sounding eerily similar: the agent gets lost, repeats itself, or starts “fixing” the same thing over and over.
That pattern shows up outside the main thread too. In another r/openclaw discussion, one user wrote: “My claw Henry has taken over my life... this job means messing with his config in ways that will certainly lead to failures and debugging and more failures and another week of a broken claw. So i found myself setting up a second cloud instance to not risk my main claw.”
That is not normal software confidence. That is someone treating an agent setup like a haunted house with backups.
And it gets more revealing. Another commenter in that orbit said they pay extra for daily backups on Hetzner because they’re scared of breaking a working setup. When users are afraid to touch config because success feels non-reproducible, that’s not just a UX issue. That’s fragility.
But then there’s the second failure mode, and honestly, it’s the one I think matters more.
Why are “small tasks” costing 8k to 18k tokens before the real work even starts?
This is the part too many agent discussions skip.
People talk about model pricing as if the only thing that matters is whether you picked Claude Opus 4.6, GPT-5.4 Codex, or a local model through Ollama. But in agent runtimes, the wrapper can be the tax.
In one related thread, a user said OpenClaw was sending nearly 18k tokens per input for small tasks. A commenter replied that “light context” is around 8k tokens and “normal context” around 12k. That’s before you even get to retries, tool outputs, repair loops, or the model deciding to think out loud for half a novella.
One Reddit reply explained why this happens: OpenClaw can consume context on workspace files, memory files, AGENTS.md, skills, and project notes before the first user message. That detail matters because it changes the economics completely.
A cheap model stops being cheap when you keep re-sending a giant backpack of context on every turn.
The hidden bill is not just inference
The hidden bill is:
- setup context n- memory and project files
- tool instructions
- agent-to-agent chatter
- retries after partial failures
- repair loops after the wrong file gets touched
That’s why people in these threads sound weirdly obsessed with token burn. They’re not whining about pricing in the abstract. They’re noticing that agent orchestration itself can become the expensive part.
And once you see that, the original “fragility” complaint starts looking less emotional and more mathematical.
Is OpenClaw actually broken, or are people just using the wrong models?
This is where the thread gets spicy.
Not everyone agreed with the original poster. One commenter basically said: use Opus. The implication was clear: if you’re throwing cheap models at hard, long-horizon tasks, don’t blame OpenClaw when the whole thing wobbles.
That argument has some truth to it. Better models usually recover better. Claude Opus 4.6 is more reliable than bargain-bin routing for complex coding and tool use. GPT-5.4 Codex can carry longer technical sessions better than weaker models that lose the thread after a few tool calls.
But I don’t think “just use a stronger model” is a satisfying answer.
Because the comments also show users doing something much more revealing: manual model routing.
In a separate “which model should I use?” discussion, users complained that Anthropic API usage is “way too expensive” for OpenClaw and asked what people were actually running instead. The answers were all over the map: GLM 5.1 on Ollama, Gemini 3 Flash Preview, GPT-5.4 Codex, and other mixed-provider setups.
One user said they spent about $120 over 3 months, roughly $40/month, using multiple specialized agents and built two apps that way. That’s the strongest counterexample in the whole conversation.
So yes, some people are getting real work done. But notice what they had to do to get there: split tasks, specialize agents, mix providers, and actively manage cost.
That’s not “OpenClaw solved it.” That’s the user becoming the routing layer.
The weirdest part? People are paying for safety, not speed
The most memorable thing in these threads isn’t even the money. It’s the behavior.
People are creating second instances. Paying for extra backups. Avoiding config changes. Hoarding working setups. Treating experimentation like a dangerous surgery.
That tells you something important: the pain isn’t just that OpenClaw can fail. It’s that when it fails, it can fail in ways that are expensive, time-consuming, and hard to unwind.
One commenter in this thread about orchestration put it perfectly: “It works well, but the token burn comment is right - you need to be deliberate about how you structure it... Really good but will burn tokens like crazy.”
That’s the most honest pro-OpenClaw take I saw.
It’s not “OpenClaw is amazing.” It’s “OpenClaw is powerful if you architect around its appetite.”
And that is a very different recommendation.
What are OpenClaw users actually choosing between?
If you strip away the drama, the Reddit threads show three real paths.
| Option | What Reddit users seem to experience |
|---|---|
| OpenClaw with frontier APIs | High capability with Claude Opus 4.6 or GPT-5.4-class models, but costs climb fast because context, tools, and retries add overhead |
| OpenClaw with local or Ollama models | Lower marginal cost and more experimentation freedom, but users report context-window limits, weaker performance, and more failures on complex tasks |
| Subscription-style coding plans like Codex or Claude plans discussed on Reddit | Predictable monthly spend is appealing, but users argue about quotas, weekly caps, and whether “unlimited” really means unlimited for agent workflows |
That last category came up a lot. One commenter referenced a “$100/month” Codex 5x plan, while another said they were already down to 39% weekly quota after 2 days on a 20x plan.
That’s why this whole debate matters beyond one angry post. People are not just arguing about OpenClaw. They are hunting for a sane economic model for agents.
If you insist on running OpenClaw, where should you look first?
The practical fixes in these threads are surprisingly unglamorous.
1. Verify your local model path before blaming the agent
If you’re using Ollama, check the obvious stuff first:
curl http://localhost:11434/
ollama list
If Ollama isn’t reachable or the model isn’t loaded, OpenClaw can look “broken” when the actual problem is just a dead local endpoint.
2. Save MCP credentials deliberately
One commenter said OpenClaw can lose track of MCP credentials unless the agent is explicitly told to save the MCP configuration as a skill. That sounds tiny until you’ve watched an agent forget how to access the thing it used five minutes ago.
3. Cut context before you upgrade models
Before swapping from Gemini 3 Flash Preview to Claude Opus 4.6, check what’s getting stuffed into the prompt:
- AGENTS.md
- memory files
- workspace files
- project notes
- accumulated skills
If your “small task” starts with 12k tokens of baggage, changing models may improve quality but not economics.
So who’s right?
The quitter or the defenders?
I think the quitter is more right.
Not because OpenClaw is useless. It clearly isn’t. People are shipping with it. Some users genuinely like it. For long coding sessions with careful structure, it can be very good.
But the thread’s core accusation — too fragile for real work — lands because “real work” is exactly where all the hidden costs show up at once. Longer sessions. More tools. More memory. More retries. More fear of breaking what already works. More money leaking into orchestration overhead.
The defenders are also right about one thing: model choice matters. If you run hard tasks on weak models, you will get garbage and blame the framework. That happens all the time.
But once a community starts normalizing second cloud instances, backup anxiety, 8k-18k token overhead, and manual provider-mixing just to keep the thing sane, I stop calling that user error. I start calling it a design constraint.
And that’s the real value of the 49-comment meltdown. It exposed something bigger than one person’s frustration.
OpenClaw’s problem is not simply that it breaks. It’s that agent runtimes make every mistake more expensive — in tokens, in time, and in confidence.
That’s why this thread hit a nerve.
Not because one person gave up.
Because a lot of people reading it recognized themselves.