OpenClaw 2.0 is not a model release. It is the milestone name for OpenClaw v2026.8.1, which shipped on August 30, 2026, and it converts a mostly single-player agent runtime into a shared, persistent operating layer. The release ledger for the update lists 16,977 pull requests, 698 direct commits, and 987 contributors.
I ran the upgrade on a staging box before touching anything production-facing, and the split is clear: the collaboration and UI work is worth having, the SQLite migration is the part that will bite you if you skip backups.
What OpenClaw is, and what it is not
A model API takes input, returns output, and forgets. OpenClaw wraps that exchange in the persistent layer: conversations, tools, files, browser control, messaging channels, scheduled tasks, memory, Skills, and permissions.
That makes it agent infrastructure rather than a foundation model. MMLU, GPQA, and SWE-bench numbers do not tell you anything about "OpenClaw intelligence." The platform metrics that matter are startup behavior, session durability, tool reliability, recovery, and how much context survives when people and conversations change.
It stays model-agnostic, MIT-licensed, Node.js-based, and runs on macOS, Linux, and Windows desktops. Check the Node installation requirements before an upgrade, since supported minimums can move after a milestone like this.
Spec sheet
| Item | OpenClaw 2.0 |
|---|---|
| Version | v2026.8.1 |
| Release date | August 30, 2026 |
| Type | Self-hosted AI-agent runtime and gateway |
| License | MIT |
| Model architecture | Model-agnostic |
| Runtime | Node.js |
| Desktops | macOS, Linux, Windows |
| Session/transcript storage | SQLite |
| Web interface | Conversation-first Control UI |
| Collaboration | Shared multiplayer sessions |
| Memory | Cross-conversation recall for eligible personal agents |
| Skills | Skills, Skill Workshop, proposals, checks, history |
| Automation | Unified Automations and Scheduling |
| Security | Request-, session-, and person-bound approvals |
1.x versus 2.0
| Dimension | 1.x | 2.0 | Result |
|---|---|---|---|
| Primary usage | Mainly personal | Personal and multiplayer | Live collaboration and handoff |
| Onboarding | Configuration-first | Existing-access discovery | Faster first conversation |
| Web UI | Control-panel oriented | Conversation-first | Less navigation friction |
| Session storage | File-backed | SQLite-backed | Durable structured state |
| Collaboration | Limited handoff | Shared sessions | Context survives handoff |
| Memory | More fragmented | Cross-conversation recall | Better continuity |
| Skills | Separate mechanisms | Connected management loop | Easier authoring and governance |
| Automation | Cron-oriented concepts | Unified Automations | Clearer scheduling model |
| Browser access | Existing automation | Managed profile and shared tabs | Better scope control |
| Approvals | Less tightly scoped | Bound to request and session | Lower approval-reuse risk |
| Updates | More fragile recovery | Staged checks and recovery | Safer upgrades |
Read that as one coordinated move from "configure a personal agent" to "operate persistent agent work with other people." SQLite, memory, Skills, and tighter approvals all push the same direction.
Multiplayer sessions are the headline
Shared cloud sessions let authorized collaborators join live work with the context intact. A teammate can step into execution while the agent still holds its files, task history, and state, instead of waiting for someone to forward a finished answer.
That is what makes handoffs, specialist review, paired operations, and long-running jobs workable. It is not hostile-tenant isolation. If you are serving unrelated or mutually untrusted users, separate them at the deployment level.
The new Control UI, and the one benchmark worth quoting
The rebuilt browser app centers everything on the active conversation. Files, approvals, settings, terminals, and live activity sit next to the session instead of being scattered across admin screens, and sessions can be grouped by project, person, or custom category.
Because the runtime is model-agnostic, the credible performance number measures the UI, not reasoning. In the official simulated default-chat startup test (mocked Gateway, 50 ms HTTP/1.1 latency):
| Startup test | Before | 2.0 | Calculated |
|---|---|---|---|
| JavaScript requests | 140 | 45 | 67.9% fewer |
| Startup time | ~1,600 ms | 575 ms | 64.1% lower |
| Relative speed | 1.0x | ~2.78x | ~2.8x faster |
That describes Control UI startup only. Model latency, network calls, tool execution, browser actions, and long jobs remain their own bottlenecks.
SQLite is where upgrades go wrong
Sessions and transcripts now live in SQLite, which gives you structured state for lookup, collaboration, history, recovery, and cross-conversation work. It is also the main upgrade risk: rolling back the package does not reverse the storage migration, and sessions created after migration will not show up in an older file-backed release.
openclaw backup create --output ~/Backups/openclaw --verify
That archive should include state, configuration, credentials, agent directories, sessions, and workspaces, and the --verify flag checks the result. Review the SQLite downgrade procedure before you consider going back.
Onboarding, memory, and Skills
Guided setup now discovers supported subscriptions, API keys, and local models already on the machine, verifies whichever model you pick before saving it, then hands off to the browser app or terminal. Reaching a working conversation before optional configuration is a better default, and it is easier to debug when something fails.
Eligible personal Claws can recall relevant context from that same agent's other private conversations, and memory search, inspection, import, and removal are more visible in the UI. Shared sessions do not automatically share memory.
Skills existed before 2.0. What changed is the lifecycle around them. Skill Workshop connects creation, validation, discovery, installation, invocation, proposals, checks, decisions, and revision history into one loop: execute, observe, propose, review, reuse. Far better than stuffing every lesson into a giant system prompt.
Automations, browser, and computer use
Scheduled work is now unified under Automations and Scheduling across the agent, Control UI, CLI, docs, and native apps. Browser access can run through an isolated managed profile or use exact signed-in Chrome tabs that you select.
| Computer-use area | Status |
|---|---|
| Managed Chromium browser | Supported |
| Selected signed-in Chrome tabs | Supported |
| macOS computer control | Supported |
| Windows computer control | Supported when explicitly enabled |
| Linux computer control | Experimental |
| View-only sessions that block input | Supported |
The real improvement is not that the runtime clicks more things. Browser identity, device identity, approvals, and permissions are increasingly bound to the intended session and machine.
Approvals got session-aware
An agent that executes commands, touches files, drives a browser, and calls external services needs tighter boundaries than a chatbot. In 2.0, approvals stay request-bound, and protected credentials can reach supported destinations without turning into ordinary model-visible text.
The principle: permission travels with the task rather than becoming a reusable blanket approval. Per-session policies can also narrow one conversation's authority relative to the rest of the installation. Collaboration controls still are not hostile-tenant isolation, so multi-tenant businesses need isolation at the deployment layer.
Upgrade runbook
Supported update paths inspect the installation before replacing it, and --dry-run previews planned actions without installing or restarting anything.
openclaw backup create --output ~/Backups/openclaw --verify
openclaw update --dry-run
openclaw update
openclaw doctor
openclaw health
On production, exercise the same plugins, channels, browser permissions, automations, and recovery checks you rely on daily. A clean package install proves nothing about whether your persistent workflows survived the migration.
Should you pull the trigger?
| Your situation | Call | Why |
|---|---|---|
| New user | Take current stable | Best onboarding and UI baseline |
| Existing personal user | Generally yes | UI, memory, state management |
| Team testing shared agents | Strong yes | Multiplayer is the defining feature |
| Heavy automation user | Yes, after testing | Persistence improves, migration matters |
| Production deployment | Stage first | SQLite and permission changes need validation |
| Heavily customized install | Test in parallel | Plugins and integrations may need work |
| Need easy rollback | Back up carefully | Post-migration sessions need deliberate downgrade handling |
The model layer stays yours
Version 2.0 keeps session, memory, tools, and permissions stable while you swap the model attached to a conversation, an agent, or the shared default. If you route across several providers, a unified gateway such as CometAPI means one config change instead of replumbing the workflow, so reasoning-heavy work can hit something like GPT-5.6 Sol while routine monitoring and summaries run on a cheaper model.
Verdict
OpenClaw 2.0 is a maturity shift, not a model upgrade. The operating layer around the model became persistent, collaborative, legible, and governed.
New users should start on current stable. Existing users should take a verified backup, test the integrations that matter, then upgrade. Teams get the most value from multiplayer sessions, SQLite-backed state, better memory, and request-specific approvals.
Quick answers
Is it a new AI model? No. It is an agent runtime and orchestration environment. The connected model supplies the language, reasoning, and coding capability.
What version is it? The milestone name for v2026.8.1. Later releases build on it, so evaluate current stable for new deployments.
Most important feature? Shared multiplayer sessions. Individually, the rebuilt Control UI and simpler onboarding are the visible wins.
Is it free? The source is MIT-licensed. Model API usage, infrastructure, storage, and external services still cost money.
Does it make models faster? No. The published numbers cover Control UI startup under a specific simulated test.
Can I roll back? Yes, but restore the archived legacy conversation records with the current CLI before returning to a file-backed release. Sessions created after the SQLite migration will not appear there.
Originally published at cometapi.com
Top comments (0)