Symphony

What Symphony is for

Claude Code can already do a task well on its own. Symphony is for the moment you want more than one at once: several of your own sessions, a colleague's, or agents that keep working in GitHub while you sleep, all on the same project, without two of them doing the same task or one undoing another. Each case below is a situation, what you do, and how far along it is. To see the same powers set beside the tools you may already use, read Symphony compared.

The idea in one minute

Think of a kitchen with one order rail. Every dish is a ticket on the rail. A cook takes a ticket by pinning it to their own station, and once it is pinned no other cook can take it. If a cook walks away from a ticket for too long, it goes back on the rail with a note of what was already done. Before a plate leaves, someone checks it.

Symphony is that rail, kept in a GitHub repository. The tickets are GitHub issues. Taking one is pushing a branch named after it, and GitHub refuses a second push of the same name, so only one worker can hold it. The work comes back as a pull request, and it lands only when the repository's checks pass. A worker can be you, a colleague, one of your Claude Code sessions or an agent running in GitHub Actions; they all follow the same rule, and the board shows who holds what.

A worked example

One person, Maya, keeps a small web app in a GitHub repository that Symphony has set up. She has three things to fix before Monday.

  1. Friday afternoon, she writes three issues and labels them todo: the sign-up form forgets the email, the dates are in the wrong time zone, and the help page is out of date. That is the queue.
  2. She opens two Claude Code sessions, one in a terminal and one in the browser. Each reads the board, the first takes the sign-up issue by pushing the branch claude/12, and the second tries the same issue a moment later. GitHub refuses its push, so it takes the time-zone issue, claude/13, instead. Neither had to be told.
  3. Each session writes its plan first: a short file on its branch naming the worker, the plan and the files it will touch. The two plans both list settings.js, so the board says the two pieces of work meet there and which should land first.
  4. Each opens a draft pull request at once and pushes as it goes, so Maya can watch both from one page, the control panel, without opening a terminal.
  5. She goes home. The help-page issue is still in the queue, so the worker in GitHub Actions she registered once, which runs on her Claude plan when work is waiting, takes it and opens its own pull request. Her computer is off.
  6. The terminal session stalls overnight when the laptop sleeps. After about a day with no new commit, the board hands the issue back to the queue, renames the branch so its half-done work is kept, and leaves a comment saying what it held.
  7. Monday morning, two pull requests have passed their checks and wait for her press of Merge (she could have let a worker merge its own once green), and the third issue is back in the queue with notes for whichever worker picks it up next.

Nothing in that story needed a server, an API key or a new app: issues, branches, pull requests and GitHub Actions, plus one Claude plan.

Use cases

Works today built and in use Early built, still being proven
Works today

Several Claude sessions on one code base

For one developer who already runs more than one session.

The problem

Two sessions started on the same afternoon pick the same bug, or one rewrites the file the other is in the middle of.

With Symphony

  1. Write each task as an issue labelled todo.
  2. Open as many sessions as you like; each takes a different issue by itself.
  3. Review and merge their pull requests as they turn green.

Instead of: keeping a list of which tab is doing what.

Works today

A team, each on their own Claude account

For two or more people sharing one repository.

The problem

Each person's Claude knows only what that person told it, and nobody can see what the others' sessions are doing.

With Symphony

  1. The project's instructions, goal and shared notes live in the repository, so every session on every account reads the same ones.
  2. Everyone's sessions claim from the same queue, under each person's GitHub name.
  3. The board shows the whole team's work in one place.

Instead of: a chat thread asking "is anyone on this?"

Works today

Work that carries on while you are away

For anyone with more tasks than hours.

The problem

Claude stops when you close the laptop, and paying per token for agents in the cloud adds up.

With Symphony

  1. Register a worker in GitHub Actions with a short form; it runs on your Claude plan's token, never an API key.
  2. It starts when an issue is queued, and again while work remains.
  3. It works by the same rule as your own sessions, so it never takes the task you are on.

Instead of: a hosted coding agent billed by the token.

Works today

A big request split into pieces

For a feature too large for one sitting.

The problem

One session on a large change runs out of room; several sessions on it trip over each other.

