Orchestrator skill
One agent launches others in the background: Claude Code, Codex, Copilot CLI, Grok Build and Pi, with a model chosen per stage.
- 119 ★ on the repository
- Last commit
Broad access
Why this level
- Launched agents run in the background with their own permissions and can edit code and run commands.
- Parallel agents quickly burn provider limits and billing.
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/orchestratorDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- Launched agents run in the background with their own permissions and can edit code and run commands.
- Parallel agents quickly burn provider limits and billing.
This is third-party code. Review the repository files before installing.
What it does
The skill turns the current agent into a coordinator. The user names models and outcomes, and the skill uses the `orchestrator` CLI to launch named background tasks in Claude Code, Codex, Copilot CLI, Grok Build, Pi and custom runtimes. Every task has status, logs, output, follow-up, resume and stop. The agent works through a short loop of JSON commands: `doctor`, `models`, `launch`, `ps`, `read`, `interrupt`. Model names and IDs come from the installed runtimes. Routing rules (which model for which work and what to use when a limit runs out) live in `skills/orchestrator/PREFERENCES.md`.
Who it is for. People who pay for several agents at once and want to hand work to them from a single window.
Good fit when
- The interface, backend and small fixes go to different models running in parallel.
- An agent collects the results of background tasks and merges them into one answer.
- One model hit its limit and work moves to the fallback from the preference list.
- Repository exploration goes to a cheaper model and the implementation plan to a stronger one.
Not a fit when
- You work with a single agent and model, and a coordinator would only add a layer.
- You want a replacement for an environment like Claude Code: Orchestrator runs on top of agents you already have.
- You plan a paid hosted orchestration service: the BSL 1.1 license forbids that commercial use.
Example request
Launch a GPT agent for the backend, then a Grok agent for the frontend, and hand the result to an Opus agent for review.Limitations
Installed agent runtimes are required, and the CLI needs npm: on first use the skill installs `@backnotprop/orchestrator-cli`. The Business Source License 1.1 allows production use except for commercial hosted or managed orchestration services. On July 9, 2029 it converts to Apache 2.0. Model names in the README are examples; `orchestrator models <runtime>` gives the live list. Every launched agent spends its own provider limits and money.
How to disable. Delete the skill folder from the agent skills directory and run `npm uninstall -g @backnotprop/orchestrator-cli`. Stop background tasks first with `orchestrator interrupt`.
FAQ
Which agents can Orchestrator launch?
Claude Code, Codex, Copilot CLI, Grok Build and Pi, plus the shell and custom runtimes described in a JSON configuration.
Do I need to install the CLI first?
No, on first use the skill runs `npm install -g @backnotprop/orchestrator-cli` itself when npm is available. You can run the command by hand too.
How do I pin which model does which work?
Edit `skills/orchestrator/PREFERENCES.md` or ask the agent to write the rules there. An explicit instruction in the current request outranks stored preferences.
What license does Orchestrator use?
Business Source License 1.1: production use is allowed except for commercial hosted or managed orchestration services. It converts to Apache 2.0 on July 9, 2029.
How do I see what the launched agents are doing?
`orchestrator ps --json --compact --active --brief` lists active tasks, and `orchestrator read <task-id> --wait` waits and prints the result. Stop a task with `orchestrator interrupt`.
Discussion
No questions or reviews yet.
Related
SkillsA skill with 25 commands to audit and improve the prompts, tools and agent designs of a project in Cursor, Claude Code and Codex
A skill that turns several Claude Code, Codex and Cursor windows into a team with a coordinator, shared registry and cross-review
A desktop app where Claude Code, Codex, Gemini and other agents work as a team of specialists in a shared project
A planner for Claude Code, Codex and OpenCode: one goal becomes a task plan and independent tasks run in parallel
multi-agents runs a team of coding agents on a task and measures whether it beat a single agent and what it cost.
The /codex-workflows skill: Claude Code writes a script, dozens of Codex agents run it, and the run shows on a map
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Repository stars | Main difference |
|---|---|---|---|
| Orchestrator (this card) | no | 119 | |
| Claw Orchestrator | no | 601 | offers one runtime with acceptance checks; Orchestrator launches already installed agents by model name |
| CLI Agent Orchestrator | no | 1,515 | the AWS supervisor hands tasks to specialists; here the calling agent decides who gets what |
README in short
Orchestrator runs inside the agent harness you already use. The CLI owns processes and task state, while the calling agent owns decisions, delegation and synthesis.
README badge
Original SKILL.md
--- name: orchestrator description: Use Orchestrator as a CLI-backed skill to delegate and coordinate work across Claude Code, Codex, Copilot, Grok, Pi, shell, and custom runtimes. Use when an agent should launch one or many sub-agents, choose runtimes or models, apply the user's orchestration preferences, inspect background work, collect results, resume sessions, or stop stale work. --- # Orchestrator Use Orchestrator to let the current agent coordinate other agents. The skill is the interface; the `orchestrator` CLI is the deterministic control plane underneath it. ## Start 1. Read `PREFERENCES.md` beside this file. Apply only non-comment content under `User Preferences`. `No preferences set.` means use judgment. 2. Follow an explicit instruction in the current user request before a stored preference. 3. Check the CLI with `orchestrator --help`. If missing and npm is available, install it with `npm install -g @backnotprop/orchestrator-cli`. 4. Run `orchestrator help --json --compact` for the current command contract. 5. Run `orchestrator doctor --json --compact` when runtime availability is uncertain. Choose only from `runtimeSummary.availableIds`. 6. Run `orchestrator models <runtime> --json --compact` before choosing an exact model value. Do not assume a runtime or model exists because it appears in an example. ## Preferences Preferences are routing policy for the calling agent. They may describe: - which runtime or model to use for a type of work; - which fallbacks to use and in what order; - when to fan out or keep work with one agent; - what to do when provider usage is exhausted. Use this precedence: 1. explicit instructions in the current request; 2. `PREFERENCES.md`; 3. live runtime and provider facts; 4. your best judgment. Map preference names to configured runtime and model values when unambiguous. If the mapping is consequential and unclear, ask the user once. Preferences do