[BUG] warm throws error code 400

[Grelo4ka]

Bug Description
oc-codex-multi-auth warm triggers error code 400

Steps to Reproduce

1. run oc-codex-multi-auth warm

Expected Behavior
Small hello message sent from each account

Actual Behavior

- [0] gr4l....com: failed — Warm request failed: HTTP 400

Environment

• opencode version: 1.18.9
• Plugin version: 6.11.0
• Operating System: Arch Linux
• Node.js version: 12.0.1

Compliance Checklist
Please confirm:

• I'm using this plugin for personal development only
• I have an active ChatGPT Plus/Pro subscription
• This issue is not related to attempting commercial use or TOS violations
• I've reviewed the FAQ and Troubleshooting sections

[coderabbitai]

Coding Plan

Summary

root cause is behavioral, not a stale constant: warmAccountWindow (lib/accounts/warm-request.ts:162) only classifies 429 and dead-ends every other status, so an account not entitled to the warm gpt-5.4 body gets a hard HTTP 400 where live chat traffic would silently fall back.

add a 400 branch that detects model_not_supported_with_chatgpt_account and retries down the shared resolveUnsupportedCodexFallbackModel chain, reusing the exact recovery the live path already ships.

route the (possibly re-modeled) warm body through shapeBodyForModel + canonical reasoning/verbosity clamps so a lite-tier fallback doesn't reintroduce the #191/#192 reasoning.context 400.

pin all of it with new regression tests in test/accounts-warm-request.test.ts, since none currently cover 400 or fallback; note windows/node have no special path here, but per-account retry cost must stay bounded given warm.ts fans out concurrently.

Design Choices

Design Choice 1: what is the actual trigger for the 400, and how much of the live pipeline should warm adopt?

Options Considered:

1. bump WARM_MODEL to a newer/older constant. cheap, but exploration shows gpt-5.4 is the shared default and the trusted fallback landing point, so this just moves the failure and desyncs test/accounts-warm-request.test.ts:39.
2. add a 400 classification branch in warmAccountWindow that reuses the existing resolveUnsupportedCodexFallbackModel chain and retries the ping on the fallback model, and route the (possibly re-modeled) body through shapeBodyForModel so a lite-model fallback gets the correct wire shape.
3. fully replace buildWarmRequestBody with transformRequestBody + the live retry loop. most "correct" long-term, but drags tools/bridge/input-filtering machinery into a minimal ping and is a much larger blast radius.

Chosen Option: 2

Rationale: it mirrors the exact recovery behavior the live path already ships, keeps warm minimal, and closes the drift risk (lite-shape reasoning.context) without importing the full chat transformer. the exploration confirms WARM_MODEL = "gpt-5.4" has not drifted from normalizeModel()'s default (lib/accounts/warm-request.ts:26, lib/request/request-transformer.ts normalizeModel), so a blind model bump is not the fix. the most plausible cause is an account-level entitlement/shape rejection that the live path silently recovers from via resolveUnsupportedCodexFallbackModel but the warm path does not.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: teach the warm ping to survive a model-rejection 400

the goal here is behavioral parity with normal chat traffic: a 400 caused by the account not being entitled to the warm model should degrade through the same fallback chain instead of being surfaced as a hard failed. today warmAccountWindow only branches on 429 and throws generically on everything else (lib/accounts/warm-request.ts:162), so an entitlement 400 dead-ends. we add a 400-specific branch that reads the error code from the already-parsed body, and if it's a model-support rejection, retries the ping against the next model in the shared fallback chain.

Task 1: classify the 400 and detect model-support rejections

add explicit handling for response.status === 400 inside warmAccountWindow.

• update lib/accounts/warm-request.ts to add a 400 branch parallel to the existing 429 branch (before the generic throw at lib/accounts/warm-request.ts:162).
• reuse the existing bodyText + extractErrorCode machinery (already read before the status check for the 429 path) to pull the upstream error code; match it against model_not_supported_with_chatgpt_account the same way parseRateLimitReason inspects 429 reasons.
• for a non-model 400 (malformed/other), keep throwing Warm request failed: HTTP 400 with the parsed error code appended to the message so the per-account detail in lib/accounts/warm.ts is actionable instead of opaque.

Task 2: retry the ping through the shared unsupported-model fallback chain

