Claude Delegator: giving Claude Code a bench of GPT and Gemini reviewers

Installing the plugin takes three commands and an external CLI

Install is deliberately plain. Add the marketplace, install the plugin, run setup:

/plugin marketplace add jarrodwatts/claude-delegator

/plugin install claude-delegator

/claude-delegator:setup

The one real prerequisite is a provider. You need the Codex CLI for GPT access or the Gemini CLI for Gemini access, and you can have either or both. Setup walks you through installing whichever is missing, so the command is doing real work rather than just writing config. Authentication is separate: `codex login` for Codex, or running `gemini` once to complete sign-in, or setting `GOOGLE_API_KEY`.

There is also an uninstall path at `/claude-delegator:uninstall`, which removes both the MCP config and the rules the setup step installs. Having a clean removal matters more than it sounds, because a stale rule file changes how the parent model decides to delegate.

Five specialists, each with a narrow trigger

The bench is five named experts. Architect handles system design, tradeoffs and complex debugging. Plan Reviewer validates a migration plan before you commit to it. Scope Analyst hunts for ambiguity in what you asked for. Code Reviewer looks for bugs. Security Analyst covers vulnerabilities and threat modeling.

Each is a system prompt in `prompts/`, not an implementation. They share a structure: role definition and context, separate advisory and implementation behaviour, response format guidance, and an explicit section on when to invoke and when not to. That last part is the design detail that matters, because the failure mode of delegation is not a bad answer but a wasted one on a trivial request.

The README is explicit about when to skip delegation. Simple file operations, the first attempt at any fix, and trivial questions do not need a second model. It also names the cases that do benefit: a caching decision, a bug that has survived two or more failed attempts, a plan before implementation, an auth flow you want checked, and a diff that deserves review.

Routing happens in the parent model, results come back synthesized

There is no separate router process. Claude reads your request, picks an expert, and calls the MCP tool, which is either the Codex one or the Gemini one depending on what is configured. The response goes back through Claude, which synthesizes it and applies judgment before you see it.

That last point is the one to be careful about. A synthesized security finding is Claude's reading of another model's analysis, and you lose a layer of traceability. The counterargument in the README is that raw passthrough is not better, since a second model's output pasted verbatim tends to arrive without prioritization or confidence attached. Worth knowing which of the two you are getting before you quote a finding in a review comment.

Retries are bounded. An expert can retry up to three times before the plugin escalates back to the caller, which keeps a failing provider from turning into a hang.

Two sandbox modes and thread ids for chained work

Every expert has two operating modes chosen from the request. Advisory runs in a `read-only` sandbox and is meant for analysis, recommendations and reviews. Implementation runs in `workspace-write` and is for making changes. Claude picks automatically based on what you asked for.

Defaults can be set once in `~/.codex/config.toml` rather than passed on every call:

sandbox_mode = "workspace-write"
approval_policy = "on-failure"

For anything longer than one exchange, the plugin uses a `threadId` to keep the expert's memory of earlier turns. The first call returns an id, later turns reply through it, so a multi-step implementation sequence runs as one conversation with the expert rather than three disconnected prompts. Single-shot calls, meaning `codex` or `gemini` with no reply, are the right choice for advisory work where there is no follow-up.

Manual MCP registration when the setup command misfires

The README gives a manual fallback, and the lines are written to be rerun safely, which is a nicer touch than most plugin docs manage. Each registration first removes any existing entry with output suppressed:

claude mcp remove codex >/dev/null 2>&1 || true
claude mcp add --transport stdio --scope user codex -- codex -m gpt-5.3-codex mcp-server

The Gemini equivalent points at the plugin's own server entry point through `CLAUDE_PLUGIN_ROOT` rather than a globally installed binary:

claude mcp remove gemini >/dev/null 2>&1 || true
claude mcp add --transport stdio --scope user gemini -- node ${CLAUDE_PLUGIN_ROOT}/server/gemini/index.js

Because the Gemini path depends on an environment variable the plugin sets, that registration is the more fragile of the two, and it is the likely reason the manual route exists. Verification is a listing plus an `initialize` handshake piped straight into the server. The troubleshooting table also covers the two most common reports: a missing server usually means Claude Code needs a restart after setup, and an expert that will not trigger can usually be forced by asking for it explicitly.

MIT licensed, small repository, development loop via plugin dir

The repository is MIT licensed, JavaScript, at 1000 stars. The tree is compact and tells you the shape of the project: `server/` for the MCP entry points, `prompts/` for the expert definitions, `commands/` for the setup and uninstall slash commands, `rules/` for the delegation rules, `config/` for defaults, and `docs/`. A `CLAUDE.md` is committed too, so the project is documented for agents as well as people.

The development loop does not require reinstalling. Cloning the repo and pointing Claude Code at it with `--plugin-dir` loads the working copy directly, so iterating on a prompt file takes effect on the next invocation.

The last push was 2026-03-09, which is well outside a recent window, so version drift against current Claude Code plugin conventions is a reasonable thing to check before relying on it heavily. The dependency on external CLIs also means provider-side breaking changes show up here first, which is the main operational risk to keep in mind.

Editorial conclusion

Claude Delegator is a small, legible piece of glue: five system prompts, one MCP registration, and a routing decision made by the model already in your terminal. It earns its place when you want a genuinely different opinion on an architecture call or a security review, because Codex and Gemini will disagree with Claude often enough to be worth listening to, and the dual sandbox mode keeps the advisory path read-only so a review cannot quietly edit your work. The seams are visible too. Setup depends on an external CLI being installed and authenticated, expert behavior lives in editable prompt files rather than code, and the last push was 2026-03-09, so read the troubleshooting table before assuming a failure is a bug. Run setup once, verify with `claude mcp list`, then try the Security Analyst on a diff you already know the answer to.

Frequently asked questions

Official sources

1. Issues
2. jarrodwatts/claude-delegator on GitHub
3. License: MIT
4. README