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

A browser wizard published on GitHub generates a working agent fleet for Claude Code or Codex from a single HTML file, on the finding that orchestrators which dispatch their implementation work run about 64% of tokens in subagents. There is no install and no build step: the file is opened in a browser, the wizard asks questions, and the download is a zip.

At a glance

• The generator runs entirely in the browser with nothing uploaded, and the download is a .claude/ directory holding agent definitions, skills, shell hooks, a settings.json wired to them, and an install script.
• Orchestrators that typed the code themselves ran 0 to 32% of tokens in subagents and cost three to four times as much for comparable work, according to the project's measurements across live runs.
• Reviewer and orchestrator sit on the top model tier while workers run mid, and the wizard ships two orchestrator files so a capable model reads a lean brief rather than full procedure.

The economics claim is the interesting part. A fleet is usually pitched as organisation, and here it is pitched as billing: the orchestrator's job is to spend tokens somewhere cheaper, and the file it reads decides whether it does. That reads as a warning for anyone who assumed that the strongest model plus the most detailed instructions is the safe default, since the measurements point the other way.

An orchestrator dispatches, workers implement one unit each, a reviewer judges

The generated bundle is a .claude/ directory containing agent definitions, skills that each role loads on demand rather than carrying always, shell hooks for scope enforcement, push gating and logging, slash commands for the workflows selected in the wizard, a settings.json wired to the hooks, and an install script. Nothing is uploaded; the wizard runs locally.

The three roles are an orchestrator that decomposes and dispatches the work, workers that implement one unit each from a brief, and a reviewer that judges the orchestrator's output before it lands. The write-up frames the split as a cost mechanism: units run on a smaller model, they run in parallel, and nothing merges without something that did not write it having looked.

The lean orchestrator file halved the cost of the capable model across eight configurations

The fleet does not put every agent on one model. The reviewer and the orchestrator sit on the top tier, since one pass over a finished diff is cheap and a dispatching orchestrator pays for itself, while workers run mid because their brief already contains everything they need.

A model class implies a file shape, so the generator keeps two orchestrator variants: the full procedural file for the smaller model and a lean one for the capable model. Measured on one identical task across eight configurations, the lean file halved the cost of the capable model and passed, while making every smaller model more expensive and no better.

Running a capable model against the full procedural file is described as the most common setup error: the model spends context on scaffolding it does not need and starts doing the work itself. Defaults sit in the MODEL_TIERS constant near the top of the wizard's script block.

Codex reads an AGENTS.md, Claude Code reads a .claude/ directory

Claude Code reads a .claude/ directory and Codex reads an AGENTS.md at the repository root, so the target is a packaging choice rather than a different fleet. Picking Both emits both entry points from one source, and the AGENTS.md states that the skill files are authoritative.

An optional checkbox adds a compact ritual for MOOTx01, with the commands /prepare-for-compact, /start-clean and /recover-from-compact, so the agent writes its own handoff before context runs out and the next session reads it back. The handoff and plan-capture skills ship regardless and are written against a generic memory system.

Everything is edited 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. There is no separate source tree, since the constants are the source, and web/SPEC.md documents what has to agree with what when a skill or hook is added, while web/GUIDE.html walks the wizard end to end across three install paths.

Anvil, removed in August The repository dropped swift/ on 16 August 2026. It held Anvil, a Swift CLI that parsed, linted, edited and deployed .claude/ libraries already on disk, shared no code with the wizard and had gone four months untouched, and it remains retrievable from git history. The Python scaffold under src/fleet_generator is reserved and currently empty, and sample_out/ is a snapshot that drifts when the wizard changes.