Bridge

The bridge is a routing overlay, not a separate path. Hosted routing through zcouncil is the default for every surface; when @zcouncil/cli bridge start is running on your machine, the hosted router prefers your local subscription clients (ChatGPT, Claude Code) for any council member where they're configured. The decision is server-side; the bridge just advertises what's available.

Same tool calls. Same surfaces. Different backend for the model invocations.

Run it

First run prompts for auth. Keep the terminal open — closing it disconnects. Node 22 or newer.

What it changes

Without bridge	With bridge
Models route through zcouncil's hosted providers (charged via the configured upstream APIs).	Configured members route through your local ChatGPT / Claude Code clients (using your subscription quotas).

That swap is invisible to MCP, CLI, /chat, and SDK callers — every surface keeps the same tools and the same answer shape. The only thing that changes is where the model invocation runs.

Status

Settings → Bridge shows live connection status, identity (operator-set name), and per-account quota usage. Disconnect closes the WebSocket from the server side and the CLI exits with a clean code.

Only one bridge per token. If a second bridge start connects with the same token, the server rejects it with WebSocket close code 1008 duplicate bridge and the CLI exits with status 3 so systemd-managed instances stop instead of looping.

Failure mode

If the bridge process is down, or the local provider is unavailable, the hosted router falls back to its configured upstream automatically. Bridge-only members fail explicitly.