Conductor shutting down means saving your cloud work now and planning a separate transition for local work. Conductor has announced its move to Meta and a phased wind-down. Cloud closes first; existing local installations have more time.
What are the key dates?
The official announcement sets out this timeline:
| Date | Change | What to prepare |
|---|---|---|
| November 4, 2026 | New sign-ups, downloads, and Pro upgrades closed. | Check your existing installation before planning local transfers. |
| November 13, 2026 | Cloud becomes read-only; old chats and exports remain accessible. | Finish active cloud work and save handoff notes. |
| November 20, 2026 | Cloud shuts down and deletion of cloud user data begins. | Complete transfers and exports before this date. |
| Early 2027 | Local model updates and critical fixes run until then; local wind-down begins. | Test a replacement while you can check the original workflow. |
The announcement gives no exact local cutoff day. Treat that broad window as time to prepare, rather than a deadline to wait for.
Start with projects that have unfinished cloud changes. Leave tool comparisons until you have saved the work you would otherwise need to recover.
How do you save Conductor workspaces?
Conductor documents two options in its export instructions. Right-click a cloud workspace and choose Transfer to local to move it and its chats to your Mac. For an archive of all Conductor data, use Settings → Account → Export data.
Use both options where they fit your needs. Then check the saved material before you depend on it.
For each active task, prepare a short handoff:
- Record the repository, branch, and related issue or pull request.
- Save unfinished changes and list files that still need review.
- Write down what the agent attempted and what remains unresolved.
- Keep reproduction steps, test commands, and the latest useful test result.
- Note any setup steps needed to run the project again.
Make the handoff understandable without reopening the old chat. A long transcript can help, but a clear next action is easier to resume.
Check one transferred workspace from start to finish. Open its files, inspect its branch, and compare the pending diff with your notes. Run the project's usual checks if the saved state allows it. Keep a separate backup before changing or cleaning up the original workspace.
Do this before read-only mode where possible. Use the remaining export window for verification and anything you missed, rather than starting the whole move then.
What happens to local workspaces?
Local work needs its own backup plan. Conductor's Git worktree documentation explains that each workspace has separate files and a branch. Those worktrees share the underlying repository's Git data.
Review each workspace separately before deciding that the repository is fully saved. Look for uncommitted edits, untracked files, and notes outside tracked code. Conductor documents a gitignored .context folder for workspace notes and handoffs.
A clean main checkout is only one item to inspect. Compare your active workspace list with the branches and pull requests you intend to keep. Mark each task as finished, ready for review, or still in progress.
Keep setup details with the handoff. The worktree docs explain that Git does not automatically include untracked or ignored files in a new worktree. Check local configuration, generated files, and any project-specific setup you need. Store secrets through your normal secure process rather than copying them into task notes.
For unfinished work, write an acceptance check before moving tools. Describe the expected behavior, the current failure, and how you will recognize a successful fix. That gives the next agent a bounded task instead of an instruction to reconstruct the whole conversation.
Keep the original saved state until you have reviewed the replacement checkout. Avoid combining a tool migration with unrelated branch cleanup.
How should you choose a Conductor alternative?
Choose around the work you need to continue. Conductor's introduction documents parallel Claude Code, Codex, Cursor, and OpenCode workflows. Start by checking your required agent, operating system, and execution location.
Make a short list of requirements before installing another app. Include branch isolation, diff review, terminal access, approvals, and the way you resume unfinished tasks. If hosted execution matters, make that an explicit requirement. Test what happens when your own computer is asleep.
Use one small, real task to evaluate each candidate. Give it the same saved brief and acceptance check. Review the resulting diff, run checks, and confirm that you can find the task again. Repeat with another project only after that path works.
The comparison pages and Conductor alternative page can help organize that review. Windows users can also read the Windows migration guide and Aiola for Windows.
Aiola is one option for building, running, and supporting products. It runs supported coding CLIs on macOS and Windows using your own provider subscriptions, without token markup. Claude Code, Codex, Cursor, and OpenCode are supported, alongside Grok CLI and Antigravity.
It also puts production errors, user feedback, analytics, GitHub records, and tasks beside the agents. App Logs, Feedback, and Analytics are part of Pro. An agent can read the relevant product evidence directly, reducing the context you need to copy between tools.
Aiola does not replace cloud-hosted workspaces. Its agents run on your own desktop, and scheduled automations need that desktop on and awake. Plan a separate hosted execution solution if that is essential to your work.
Try it in Aiola
Give your agent one saved task brief and a local repository after you download Aiola. Authenticate your chosen CLI, open the project, and choose Local or Worktree execution before starting. Review the diff and run your acceptance checks before moving another task.
