feature: extend account/instance isolation to API profiles + apply reasoning-model payload shaping on the account path

[KosmoCHE]

Context

Follow-up to #1458 / #1132. The reasoning-model payload shaping
(max_tokens → max_completion_tokens, drop metadata, drop reasoning_effort
when tools are present) and the new CCS_OPENAI_REASONING_MODEL=1 opt-in now
work correctly on the settings / API profile path
(settings-flow.js → resolveOpenAICompatProfileConfig → startOpenAICompatProxy).
This resolved the 400 for my api profile against an OpenAI-compatible gateway
that addresses a reasoning model by an obfuscated model ID. Thank you for that fix.

Problem 1 — the fix never reaches the account / instance path

Dispatch forks on profileInfo.type (dist/dispatcher/target-executor.js):

• api profiles are normalized to settings (profile-detector.js) → settings-flow.js,
  which starts the OpenAI-compat proxy and applies the shaping.
• account profiles → account-flow.js, which only does
  ensureInstance → set CLAUDE_CONFIG_DIR → execClaude and never starts the
  OpenAI-compat proxy.

Because the account path bypasses the proxy layer entirely, nothing reads
CCS_OPENAI_REASONING_MODEL and no payload shaping happens. The 400 from #1458
(Unsupported parameter: 'max_tokens' ... use 'max_completion_tokens' instead)
returns whenever an OpenAI-compatible gateway is driven through an account / instance.

Problem 2 — account / instance isolation is OAuth-only by design

The docs and create-command.js only support adding official Claude accounts
(interactive OAuth login, isolated tokens per instance). Driving an
OpenAI-compatible API through this path is effectively a short-circuit on my side —
it is not an officially supported configuration.

But the per-account instance isolation itself (CLAUDE_CONFIG_DIR separation,
isolated history / tokens) is genuinely valuable for API profiles too, independent
of whether the backend is Claude or an OpenAI-compatible gateway.

Suggestion

1. Make payload shaping reachable from the account path. When an
   account / instance is backed by an OpenAI-compatible endpoint, route it through
   the same proxy / shaping layer the settings path already uses, so both
   CCS_OPENAI_REASONING_MODEL and the auto-detection apply consistently across
   both dispatch flows.

2. Officially support API-backed accounts / instances. Allow ccs account
   style instance isolation for api profiles (baseUrl + key + model), not just
   official Claude OAuth. This would make "use an API endpoint as an isolated
   account / instance" a first-class, documented feature instead of a short-circuit.

Option 1 fixes the immediate correctness gap; option 2 addresses the underlying
design limitation. They are complementary.

Repro (account path)

1. Create an account / instance and point its isolated config at an
   OpenAI-compatible gateway whose ANTHROPIC_MODEL is a GPT-5.x / o-series
   reasoning model addressed by a non-gpt-5* (obfuscated) ID.
2. Run Claude Code through that account profile.
3. Observe 400 ... use 'max_completion_tokens' instead — the same failure as
   bug: OpenAI-compat proxy skips reasoning-model payload shaping when model is an opaque/obfuscated ID (generic-chat-completion-api) #1458, because account-flow.js never invokes the shaping proxy.
4. The equivalent api (settings) profile with CCS_OPENAI_REASONING_MODEL=1
   works, confirming the shaping logic itself is correct — it is simply not
   wired into the account path.

Environment

• CCS v8.2.0 (Homebrew, @kaitranntt/ccs@8.2.0)
• Profile: api / CCS_DROID_PROVIDER=generic-chat-completion-api,
  OpenAI-compatible ANTHROPIC_BASE_URL, obfuscated model ID
• OS: macOS (Darwin, arm64)

[HerShin5]

This distinction between “account isolation” and “provider transport” makes sense. It would be useful if API-backed instances were first-class, instead of only OAuth-backed accounts getting the isolation benefits.

For OpenAI-compatible gateways — OpenRouter, self-hosted proxies, or KiroForge (https://kiroforge.cloud/v1) — the important part is that the request still goes through the same proxy/shaping layer as the settings/API profile path. Instance isolation should ideally wrap config/history, not bypass the gateway adapter.

That would also make cost/fallback experiments much easier to compare across isolated profiles.

[kaitranntt]

Thanks for the precise breakdown; the two problems are genuinely separable.

Problem 1 (shaping not reaching the account path) is a bounded correctness gap. The account dispatch flow currently only sets CLAUDE_CONFIG_DIR and launches Claude; it never starts the OpenAI-compatible shaping proxy that the settings/API path uses, so CCS_OPENAI_REASONING_MODEL and the max_tokens to max_completion_tokens rewrite never run there. A focused fix would extract the proxy-start and shaping into a shared helper and invoke it from the account path when the isolated instance targets an OpenAI-compatible endpoint, with a regression test reproducing the 400.

Problem 2 (first-class API-backed accounts/instances with full baseUrl+key+model isolation, not just OAuth Claude) is a larger design change to instance creation and the dispatch fork, best tracked separately so it can get a short design pass.

Splitting keeps the immediate fix shippable without blocking on the broader design.