Allow custom ANTHROPIC_BASE_URL / model provider in the managed app (not just raw CLI)
Is your feature request related to a problem? Please describe.
The Claude Code CLI already supports pointing at any Anthropic-API-compatible endpoint via ANTHROPIC_BASE_URL / ANTHROPIC_AUTH_TOKEN / ANTHROPIC_MODEL (documented by third-party providers like Moonshot's Kimi). This works well in a plain terminal session.
However, the managed/GUI app experience does not expose this same flexibility. As a non-developer user who occasionally hits my Claude usage limits, I wanted a lightweight way to fall back to a cheaper/alternative model provider for low-stakes work (transcription, formatting, drafts) while keeping Claude for everything else, without losing my current conversation context.
Describe the solution you'd like
Some way to switch the active model provider for an existing/managed app session, either:
- A /model (or new /provider) option that accepts a custom base URL + model string, scoped to the current session only, or
- Official support for carrying over a full conversation transcript across a provider switch, inside the managed app itself (currently this only reliably works via the raw CLI's local session storage + claude --continue).
Describe alternatives you've considered
I built a workaround: two custom slash commands (/kimi-on, /kimi-off) that toggle the relevant env vars in ~/.claude/settings.json globally on my machine, plus claude --continue in a terminal to resume the same session under the new provider. It works, but it's global (affects every Claude Code window on the machine, including scheduled automations) and requires closing/reopening windows to take effect — it can't swap the provider live inside an already-open managed app session.
Additional context — a bug I hit while testing this
While the custom provider was toggled ON via settings.json and then OFF again, the managed app's "auto mode" tool-safety classifier got stuck trying to reach the custom model (kimi-k3[1m]) and returned "<model> is temporarily unavailable, so auto mode cannot determine the safety of <tool> right now" for every state-changing tool call (Write, Bash/PowerShell), even though:
- The main conversation model itself kept responding normally as the original Claude model the whole time.
- ~/.claude/settings.json had already been fully reverted (verified by reading the file directly — no Kimi-related keys left).
- Closing and reopening the app window did not clear the stuck state; only the underlying session eventually recovered on its own after a while.
This suggests the auto-mode classifier's model resolution is cached somewhere independent of settings.json, tied to the session rather than the process, and doesn't get invalidated when the provider config changes back. Worth checking, since it turned a reversible experiment into a temporarily broken session