Agent backends

PwrAgent drives a coding agent — it isn’t one. The agent is a CLI you install and sign in to yourself, and PwrAgent is the desktop, the messaging surface, and the thread state wrapped around it.

Codex is the default and the recommendation. It’s the built-in backend, it’s what the first-run wizard sets up, and it’s the one every PwrAgent feature supports. If you’re getting started, install Codex and stop reading here.

The rest of this page is for when you want something else. PwrAgent also drives Gemini CLI, Grok Build, Kimi Code, and Qwen Code over the Agent Client Protocol (ACP) — a protocol for talking to a coding agent over stdio. Those four are third-party executables. PwrAgent discovers them, launches them, and mediates the filesystem and terminal requests they make through the protocol; it doesn’t ship them, sign in for you, or sandbox what they do internally outside those requests.

You pick one per thread, from the Provider control on the launchpad. Threads on different providers live side by side in the same sidebar.

Choosing a backend

The label in the second column is what you’ll see on thread chips and in the Provider picker. Settings uses the longer product names — Gemini CLI, Kimi Code, Qwen Code — because that’s what you go install.

Pick Codex unless you have a specific reason not to. Reasons people actually have:

• You already pay for one of the others. Each CLI authenticates to its own vendor with its own subscription or API key. PwrAgent never brokers that.
• You want a second opinion on the same repo. Fork a thread onto a different provider and compare.
• A model you want lives behind a specific CLI. Each agent reports its own model list; PwrAgent shows you whatever it advertises.

What each one needs installed

The first-run wizard’s AI Providers step shows these same commands with a copy button, per platform. Help → Replay Onboarding reopens it any time without resetting your settings.

Install the CLI, sign in to it once in your own terminal, then come back to PwrAgent and hit Refresh in Settings → AI Providers.

Codex

OpenAI’s coding agent. Sign in with your ChatGPT account after install.

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Homebrew (brew install --cask codex) and npm (npm install -g @openai/codex) work too. On Windows, the PowerShell installer is the recommended path.

PwrAgent also finds Codex from an installed Codex Desktop — see Settings → AI Providers → Codex for how discovery picks between sources and how authentication is shared.

Codex CLI docs →

Gemini CLI

Google’s terminal coding agent, with Google-account and API-key login options.

brew install gemini-cli

Or npm install -g @google/gemini-cli, which is the path on Linux and Windows.

PwrAgent launches Gemini with workspace trust pre-granted, because Gemini refuses to operate without it.

Gemini CLI docs →

Grok Build

xAI’s coding agent. The CLI opens a browser sign-in on first launch.

curl -fsSL https://x.ai/cli/install.sh | bash

On Windows: irm https://x.ai/cli/install.ps1 | iex.

Grok is the one provider PwrAgent can supply itself. Turn on Use managed PwrAgent Grok builds in Settings → AI Providers → Grok and PwrAgent downloads verified releases from pwrdrvr/grok-build and prefers the newest one for new threads. A manual path always wins over the managed build.

Grok docs →

Kimi Code

Moonshot AI’s coding agent. Run /login inside the CLI for OAuth or an API key.

curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash

Or npm install -g @moonshot-ai/kimi-code on Node.js 22.19 or newer.

• The official installer drops a standalone binary at ~/.kimi-code/bin/kimi and doesn’t add it to your PATH. PwrAgent checks that location anyway, so a Finder-launched app still finds it.
• On Windows, install Git for Windows first — Kimi uses its bundled Git Bash.
• If you ever installed the retired Python kimi-cli, PwrAgent detects the collision, tells you, and excludes those binaries from model discovery. They’re incompatible with current Kimi Code.

Kimi Code docs →

Qwen Code

Qwen’s coding agent. Run /auth after launch to pick ModelStudio, a third-party provider, or a custom one — Qwen’s own OAuth has ended, so there’s no “just sign in” path.

curl -fsSL https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen-standalone.sh | bash

Homebrew (brew install qwen-code) and npm (npm install -g @qwen-code/qwen-code@latest, Node.js 22+) both work. On Windows, restart your terminal after installing.

Qwen Code docs →

What differs between them

Everything PwrAgent owns — threads, worktrees, the sidebar, messaging, automations, the context rail, pricing — works the same whichever provider a thread is on. What differs is what the agent itself can do, and PwrAgent reports each agent’s answer rather than guessing.

Fast mode is a Codex control (it maps to Codex’s priority service tier — same model, faster scheduling) and doesn’t appear on the others.

A few of the columns deserve a sentence.

Access modes. On Codex, Default Access and Full Access are PwrAgent’s own controls — see Desktop → Access modes. ACP agents mostly ship their own runtime mode selector (Kimi surfaces Default / Plan / Auto / Yolo, for instance), and when an agent advertises one, PwrAgent defers to it completely rather than stacking a second, mirrored dropdown on top. Grok has no runtime selector of its own, so it gets PwrAgent’s Default Access / Full Access pair, and PwrAgent drives Grok’s always-approve control for you when you flip it.

Models and reasoning. Codex’s model list comes from Codex. Every ACP agent reports its own models, modes, and reasoning levels over the protocol, and the Provider / Model / Reasoning controls on the launchpad render whatever came back. Capability answers are cached, so opening Settings doesn’t launch five agents to re-ask.

Images. Most models take image attachments. A model that reports it can’t — or an ACP agent that advertises no image support — has the composer’s attachment path gated for that thread rather than failing at send time.

Environments. Codex environments are read from .codex/environments/*.toml in the project and run for every provider, not just Codex. Pick one on the launchpad and its setup hook fires before the first turn whichever agent you chose.

Managing providers

Settings → AI Providers is the one screen for all of this: Codex discovery and auth profile at the top, then one section per ACP agent. See Settings → AI Providers for the full walkthrough. The short version:

• Each provider section shows every binary PwrAgent found — PATH matches, well-known install directories, and any manual path you added — with a version chip and which one is currently in use. Use pins a different one.
• Enabled controls whether the provider appears in the Provider picker at all. A disabled provider is never launched, which matters because probing an agent can kick off its browser sign-in flow.
• Manual path points a provider at an install discovery can’t see.
• Refresh re-runs discovery. Re-probe forces a fresh capability check instead of reusing the cache.

Not yet

Honest gaps in backend coverage today:

• No PwrAgent-managed install for anything but Grok. Every other provider is “install the CLI yourself, then Refresh.” There’s no in-app installer, and the older registry-driven Review install flow is gone.
• No cross-provider thread migration. A thread stays on the provider it was created with. To try the same work on another agent, fork the thread and pick a different provider on the fork.
• Steering and managed review are Codex- and Grok-only (managed review adds Kimi). Gemini and Qwen threads don’t offer either.
• Execution mode is inert on most ACP agents. Where an agent doesn’t expose an approval-policy control PwrAgent can drive, the Default / Full Access distinction doesn’t reach it.

See also

• Settings → AI Providers — the screen where discovery, pinning, and enabling live.
• Desktop → Per-thread settings — choosing a provider, model, reasoning, and access mode per thread.
• Desktop → Codex environments — setup hooks and quick commands, which run for every provider.
• Driving an agent from a messenger — the messaging-side New Thread starter also carries the Provider picker.