Epic: Bring your own subscription (BYOS) — run the user's own coding-agent CLI

[suleimansh]

Bring your own subscription (BYOS): run the AI on the CLI the user already pays for, instead of reselling tokens or asking for API keys.

Idea from Traycer (open source). They don't touch keys. They run the user's already-installed coding-agent CLI (claude-code, codex, gemini), which already holds that subscription's auth. Requests go straight through it.

Fits our existing seams with almost no new concepts. Two plug points already exist:

• Runner (where code executes) — the local runner spawns the CLI.
• ai-sdk ProviderAdapter (which model does the work) — a new cli/* adapter.

BYOS = a new adapter that spawns the user's CLI through the local runner, plus a small discovery step. Other providers are just more entries: ChatGPT via Codex CLI, Gemini via Gemini CLI, Claude via Claude Code. A plain web subscription with no CLI is not reachable this way.

Plan:

• Spike cli/claude-code adapter + PATH discovery (child)
• Widen discovery to codex + gemini CLI
• Provider config: where the pick + custom paths persist (framework config, TBD with Rom)

Open calls for Rom:

• go/no-go on the spike
• config location: framework config (env-paths/XDG) vs a separate dotfile

[suleimansh]

Read Traycer's repo. What's actually borrowable is less than it looks, worth knowing before we commit.

Open: the wire protocol, the provider-id schemas, the usage panel rendering, the polling policy. Closed: the host binary that does the actual reads and runs the CLIs. Their provider resolution has the shape we want (bundled / PATH / custom, persisted to provider-overrides.json) but no implementation, and there are no headless invocation args for claude, codex, or gemini anywhere in the repo.

So we get the schema and the credential model, not the brain.

The credential model is the part worth copying exactly: "ambient" is the user's own ~/.claude, read-only, never written to. "managed" is an isolated config dir Traycer owns. They never parse a token, they point the CLI at a config dir and let it authenticate itself. We should hold that same line.

#496 scope is unchanged then, we still have to find the invocation ourselves. The generation half I've already proven locally: claude -p, no API key set, clean JSON back with the result, a usage block, and a session id.

Still need two things from you before I build:

• go/no-go on the spike
• config location: framework config (env-paths/XDG, like the dashboard prefs) or a separate dotfile

[suleimansh]

Consolidated the whole thread into #516 (status + the 3 decisions I need from you). Easier read than the comments scattered across here, #496 and #298.