when the 400 is a model-support rejection, walk the same chain the live path uses.

• import resolveUnsupportedCodexFallbackModel / DEFAULT_UNSUPPORTED_CODEX_FALLBACK_CHAIN from lib/request/fetch-helpers.ts into lib/accounts/warm-request.ts and iterate to the next candidate model when the current warm model is rejected.
• rebuild the ping for the fallback model (new body + createCodexHeaders({ model: <fallback> })) and re-send, bounded by the chain length so there is no unbounded loop; if the whole chain is exhausted, return a distinct classification (e.g. exhausted/failed with a no entitled warm model detail) rather than a bare HTTP status.
• keep the existing 15s AbortController timeout semantics per attempt; do not let the retry loop stack timeouts unboundedly (concurrency risk: warm.ts already fans out across accounts, so per-account retry cost must stay bounded).

Task 3: shape the fallback body correctly for lite models

the fallback chain can land on a gpt-5.6-* (responses-lite) tier, and the warm body is currently hand-built and never passes through shapeBodyForModel (lib/accounts/warm-request.ts:61), which is exactly the reintroduced-#191/#192 shape (missing reasoning.context: "all_turns", top-level tools/non-empty instructions) that upstream rejects with a second 400.

• route the warm body through shapeBodyForModel (from lib/request/fetch-helpers.ts) at serialize time for whatever model is actually being sent, matching the live path (lib/request/fetch-helpers.ts:807).
• also derive reasoning/text.verbosity for the fallback model via the canonical clamps (getReasoningConfig / resolveTextVerbosity in lib/request/request-transformer.ts) instead of the hardcoded { effort: "none", summary: "auto" } / verbosity: "low" so a fallback model that rejects none effort doesn't produce yet another unsupported_value 400.
• this makes createCodexHeaders' responses-lite header (already model-driven and correct via usesResponsesLite) consistent with the body shape for every model in the chain.

🤖 Prompt for AI agents

implement behavioral parity between the warm ping and the live chat fallback
path so a `400` model-entitlement rejection degrades gracefully instead of
surfacing as `failed`.

in `lib/accounts/warm-request.ts`, add a `400` branch in `warmAccountWindow`
parallel to the existing `429` branch, placed before the generic throw at
`lib/accounts/warm-request.ts:162`. reuse the existing `bodyText` +
`extractErrorCode` machinery to pull the upstream error code and match it
against `model_not_supported_with_chatgpt_account` (mirroring how
`parseRateLimitReason` inspects 429 reasons). for a non-model 400, keep throwing
`Warm request failed: HTTP 400` but append the parsed error code to the message
so `lib/accounts/warm.ts`'s per-account `detail` is actionable.

when the 400 is a model-support rejection, import
`resolveUnsupportedCodexFallbackModel` /
`DEFAULT_UNSUPPORTED_CODEX_FALLBACK_CHAIN` from `lib/request/fetch-helpers.ts`
and iterate to the next candidate model. rebuild the ping (new body +
`createCodexHeaders({ model: <fallback> })`) and re-send, bounding the loop by
chain length. if the whole chain is exhausted, return a distinct classification
(e.g. `exhausted`/`failed` with a `no entitled warm model` detail) instead of a
bare HTTP status. preserve the existing 15s `AbortController` timeout per
attempt without letting retries stack unbounded timeouts, since `warm.ts` fans
out across accounts concurrently.

route the warm body through `shapeBodyForModel` (from
`lib/request/fetch-helpers.ts`) at serialize time for whichever model is
actually being sent, matching the live path at
`lib/request/fetch-helpers.ts:807`, since the current hand-built body at
`lib/accounts/warm-request.ts:61` never passes through this and can hit the
reintroduced-#191/#192 shape mismatch (missing `reasoning.context: "all_turns"`,
stray top-level `tools`/`instructions`). also replace the hardcoded `{ effort:
"none", summary: "auto" }` / `verbosity: "low"` with the canonical
`getReasoningConfig` / `resolveTextVerbosity` clamps from
`lib/request/request-transformer.ts` so a fallback model rejecting `none` effort
doesn't trigger a second `unsupported_value` 400. ensure `createCodexHeaders`'s
model-driven responses-lite header stays consistent with the body shape for
every model in the chain.

