dispatch

Many CLIs, many quotas

I use several coding agent CLIs, each with its own plan and its own weekly limit. Every time I delegated work I had to remember which one still had room and which model name was current, and the names change often.

I wanted to say how hard the task is and let something else pick where it runs.

Tiers instead of model names

dispatch takes easy, normal, or hard and resolves it through an editable table of agent and model pairs. I did not build another coding agent: it wraps the CLIs that are already installed and returns a compact result, so the caller spends few tokens reading it.

Candidates are ranked by quota pace, the same linear expected-versus-actual idea CodexBar uses, with a weekly historical estimate once enough snapshots exist. When an agent fails or hits a rate limit, the run falls back to the next one, and a rate-limited agent sits in a one-hour cooldown. Writing runs get their own git worktree and branch, so parallel delegations do not collide, and sessions can be resumed across them.

I chose a CLI over MCP on purpose. An MCP server adds fixed context cost and long runs fight its timeouts, while every client already has a shell. Agents learn the tool from a skill that dispatch skill install writes into each agent's skills folder.

Watching it work

Bare dispatch opens a terminal UI that follows the repository's runs live: one card per delegation, a full-screen view of the agent's output as it is written, a statistics screen, and a learning screen. The statistics count only what dispatch itself ran, not my whole account, because I use these CLIs for other things too. The learning screen shows what a small per-tier classifier has learned about which runs fail verification, and it says so plainly while there are too few samples. A settings screen edits the config, the tier table, and subagent profiles in place, validating each value before it saves, with the whole file one keypress away in $EDITOR for anything bigger. Its Agents tab detects the CLIs on the machine and lets me register a binary path, so a CLI that is not on PATH can still be found.

Every run is verified against its base before it can merge. dispatch merge refuses a failed verification, checks for conflicts first, verifies again after merging, and records the outcome on the run.

It learns from use

Routing is not a fixed table. Every run is recorded with how it went and whether it passed verification, and dispatch learns from that history. A small classifier per tier, trained only on this machine with no LLM and no network, learns which kinds of tasks fail verification and can suggest a higher tier. It starts from simple rules, like bumping sensitive code up a tier, and the learning screen shows how far its own evidence goes, saying so plainly while the samples are few. Quota snapshots feed a pace estimate, and a rate limit puts that agent in a one-hour cooldown and moves it down the ranking. The suggestions never change a run on their own: they show up as a note.

Where it is now

It is a working v0.4.0: the adapters run, resume, and fall back, and I verified background runs, worktrees, and merges against a real repository. Routing can be steered with provider, model, effort, and priority filters and a persistent allow and deny policy, and dispatch route reports the plan a run would execute. dispatch update upgrades the binary in place (SHA-256 checked), and named subagent profiles (dispatch run --as reviewer) fix a role, tier, and soft agent preferences. Prebuilt binaries are published for macOS and Linux, but I only exercised the macOS arm64 one.

Quota is real only for the CLIs that expose it. The others have no official source, so for them the router learns from rate-limit errors instead of predicting. I have also not yet watched Claude Code drive it end to end, so the skill is written for that case but unproven there.