Maestro Orchestrate: One Agent Tree Behind Gemini CLI, Claude Code, Codex and Qwen Code
Multi-agent orchestration platform for Gemini CLI, Claude Code, Codex, and Qwen Code — 39 specialists, parallel subagents, persistent sessions, and built-in code review, debugging, security, SEO, accessibility, and compliance tools
At a glance
- What is it?
- Maestro packages 39 specialist subagents and a two-track workflow (Express or four-phase Standard) into a single src/ tree that four different CLI runtimes consume. The interesting part is the portability layer, not the agent count.
- Who is it for?
- Adopt Maestro if you already live in one of the four supported CLIs and want review, security, accessibility and SEO passes wired into the same session state rather than assembled per task. Skip it if you need a runtime outside those four, or if your team cannot edit ~/.gemini/settings.json or ~/.qwen/settings.json, since the README states Maestro will not do that for you.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 40 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is not agent count, it is four CLIs with four different plugin formats
Most multi-agent setups are written for one assistant. You get a set of prompts that work in Claude Code, and if a teammate prefers Codex or Gemini CLI, they either maintain a fork or give up. Maestro takes the opposite position: one canonical src/ tree, four thin runtime adapters. The README states it runs across Gemini CLI, Claude Code, Codex and Qwen Code, and the table of runtime targets shows how differently each one is wired. Gemini CLI and Qwen Code get snake-case agent names, TOML commands and hooks. Claude Code gets kebab-case agents under a maestro: subagent namespace and a shorter command surface such as /orchestrate and /review-code. Codex gets plugin skills, spawn_agent, and explicitly no runtime hooks. That last detail matters more than it looks: the same orchestration has to work without a hook mechanism on one target, which constrains how much state can be captured automatically. The audience is a team that has standardised on one of these four CLIs and wants repeatable, reviewable agent runs instead of ad hoc prompting.
Express versus Standard: two workflows picked by task classification
The entrypoint does not hand your prompt straight to a specialist. According to the README, Maestro classifies the task, chooses Express or Standard, asks the required design questions, produces an implementation plan when needed, delegates execution, runs a quality gate, and archives session state under docs/maestro/. Express is described as the path for simple work; Standard is a four-phase workflow for medium and complex work. The design questions arrive before planning, which is a deliberate interruption: you cannot get a plan out of a vague request. The quality gate sits at the end, so the last thing that happens is not the last specialist writing code. What the README does not specify is the classification rule itself, or what happens when a task is misclassified as Express and turns out to need the four-phase path. Treat the classification as a heuristic you will learn by running it, not as a documented contract.
39 specialists and the standalone entrypoints that bypass orchestration
The specialist pool is the headline number, but the more useful design decision is that review, debug, security, performance, SEO, accessibility and compliance are exposed as standalone entrypoints. You do not have to start a full orchestration to get a security pass. On Gemini CLI that is /maestro:security-audit; on Claude Code it is /security-audit; on Codex, $maestro:security-audit. The README gives a concrete example prompt: audit authentication, authorization, data exposure, secret handling, and exploitability risks. The review entrypoint is similarly scoped, asking for correctness, regressions, security, maintainability risk, and missing tests. That is a fixed checklist rather than an open-ended request, which makes the output more comparable between runs. Two things the material does not give you: the names of the 39 specialists, and any statement about how they are selected for a given task beyond the MAESTRO_DISABLED_AGENTS exclusion list. If you need to know exactly which agent will touch your authentication code, that is not answerable from the README.
Installing against four runtimes, and the settings file Maestro will not edit
Installation is a single command per runtime. Gemini CLI: gemini extensions install https://github.com/josstei/maestro-orchestrate. Qwen Code: qwen extensions install https://github.com/josstei/maestro-orchestrate. Claude Code uses a marketplace flow, claude plugin marketplace add josstei/maestro-orchestrate followed by claude plugin install maestro@maestro-orchestrator --scope user. Codex registers a marketplace with codex plugin marketplace add josstei/maestro-orchestrate, then you start Codex, run /plugins, select Maestro and install. For local development, Gemini CLI and Qwen Code use gemini extensions link . and qwen extensions link . after cloning; Claude Code can load a directory with claude --plugin-dir /path/to/maestro-orchestrate/claude. One Codex quirk is documented explicitly: a local path must start with ./, ../, /, or ~/, because Codex otherwise treats a bare owner/repo string as a GitHub source. Node.js 20+ is required for the MCP server and helper scripts. The prerequisite that will catch people out is subagents: Gemini CLI and Qwen Code require experimental subagents to be enabled in ~/.gemini/settings.json or ~/.qwen/settings.json via the experimental.enableAgents key, and the README states plainly that Maestro does not edit those files for you. Verify the install with gemini extensions list or qwen extensions list.
Session state, retries and the concurrency cap you have to set yourself
Six environment variables tune behaviour, and the defaults are meant to work untouched. MAESTRO_STATE_DIR defaults to docs/maestro and controls where sessions, plans and archives are written. MAESTRO_EXECUTION_MODE defaults to ask, with parallel and sequential as the other options, so nothing runs concurrently until you say so. MAESTRO_AUTO_ARCHIVE defaults to true, which means a successful session writes an archive without asking. MAESTRO_MAX_RETRIES defaults to 2 and applies to failed phases. MAESTRO_MAX_CONCURRENT defaults to 0, documented as meaning no Maestro cap, so the ceiling is whatever your runtime and machine allow. MAESTRO_DISABLED_AGENTS is unset by default and takes the specialists you want excluded from assignment. The design choice worth flagging is the pair of defaults: auto-archive on and no concurrency cap. The first writes to your repository by default, which is convenient but means docs/maestro accumulates unless you prune it. The second means the parallel path has no built-in brake, so on a large repo the limiting factor is the underlying CLI, not Maestro.
Where Maestro is the wrong tool, and what a plain reviewer does differently
The clearest failure mode is the runtime boundary. Four targets are supported and the README does not claim others. If your team uses a CLI outside that set, the orchestration layer does not apply, and the canonical src/ tree is not documented as a general-purpose library you can call directly. The second constraint is the settings edit: without experimental subagents enabled in the Gemini or Qwen settings file, the subagent model those two runtimes depend on is not available, and Maestro will not make that change. The third is Codex, which the runtime table says has no runtime hooks, so anything hook-driven on the other targets has to be handled differently there. Compare with a single-agent code reviewer such as a plain Claude Code or Gemini CLI review command with no plugin installed. That approach reads your diff and answers in one pass, with no session directory, no phase retries, no specialist routing and no archive. It is cheaper to reason about and has nothing to configure. Maestro's difference is persistence and division of labour: state in docs/maestro, a retry budget for failed phases, and separate entrypoints for security, accessibility, SEO and compliance that would otherwise be four different prompts you maintain by hand. If your reviews are already consistent and you never resume a session, the extra machinery buys you little.
Licence, release cadence and what upgrading actually costs
Maestro is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, with the usual requirements around retaining notices and stating changes. That is a permissive licence, not legal advice; check the LICENSE file and your own obligations. Release cadence from the recent tags is roughly one patch every one to three weeks: v1.6.2 on 2026-04-15, v1.6.3 on 2026-04-21, v1.6.4 on 2026-04-30. Patch-level churn at that rate suggests active maintenance, and it also means your pinned version drifts quickly. The upgrade cost is not the install command, which is the same one-liner; it is the session state. docs/maestro holds plans and archives written by an older version, and the README does not describe a migration path or a schema version for that directory. If you rely on archived sessions for audit, verify after upgrading that /maestro:status and /maestro:resume still read sessions written before the bump. The safest pattern the material supports is running the install command, then checking gemini extensions list or qwen extensions list to confirm the version, before starting new work.
Editorial conclusion
Adopt Maestro if you already live in one of the four supported CLIs and want review, security, accessibility and SEO passes wired into the same session state rather than assembled per task. Skip it if you need a runtime outside those four, or if your team cannot edit ~/.gemini/settings.json or ~/.qwen/settings.json, since the README states Maestro will not do that for you. Before committing, run the install for your runtime, confirm it with gemini extensions list, claude plugin list or qwen extensions list, and try one /maestro:review pass on staged changes to see whether the specialist output matches how your team reviews code.
Community notes