Phase 2: lock the behavior with regression coverage

the exploration flagged that test/accounts-warm-request.test.ts has no 400 case and no fallback-retry case — only generic 401/500 throws — and hardcodes body.model === "gpt-5.4" at test/accounts-warm-request.test.ts:39. we add coverage so this recovery path can't silently regress the way the live path's reasoning.context did (guarded by test/gpt56-sol-wire-parity.test.ts:121).

Task 1: add warm 400-fallback regression tests

cover both the happy fallback and the exhausted-chain case.

• extend test/accounts-warm-request.test.ts with a fetchImpl that returns 400 + a model_not_supported_with_chatgpt_account body on the first call and 2xx on the second, asserting the retry hits the next chain model and returns opened.
• add a case where every model in the chain returns the model-support 400, asserting the final classification/detail (not a bare HTTP 400).
• add a case for a non-model 400, asserting it still throws but now carries the parsed error code in the message.
• if a fallback lands on a lite tier, assert the outgoing body carries reasoning.context: "all_turns" and empty top-level tools, mirroring test/gpt56-sol-wire-parity.test.ts so the shape fix is pinned.

Task 2: confirm the orchestrator + tool layers stay untouched

lib/accounts/warm.ts and lib/tools/codex-warm.ts mock at the status level and never see raw http, so they need no logic change — but we should confirm the new exhausted/detail values render sensibly in their summaries.

• verify test/tools-codex-warm.test.ts and test/chaos/accounts-warm-stress.test.ts still pass unchanged; if the new terminal classification introduces a status value they don't map, update the summary rendering in lib/accounts/warm.ts (currently it records any thrown message verbatim as failed).

🤖 Prompt for AI agents

add regression tests to pin the new 400-fallback behavior since none currently
cover 400 or fallback retries, and confirm downstream layers still work.

in `test/accounts-warm-request.test.ts` (currently hardcodes `body.model ===
"gpt-5.4"` at line 39), add: a `fetchImpl` returning `400` +
`model_not_supported_with_chatgpt_account` body on the first call and `2xx` on
the second, asserting the retry hits the next chain model and returns `opened`;
a case where every model in the chain returns the model-support 400, asserting
the final classification/detail is returned instead of a bare `HTTP 400`; a case
for a non-model 400, asserting it still throws but the message now carries the
parsed error code; and, if a fallback lands on a lite tier, assert the outgoing
body carries `reasoning.context: "all_turns"` and empty top-level `tools`,
mirroring the pattern in `test/gpt56-sol-wire-parity.test.ts` so the shape fix
stays pinned.

separately, verify `test/tools-codex-warm.test.ts` and
`test/chaos/accounts-warm-stress.test.ts` still pass unchanged since
`lib/accounts/warm.ts` and `lib/tools/codex-warm.ts` mock at the status level
and never see raw http. if the new terminal classification (e.g. `exhausted`)
introduces a status value these layers don't map, update the summary rendering
in `lib/accounts/warm.ts`, which currently records any thrown message verbatim
as `failed`.

Research

the warm feature is split three ways: lib/accounts/warm.ts is a pure orchestrator (skip/success/failure bookkeeping, no http), lib/accounts/warm-request.ts owns the actual POST /codex/responses ping plus status classification, and lib/tools/codex-warm.ts wires auth/account resolution into warmAccountWindow. the live chat path instead runs bodies through lib/request/request-transformer.ts (transformRequestBody, normalizeModel, getReasoningConfig) and lib/request/fetch-helpers.ts (shapeBodyForModel, and the unsupported-model fallback via DEFAULT_UNSUPPORTED_CODEX_FALLBACK_CHAIN / resolveUnsupportedCodexFallbackModel). createCodexHeaders (lib/request/fetch-helpers.ts:824) is shared by both paths, but the warm body-build (lib/accounts/warm-request.ts:61) and its status handling (lib/accounts/warm-request.ts:162) are completely decoupled from the transformer and the fallback chain.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

implement behavioral parity between the warm ping and the live chat fallback
path so a `400` model-entitlement rejection degrades gracefully instead of
surfacing as `failed`.

