Operit2 spreads one agent across your phones, desktops and cloud boxes

What the project is trying to build

Operit2 is described as an open-source, cross-device Agent project for personal users, with the aim of letting phones, desktops and cloud devices each play to their strengths so that conversations, tasks and context can continue across a personal device space. The README is careful to say this is a preview release, and that during the preview stage the underlying structure, data formats, plugin contracts and cross-device workflows may still undergo breaking changes. The project's own framing of the experience is worth quoting as a goal rather than a feature, since the text says the complete experience is still being developed: start a task on a phone, let a suitable device continue executing it, view or approve it on a desktop, and finally return to the phone to receive the result. The primary conversation retains the interaction ownership of the originating device, subtasks advance on the execution node, and other devices learn about progress through asynchronous synchronisation.

CoreNode, Host, Space and Binding

Four concepts carry the architecture. Each instance running Core is a CoreNode, and it uses capabilities such as files, terminals and browsers through its local Host, which is the platform-specific part. Space organises the collaboration and the persistent synchronisation between nodes. Binding records which node continues the task next. The design decision that matters is that nodes in a Space have equal standing, so a Linux cloud device may handle more tasks because it is always online or has the right capabilities, but it does not thereby become a fixed primary node. Joining a Space also does not automatically grant a node the system permissions of other devices, which is the property that makes the model safe to reason about: a node can only do what its own Host, its permissions and the current user approval allow, and the README says explicitly that whether an operation can actually be executed depends on the target node's Host description, system permissions, installed services and current user approval.

Where the handoff happens, and what it does not carry

The handoff rule is specific and it is the part that makes cross-device work tractable. Task handoff is bounded by the point at which the tool result has been persisted and the next model request has not yet started, and after the target node obtains the required synchronisation records it continues the work. The continuation relies on saved context and task facts. It explicitly does not move an in-progress model request, a terminal process or a browser session, and those three exclusions are the ones to hold on to, because a browser session in particular is stateful in a way that a saved context summary is not. In other words, a task can be handed over at a quiet moment, but the live tools running at that moment cannot travel with it. That is a much smaller claim than continuous handoff, and it is the one the project actually makes.

Pairing and joining a Space from the CLI

The CLI already has the entry points for the multi-node side, covering pairing, discovery, connection, sessions, transport methods and Space member management. Nodes establish authenticated connections through Link Access, and PeerLink then carries Space requests and synchronisation traffic. The commands are shown as:

operit2 cli link serve --bind <address:port> --token <strong-token>
operit2 cli link discover
operit2 cli link connect <url> --token <token> --save <session-name>
operit2 cli link space join <session-name>
operit2 cli link space show

The README is explicit about two things. It says to use the actual output of operit2 --help and operit2 cli as the source of truth for command parameters, which is a good instruction for a preview tool, and it says not to listen on the public internet with the default development token, and not to put tokens, private keys or real business data into public logs or screenshots. The described use is experimentation on a local or controlled LAN, which is a narrower claim than production multi-device deployment and should be read as the intended scope today.

What a single node can already do

Each CoreNode can run its own agent workflow independently, and its capabilities depend on the platform Host, the model Provider and the local configuration. The repository already includes conversations, session branches, message management, attachments, character cards, character groups and prompt configuration; provider configuration, model parameters, tool calls, request queues and local model directories; workspaces, file operations, project templates, commands and backup, import and export; terminal sessions with PTY input and output streams; web access, browser automation, workspace browsers and runtime WebView session projections; and memory, summarization, speech recognition and speech synthesis among the built-in tools. The catalogue is wide enough that the interesting question is not what a node can do but what it is allowed to do, and the answer is bounded by the Host description, system permissions, installed services and the current user approval.

Plugins, Skills, ToolPkg and MCP

The extension surface is described as having been gradually abstracted from a built-in tool collection into manageable runtimes and SDKs. You write Packages and ToolPkgs in JavaScript or TypeScript, and build tools and user interfaces with the JavaScript bridge, a Wasm runtime and a Compose DSL. Skills provide importable workflows and knowledge resources with controllable visibility. There is MCP support for connecting to servers and managing configurations, tools and local processes, and a plugin marketplace with package manager commands to install, enable, disable, inspect and execute extensions. The Rust SDK, the TypeScript declarations and the codegen are the plugin development entry points, and the README says these interfaces are still evolving. The stated direction is that runtime, Host capabilities, permissions, compatibility versions and state-scope declarations will be refined so that extensions can run or continue on compatible nodes, while for now you should validate plugins and their dependencies on the target platform, because cross-device portability remains a major development focus.

Backup, migration and the web front end

Operit2 treats migration as part of personal-device continuity, and the CLI has entry points for identity, storage paths, snapshot export and restore, backup inspection and Operit v1 snapshot inspection:

operit2 cli identity list
operit2 cli storage paths
operit2 cli export snapshot <snapshot.zip>
operit2 cli backup inspect <snapshot.zip>
operit2 cli backup restore <snapshot.zip>

That is a differentiator worth noting, because moving from the earlier Operit to Operit2 is explicitly part of what the tool supports rather than something users have to work around. Web Access is the other half, and it comes with a caveat that is easy to skim past: it lets a browser access a running CoreNode, but opening the page does not automatically make the browser an independent node in the Space. The browser Host and the WebAssembly runtime are separate engineering paths with their own capabilities and deployment methods, and the README says to consider them separately. The dedicated Deploy Web Experience GitHub Actions workflow builds the Flutter Web front end and publishes it to gh-pages.

Where Operit2 is the wrong choice

Three cases. The first is anything that needs a stable interface now, because the preview notice says the structure, data formats, plugin contracts and cross-device workflows may still change in breaking ways, and a tool whose whole point is synchronising state across your devices is a bad place to be reshaped under you. The second is a team that wants a single-device agent with a good tool set, because the single-node capabilities are already broad and the multi-node machinery is the part still under development, so the complexity buys you nothing yet. The third is a security-sensitive environment, because a system that hands a task to whichever device can run it, with live terminals and browser sessions on the other side, is a large surface, and the README's own warnings about tokens and the fact that joining a Space does not grant system permissions suggest the boundaries are still settling. Against a single-device agent runtime, the difference in approach is that Operit2 treats a task as a portable unit of work with a persisted result and a handoff point, rather than as a session bound to one process, and the cost is that the state has to be serialisable, which constrains what a task can be.

Editorial conclusion

Operit2 is a good fit for someone who starts a task on a phone, wants a machine that is always online to finish it, and wants the result back on the phone, which is the workflow the README describes as the goal rather than a completed feature. It is a poor fit for anything that needs a stable interface today, because the preview stage allows breaking changes to the data structures, plugin contracts and cross-device workflows. Check three things before you commit: that you are prepared for the interface to move, since the project states this plainly in the preview notice, that you understand what joining a Space does not grant, because nodes in a Space have equal standing and joining does not automatically give a node the system permissions of other devices, and that you follow the CLI's own advice about tokens, because the README says not to listen on the public internet with the default development token and not to put tokens or private keys into public logs or screenshots.

Frequently asked questions

Official sources

1. AAswordman/Operit2 on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases