Agent backends

PwrAgent drives a coding agent — it isn’t one. The agent is a CLI you 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 sign in for you, or sandbox what they do internally outside those requests. Grok Build ships inside every PwrAgent installer. The other three you install yourself.

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

Provider	Chip label	What it is	Ships with PwrAgent?
Codex (default)	`OpenAI`	OpenAI’s coding agent. The built-in backend — every feature below works on it.	No — install the Codex CLI or Codex Desktop.
Gemini	`Gemini`	Google’s terminal coding agent, over ACP.	No — install Gemini CLI.
Grok	`Grok`	xAI’s coding agent, Grok Build, over ACP.	Yes — every installer carries a pinned build. You sign in with your own xAI account.
Kimi	`Kimi`	Moonshot AI’s coding agent, over ACP.	No — install Kimi Code.
Qwen	`Qwen`	Qwen’s coding agent, over ACP.	No — install Qwen Code.

The label in the second column is what you’ll see on thread chips and in the Provider picker. Settings heads each section with the longer product name — Gemini CLI, Kimi Code CLI, Qwen Code — because that’s what you go install. Grok’s section is headed plain Grok.

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. Grok Build is the exception: it’s already installed, and you only sign in.

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. You don’t need to install it. Every PwrAgent installer, on macOS, Windows, and Linux, carries a pinned build of Grok Build from PwrAgent’s pwrdrvr/grok-build repository. If there’s no other grok on the machine, new Grok threads run that copy. The CLI opens a browser sign-in on first launch, and you sign in with your own xAI account. PwrAgent never does that part for you.

The bundled copy changes only when PwrAgent itself updates. To run xAI’s own release instead, install it the usual way:

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

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

Which Grok runs. Settings → AI Providers → Grok → Detected paths lists every Grok binary PwrAgent found, and marks each one as a PwrAgent build or an xAI build. New threads use the first of these that exists:

A Manual path you set.
The binary you picked with Use.
A newer PwrAgent build it downloaded (below).
An installed grok on your machine.
The copy bundled with the app.

Newer PwrAgent builds between releases. Turn on PwrAgent build in Settings → AI Providers → Grok and PwrAgent downloads, verifies, and installs newer builds from pwrdrvr/grok-build, and new threads use the newest verified one. It’s off by default. On macOS and Windows it only installs builds that carry a valid platform signature.

Grok Build 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.

Provider	Steer a turn mid-flight	PwrAgent-managed `/review`	Access modes
Codex	Yes	Yes	PwrAgent’s Default / Full Access
Gemini	No	No	The agent’s own runtime modes
Grok	Yes	Yes	PwrAgent’s Default / Full Access
Kimi	No	Yes	The agent’s own runtime modes
Qwen	No	No	The agent’s own runtime modes

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:

Grok Build is the only agent that ships with PwrAgent. 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.