[Bug]: Claude Opus 5.5 rejected as old client on stable 0.0.42 despite standalone CLI 2.1.280

[maheshrijal]

Update: resolved by upgrading CLIProxyAPI

After filing, we traced a more direct cause: CLIProxyAPI 7.3.12 used the older Claude baseline. Stable CLIProxyAPI 7.3.15 explicitly updates that baseline to 2.1.280 (https://github.com/router-for-me/CLIProxyAPI/releases/tag/v7.3.15).

We upgraded only the proxy to 7.3.15, preserving its configuration and credentials. T3 remains stable 0.0.42. A standalone Claude Code 2.1.280 no-tools request for claude-opus-5-5[1m] through the proxy returned PROXY_OK, exit 0, with CLAUDE_AGENT_SDK_VERSION=0.3.260 and CLAUDE_CODE_ENTRYPOINT=sdk-ts set. This is not yet a full T3 UI reproduction, but the result strongly points to the proxy baseline rather than T3's bundled SDK. The original suspected T3 diagnosis below should not be treated as confirmed.

---

Before submitting

• I searched existing issues and did not find a duplicate.
• I included details to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Observed on a Linux ARM64 remote server:

1. Run T3 Code stable 0.0.42 as a systemd user service.
2. Have standalone Claude Code updated to 2.1.280 (claude --version verified).
3. Use the Claude provider configured through CLIProxyAPI, with ANTHROPIC_BASE_URL=http://127.0.0.1:8317 and proxy authentication configured in the user Claude settings.
4. Select Claude Opus 5.5 (claude-opus-5-5[1m]) and send a message.
5. The turn fails with the older-client error below and eventually “Claude gave up after repeated API errors.”

This is the observed configuration, not yet a minimal reproduction without the proxy. Direct Anthropic authentication and a fresh empty userdata directory have not been tested.

Expected behavior

A supported model should run with the updated Claude installation, or T3 should clearly identify an incompatible bundled/runtime version before starting the turn. The error should point to the component that actually needs updating.

Actual behavior

The API identifies the request as Claude Code 2.1.258 even though the standalone CLI reports 2.1.280. Repeated retries fail with the same version requirement.

Impact

Major degradation or frequent failure: affected Claude model turns cannot run. This does not establish that other models/providers fail.

Version or commit

T3 Code stable 0.0.42.

Environment

• Remote server: Linux aarch64 (Ubuntu 24.04).
• Background service: systemd user service.
• Client: T3 desktop on macOS, accessing the remote server through Tailscale HTTPS.
• Standalone Claude Code: 2.1.280, verified during investigation.
• Model: Claude Opus 5.5, 1M context.
• Claude requests use CLIProxyAPI on loopback. The proxy is a possible contributing factor; this has not been isolated from it.

Logs or stack traces

API Error: 400 Claude Code 2.1.258 does not support this model; version 2.1.280 or newer is required. Run 'claude update', or update the Claude desktop app, then try again.

Claude gave up after repeated API errors.

Investigation and recovery performed

• The active service was confirmed to select T3 0.0.42.
• The installed 0.0.42 executable contains CLAUDE_AGENT_SDK_VERSION = "0.3.260".
• After the failure, the service was stopped and userdata backed up. The old runtime was moved aside, and stable 0.0.42 was freshly downloaded using the official https://t3.codes/install.sh installer, including its release checksum verification. The service was installed with t3 service install.
• The fresh stable executable still contains the same SDK version string. The service is enabled/active, the frontend responds, and the retained SQLite database passes its integrity check.
• A new model request after the clean reinstall has not yet been independently verified. The identical bundled SDK alone is not proof of a post-reinstall reproduction.

The bundled SDK/client-version interaction is a suspected cause, not a confirmed diagnosis. We have not traced which component sets the version seen upstream or ruled out proxy header handling.

Related reports

• feat(models): add Claude Opus 5.5 #13087 documents the same model minimum-version rejection (closed, unmerged PR).
• feat(server): flag incompatible provider versions from the model manifest #13131 proposes provider compatibility warnings (closed, unmerged PR).

Neither appears to report this exact mismatch between the standalone CLI version and the version identified by the API.

Workaround

No verified model-level workaround yet. Prefer to remain on stable rather than preview. Reinstalling restored a clean supported installation, but did not change the bundled SDK version.

Report prepared with assistance from a coding agent; observed error supplied by the user and installation/version details checked on the affected server.

[maheshrijal]

Confirmed resolved in the T3 UI after upgrading CLIProxyAPI from 7.3.12 to 7.3.15. T3 remains on stable 0.0.42, with the same bundled SDK and retained session data.

This was an outdated proxy compatibility baseline, not a T3 bug.
CLIProxyAPI 7.3.15 updates its Claude baseline to 2.1.280; upgrading the proxy resolved the model rejection.

[juliusmarminge]

Triage

Not a confirmed T3 defect. The version in the API error does not match anything T3 0.0.42 sends.

Stable 0.0.42 pins @anthropic-ai/claude-agent-sdk 0.3.260. That package’s claudeCodeVersion is 2.1.260, which is the string CLAUDE_AGENT_SDK_VERSION = "0.3.260" inside the executable corresponds to. The API text is Claude Code 2.1.258, not 2.1.260 and not 0.3.260. Reinstalling stable cannot change that string, and a newer T3 build would not either: main is on SDK 0.3.276 (parity 2.1.276).

On Linux the Claude session does not use the SDK’s bundled binary. resolveClaudeSdkExecutablePath returns the configured binary unchanged, and the adapter passes it as pathToClaudeCodeExecutable. The health check that decides whether Opus 5.5 is allowed is claude --version on that same binary. Opus 5.5 is not in the 0.0.42 bundle; it arrived on main in #13094 with minVersion: 2.1.280 and is picked up through the remote manifest. A probed CLI of 2.1.280 passes that check, so T3 starts the turn. Claude gave up after repeated API errors. is only the generic terminal_reason: api_error line. The 400 Claude Code 2.1.258… text is the upstream error the CLI already returned.

That 2.1.258 matches CLIProxyAPI’s current default Claude fingerprint, not T3:

# claude-header-defaults:
# user-agent: "claude-cli/2.1.258 (external, cli)"

Their config comment says verified CLI / sdk-cli / VSCode requests keep their own shape only when the Claude Code version, package version, and runtime version exactly match that baseline. Unmeasured versions fall back to it. A real 2.1.280 CLI pointed at ANTHROPIC_BASE_URL=http://127.0.0.1:8317 is an unmeasured client, so the proxy advertises claude-cli/2.1.258 and Anthropic rejects Opus 5.5, which requires 2.1.280. The same request outside the proxy would not produce this number.

#13087 and #13131 are closed, unmerged PRs (model entry, and a general “CLI too old” warning). Neither is this mismatch. The model entry landed separately as #13094.

What would change this

1. From the systemd user service environment (not an interactive shell), run claude --version and claude -p --model claude-opus-5-5 with the same ANTHROPIC_BASE_URL. If that fails with 2.1.258, T3 is not involved.
2. Repeat one T3 turn with the proxy unset (direct Anthropic). If that succeeds, the proxy fingerprint is the cause.
3. In CLIProxyAPI debug logs, the outbound User-Agent on the failing request. A fallback to claude-cli/2.1.258 confirms it.

Proxy-side fix is to measure the real 2.1.280 client and update claude-header-defaults (user-agent, package version, and runtime version together), or stop rewriting unmeasured clients. Updating T3 or the standalone claude binary does not change that fallback.