DEV Community

Ordewell
Ordewell

Posted on

Why I stopped choosing one coding agent — and route each task to the one that fits

Disclosure up front: I built the tool described here. Free and Apache-2.0;
the point of this post is the design thinking, not a purchase.

Most agent tooling assumes you've picked a vendor. You're a Claude Code shop or
a Codex shop or a Cursor shop, and everything you run is that one thing. But
that assumption was never true for me — Codex is better at some tasks, Claude
Code at others, and I wanted a single plan that could use both without me
shepherding each step by hand.

This post is about the design decision behind letting one plan hand work to
different agents — and what it takes to make that safe.

A plan as a portfolio decision

The tool starts the same way each time: a goal in, a planner reads the repo
read-only, and an ordered list of tasks comes back. What's different is that
each task carries its own runner, model, thinking effort, and mode. The planner
makes one portfolio decision across the whole plan — a security refactor and a
README update should not get the same model, let alone the same agent — and
shows you every assignment before anything runs. You can change any of it.

That's the part worth dwelling on: per-task routing as a first-class feature,
decided in the open, rather than "pick one agent and hope."

Adding an agent is a plugin manifest, not a fork

The barrier that usually stops multi-agent setups is that wiring in a second
agent means invasive code. Here, adding an agent is a small plugin manifest, not
a code change. Claude Code, Codex, and OpenCode ship built-in; Aider or your own
CLI is just another manifest. The planner reads each runner's catalog, so a
task's mode and model re-derive from what that runner can actually spawn — you
can't configure a task into a runner that can't run it.

The safety boundary that makes mixed plans viable

Routing work across agents raises an obvious question: what stops the planner
from doing damage in your repo? Two answers, both deliberate.

First, the planner can't write. Research commands are lexed the way a shell
would lex them and classified per segment; the write tier returns refused before
any approval prompt exists, so there's no "allow once" to click through.
Mutation belongs to the runners.

Second, completion is evidence-based. A task is done only when its unique
completion marker appears in the runner's output, exit code retained separately.
No agent grades its own work — the marker and the exit code agree, or it fails.

Honest limits

The planner is an LLM and occasionally produces a bad plan — the argument for
this design is that you see the bad plan before a single execution token is
spent. Also, mixing runners means you hold the subscriptions for whatever you
mix: it rides the Claude subscription you already have for Claude Code, the
Codex subscription for Codex. No extra API key, but also no free ride for a
runner you don't already pay for. And the TUI needs tmux (WSL on Windows); the
CLI and VS Code extension don't.

Try it

npm install -g ordewell && ordewell
Enter fullscreen mode Exit fullscreen mode
  • GitHub: github.com/ordewell/ordewell
  • Apache-2.0, free.

One question I'd genuinely like input on: is per-task model routing useful, or a
knob nobody touches? Curious what multi-agent people think.

Top comments (0)