Conductor is joining Meta. Its cloud workspaces become read-only on 13 November and shut down on 20 November, and the Mac app stops getting new models and fixes in early 2027. If your work runs through it, here is what cherry π does with the same loop, what carries over unchanged and what isn't here yet.
The loop Conductor made standard is a good one: a task gets its own copy of the repository and its own branch, an agent works there, you read the diff, send it back with comments, run the app, and merge what you want. cherry π keeps that loop. It calls one task a goal.
Bring your setup and run scripts
Conductor keeps a repository's scripts in the repository, in .conductor/settings.toml (or the older conductor.json). The Conductor addon reads them and sets the same commands on your layer:
picache addons enable conductor
picache conductor # what it found, and what it would set
picache conductor import # set this layer's setup and run commandsYour scripts run unchanged. Each goal gets ten ports of its own, as each Conductor workspace did, and its commands see CONDUCTOR_PORT, CONDUCTOR_ROOT_PATH, CONDUCTOR_WORKSPACE_PATH and CONDUCTOR_WORKSPACE_NAME beside cherry π's own CHERRYPI_ names for the same values. A run action other than the default, the archive script and run_mode have no equivalent yet, and picache conductor lists each one it leaves out.
The same loop, side by side
| In Conductor | In cherry π |
|---|---|
| A workspace: a git worktree on its own branch | A goal: a copy-on-write copy or a worktree, on cherrypi/goal-… |
| Setup and run scripts, a port block per workspace | The layer's setup and run commands, ten ports per goal, Run in a pane |
| Several agents in parallel | One goal to several agents with @a,@b; accepting one offers to reject the rest |
| Diff viewer with comments | The goal's diff with line comments; Request changes sends them |
| The Review action | Picache reviews every goal, read-only, before you decide |
| Checks tab and todos | Ready?: tests, review, open comments, todos, conflicts, and a pull request's checks and review |
| Checkpoints | A snapshot at every step, and every turn kept |
| Merge, or open a pull request | Accept to merge here, Push… to any remote with git request-pull, Open pull request… on GitHub, GitLab or Forgejo, or Offer… to a paired machine |
Pull requests on GitHub, GitLab or Forgejo
If your team merges through pull requests, a goal can open one. Turn on your host's addon and keep a token for it in Keys:
picache addons enable github # or gitlab, or forgejoPush the goal's branch, then press Open pull request… on its card, or run picache goal pr <run>. It asks for the base branch and whether to open it as a draft, and the description says what the goal was, which agent worked it, how its last test went, and Picache's review. From then on the card follows it: its checks, its review, and why the host won't merge it when it won't. It checks every 15 minutes, or as often as you choose, and Refresh checks now. Failing checks can hold Accept if you want them to.
cherry π makes those calls itself, only to your host's API. The token stays in Keys, and no agent ever sees it. Only you open a pull request.
Isolation that is a boundary
Conductor's own documentation says it plainly: "Workspace isolation is development isolation, not a security boundary," and agents "run on your Mac with your user permissions." That is honest, and it is the main thing cherry π does differently.
A goal's agent runs inside the agent box: Seatbelt on macOS, bubblewrap on Linux. Its own tools are narrowed to reading, so every change it makes goes through cherry π, into its copy and nowhere else, with the copy's .git read-only. Each command it wants to run is a request you approve, unless you allowed that exact command for that goal. The agent can't merge, push or accept its own work. Those are yours.
No host, no account, no cloud
cherry π is one file you download and run. There is no account and no service between you and your work. A goal's branch can go to any git remote you already push to, or straight to another of your machines, peer to peer, with no git host in between. It runs on macOS and Linux.
What isn't here yet
If you depend on any of these, it's better to know before you switch:
- Review threads back to the agent, and merging in the app. A goal opens its pull request on GitHub, GitLab or Forgejo, and its card follows the checks and the review, but review threads aren't sent back to the agent yet, and merging happens on the host. Those come next, in the same addons.
- More agents on goals. Claude Code and OpenCode take goals, through the Agent Client Protocol; OpenCode is measured in the box on macOS, not yet on Linux. Codex, Cursor and others run in terminal panes, each in its own box, but not as goal agents yet.
- Starting from an issue. No GitHub or Linear issue to goal yet; an Inbox thread can become a goal.
- Your Conductor worktrees as goals. The addon carries scripts, not work in progress. Commit or push what a workspace holds; a goal starts from your layer as it is.
- Windows, a phone app and team seats. None of these exist.
Start with one goal
Download cherry π, open your repository as a layer, import its scripts, and give an agent one task you would have given it in Conductor:
picache conductor import
picache goal @claude "make the login tests pass" --steps 8Then read its diff, comment, press Run to try it on its own port, and accept it, open a pull request for it, or let it go.
See goals in the manual, What if… for the box, and Download.