Conductor Cloud shuts down Nov 20: how to move your agent work

If you have unfinished work in Conductor Cloud, the first decision is not which tool to try next. It is how to get your work out and make sure you can continue it.

Conductor's November 4 announcement says Conductor is joining Meta. Conductor Cloud goes read-only on November 13, 2026, and shuts down on November 20, 2026. Local Conductor keeps getting new models and critical bug fixes until early 2027.

Treat November 13 as your working deadline. You do not need to choose a replacement before preserving what you have.

Here is a four-step migration checklist, followed by one option to evaluate if you decide to move.

1. Transfer your workspaces and export your data

Conductor documents two ways to move your work:

• To move a cloud workspace and its chats to your Mac, right-click the workspace and choose Transfer to local.
• To download all your data, open Settings → Account → Export data.

These serve different purposes: one lets you continue a workspace locally; the other gives you a data export. If both matter to you, do both.

Start with workspaces that have unfinished changes or conversations you still rely on. Keep a short checklist so an older, less visible workspace does not get missed.

Afterward, check that you can open the transferred work and locate the export. Do not treat a downloaded archive as a verified backup until you have inspected what it contains. Store it somewhere appropriate for the sensitivity of your repository and conversations.

2. Reconcile branches and unfinished changes

Before switching tools, establish what is actually saved in git.

For each active repository, review:

• The current branch and any other branches with unfinished work.
• Modified and untracked files.
• Commits that exist locally but have not been pushed.
• Open pull requests and the branches they use.

Useful starting commands are:

git status --short git branch -vv git log --oneline --decorate -10 

Review files before staging them. Do not use a blanket commit as a backup strategy: untracked files can include credentials, local configuration, or generated output that should never enter git.

Push the branches you intend to preserve to your normal remote, following your team's usual process. For unfinished work you are not ready to commit, make a deliberate backup that respects your repository's security requirements.

A chat saying that a task is complete is not the same thing as a saved commit or an open pull request. Check the repository itself.

3. Write down how to resume the work

A branch preserves code. It does not necessarily explain how to run it or what the agent was trying to finish.

Create a short handoff note for each important task:

• What change was requested?
• Which branch contains it?
• What is finished, and what remains?
• Which setup, build, and test commands should run?
• Are there known failures or required local services?

Document required environment variable names, their purpose, and the approved way to obtain their values. Do not paste secrets into the handoff, an issue, a prompt, or a repository.

Then try the setup and tests from your intended destination. This is the point to discover a missing dependency or an undocumented setup step—not after the cloud workspace is gone.

4. Choose where the next task should run

Staying on local Conductor is a valid option. Its announced window for new models and critical fixes runs until early 2027. If it meets your needs, moving cloud workspaces locally may be the least disruptive next step.

If you evaluate another tool, separate two questions:

1. Can I continue working on this repository?
2. Does it support the workflow I actually need?

In particular, do not assume that every feature called “cloud” means a persistent hosted workspace. Check what runs remotely, what comes back, and how you inspect the result.

One option: a lead model, reviewers, and command receipts

Disclosure: I built LetThemBuild. It is one option to evaluate, not a requirement for completing the steps above.

LetThemBuild has a desktop app for Mac, Windows, and Linux, plus the ltb CLI. On Mac, the installation command is:

brew install --cask gpulogyai/tap/ltb 

The workflow starts with one lead model—Claude, ChatGPT, Gemini, or Grok—making a change in its own git worktree. Other models re-run the build and tests, then agree or object. A receipt records each command and its exit code, so you can inspect what actually ran before deciding whether to merge.

You can bring your own Claude Code, Codex, Gemini CLI, or Grok Build CLIs, or an OpenRouter key, on Pro. Those bring-your-own options have a 14-day trial on Free.

For remote execution, Run in the Cloud runs a discussion's task on LetThemBuild's machine and returns a branch or pull request. That is not a claim of parity with Conductor Cloud's persistent hosted workspaces.

Start with one small, reversible change. Read the diff, inspect the receipts, and run your normal checks. Reviewers re-running tests do not prove that code is correct; incomplete tests and shared blind spots still matter.

I put the product details and migration steps on the LetThemBuild comparison page.

Whatever you choose, preserve your work first. A verified export, clean branch inventory, and usable handoff will help more than a rushed tool decision.