OpenAI-compatible non-streaming Responses requests fail on Codex pool (Hindsight 0.10.1) #6162

Client or integration

OpenAI-compatible SDK: Hindsight 0.10.1's openai-responses provider.

Provider or upstream service

OpenAI Codex through an OpenCodex OAuth account pool.

OpenCodex version

Reproduced on 2.64.0. I inspected the v2.69.0 source but have not run this reproduction on 2.69.0, so I am not claiming a runtime failure on that release.

Endpoint or capability

POST /v1/responses, non-streaming requests.

Current behaviour

A non-streaming Responses request reaches the Codex pool but returns HTTP 400 with {"detail":"Stream must be set to true"}. The same model and admission key work with stream:true: HTTP 200 with a response.completed event. OpenCodex's request log identifies the successful route as an OpenAI Codex pool account.

A disposable process using Hindsight 0.10.1's actual OpenAIResponsesLLM.call() path also raises BadRequestError (HTTP 400) with that detail. Hindsight calls responses.create(**params) without setting stream; its normal and tool-call request builders both use this pattern:

• Hindsight v0.10.1 provider call
• Hindsight v0.10.1 request body
• Hindsight v0.10.1 tool-call request body

Expected behaviour

The official OpenAI Responses create reference defines stream as optional; setting it to true enables server-sent events. An OpenAI-compatible client that omits stream or sets it to false expects a complete JSON Response.

For a Codex upstream that requires SSE, OpenCodex could make the upstream request with stream:true and return a complete JSON Response to a non-streaming client. If this endpoint intentionally supports streaming clients only, please document that limitation so compatible clients can choose another route.

Minimal redacted request or reproduction

curl -i http://127.0.0.1:50000/v1/responses \
  -H 'content-type: application/json' \
  -H 'x-opencodex-api-key: <REDACTED>' \
  -d '{"model":"gpt-6-luna","input":[{"role":"user","content":"Reply PONG"}],"store":false,"stream":false}'

Control: set "stream":true in the same request. It returns HTTP 200 and reaches response.completed.

Actual response or error

HTTP/1.1 400 Bad Request
{"detail":"Stream must be set to true"}

Upstream documentation

OpenAI Responses create reference: stream is optional and enables server-sent events when set to true.

Suggested mapping or implementation notes

A focused implementation should preserve complete output and usage, fail closed when no terminal event arrives, retain the existing storage semantics, and leave stream:true callers unchanged.

Additional context and attachments

The related PR #293 proposed SSE-to-JSON buffering but was closed without merge. Maintainer review identified incomplete reconstruction of tool calls, reasoning summaries, refusals, and annotations; false HTTP 200 on truncated streams; and unintended store changes.

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on an upstream specification or a concrete client requirement.