Concepts

Four words carry the whole CLI. Once they are clear, every command reads the same way.

The grammar never changes:

anypick use|run <client> --with <source|@preset>

Clients

A client is a CLI AnyPick knows how to configure. anypick clients lists them along with what it writes for each:

• claude — Claude Code (ANTHROPIC_* variables; isolated temp home on run)
• codex — Codex CLI
• gemini — Gemini CLI (GEMINI_API_KEY, GEMINI_MODEL)
• kiro — Kiro

Each client has an isolation manifest describing which files and variables belong to it, which is what makes anypick reset <client> and rollback exact rather than best-effort.

That list is about binding. Switching which account is live is broader, because AnyPick writes the tool’s own credential file rather than something only it understands — so anything else reading that file follows. claude covers the Claude Code CLI and its IDE extensions, and a gemini login may be the Gemini CLI’s OAuth or Antigravity’s.

Sources

A source is anything that can answer model requests.

Accounts are native logins that some other tool created — a Codex auth.json, a Grok credential, a Gemini OAuth token. AnyPick snapshots them so several can coexist, and restores the one you selected when you activate a binding. See Accounts.

Gateways are API profiles you configure yourself: an endpoint, a key, and optionally a model catalog. Nothing to log into. See Gateways.

Pools are an opt-in grouping of several accounts of one provider behind a single port, for failover. See Proxies.

Proxy Hub is a separate opt-in endpoint that can expose several saved accounts behind one local address and route by model (hub:default). See Proxies.

They are interchangeable at the --with boundary. A client neither knows nor cares which kind it got.

Bindings

A binding is a snapshot, not a reference. When you run:

anypick use claude --with grok/work

AnyPick resolves the source, picks model defaults, plans the activation steps, and records the result. Later edits to the account or preset do not silently rewrite that binding — which is the point. What ran yesterday still runs today.

There are three scopes, checked in this order when you run:

1. Ephemeral — run --with <source> applies for that launch only
2. Project — anypick link writes a binding scoped to the current directory
3. Global — anypick use writes the default

use   = set the global default (persistent)
run   = launch with the effective binding (ephemeral; never rewrites defaults)
link  = set a project-local binding

Inspect what is in effect with anypick current, optionally narrowed to one client.

Presets

A preset is the one editable thing. It is a named template you can reuse and revise:

anypick use claude --with grok/work --save work-stack
anypick use claude --with @work-stack
anypick preset show work-stack

There is no in-place preset editor: create a new snapshot with use … --save, or remove the old one with preset remove. Editing a preset would not rewrite bindings that were created from it anyway, because those are snapshots.

Activation

Turning a binding into a working client is a planned operation, not a series of side effects. AnyPick builds a step list, records mutating steps in an operation journal with backup paths, then executes. If a step fails, prior state is restored — client config, native auth, and any proxy it started.

--dry-run prints the plan without writing. --trace names the steps as they run, without secrets.

Non-interactive behavior

AnyPick never prompts when there is no TTY, and never guesses a source. use <client> requires --with or --current; without one it exits 2. This makes it safe in CI and in scripts. --no-input forces the same behavior on a TTY, and --json switches every command to machine-readable output.