Agent Swarm 2.6 Adds Codex Gateway Routing and Workflow Run Trees

Agent Swarm released version 2.6.0 on October 26 with Codex gateway routing and new APIs for inspecting nested workflows. For teams running several coding agents, the useful changes concern where model requests go and how to tell whether delegated work has actually finished.

This is Desplega's Agent Swarm project, not OpenAI's similarly named Swarm framework. Its documentation describes a lead-and-worker system: a lead receives work, delegates tasks to agents and tracks their progress. Workers can run different coding assistants, including Claude Code and Codex, with a dashboard and integrations around them.

That coordination brings its own engineering problems. A single coding session has one owner and one visible conversation. A workflow with several workers, retries and child workflows needs a clearer way to expose its state.

What Agent Swarm 2.6 changes

The 2.6.0 release is available through npm, Bun and versioned Docker images. The project is MIT-licensed. Self-hosting the software does not remove the cost of compute, model access or operating it.

Alongside gateway routing and workflow APIs, the release adds artifact-review conveniences under Comb, including search, share links, audio and HTML previews, uploads and comment controls. It also changes credential-pool management so individual keys can be added, removed and checked.

The more substantial developer changes are easier to understand by separating the model connection from the workflow that surrounds it.

Codex gateway routing requires a Responses API endpoint

The merged gateway implementation adds two per-agent settings: CODEX_GATEWAY_BASE_URL and CODEX_GATEWAY_API_KEY. The URL includes the /v1 prefix and points to a non-api.openai.com origin. The gateway must support POST /v1/responses.

Previously, Agent Swarm could route Claude agents through a gateway using per-agent configuration, but its stock Codex setup did not provide the equivalent path. Version 2.6 generates a separate Codex provider configuration for the gateway rather than relying on a generic base-URL override.

On that route, the adapter removes the direct OpenAI key and Codex OAuth variable from the Codex process environment and skips the OAuth pool and authentication-file restoration path. Its credential check targets the gateway. When the new route is not configured, the existing authentication path remains unchanged.

“OpenAI-compatible” is not a sufficient compatibility check here. A gateway that only implements Chat Completions does not satisfy the documented Responses API requirement. Teams should validate the actual endpoint and model behavior before moving working agents onto it.

The practical benefit is a more deliberate connection boundary. An operator can choose the gateway for a Codex worker without rebuilding the worker image. That is useful routing control, but it does not prove that every gateway preserves tool use, streaming or billing behavior in the same way.

Workflow run trees make unfinished work visible

The new workflow-tree endpoint, GET /api/workflow-runs/{id}/tree, returns a root run and its descendants, plus a hasOpenWork flag. Previously, callers had to find child runs by listing runs and matching their parent-step references.

The response follows stored parent links across step attempts, including terminal runs. Its summaries and open-work state come from the same database snapshot, so the relationship information and status are read together.

Consider a parent workflow that launches a code change and a test workflow. A finished parent row alone is not enough to describe everything underneath it. The tree provides a way to inspect the related work without reconstructing that relationship in each monitoring client.

There are limits. The endpoint has no pagination, and cycles or nesting beyond the supported depth return an error. The merged change also notes that it does not add a corresponding MCP tool. Developers should treat it as a specific REST addition, not assume that every agent interface exposes it automatically.

Slim workflow responses reduce repeated context transfer

A separate slim-response change adds fields=slim to the run-detail endpoint. It omits the run's context and each step's input snapshot while retaining outputs, errors, diagnostics and retry information. Full responses remain the default.

That distinction matters for loops. If every step contains a snapshot of a growing context, repeatedly fetching the whole run can transfer far more data than a status view needs. The dashboard now uses the smaller response for child-workflow cards.

In the contributor's reported handler measurement, a 30-step run with a 20 KB context fell from 630.6 KB to 8.5 KB. That is a response-size result for that example, not a demonstrated reduction in model tokens, inference cost or task completion time.

Who should consider the update

The strongest fit is an existing Agent Swarm operator managing Codex workers or nested workflows. Someone running one coding agent locally is unlikely to need an orchestration platform just to obtain these changes.

For an existing deployment, a useful upgrade check is concrete: verify the gateway destination with a non-sensitive test, confirm a child run appears in its parent's tree, and check that monitoring clients handle both full and slim responses. Keep model credentials and operational access scoped to the work being performed.

The release makes parts of an agent system easier to inspect. That is worth paying attention to because adding workers is straightforward compared with knowing where their requests went, which work remains open and what a finished status actually means.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn product updates and engineering decisions into clear stories that developers understand and share.

Book a 30-minute call.