Conductor Cloud: When Coding Agents Outlive Your Laptop

On July 30, 2026, Conductor shipped Conductor Cloud — persistent, shareable workspaces where coding agents keep running after you close your laptop. The same release introduced a Conductor API so other apps (Slack bots, internal dashboards, even other agents) can create workspaces, send prompts, and read transcripts programmatically.

If you have only used agents inside a local IDE tab, this is a different mental model: the agent's home moves from your Mac to an isolated cloud machine, and teammates can join the same session.

Why this matters now

Think of a coding agent like a junior developer who needs a desk, a clone of the repo, and a terminal. Until recently, that desk lived on your machine:

• Close the lid → processes may sleep or die.
• Spin up three parallel agents → RAM and CPU spike on one laptop.
• Hand work to a teammate → you export a PR link and hope they can reproduce context.

Conductor Cloud moves the desk to an isolated microVM (Conductor's docs call these sandboxes). The agent keeps working when you step away. Teammates open the same workspace link, see who is active, and prompt together in real time — no "works on my machine" handoff.

This is not a new model vendor. Conductor still runs first-party harnesses you already pay for — Claude Code, Codex, Cursor, OpenCode — using your subscriptions or API keys. Conductor sits above the model layer as an orchestration and workspace manager. That vendor-neutral bet matters because "the vibes shift every few months" (as Conductor CEO Charlie Holtz told Vercel's blog): today's best model is not next quarter's.

For teams, the July 30 launch also adds cloud organizations, shared repo settings, and programmatic control — the bridge from solo Mac app to team budget line item.

Comparison: three ways to run parallel agents

Cursor Cloud Agents (which PapaCoder's own automations use) optimize for developers already inside Cursor: spawn subagents on remote VMs, continue sessions across devices. Conductor Cloud optimizes for harness agnosticism — one pane to run Claude Code and Codex and Cursor agents on separate branches, with a first-class HTTP API and transcript SQL search.

Neither replaces the other today; they solve overlapping problems with different lock-in tradeoffs. Conductor's API-first design is the differentiator if you want bots and cron jobs to assign agent work before a human opens a GUI.

The orchestration-layer pattern (PapaCoder lens)

PapaCoder Labs treats agents as specialized team members with typed handoffs — not one mega-prompt (specs/11-agent-architecture.md). Conductor Cloud is a real-world example of the Platform Intelligence layer:

1. Specialized workers — Claude Code for refactors, Codex for tests, Cursor for UI — each on its own branch/worktree.
2. Persistent runtime — like our editorial cron that must finish even if the triggering laptop sleeps; cloud workspaces are the same idea for code agents.
3. Typed programmatic handoffs — the Conductor API (POST /v0/sessions/{id}/messages, GET .../status) is structurally similar to PapaCoder's Internal API for draft upserts: machines talking to machines with auth, not humans copy-pasting chat logs.
4. Human gate at the end — Conductor does not auto-merge to main; humans review diffs in the git panel. PapaCoder likewise stops at status=draft until an admin publishes.

The July 23 alpha already let agents inside cloud workspaces call the Conductor API to spawn other workspaces — agents managing agents. That is the same direction as Cursor subagents, expressed as REST instead of IDE UI.

Code example: start agent work from a script

Conductor documents a REST API at https://api.conductor.build/v0. Below is an illustrative TypeScript client shape — adapt paths to your org's OpenAPI spec and never commit API keys.

const CONDUCTOR_API = "https://api.conductor.build/v0";

async function startAgentTask(apiKey: string, projectId: string, prompt: string) {
  // 1) Create an isolated cloud workspace
  const wsRes = await fetch(`${CONDUCTOR_API}/workspaces`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ projectId, name: `nightly-refactor-${Date.now()}` }),
  });
  if (!wsRes.ok) throw new Error(`workspace: ${wsRes.status}`);
  const { id: workspaceId } = await wsRes.json();

  // 2) Open an agent session (claude | codex | cursor per Conductor docs)
  const sessionRes = await fetch(`${CONDUCTOR_API}/workspaces/${workspaceId}/sessions`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ agent: "claude", model: "claude-sonnet-4-20250514" }),
  });
  const { id: sessionId } = await sessionRes.json();

  // 3) Send the task — agent keeps running if you disconnect
  await fetch(`${CONDUCTOR_API}/sessions/${sessionId}/messages`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ content: prompt }),
  });

  // 4) Poll until idle, then fetch transcript
  for (;;) {
    const statusRes = await fetch(`${CONDUCTOR_API}/sessions/${sessionId}/status`, {
      headers: { Authorization: `Bearer ${apiKey}` },
    });
    const { state } = await statusRes.json();
    if (state === "idle") break;
    await new Promise((r) => setTimeout(r, 5000));
  }

  const txRes = await fetch(`${CONDUCTOR_API}/sessions/${sessionId}/messages`, {
    headers: { Authorization: `Bearer ${apiKey}` },
  });
  return { workspaceId, sessionId, transcript: await txRes.json() };
}

