GPT-56T 861 —
MUSE-SPK 837 +0.2%
GPT-56SC 790 -4.6%
GLM-5 781 -0.4%
CL-OP55X 780 -5.1%
GROK-46H 780 -5.1%
QWEN-38X 748 -9.2%
GPT-6A 743 -9.4%
KIMI-K3X 742 —
CL-FAB5H 698 -6.1%
CL-OP5H 675 -6.2%
GEM-38FH 672 -0.7%
CL-OP5X 670 -5.5%
CL-OP55H 668 —
CL-OP46H 657 -5.9%
CL-OP47H 648 -6.1%
GPT-56S 618 -0.6%
GEM-37FH 610 -7.2%
GEM-36FH 593 —
CL-OP48H 588 —
CL-OP47 581 -0.2%
GEM-35FH 580 —
GPT-55H 541 -7%
INKL 531 —
GEM-31P 512 -0.2%
CL-OP46 498 +0.4%
GEM-3P 498 -0.2%
CL-OP48 492 +0.4%
GPT-52 464 —
GPT-55 423 —
GPT-56T 861 —
MUSE-SPK 837 +0.2%
GPT-56SC 790 -4.6%
GLM-5 781 -0.4%
CL-OP55X 780 -5.1%
GROK-46H 780 -5.1%
QWEN-38X 748 -9.2%
GPT-6A 743 -9.4%
KIMI-K3X 742 —
CL-FAB5H 698 -6.1%
CL-OP5H 675 -6.2%
GEM-38FH 672 -0.7%
CL-OP5X 670 -5.5%
CL-OP55H 668 —
CL-OP46H 657 -5.9%
CL-OP47H 648 -6.1%
GPT-56S 618 -0.6%
GEM-37FH 610 -7.2%
GEM-36FH 593 —
CL-OP48H 588 —
CL-OP47 581 -0.2%
GEM-35FH 580 —
GPT-55H 541 -7%
INKL 531 —
GEM-31P 512 -0.2%
CL-OP46 498 +0.4%
GEM-3P 498 -0.2%
CL-OP48 492 +0.4%
GPT-52 464 —
GPT-55 423 —
← Back to feed

OpenAI Open-Sources Symphony: A Codex Orchestration Spec That Turns Issue Boards Into Autonomous Agent Pipelines

OpenAI formally announced Symphony on April 27, two months after its GitHub repository first appeared. The project is a language-agnostic specification — and an Elixir reference implementation — for a long-running daemon that watches a Linear issue board and dispatches a Codex agent session for each issue it picks up.

The idea is a level of abstraction above “run this agent on this task.” Symphony’s unit of work is the issue, not the prompt. An engineer marks a ticket as ready; Symphony picks it up, provisions an isolated workspace, builds a prompt from the issue description plus the repo’s WORKFLOW.md policy file, launches Codex, and streams back CI status, PR review feedback, and a walkthrough on completion. The engineer reviews and approves the PR. At no point does anyone supervise the agent session itself.

The Design Decisions That Matter

Per-issue workspace isolation. Every issue gets its own directory. Agent commands can’t bleed across sessions. This is the safety boundary that makes unattended operation tractable without a full sandbox.

WORKFLOW.md as the contract. The workflow policy lives in the repository, version-controlled with the code. Teams change agent behavior by committing a file, not by reconfiguring an external service. This is the same pattern Codex uses for its harness — Symphony extends it to the orchestration layer.

No persistent database required. Symphony’s orchestrator state is in-memory and restartable. This keeps the deployment surface minimal: a single process, filesystem access, Linear API credentials, and a Codex app-server binary.

Spec-first, not product-first. OpenAI has said explicitly it won’t maintain Symphony as a standalone product. The spec is language-neutral — the README instructs developers to ask their favorite coding agent to implement it in any language they prefer. OpenAI wrote the Elixir version by asking Codex to do it; Go, TypeScript, Python, Rust, and Java variants were generated to surface spec ambiguities.

Numbers

  • 18,615 GitHub stars as of April 29
  • 1,550 forks
  • Published April 27, 2026 on openai.com/index/open-source-codex-orchestration-symphony/
  • License: Apache 2.0
  • Reference implementation: Elixir (95.4% of code), with Python tooling
  • Last commit: April 27

The Broader Context

Symphony is a spec for how coding agents should be managed at the project level — not how they reason, not how they generate code, but how work gets assigned, isolated, and delivered. The fact that OpenAI is publishing this as an open standard rather than a proprietary product is a deliberate move: they want Symphony-compatible tooling to proliferate around Codex, not to own the orchestration layer themselves.

The immediate comparison is AWS AgentCore, which ships a persistent filesystem and execution environment but positions itself as infrastructure, not workflow. Symphony is opinionated about workflow — it wants Linear, per-issue isolation, and repo-owned policy — while staying silent on the execution environment. The two could coexist.

For teams already running Codex at scale, Symphony provides the scaffolding that most of them have been building internally anyway: a way to stop babysitting agent sessions one by one and manage work queues instead.