Supported coding agents
4 min read
DevThrottle is vendor-neutral: it runs the coding agents you already use, side by side in one place, each in its own session on its own repository. You keep your own subscriptions and keys - running an agent through DevThrottle costs nothing.
First-class agents
Eight agents have a built-in driver. There is no waiting list and no gate: you install the agent's own command-line tool yourself, DevThrottle detects it, it appears as a row under Settings -> Agents, and from there it is one of the options in the New Session window. An agent whose tool is not installed on this machine simply is not in the list - that is true of every one of them, Claude Code included.
- Claude Code
- Pi
- Codex
- Gemini
- OpenCode
- Cursor
- Grok
- GitHub Copilot
Those are the names as they appear on the screen, in the order the list is built in. You can have more than one row of the same type - two Claude Code entries with different settings, say - and you choose the order they appear in.
What each one launches with
This is the real difference between them. A fleet that stops to ask permission on every tool call does not run, so a freshly detected agent is set up to work without stopping for approval wherever its command line offers a way to say so. Six of the eight do. Two do not, because their tool has no such option to give: Pi's approval flag only trusts files inside the project, and OpenCode keeps permissions in its own configuration file rather than on the command line.
| Agent | Recommended setting | What it adds to the command |
|---|---|---|
| Claude Code | Automatic | --permission-mode auto |
| Pi | Standard only | nothing - Pi has no full-permission option |
| Codex | Full access | --dangerously-bypass-approvals-and-sandbox |
| Gemini | Automatic (yolo) | --yolo |
| OpenCode | Standard only | nothing - OpenCode keeps permissions in its config file |
| Cursor | Automatic (yolo) | --force |
| Grok | Automatic (approve all) | --always-approve |
| GitHub Copilot | Automatic (yolo) | --allow-all |
Standard - the agent's plain command line, asking you for permission as it normally would - is selectable for every one of the eight, so nothing here is forced on you. Claude Code also offers Skip permissions (--dangerously-skip-permissions) as its own named choice; it is deliberately not the recommended one. Every flag above was read from the installed tool's own help output.
Any other CLI: the custom agent
The ninth type is called Custom, and it is the escape hatch: point DevThrottle at any command-line program and it runs as a session like the rest - terminal in the Director, cards, history. If a coding CLI exists, it can sit in the Director today, even before it gets a first-class driver.
What a custom session does not get is worth knowing before you pick it. These are not weaker versions of the features - they never run at all:
- No Director-assigned session id. The Director cannot name the session before it starts.
- No resume. There is no reopening a custom session where it left off.
- No Studio mode, the card view built on the agent's structured output.
- No turn detection, no wingman briefing, no transcript link. There is no output pattern to read, so the session never announces that it needs you and never links to a conversation.
Nothing breaks and nothing errors - the terminal, the repository, and the history are all there. The parts that read what the agent is saying are the parts that stay quiet.
What "supported" means here
A first-class driver knows the agent's install, launch, and interaction quirks, so the session's state - Working, Needs you, Ready, Background, Snoozed, Exited, Crashed - is read from what that agent actually does. Every screen you can watch a session on shows the same word for it. A custom session gets the states its terminal can prove and none of the ones that need the agent to be understood.