With Symphony

  1. Write the request once and label it epic.
  2. Claude plans it into tasks, each owning its own files, and puts them in the queue.
  3. When the last task lands, Claude checks the whole and fixes what the pieces broke together.

Instead of: splitting the work up by hand.

Works today

Run the project from one web page

For someone who would rather not live in a terminal.

The problem

The state of the work is spread over issues, branches, pull requests and workflow runs.

With Symphony

  1. Sign in to the control panel with GitHub.
  2. See the board, queue a task, start the workers and merge a green pull request, all as buttons.
  3. Ask Claude a question about the project in its Assistant box; the answer comes back on the page.

Instead of: a dozen GitHub tabs.

Early

Revising papers from reviewers' comments

For anyone whose Word documents come back full of comments.

The problem

Every comment needs an edit and a reply, across several documents, and each edit must stay reviewable.

With Symphony

  1. Put the documents in a repository; each one becomes one task, made from its comments.
  2. A worker takes a document, answers each comment, and its edits are written back into the .docx as Word's own tracked changes, each with a comment saying why.
  3. You open the file in Word and accept or reject each change, as you would a colleague's.

Built and checked on documents it made; not yet proven on one saved by Word.

Early

A folder of Drive or OneDrive files, kept in step

For a group whose work lives in shared folders, not in code.

The problem

Files in a shared drive have no queue, no claim and no review before a change lands.

With Symphony

  1. Sign in to Google Drive or OneDrive once, in the browser, and pick the files or folders.
  2. A new repository tracks them and stays in step with the drive.
  3. A new comment on a file starts a task, worked by the same rules as code.

The sync is built; the one sign-in waits on a one-time setup, and until then it goes through a folder on your own computer.

Early

A job on a university cluster, from GitHub

For a research lab whose code is on GitHub and whose computing is on a shared cluster.

The problem

Running a job means signing in, copying files, writing a batch script and copying results back by hand.

With Symphony

  1. The lab sets it up once, in the cluster's own web shell.
  2. Press Run on a workflow in GitHub; a runner that lives for that one job starts on a compute node through the cluster's own scheduler.
  3. The output comes back as the job's log and a file, beside the commit that made it. GitHub holds no password, only a key that can start, check or stop the runner.

Running on one university's cluster so far.

Early

A project open to volunteers

For an open project that many people want to help with.

The problem

Volunteers duplicate each other's work, abandon tasks halfway, and nobody wants to hand out an AI key.

With Symphony

  1. The owner turns on crowd mode once; the repository then holds no Claude credential of anyone's.
  2. Once the owner invites them, each volunteer works on their own Claude account and claims from the queue the maintainers fill.
  3. Abandoned tasks come back after about a day, and every contribution passes the required check.

Built; waiting for its first crowd.

Early

Several Claude accounts as one pool

For one person with more than one Claude plan of their own.

The problem

One plan's usage window runs out while another account sits idle.

With Symphony

  1. Add each of your accounts to the pool from the control panel's Tokens tab.
  2. The page shows each account's recent use.
  3. A worker can run on a chosen account, or on whichever has room.

The pool works; the page's Add box waits on a one-time permission. Each account stays its owner's own; a pool is never shared between people.

Case study: Symphony builds Symphony

Symphony's own repositories, its protocol library, its template, its GitHub Apps, its extensions and this website, are built the way the cases above describe. One person sets the direction, and many Claude Code sessions work in parallel, each in its own thread: each takes one piece of work, does it on its own branch, opens one pull request, runs the repository's checks first, and merges only once they are green. When two pieces of work need the same file, one owns it and the other hands its change over. When a session is cut off halfway, its branch and its notes are still there for the next one.

What this case shows is that the way of working holds up day to day, on real work, with one person and many sessions. What it does not show is a measured speed-up over one agent working alone: that comparison is a benchmark still running, and no result is claimed here until it is done.

Other work with the same shape

Symphony fits any work that splits into tasks, where each task changes files and can be checked before it counts. Beyond the cases above, that includes translating a set of documents, writing course material chapter by chapter, cleaning a collection of data files, keeping a set of policies or procedures up to date, and building out a website page by page. None of these has been run under Symphony here yet; they are named so you can see whether your own work has the shape.

Start with Symphony Compare it with the tools you know What it costs