in `lib/accounts/warm-request.ts`, add a `400` branch in `warmAccountWindow`
parallel to the existing `429` branch, placed before the generic throw at
`lib/accounts/warm-request.ts:162`. reuse the existing `bodyText` +
`extractErrorCode` machinery to pull the upstream error code and match it
against `model_not_supported_with_chatgpt_account` (mirroring how
`parseRateLimitReason` inspects 429 reasons). for a non-model 400, keep throwing
`Warm request failed: HTTP 400` but append the parsed error code to the message
so `lib/accounts/warm.ts`'s per-account `detail` is actionable.

when the 400 is a model-support rejection, import
`resolveUnsupportedCodexFallbackModel` /
`DEFAULT_UNSUPPORTED_CODEX_FALLBACK_CHAIN` from `lib/request/fetch-helpers.ts`
and iterate to the next candidate model. rebuild the ping (new body +
`createCodexHeaders({ model: <fallback> })`) and re-send, bounding the loop by
chain length. if the whole chain is exhausted, return a distinct classification
(e.g. `exhausted`/`failed` with a `no entitled warm model` detail) instead of a
bare HTTP status. preserve the existing 15s `AbortController` timeout per
attempt without letting retries stack unbounded timeouts, since `warm.ts` fans
out across accounts concurrently.

route the warm body through `shapeBodyForModel` (from
`lib/request/fetch-helpers.ts`) at serialize time for whichever model is
actually being sent, matching the live path at
`lib/request/fetch-helpers.ts:807`, since the current hand-built body at
`lib/accounts/warm-request.ts:61` never passes through this and can hit the
reintroduced-#191/#192 shape mismatch (missing `reasoning.context: "all_turns"`,
stray top-level `tools`/`instructions`). also replace the hardcoded `{ effort:
"none", summary: "auto" }` / `verbosity: "low"` with the canonical
`getReasoningConfig` / `resolveTextVerbosity` clamps from
`lib/request/request-transformer.ts` so a fallback model rejecting `none` effort
doesn't trigger a second `unsupported_value` 400. ensure `createCodexHeaders`'s
model-driven responses-lite header stays consistent with the body shape for
every model in the chain.
===============================================================================

Task: 2

add regression tests to pin the new 400-fallback behavior since none currently
cover 400 or fallback retries, and confirm downstream layers still work.

in `test/accounts-warm-request.test.ts` (currently hardcodes `body.model ===
"gpt-5.4"` at line 39), add: a `fetchImpl` returning `400` +
`model_not_supported_with_chatgpt_account` body on the first call and `2xx` on
the second, asserting the retry hits the next chain model and returns `opened`;
a case where every model in the chain returns the model-support 400, asserting
the final classification/detail is returned instead of a bare `HTTP 400`; a case
for a non-model 400, asserting it still throws but the message now carries the
parsed error code; and, if a fallback lands on a lite tier, assert the outgoing
body carries `reasoning.context: "all_turns"` and empty top-level `tools`,
mirroring the pattern in `test/gpt56-sol-wire-parity.test.ts` so the shape fix
stays pinned.

separately, verify `test/tools-codex-warm.test.ts` and
`test/chaos/accounts-warm-stress.test.ts` still pass unchanged since
`lib/accounts/warm.ts` and `lib/tools/codex-warm.ts` mock at the status level
and never see raw http. if the new terminal classification (e.g. `exhausted`)
introduces a status value these layers don't map, update the summary rendering
in `lib/accounts/warm.ts`, which currently records any thrown message verbatim
as `failed`.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

🔗 Related PRs

#185 - feat(cli): add warm standalone command — token-free direct warm-up (#182) [closed]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Grelo4ka]

Hi @ndycode it seems like the commit hasn't fixed the issue:

- [0] gr4l....com: failed — Warm request failed: HTTP 400: {"detail":"Unsupported content type"}

[ndycode]

Reopening — you're right, @Grelo4ka, and thanks for pasting the full error. That extra {"detail":"Unsupported content type"} is what cracked it.

The 400 was never about the model. warm was sending its request body without a content-type header, so fetch fell back to its default for a string body, text/plain;charset=UTF-8, and the backend rejected it before it ever looked at the model.

It only affects warm. The live request path wraps opencode's own request object, which already carries a JSON content type, so normal traffic was never touched — warm is the one place that builds its headers from scratch.

