Bug Summary

Hermes fails against some provider: custom + api_mode: codex_responses endpoints when the Responses stream starts with response.in_progress instead of response.created.

The underlying byte stream is still usable — curl -N can read it and the response completes normally — but the OpenAI SDK's strict Responses stream state machine raises before Hermes can consume any events.

Repro

Use a custom endpoint configured like this:

model:
  provider: custom
  default: gpt-5.4
  base_url: https://<custom-endpoint>/openai
  api_key: <key>
  api_mode: codex_responses

Then run Hermes against a third-party relay that emits a stream like:

event: response.in_progress
data: {...}

event: response.output_item.added
data: {...}

event: response.output_text.delta
data: {...}

Observed Hermes error:

Expected to have received response.created before response.in_progress

Expected

For custom Responses-compatible endpoints, Hermes should tolerate this missing response.created prelude and continue streaming / complete normally.

Why this matters

This is not a total protocol failure:

• the endpoint is still usable from curl
• Hermes already has a responses.create(stream=True) fallback path for other Responses-stream edge cases
• the failure is specific to SDK-level ordering validation, not to the model output itself

A narrow compatibility fallback for custom endpoints would make Hermes substantially more reliable with third-party Responses relays without changing the strict path for native Codex/OpenAI flows.