Show HN: Generate a Claude Code or Codex agent fleet from one HTML file

fleet-generator, a browser wizard, packs a multi-agent setup for Claude Code or Codex into a single download. The most useful part is a finding its author built into the output: the orchestrator ships as two separate agent files, because the prompt that suits a smaller model makes a capable model more expensive.

The tool itself is one HTML file with no install and no build step. You open it, answer the questions, and download a zip. Nothing is uploaded, since everything runs locally. The project’s GitHub README lists what comes out: a .claude/ directory with agent definitions (tools, model and skills for each role), skills that each role loads on demand instead of carrying them all the time, shell hooks for scope enforcement, push gating and logging, slash commands for the workflows you picked, a settings.json wired to those hooks, and an install script that puts it all in place. Drop it into a repository and the agents are there the next time you start a session. If you would rather read the output before running anything, sample_out/ holds a full generated bundle.

Why split one agent into three roles

The README calls a single agent that does everything the default and “the expensive way”: it keeps the whole task in one context, reasons about all of it at the top tier, and types every line itself. The fleet splits the work into three roles. An orchestrator breaks the task down and dispatches it, workers each implement one unit from a brief, and a reviewer judges the orchestrator’s output before it lands. Because the units are small, they can run on a smaller model and in parallel, and nothing merges until something that did not write it has looked at it.

The author’s measurements across live runs back this up. Orchestrators that dispatched their implementation work ran about 64% of their tokens in subagents. Those that typed the code themselves ran 0 to 32% in subagents, and cost three to four times as much for comparable work. The README is blunt about it: “The orchestrator writing the code itself is the failure of that job, not a shortcut to it.”

Underneath, this relies on how Claude Code subagents already work: each one runs in its own context window with its own system prompt and tool access, and only a summary goes back to the main conversation. Delegating does not make the tokens free, though. Anthropic’s Claude Code documentation says a subagent’s requests count toward the same usage limits as the main conversation. So the savings likely come from cheaper models doing the bulk of the typing and from a smaller orchestrator context.

Which model gets which tier

The generated fleet does not put every agent on the same model:

• Reviewer, top tier: one pass over a finished diff, which is cheap, and it is the only thing between a plausible-looking change and your main branch.
• Orchestrator, top tier: pays for itself if it dispatches. If it types the code itself, this is the most expensive arrangement possible.
• Workers, mid tier: their brief contains everything they need, so a more capable model buys less here than anywhere else.

Anthropic’s documentation makes a similar point and lists routing tasks to “faster, lower-cost models like Haiku” among the benefits of subagents. The defaults live in a MODEL_TIERS constant near the top of the wizard’s script block. The tier split depends on Claude Code respecting the model each agent declares, and a model pin in agent frontmatter has dropped out across several releases, sending pinned agents to the session model.

Claude Code, Codex or both

The target you pick is a matter of packaging. Claude Code reads a .claude/ directory and Codex reads an AGENTS.md at the repository root, but the instructions inside are the same either way. Picking Both emits both entry points from one source, and the generated AGENTS.md says the skill files are authoritative. The reasoning, in the README’s words: “Two descriptions of one fleet drift the moment either is edited, and saying which one wins is cheaper than reconciling them later.”

An optional checkbox adds a compact memory ritual for MOOTx01 through three commands: /prepare-for-compact, /start-clean and /recover-from-compact. With it, the agent writes its own handoff note before its context runs out, and the next session reads it back. The handoff and plan-capture skills ship either way. They are written against “your memory system”, so they work with any store, and better with a real one behind them.

Editing the wizard

There is no separate source tree. Everything sits in web/fleet-generator.html as JavaScript constants: ROLES for the agents, CLI_SKILLS and OPTIONAL_CLI_SKILLS for skill bodies, OPTIONAL_HOOKS for hooks, and MODEL_TIERS for the tiers. web/SPEC.md documents the structure and what has to stay consistent when you add a skill or a hook, and web/GUIDE.html walks through the wizard end to end, including three install paths depending on how much you want to decide up front. sample_out/ is a snapshot, so it falls out of date whenever the wizard changes and has to be refreshed by hand. A Python scaffold in src/fleet_generator/ is reserved and currently empty.

Anvil, a Swift CLI that parsed, linted, edited and deployed .claude/ libraries already on disk, used to live in the same repository. It shared no code with the wizard, had gone four months untouched, and was removed on August 16; it remains in the git history.

Two orchestrator files

The README argues that the model class decides the shape of the agent file. The bundle therefore keeps two versions of the orchestrator: a full procedural file for the smaller model and a lean one for the capable model. On just one identical task, run across eight configurations, the lean file halved the cost of the capable model and still passed. The same lean file made every smaller model more expensive and no better.

The author calls running a capable model against the full procedural file the most common setup error: “It reads as the safe choice and it is not.” In the README’s account, the model spends context on scaffolding it does not need, has less left for the actual work, and starts doing the work itself instead of dispatching it.