Launch Claude, Codex, OpenCode, and Pi through a LiteLLM gateway (lite CLI)

[hyrmedia-hector]

Problem

Many companies give engineers model access only through a LiteLLM gateway with SSO. Those users cannot use their direct Claude, Codex, OpenCode, or Pi subscriptions in T3 Code. Today they must configure each harness's gateway settings by hand, manage keys that expire, and they get no per-project spend tracking.

Proposal

Add an optional Launch through LiteLLM toggle to the Claude, Codex, OpenCode, and Pi provider instances. When it is on, T3 Code starts the harness through the LiteLLM CLI (lite <harness>, 1.102.0+) instead of directly.

• lite owns SSO sign-in, the key, its renewal, the gateway URL (LITELLM_PROXY_URL), and the harness gateway config. T3 Code stores no LiteLLM secret.
• The existing drivers stay the same. The instance binaryPath points at a per-instance shim that execs lite <harness>. This keeps the change at the adapter boundary.
• Sign-in uses the existing provider auth flow (lite login --pkce), with a paste-the-URL fallback for remote clients.
• Model lists come from the gateway (refreshed at most once a minute), so a user can, for example, run a GPT model on the Claude harness.
• Optional request tags per thread (repo:, project:, jira:, tool:) for spend tracking on the gateway.

Prior work

We built and use this in our fork, HYRMedia-LLC/t3code, kept in sync with upstream main:

• User guide: docs/user/providers-litellm.md
• Launcher core: packages/provider-core/src/server/litellm.ts
• Per-harness specs: apps/server/src/provider/liteLLMLaunchers.ts
• Auth retry for a key that expires mid-turn: apps/server/src/orchestration-v2/ProviderAuthRetry.ts

Hard parts we solved, which a maintainer would want to judge:

• A harness process keeps the key and model list it started with. An adapter launchGeneration (key expiry + gateway models) lets the session manager replace an idle process before its next turn and resume the thread. LiteLLM instances use per-thread sessions, also for Codex and OpenCode.
• A turn that fails on a gateway 401 before any side effect is sent again once.
• lite prints a routing line before protocol output, so parsers tolerate leading text, and --version probes bypass lite.
• Codex drops root -c overrides when a -c follows a subcommand ([Bug]: lite codex silently bypasses the proxy when -c is passed after a Codex subcommand (exec/resume/review) BerriAI/litellm#40651), so LiteLLM Codex rejects -c/--config in launch args. OpenCode with Server URL is rejected for the same reason (it would bypass the gateway).

Known limits: not on Windows yet; Pi does not send request tags yet.

Scope question

We can split this into small PRs if you approve the direction, for example:

1. Launcher + sign-in + gateway models for Claude.
2. Codex, OpenCode, Pi launchers.
3. Request tags (optional; can stay out).

Is this a direction you would accept, and in which scope? We will open no PR without your approval.

Related: #30930 (per-thread cost for Claude behind a LiteLLM proxy).

---

Drafted by Claude Opus 5.5 in Claude Code.