Symphony launches Codex orchestration for Linear and GitHub issue queues

• OpenAIDevs' launch post introduced Symphony as an open-source orchestration layer for Codex that turns issue trackers into an always-on queue for agentic work.
• In reach_vb's summary, the core loop is simple: open issue, assign agent, generate PR, then hand the result to a human reviewer.
• WesRoth's demo recap says Symphony plugs into trackers including GitHub Issues and Jira, with one autonomous Codex agent attached to each ticket.
• Early hands-on feedback from daniel_mac8 is bullish on throughput, 30 Linear issues closed in a week, but also blunt about the tradeoff: Symphony is "VERY" token hungry.

You can read OpenAI's announcement, watch the launch demo, and skim an early user writeup teaser from daniel_mac8. The interesting bit is not a new model. It is a workflow wrapper that treats a backlog like a live work queue, with one agent per issue and humans shifted to review and direction.

Symphony is positioned as a minimal orchestration layer for Codex, not a standalone coding agent. In OpenAIDevs' wording, the point is to turn task trackers into "always-on systems for agentic work," while reach_vb's summary frames it as one Codex session per task.

That gives the product a very specific shape:

• issue tracker as the intake layer
• one agent attached to each open task
• PR generation as the default output
• human review as the control point

The workflow described across the launch posts is a tight four-step loop:

1. Open an issue.
2. Assign an agent.
3. Let Codex generate a pull request.
4. Put a human back in the loop for review.

According to WesRoth's recap, OpenAI is pitching this against existing systems of record, not as a replacement for them. The examples named in the evidence are Linear, GitHub Issues, and Jira.

The strongest claim in the launch framing is concurrency. OpenAIDevs describes "every open issue" having a Codex agent, and WesRoth translates that into a backlog becoming an "army of agents."

That matters because the unit of orchestration is the ticket, not the repo. Symphony's model is many narrow runs in parallel, each scoped to one issue, instead of one long interactive session working through a queue.

The first concrete caveat came from usage, not the launch copy. daniel_mac8 said Symphony plus Codex closed 30 Linear issues in a week, but nearly exhausted a weekly Codex limit under a ChatGPT subscription.

That is the cleanest data point in the evidence pool: early throughput looks real, and so does the cost of fanning out agents across many tickets. The workflow makes parallel work easier; it also multiplies token consumption fast.

One useful implementation detail surfaced in daniel_mac8's post: Symphony is open-source and, at least for this early user, usable with a ChatGPT subscription rather than requiring a separate enterprise setup. that follow-up post points to a longer writeup on how the stack was configured and what the results looked like.

That makes Symphony look less like a top-down platform rollout and more like a harness other teams can wire into their own issue queues.