The reason my first attempt went after gpt-5.4 instead: the old code read the error body but threw with just the status, so all I had to go on was a bare HTTP 400, and the recently-retired model was the best guess available. Ironically the v6.11.1 change is what surfaced the body and gave away the real cause. The gpt-5.5 switch and the fallback chain stay — they were worth doing, just not what was breaking you.

Fix is up in #212, with a regression test that fails on 6.11.1 with exactly expected 'text/plain;charset=UTF-8' to be 'application/json'.

I'll ship a patch release shortly. Would appreciate it if you'd confirm on the published build before I close this again — I'd rather not close it on you twice.

[Grelo4ka]

Wait, GPT 5.5? I think 5.6 Luna would be better @ndycode - it’s way cheaper for just a warm request than 5.5

[ndycode]

Confirmed on my end, @Grelo4ka — I reproduced your exact error locally and verified the fix against the real API.

Same request body, same account, only the content type differing:

	content-type sent	Result
v6.11.1 (what you're on)	text/plain;charset=UTF-8	400 {"detail":"Unsupported content type"}
with the fix	application/json	200 OK

The first row is your error, character for character. warm was omitting the header, so fetch fell back to text/plain for the body and the backend refused it before ever reading the model.

It reproduced on a Pro account that is fully entitled to gpt-5.5, which confirms this had nothing to do with your account or your plan — warm has been broken for everyone on 6.11.1 and below. Nothing to do on your side.

Fix is in #212, verified end-to-end (warmAccountWindow returns opened). I'll get a patch release out and ping you here — would still appreciate a confirmation on the published build before I close this.

[ndycode]

Released in v6.11.2 — @Grelo4ka this should be sorted now.

npm install -g oc-codex-multi-auth@6.11.2
rm -rf ~/.cache/opencode/packages/oc-codex-multi-auth*
oc-codex-multi-auth warm

The cache line matters — opencode caches plugin packages, so without it you may keep loading 6.11.1.

I verified end-to-end by installing 6.11.2 straight from npm and running its own published code against the live API: warmAccountWindow returns opened, where the same request on 6.11.1 returns 400 {"detail":"Unsupported content type"}.

Leaving this open until you confirm. Thanks for pushing back after the first attempt — the fix I shipped in 6.11.1 was aimed at the wrong layer, and that second report with the full error body is what actually located it.

[ndycode]

@Grelo4ka on the 5.6 Luna idea — I owe you a proper answer, sorry for skipping past it while chasing the 400.

The instinct is right (a warm ping should cost as little as possible), but Luna would land worse on all three counts. Checked against the shipped code:

1. Luna can't take effort: "none", and 5.5 can.

gpt-5.5        reasoning= {"effort":"none","summary":"auto"}   responses-lite= false
gpt-5.6-luna   reasoning= {"effort":"low","summary":"auto"}    responses-lite= true

The transformer clamps the 5.6 tiers up to "low". So a Luna ping actually generates reasoning tokens where the 5.5 ping generates none. For a request whose entire body is "warm ping", that effort floor dominates the cost far more than the per-token rate does — the cheaper sticker price gets spent on reasoning we don't want.

2. Luna is limited-preview, so for many accounts it costs two requests.

The chain is gpt-5.6-luna -> gpt-5.5. Accounts outside the preview get model_not_supported_with_chatgpt_account, warm falls back, and those users pay a rejected request plus the 5.5 request they'd have sent anyway. gpt-5.5 is the generally-available anchor every 5.6 tier degrades toward, which is exactly why it's the entry point.

3. Luna rides the responses-lite path, which is where #191/#192 came from (reasoning.context="all_turns" omissions returning 400). That's real failure surface to take on for something whose only job is to start the usage window.

There's also a question I genuinely don't know the answer to: whether a 5.6-tier request opens the same rolling window limits reports, or a separate pool. If it's separate, warming with Luna would open the wrong window entirely — which would make it not just costlier but wrong. I'd want to confirm that before moving off 5.5 regardless.

If you're seeing actual billing data that says otherwise, post it and I'll take another look — happy to be wrong here.

Separately: still keen for your confirmation that 6.11.2 fixes the original 400 whenever you get a chance.

npm install -g oc-codex-multi-auth@6.11.2
rm -rf ~/.cache/opencode/packages/oc-codex-multi-auth*
oc-codex-multi-auth warm