A practical upgrade guide for people running OpenClaw in production, written by people running OpenClaw in production.
If you run OpenClaw for anything that matters, September 2026 handed you a decision. The June LTS line reached its final release, the 9.x line is moving fast enough that two releases can land in a week, and the two lines are pulling in different directions: one toward stability, the other toward sub-agent orchestration and cloud sessions.
This guide covers how to think about that choice, what actually changed, and the upgrade mistake that will cost you an afternoon if nobody warns you. We have made that mistake, which is why it is in here.
OpenClaw ships on calendar versioning: year.month.patch. There is no semantic version, and despite press coverage referring to a "2.0," no release is tagged 2.0. If you go looking for it in the release list you will not find it, and you will waste ten minutes wondering whether you are on the wrong repository.
What exists instead, as of this writing:
| Version | Date | What it is |
|---|---|---|
| 2026.9.4 | September 11, 2026 | Current |
| 2026.6.35 | September 10, 2026 | Final June 2026 LTS release |
| 2026.9.3 | September 8, 2026 | Team activity reports, folding-device layouts |
| 2026.9.2 | September 5, 2026 | GPT-6 Astra, Swarm sub-agent orchestration |
| 2026.9.1 | September 3, 2026 | Mermaid in chat, faster first run |
Note the two lines running in parallel, and note the word final next to the LTS. That is the decision.
Stay on the LTS line if OpenClaw sits in front of something you get paged about, your configuration is stable, and you would rather spend your attention elsewhere. The final June LTS release is not a dead end so much as a deadline: it tightened provider and channel boundaries so that bundled adapters bound untrusted response bodies and reject oversized inputs, which is exactly the kind of change you want on a long-term line. But "final" means the clock is running, and planning the move now beats planning it under pressure.
Move to the current line if any of these are true:
The honest version: most teams reading this should be on the current line, because the features that landed are not cosmetic. The LTS exists for people who have a genuine reason to hold still, not as a default for the cautious.
Release notes are organised by release. Decisions are not. Here is the same material grouped by the question you are actually asking.
Swarm sub-agent orchestration, on by default. Your agent can now delegate rather than doing everything in one context. This is genuinely a different operating model, and the important consequence is not performance, it is that your existing rules were written for a single agent. Instructions that say "do X then Y" assume one actor. Revisit them.
Terminal question controls. Agents can ask you something mid-execution and get an answer back, rather than guessing or stopping. This quietly removes a whole class of "the agent assumed wrong and carried on" failures.
Persistent skill collections via the Workshop. Procedures belong in skills, loaded on demand, not in an ever-growing instructions file. The tooling now agrees with that advice.
Safer updates with candidate rehearsal. The updater tries the new version before committing to it. Given how fast this project moves, this matters more than it sounds.
Verified SQLite backup and fresh-target restore commands. Backups you have not restored are not backups. There is now a supported path to restore onto a clean target, which is the only restore worth trusting.
Centralised provider account management. Provider credentials in one place rather than scattered.
Performance work that preserves prompt caches. Cache-aware behaviour is a direct cost line, not a nicety, particularly with providers cutting cache read pricing.
Home opens in a docked panel beside your work with Cmd/Ctrl+Shift+H. There is a Linux desktop app with Gateway connection and Quick Chat. New Session can start background sessions without leaving the dialog. Mermaid blocks render as diagrams in chat. Conversations can be shared by public link, and 2026.9.3 added team activity reports.
One behavioural change worth reading twice: unsandboxed sessions now work with other sessions of the same agent by default. If you relied on sessions being isolated from each other, verify that assumption still holds.
Here is the one we learned the hard way.
We had a gateway host that had been left alone while the fleet was paused. When we brought it back, we started the service first and investigated afterwards. The host was dozens of commits behind, running a stale build, and everything downstream of that was noise: agents behaving oddly, features missing that the docs said existed, configuration that looked correct doing nothing.
The order matters, and it is not the obvious one:
Starting the gateway on a stale build wastes the entire debugging session, because every symptom you investigate is downstream of the build and none of them point at it. On a project shipping multiple releases a week, "I pulled last month" is far enough behind to matter.
A related trap: if you use a process supervisor with a watchdog, disable the watchdog first when taking things down. Otherwise it helpfully restarts what you just stopped and you conclude the shutdown does not work.
Upgrades on a fast-moving project fail quietly more often than they fail loudly. Three checks catch most of it.
Did your instruction files load completely? OpenClaw truncates long injected workspace files, and it does so silently. We ran for weeks with an agent seeing roughly half its own rulebook while every functional test passed, because the tests exercised routing rather than prompt assembly. Query the system prompt report and confirm the truncated-file count is zero. Do not infer this from behaviour.
Did your model configuration survive? Model identifiers move. A config naming a model that no longer resolves may fail in a way that looks like a different problem entirely.
Do your rules still make sense with sub-agents on? See above. This is the assumption most likely to be silently wrong after 2026.9.2.
Running agents in production and want a second opinion on the setup? Get in touch.
This article is a live example of the AI-enabled content workflow we build for clients.
| Stage | Who | What |
|---|---|---|
| Direction | Tom Hundley | Set the angle: an upgrade decision guide, not a release digest |
| Research | Claude Opus 5 | Release tags and notes read from the project's own releases, in preference to secondary coverage |
| Drafting | Claude Opus 5 | Written on the Claude subscription in an interactive session, not through a billed pipeline |
| Fact-Check | Human + AI | Version numbers and dates taken from the release list; operational advice drawn from our own deployment and labelled as such |
| Editorial | Tom Hundley | Final review for accuracy, tone, and value |
A sourcing note. Secondary coverage of this release train describes an "OpenClaw 2.0" and attributes a set of changes to it. The project's own release list has no such tag and distributes those changes differently across versions. Where the two disagree, this article follows the tags, and we corrected an earlier article of ours that had followed the coverage instead.
Want to build this capability for your team? Let's talk about AI enablement →
Discover more content:
