Operating OpenClaw reliably for a client: tokens, churn, and a stability fork

This is the operator's ledger from our managed AI agent deployment, built on the OpenClaw runtime and deployed for real customers. The first number is what the thing cost to run. The second is what it cost to keep safe and stable.

Our flagship deployment, a procurement research team running multi-hour document analysis sessions nearly every day, burned a few hundred dollars a month in tokens. The infrastructure underneath it was almost noise: compute, VPN, and search APIs together came to roughly a tenth of the token bill per agent. Tokens were the overwhelming majority of the cost.

That number was a choice, not luck. The workload was sustained reading, comparison, and structured summarization, and we routed it to a cost-efficient model rather than a frontier one. A frontier model would have cost several multiples more for capability the workload did not need. The scaffolding, persistent memory, skills, validated prompts, did the work that people usually try to buy from the model.

Two mechanics made that choice cheap to make and cheap to revisit. Per-agent model routing: each agent has its own model configuration, so one can move up to a stronger model without a fleet-wide cost decision. And per-agent API keys: each agent's spend is its own line item with its own rate limits, so COGS per agent is a number you read, not an allocation you argue about. If you remember one thing about agent unit economics, make it this: match the model to the workload, and instrument cost per agent from day one. The spread between a defensible COGS and an indefensible one is wider than any infrastructure decision you will make.

I have written before about the seven hidden costs of production AI. This deployment confirmed the thesis from the inside: inference was manageable and measurable. The cost that does not show up on the OpenRouter dashboard was the one that hurt.

OpenClaw was capable enough that the operating model felt safe to lean on: channels, tools, skills, cron, and sessions that would take a team a year to rebuild. The product surface was real, and that is exactly why I treated a fast-moving runtime as a customer substrate before we owned enough release governance of our own. It is built for velocity: releases are date-versioned feature trains, there are no patch releases for a given version, and semantic defaults move between releases without ceremony. For an operator with paying customers on the line, every routine version bump is a behavior change you have not discovered yet.

In one stretch of spring 2026, consecutive upstream releases gave us: a version that silently dropped messages ("Agent couldn't generate a response"), a version whose plugin-dependency rework crash-looped channel polling, and, the one that made it personal, a version that flipped a streaming default so that internal tool-call previews, file paths and shell commands included, streamed straight into a customer's chat. Nothing in our code changed. The ground moved. I wrote up the OpenClaw stability war stories separately because those incidents deserve their own ledger.

We kept a known-bad version table the way other teams keep a CVE list, and the worst week of the system's life, a multi-day spiral of grouped symptoms, an over-broad upgrade, and manual production rescue that left host state drifted from code, produced the lessons that reshaped how we operate. The discipline that came out of it:

Checklists tame individual upgrades. They do not change the underlying mismatch: an upstream optimized for shipping fast, consumed by an operation that needs the ground to hold still. So we built KissClaw, a production-stability downstream of OpenClaw. Not a feature fork, and not a rewrite: a governance layer over an upstream we continue to respect and track.

The mechanics are deliberately boring. KissClaw pins a vetted upstream baseline and re-versions it under SemVer, with a GA channel cut at most every two weeks from upstream releases that have aged at least ten days, and an LTS channel promoted quarterly. It stays a drop-in replacement, same binary name, same config location, same plugin SDK, so hosts swap one tarball for another. The branch model structurally prevents raw upstream from leaking into a release: governance and release workflows live on a permanently maintained patch branch, release branches cut from there, and CI verifies that every release artifact was built from a tagged release branch and not from the upstream mirror.

The most important policy is about restraint: backports are incident-driven only. A commit gets cherry-picked from upstream only when it addresses a tracked production incident, never because it "looks useful." We learned that one the hard way: an earlier attempt at curating upstream by cherry-picking recently-merged, useful-looking PRs produced 21 backports that addressed zero production incidents and shipped four broken references. When three or more incidents would be fixed by a newer baseline, the policy prefers advancing the whole baseline over growing an unbounded cherry-pick set.

And because cherry-picks onto an older baseline love to reference helpers that never came along for the ride, every backport is validated by a purpose-built tool, kc-check-imports: it simulates each cherry-pick in a disposable worktree against the real baseline and runs the TypeScript compiler's module resolution over the touched files, catching unresolved imports that no regex review would find. It runs per-candidate in CI (so failures attribute to a specific commit), over the accumulated final tree (so same-release backports that depend on each other get caught), and as a pre-commit check.

None of this is glamorous. That is the point. The fork's entire feature set is predictability, and predictability turned out to be the scarcest resource in the open-source agent ecosystem.

Building on a fast-moving open-source agent runtime taught us a hard lesson: it let us ship a working product to a real team faster, and the wins were real, but I would not make that bet again without release governance in place before the first customer depended on it. The build-versus-buy math for agent infrastructure has a third column most spreadsheets miss: the cost of consuming someone else's velocity. You will pay it as upgrade discipline, as canary infrastructure, as field notes from incidents, and past a certain stake, as a governance fork with its own release engineering.

Price all three columns. The tokens, it turns out, are the cheap part.