Inside a cloud workspace, Conductor injects environment variables such as CONDUCTOR_API_URL and (for machine-launched team workspaces) a scoped CONDUCTOR_API_KEY, so an agent can programmatically fan out more sessions — useful for "manager agent assigns subtasks" patterns.

Conductor also documents POST /v0/sql for read-only transcript search — enabling internal compliance dashboards without exporting chat to a third party.

Practical team workflows

Multiplayer debugging. A senior engineer and a junior open the same workspace link. Both see the agent transcript and git diff; either can steer the next prompt. This replaces the async loop of "I pushed a branch, here's the PR, try reproducing my agent session."

Slack / PagerDuty bots. Because the API can create workspaces and enqueue prompts, a /fix-flaky-test slash command can spawn an isolated agent run on a cloud VM while the on-call engineer stays in Slack.

Async overnight refactors. Start a large migration prompt, close the laptop, review the diff next morning — the pattern Conductor Cloud marketed explicitly in its July 30 changelog.

Background task visibility. Version 0.77 (July 23) added transcript indicators when an agent waits on shell commands — small UX detail, but critical for trust when agents run unattended in the cloud.

Senior engineer perspective (NZ timezone reality)

From Auckland or Wellington, your day often ends when San Francisco starts. Cloud-persistent agents flip the handoff:

• Before: You leave a long agent job running locally, VPN drops, laptop sleeps, work stalls.
• After: You enqueue work on a US-region microVM (exact regions depend on Conductor/Vercel Sandbox placement), log off at 6 pm NZST, and review results at 9 am.

Caveats a senior engineer should still enforce:

1. Review before merge — unattended agents optimize for "done," not "correct." Treat cloud output like a contractor PR.
2. Secrets — cloud workspaces need the same .env hygiene as CI; never paste production credentials into prompts.
3. Cost visibility — you still burn your Claude/Codex/Cursor quotas; Conductor adds Pro/cloud fees on top. Track both.
4. Audit — use transcript SQL export for incident postmortems when an agent ran while nobody was watching.

The orchestration layer does not remove accountability; it moves the accountability question from "did my laptop stay awake?" to "did our team process review agent output?"

How this relates to Cursor Cloud Agents

PapaCoder runs editorial automations on Cursor Cloud Agents — cron-triggered runs that write drafts via Internal API, never auto-publishing. Conductor targets a adjacent problem:

If you already live in Cursor, Cloud Agents are the lowest-friction path. If your team standardizes on multiple coding agents or wants HTTP-first integration with internal tools, Conductor's July 30 API launch is the news worth tracking.

You can use both metaphors in one organization: Cursor for feature development, Conductor API for scheduled maintenance bots — provided you maintain clear ownership of branches and review gates.

FAQ

Does Conductor replace Claude Code or Cursor?
No. It orchestrates them. You bring your own subscriptions/API keys.

Can agents run after I close my laptop?
Yes — that is the core Conductor Cloud promise (isolated cloud machine, not your Mac).

Is the API generally available?
It launched July 30, 2026 alongside Conductor Cloud; Pro/team onboarding applies per Conductor docs. Alpha began July 23 for Pro users.

Does Conductor auto-merge code?
No. Humans review diffs in Conductor's git panel before merge — same class of gate as PapaCoder's admin publish step.

How is this different from GitHub Copilot coding agent?
Copilot's agent is tied to GitHub's ecosystem. Conductor is harness- and repo-hosting-agnostic orchestration with multiplayer workspaces.

What infra runs the sandboxes?
Conductor Cloud Workspaces use Vercel Sandboxes per Vercel's public case study — isolated microVMs, not processes on your laptop.

Sources

• Conductor changelog 0.78.0 — Introducing Conductor Cloud (July 30, 2026)
• Conductor changelog 0.77.0 — Multiplayer & API alpha (July 23, 2026)
• Conductor API documentation
• RuntimeWire coverage
• Vercel: Conductor Cloud on Vercel Sandboxes