Credentials and preflight

Orchestrating coding agents without a second API key

The first screen of most orchestrators asks for an API key. That is a design choice, not a law. An orchestrator can instead start the coding-agent CLI you already installed and signed into, hand it the goal, and never hold a credential of its own. The arrangement is worth understanding, because it decides what the tool can check before you type anything, and what it can only find out the hard way.

Disclosure: I build Ordewell, so what follows is how it does this rather than a survey. It is free and Apache 2.0. The same question applies to any tool that runs more than one agent, so the reasoning is useful even if you never install it.

Why the key question comes first

An orchestrator has to think somewhere. It plans, and for that it needs a model. There are two ways to give it one. It can call a model provider directly with an API key it stores, or it can start a coding-agent CLI that already knows how to reach a model because you logged it in.

The first is the common default, and it is easy to see why. One HTTP client, one key, one place to bill. The second is what you get if the orchestrator treats the agent as a process rather than a library. That is a harder thing to build, and it changes the shape of the tool in ways that show up in the first five minutes.

What "no extra key" means in practice

Ordewell's planner is a coding-agent CLI. It spawns claude, codex or opencode over stdio and speaks to it turn by turn. The credential is the CLI's own: the login or the key you already gave it. Ordewell never reads it, never stores it, and has nothing to rotate.

A provider API key still works if you prefer that route. Then the planner runs against the provider directly and the CLI is only used for execution. The point is that the key is optional rather than a toll gate on the front door.

Either way the planner stays read-only. It reads the repository, asks questions, and writes a plan. Commands that would change your working tree are refused, because planning and doing are separate jobs and mixing them is how an agent ends up editing files before you have seen what it intends.

The preflight, and what it can honestly know

Before you type a goal, the picker checks each runner. The check is one command, the same one you would type yourself:

claude --version
codex --version
opencode --version

A runner whose binary answers is offered. A runner whose binary is missing is greyed out with the reason attached, in plain words:

claude is not installed or is not on PATH.

That is the whole preflight, and the restraint is deliberate. What it cannot know is whether your login is still live. Answering that question honestly would mean spending a turn on it, which is exactly what a preflight exists to avoid. So an expired session is not predicted. It surfaces on the first turn, as the agent's own error text, in the place where it actually bites.

A preflight that pretended to be deeper would be worse than this one. It would either burn a request at picker time or report a health it never verified, and a confident wrong answer is more expensive than an admitted gap.

The detail worth knowing even if you never use this

On Windows, a CLI is often a .cmd shim rather than an executable. Running it through a shell works, because the shell does the extension lookup. Starting it directly as a process does not, because the process creation call performs no such lookup. So a runner can look healthy in the picker and then die on the first turn with a bare ENOENT and nothing to act on.

The fix is to ask the second question separately. Ordewell probes the binary for a version and probes spawnability as its own check, and when they disagree it refuses the runner with a reason that names the two documented remedies: reinstall with the CLI's own installer, or put its install directory on PATH.

The general lesson is worth carrying to any tool that shells out. "It works in my terminal" and "I can start it as a process" are two different questions, and a check that answers only the first will pass a runner that cannot run.

Which agents can plan

Today only Claude Code, Codex and OpenCode carry a planner transport, so those three are the ones offered as planners. Other runners can still execute the tasks in a plan, each with its own model and mode. The distinction matters when you read a claim like "supports any agent": executing many is a much easier bar than planning with one.

Honest limits

• A credential you do not manage is one you cannot fix from here. If the CLI is logged out or its plan has lapsed, the fix lives in the CLI, not in the orchestrator. You get the agent's error text, not a re-auth button.
• Presence is not health. The preflight proves a binary answers a version flag. It says nothing about whether the first real turn will succeed.
• The planner is bounded by that CLI. Its model catalog and its capabilities set the ceiling. A key-based planner is a different ceiling, not a higher one by default.
• Keys are still supported, and still your problem. If you route the planner through a provider API key, you own a credential and a bill again. That is a trade, not a downgrade.
• Three planners is a short list. A runner with no planner transport can execute but not plan, and there is no promise here about when that changes.

Source and design notes

Everything above is in the repository rather than recalled: RunnerInstallation.ts (the version probe, the spawnability check, the greyed-out reason), the README's credentials note, the design decision on coding agents as planners, and github.com/ordewell/ordewell.