Hermes /v1 traffic is ineligible for the experimental upstream websocket bridge

[masterkain]

Summary

Hermes Agent traffic sent through the public OpenAI-compatible /v1/responses endpoint does not become eligible for the upstream websocket bridge, even when the Pool toggle and websocket owner forwarding are enabled.

Hermes has a stable session identifier internally, but its custom OpenAI-compatible provider path does not send one of the continuity headers accepted by Codex Pooler. As a result, Codex Pooler does not create or attach a CodexSession, the bridge eligibility check returns false, and every request continues upstream over HTTP SSE.

Verified behavior

A bounded metadata-only deployment audit showed:

• Pool-level upstream_websocket_bridge_enabled was enabled
• CODEX_POOLER_WEBSOCKET_OWNER_FORWARDING=true was active on every app replica
• Hermes-shaped /v1/responses requests had no persisted codex_session_id
• request and attempt transport remained http_sse
• no attempt had response_metadata.upstream_websocket_bridge=true
• no bridge fallback logs were emitted because bridge preflight was never entered
• native websocket traffic retained high prompt-cache reuse, while the affected HTTP traffic had materially lower and less predictable cache reuse

This confirms an eligibility/interoperability gap rather than a websocket bridge failure.

Root cause

Codex Pooler requires a stable per-conversation continuity header such as session-id, x-session-id, x-session-affinity, or session_id before an OpenAI-compatible HTTP request can use the bridge safely.

Hermes currently adds its dynamic session_id routing headers only when it classifies the target as the direct ChatGPT Codex backend. A custom OpenAI-compatible /v1 provider does not enter that branch, so no continuity header reaches Codex Pooler.

Expected outcome

Track the cross-project compatibility work and make the ineligible state operationally clear:

• document that bridged /v1/responses clients must send a stable, per-conversation continuity header
• document Hermes Agent configuration or version requirements once upstream support is available
• expose a bounded eligibility reason in metadata or telemetry so missing continuity session can be distinguished from a bridge preflight fallback
• retain fail-closed behavior for session-less traffic; Codex Pooler must not synthesize a shared session from an API key, prompt cache key, or other non-conversation identifier

The corresponding Hermes Agent issue should add a provider-safe way to forward the current dynamic Hermes session identifier as an HTTP header for Codex-compatible custom /v1/responses providers.