bug: every second request fails with 400 "The requested model is not supported" using openai proxy + gpt-5.4 & opus 4.6

[mardausdennis]

Affected area

Provider integration

What broke?

When using CCS with Provider: openai (proxy) and Model: gpt-5.4, roughly every second request fails with a 400 provider error saying the requested model is not supported.

The pattern is weird because the next request often works again, then the following one fails again. In practice it feels like alternating success and failure rather than a fully broken configuration.

This makes normal multi step workflows unreliable.

Reproduction steps

1. Configure CCS to use openai (proxy) with model gpt-5.4.
2. Trigger multiple consecutive requests.
3. For example, let it:
   1. create a new file
   2. edit that file
   3. perform another edit or follow up action
4. Observe the request results.

In my case, one request often succeeds, the next fails with a 400, then the next succeeds again.

Expected behavior

All valid consecutive requests should succeed when using the same configured provider and model.

If openai (proxy) with gpt-5.4 or claude-opus-4-6 is supported, repeated requests in the same task should be handled consistently without alternating failures.

Actual behavior

Requests appear to fail in an alternating pattern.

Typical observed behavior:

1. first request works
2. second request fails with 400
3. third request works
4. fourth request fails with 400

The error shown is:

400
OpenAI completion error: 400 The requested model is not supported.

This happened during normal file operations in Kilo Code, such as creating and editing test-capabilities.txt.

CCS version

v7.55.0

Operating system

Windows

Environment details

No response

Logs, screenshots, or terminal output

Before submitting

• I searched existing issues first.
• I removed secrets and private data from logs/screenshots.
• I can still reproduce this on the latest released or dev build.

[mardausdennis]

Its an issue with CLIProxyAPI

[kaitranntt]

Traced the alternating 400 model not supported behavior to CLIProxyAPI routing, not the CCS wrapper itself.

Root cause:

• model-support failures coming back as 400 invalid_request_error were being treated like terminal request-shape errors, so fallback to another auth / pooled upstream stopped too early
• the bad auth-model path could stay immediately eligible for later picks, which makes hidden rotation show up as fail/succeed/fail/succeed

I have a local upstream patch + regression coverage for that path. I am not marking this released yet because CCS still needs the fixed CLIProxyAPI binary path to be adopted after the upstream change is available.

[kaitranntt]

Upstream tracking is now live:

• CLIProxyAPI issue: bug: model-support 400/422 can cause alternating fallback failures router-for-me/CLIProxyAPI#2221
• CLIProxyAPI PR: fix: fall back on model support errors during auth rotation router-for-me/CLIProxyAPI#2222

That upstream PR contains the validated routing fix for the alternating model not supported behavior.

[kaitranntt]

Upstream update: router-for-me/CLIProxyAPI#2222 has been refreshed on commit ea3e0b71 to address the review feedback. That update now covers pooled alias fallback state, ExecuteCount parity, the pre-first-byte stream auth-rotation edge case, and the retry-budget edge case for fully blocked pools. Full upstream verification on the PR branch passed with go test ./....

[kaitranntt]

Retagging this as upstream-blocked.

The failure pattern was already traced to CLIProxyAPI routing, and the upstream tracking links are in this thread (router-for-me/CLIProxyAPI#2221 / #2222). I am keeping the issue open here so CCS can track adoption once the upstream fix path is settled.