Welcome to cherry π. We're building a workspace for people who like choosing their own tools, running their own machines and having a say in what their software does.
Think of it as a Swiss Army knife for sovereign computing. cherry π brings a terminal multiplexer, a graphical browser desktop, an app platform and agent harnesses into one environment. It runs from a single binary, with P2P connections between machines that hold their own work.
For us, sovereign computing starts with practical choices: where your projects live, which model you use, who you share with and what an agent is allowed to change. Those choices belong with the person doing the work.
You can work in the terminal TUI or open the Web GUI. You might want a keyboard-driven pane layout for coding, then a canvas of terminals, apps and notes in the browser. Both are ways into cherry π, with their own arrangements.
Bring your tools
You probably have an editor you like and a shell full of habits. Bring them. Open cherry π in Ghostty or your preferred terminal, run Neovim in a pane and put lazygit beside it. If you use tmux or Zellij, you'll recognize the idea of a workspace made of running terminal programs.
cherry π has its own editors, too: a built-in editor pane in the TUI and editor.pi in the Web GUI. You can use those or bring your favorite editor into the workspace.
Projects get their own layers. Your API can have its code, tests and agent conversation in one layer while the website has another. Switch projects and leave the terminals running. Picache, our workspace agent, is there when you want help with the workspace.
The terminal side is a multiplexer you can shape as you work. Split panes, zoom into one, move between project layers or script an arrangement with Lua. The workspace gives your tools somewhere to run together, including tools that were never designed with an agent in mind.
The TUI also has floating windows. Lift a pane out of the tiled layout, drag its title to move it and resize it by its edges. You can stack floats in a cascade, make one translucent or dock it back into a tile or tab. Keep a monitor floating over your editor, or pull a tool forward while you need it and put it back afterward.
Buried floats still give you useful signals: an agent's badge stays visible, and a terminal title shows its last line of output. The terminal desk can be arranged with windows as well as splits.
A desktop in your browser
Cherrytop is cherry π's graphical side. Open it in a browser and you get windows over an infinite canvas. A window can hold a shell, the TUI, a running workspace terminal, an app or a conversation with Picache. The canvas underneath gives you room for widgets, frames and named spaces that you can pan and zoom between.
This gives a project a different kind of working view. Keep an app open beside its terminal, leave a conversation in another window or zoom out to find something on the canvas. Cherrytop has its own window arrangement; it doesn't have to reproduce your TUI's panes.
With local names installed, the workspace is available at https://cherry.pi, and served apps can have names such as https://my-app.pi. These are names for services on your machine. Sakura supplies the session protocol behind browser terminal attachments, including the state and streams needed to attach to a running session.
Work should outlast the window
Closing a client shouldn't mean throwing away the workspace. cherry π keeps conversations and run records in SQLite, and terminal processes run separately from the desktop client. You can quit the client and reconnect to those terminals when you return. Surviving a machine reboot is a different promise, and terminal reboot recovery remains unfinished.
Agent work needs more than a surviving terminal. For changing operations governed by cherry π, intent is recorded before execution and the result afterward. If a connection drops at the wrong moment, a missing result can leave the outcome uncertain. Recovery gives you a place to settle that outcome before another attempt repeats a change.
That's why durability gets its own place in the architecture. A conversation, a process and an external effect each need different handling when something stops. Keeping records makes it possible to investigate what happened without assuming that everything failed or blindly replaying it.
Room for more than one harness
We expect people to use different agents for different work. Claude Code and Codex have their own harnesses. Picache has native agent machinery. cherry π provides the workspace around them.
Our view is that harnesses compose. An agent can keep its own loop and tools while the workspace sets boundaries around the work. cherry π can confine a vendor agent's access to files and the network, and checks and records calls made through cherry π. That doesn't give it oversight of every step inside the vendor's loop.
You should also get to decide what comes back. A goal gives an agent a separate project copy to work in. Tests and Picache's review help you inspect the result before accepting it. If an interrupted write has an unknown outcome, Recovery holds it for you to settle before continuing.
Agents can talk to each other
Putting several agents in panes is only part of the arrangement. They can send each other questions, answers and handoffs through cherry π. A handoff can point to a branch, commit, path or goal for the next agent to pick up. Messages are addressed to a particular agent pane and handed over through that agent's hooks.
Picache participates in that work alongside the vendor agents. It can use the workspace tools to arrange panes and work with the Inbox. An agent that opens another agent's pane receives notices when that agent finishes a turn, needs your permission or exits. Message budgets put a bound on agents sending back and forth.
The same workspace has ways to reach beyond the current layer. An ask puts a question to another layer's agent in a separate, read-only thread. It cannot see either layer's chat; its answer comes back labelled with its source. For a change, an agent or Picache can offer a patch or file to the other layer's Inbox. The receiving operator decides whether to accept it.
Conduit carries these interactions between layers, linked workspaces and paired machines, with the same offer lifecycle, receipts and authorization. A task accepted at the destination can run there and return a report. Cross-layer work goes through those boundaries rather than writing directly into another project's files.
Build tools that belong in the workspace
A .pi app packages code, assets and its own data in one SQLite file. It can bring a tool into the workspace as a pane program, a web page or another supported contribution. Its access comes from explicit capabilities granted by the host. That makes the app platform useful for small tools specific to your work, as well as larger pieces of the environment.
The software factory gives those tools a build-and-review flow. Start with a schematic and an order: what you want made, the starting skeleton, and the capabilities it may need. A builder agent works in a product layer. Public checks help it while it builds; hidden scenarios stay with the workspace harness and test the candidate separately.
You can Try a candidate on its own data before installing it. Acceptance requires a current passing result, and packing reruns the checks before producing a signed app with its evidence. You still make the acceptance decision.
Your other machine belongs here
P2P is part of the foundation. Each installation has its own identity; you pair machines and choose what to share. Pairing alone grants no access. A share can cover a workspace, a layer or a terminal, and you can revoke it.
Peer connections may pass through relays. The machines still hold the work and make their own access decisions. Offers and replies have an outbox, inbox and receipts so they remain tracked beyond the connection that carried them.
You can also export a project layer as a signed file containing its folder and history, then import it elsewhere. Permissions stay behind for the receiving workspace to decide. Live layers are the ongoing collaboration path: sharing project changes and completed turns while people keep their own tools and layouts. Their complete trial across two physical machines is still in progress.
We're also developing ways to move through these connected environments more spatially: terminal worlds in Cellar Door and infinite-canvas worlds in Cherrytop. These navigation experiments extend the question of how you find and enter work across machines. They're experimental, alongside the concrete pairing and sharing controls available today.
Come try it with us
We're opening cherry π to early testing. It's an engineering prototype: the local workspace, layer exports, pairing and scoped shares work, while live layers between two physical machines are still being tried.
If this sounds like a place for your tools, join early access. We'd like you to try it with your projects and tell us where it gets in your way. The manual has the details when you're ready to dig in.