v6.7.1

Patch for a total GPT-5.6 outage in 6.7.0. If you use gpt-5.6-sol, gpt-5.6-terra, or gpt-5.6-luna, upgrade — every request on 6.7.0 fails.

Fixed

GPT-5.6 requests no longer fail with HTTP 400 (#191, #192).

The backend rejects any request carrying the x-openai-internal-codex-responses-lite header that does not also set reasoning.context = "all_turns":

{
  "error": {
    "message": "X-OpenAI-Internal-Codex-Responses-Lite requires `reasoning.context` to be `all_turns`.",
    "type": "invalid_request_error",
    "param": "reasoning.context",
    "code": "unsupported_value"
  }
}

6.7.0 sent the header but never the field, so every gpt-5.6-* turn returned HTTP 400. Because that error is not model_not_supported_with_chatgpt_account, the sol → terra → luna → gpt-5.5 degradation never triggered — the request hard-failed instead of falling back.

This matches upstream codex-rs/core/src/client.rs (build_reasoning):

context: model_info.use_responses_lite.then_some(ReasoningContext::AllTurns),

ReasoningContext is serde(rename_all = "snake_case") and context is skip_serializing_if = Option::is_none, so responses-lite models send "all_turns" and every other model omits the field entirely.

The field is written inside the responses-lite reshape, which shapeBodyForModel applies to a structuredClone for lite models only. The canonical body stays free of context, so a gpt-5.6-sol request that falls back to gpt-5.5 is re-serialized in the classic shape without it — pinned by a mutation-isolation test and an end-to-end fallback test, both of which fail if the clone boundary is removed.

Credits

Reported, diagnosed, and fixed by @UnknOownU, who has GPT-5.6 access and verified the fix against the live Codex backend (identical POST /codex/responses 400s without the field, 200s with it). This is the first live-backend confirmation of the responses-lite path shipped in 6.7.0.

Full changelog: v6.7.0...v6.7.1