feat(providers): translate chat completions onto Responses-only upstreams (chatgpt/Codex backend)

[weselben]

Part of #723 (dialect independence across providers). This issue specifies the first slice: the chat-to-Responses adapter and its wiring into the chatgpt provider.

Problem

GoModel translates Responses API requests onto chat completions. See ResponsesViaChat in internal/providers/responses_adapter.go:364. The reverse direction does not exist. A client that calls /v1/chat/completions cannot use an upstream that serves only the Responses API.

This case already exists in the repo. The chatgpt provider targets the ChatGPT Codex backend at https://chatgpt.com/backend-api/codex. That backend serves only the Responses API. Its chat surface returns an error today (internal/providers/chatgpt/chatgpt.go:142). Chat-completions clients cannot use these models.

Current state

• The adapter works in one direction only: Responses request to chat upstream (ResponsesViaChat, StreamResponsesViaChat).
• The machinery for the reverse direction already exists:
  • Shape converters: responses_converter.go, responses_input.go, responses_output.go.
  • History reconstruction from stored snapshots: previous_response.go.
  • ID minting: responses_converter.go:47 mints resp_<uuid> for translated streams.
• The chatgpt provider is the first consumer. It is Responses-native today. Its chat surface is unsupported.

Proposal

Add a ChatViaResponses helper that mirrors ResponsesViaChat. Wire it into ChatCompletion and StreamChatCompletion of the chatgpt provider.

• Convert messages to Responses input items. This reverses the responses_input.go mapping.
• Convert Responses output items to chat choices: text, tool calls, finish reasons. Map reasoning to reasoning_content, per repo convention.
• Convert Responses SSE events to chat completion chunks. This reverses OpenAIResponsesStreamConverter. The Codex backend is streaming-only. A non-streaming chat request must collect the stream before it replies.
• Map usage fields: input_tokens to prompt_tokens, output_tokens to completion_tokens. Map input_tokens_details.cached_tokens to prompt_tokens_details.cached_tokens.
• Respect the strict parameter allowlist of the backend. Translate fields that keep their meaning. Reject fields that do not, such as logprobs and logit_bias. Do not drop fields silently. Postel's law applies in both directions.

IDs and conversation state

Minted IDs make the response shape correct. They are not resource handles.

• Mint chatcmpl-<uuid> for the client-facing reply. This keeps the OpenAI chat shape. Chat clients do not send this ID back. Chat completions is stateless: each request carries the full messages array.
• Keep the upstream resp_ ID internal. Use it for diagnostics and logs.
• Server-side chaining cannot exist on the Codex backend. The backend pins store: false. It rejects store: true and previous_response_id (internal/providers/chatgpt/request.go). An ID without a stored response behind it is a label, not a handle.
• Consequence: no client gets previous_response_id chaining through Codex. Full history travels in the request body.
• Chat-path snapshots are out of scope here. If added later, they are gateway-side history reconstruction. They need their own lookup and ownership design.

Out of scope

• Non-streaming translated Responses replies keep the upstream chatcmpl- ID. Translated streams mint resp_ IDs. Minting resp_ for non-stream replies too would make the translated surface consistent. This is a separate change.

---

This issue was drafted with AI assistance.

[weselben]

@coderabbitai WDYT — looking for a third opinion on the proposal above. Context: the reverse adapter (chat completions → Responses) would let the Responses-only ChatGPT Codex backend (internal/providers/chatgpt/chatgpt.go, chat surface currently unsupported) serve chat-completions clients. The repo already has the one-way ResponsesViaChat plus converters and history reconstruction. Open questions where your analysis would help: (1) any pitfalls in reversing the OpenAIResponsesStreamConverter for SSE → chat chunks, (2) whether minting client-facing chatcmpl- IDs while keeping upstream resp_ IDs creates problems in the snapshot/chaining store, (3) fields that have no honest mapping and should be rejected rather than dropped.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail
gh issue view 1084 --repo ENTERPILOT/GoModel --json title,body,comments --jq '{title,body,comments:[.comments[]|{author:.author.login,body:.body}]}'
printf '\nFiles:\n'
fd -i 'chatgpt.go|responses|chat' internal | head -100
printf '\nSymbols:\n'
rg -n -C2 'OpenAIResponsesStreamConverter|ResponsesViaChat|previous_response_id|chatcmpl-|resp_' internal | head -240

Length of output: 23637

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail
for f in internal/providers/responses_adapter.go internal/providers/responses_converter.go internal/providers/responses_input.go internal/providers/responses_output.go internal/providers/chatgpt/chatgpt.go internal/server/conversation_responses.go internal/server/handlers_responses.go internal/core/chat_json.go internal/core/responses.go; do
 echo "=== $f ==="; ast-grep outline "$f" --items all | head -85
done
echo '=== store files ==='; fd . internal/responsestore
echo '=== focused symbols ==='
rg -n -C2 'OpenAIResponsesStreamConverter|ResponsesViaChat|previous_response_id|PreviousResponseID|Snapshot|snapshot|ChatCompletion\(|StreamChatCompletion\(' internal/providers/responses_adapter.go internal/providers/responses_converter.go internal/providers/chatgpt/chatgpt.go internal/server/conversation_responses.go internal/server/handlers_responses.go internal/responsestore | head -320

Length of output: 37945

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail
echo '=== relevant files ==='
fd 'previous_response.go|chat.go|responses.go|store.go|chat_codec.go|responses_codec.go' internal | head -90
echo '=== chatgpt provider ==='; sed -n '87,173p' internal/providers/chatgpt/chatgpt.go
echo '=== chat req definition ==='; rg -n -A115 -B5 'type ChatRequest struct' internal/core
echo '=== adapter request mapping ==='; sed -n '26,151p' internal/providers/responses_adapter.go
echo '=== adapter calls ==='; sed -n '361,405p' internal/providers/responses_adapter.go
echo '=== store ==='; sed -n '1,200p' internal/responsestore/store.go
echo '=== server chaining locations ==='; rg -n -C3 'previous_response_id|PreviousResponseID|StoredResponse|store\.Create|store\.Get' internal/server -g '*.go' | head -240
echo '=== codex request mapping ==='; rg -n -C3 'allowlist|unsupported|stream|previous_response_id|responses' internal/llmclient -g '*codex*' -g '*chatgpt*' | head -190

Length of output: 44720

---

🏁 Script executed:

#!/bin/bash
set -uo pipefail
echo '=== chatgpt files ==='; fd . internal/providers/chatgpt
echo '=== specific outlines ==='
for f in internal/server/previous_response.go internal/server/response_snapshot.go internal/streaming/responses_codec.go internal/streaming/chat_codec.go; do if [ -f "$f" ]; then ast-grep outline "$f" --items all | head -110; fi; done
echo '=== snapshot names ==='; rg -n -C2 'ProviderResponseID|StoredResponse\{|saveResponse|snapshot|Snapshot' internal/server -g '*.go' | grep -E '^[^:]+:[0-9]+:' | head -100
echo '=== codex request ==='; rg -n -C3 'newUpstreamRequest|collapseResponsesStream|response\.output_text\.delta|response\.function_call_arguments\.delta' internal/providers/chatgpt
echo '=== previous response ==='; sed -n '18,159p' internal/server/previous_response.go; sed -n '204,305p' internal/server/previous_response.go
echo '=== stream codec ==='; sed -n '1,160p' internal/streaming/responses_codec.go; sed -n '1,110p' internal/streaming/chat_codec.go

Length of output: 42384

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail
ast-grep outline internal/providers/chatgpt/request.go --items all
ast-grep outline internal/providers/chatgpt/stream.go --items all
rg -n -C2 'func .*storeResponseSnapshot|ProviderResponseID|snapshotStream\(' internal/server/response_snapshot* internal/server/translated* | head -155 || true
sed -n '1,210p' internal/providers/chatgpt/request.go
sed -n '1,165p' internal/providers/chatgpt/stream.go
sed -n '1,125p' internal/server/response_snapshot_stream.go
sed -n '435,562p' internal/providers/responses_converter.go
sed -n '115,210p' internal/core/types.go

Length of output: 21518

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail
sed -n '252,395p' internal/server/translated_inference_service.go
sed -n '415,500p' internal/server/translated_inference_service.go
rg -n -C3 'storeResponseSnapshotAsync\(|snapshotStream\(|ChatCompletion\(' internal/server/translated_inference_service.go internal/server/handlers_chat.go internal/server/internal_chat_completion_executor.go 2>/dev/null || true
sed -n '129,191p' internal/providers/responses_output.go
sed -n '218,268p' internal/providers/responses_output.go
sed -n '240,307p' internal/providers/responses_converter.go

Length of output: 25059

---

@weselben, I support the adapter, with one correction to the ID proposal: a chat completion does not currently create a Responses snapshot.

1. Streaming needs its own state machine, not a mechanical inverse. Responses events identify output items and content parts by index. Track each text part and function_call separately. Emit one chat tool-call index and ID when a call starts, then append argument deltas to that call. Do not emit the terminal response’s full output again after emitting deltas. Map response.completed to stop or tool_calls according to the output; map a known token-limit response.incomplete to length. Do not report stop for an interrupted stream, response.failed, or an unknown incomplete reason. Send a usage chunk only when stream_options.include_usage requests it. For non-streaming chat, require a terminal event before returning a successful response, as collapseResponsesStream already does.

2. Keep IDs separate, but do not promise chaining from a chat ID. A stable client-facing chatcmpl- ID is appropriate across all chunks. The upstream resp_ ID can remain internal for diagnostics. The Responses snapshot writer runs on the /v1/responses path and currently sets ProviderResponseID to the response ID it stores. The chat path does not call that writer. More importantly, internal/providers/chatgpt/request.go pins upstream store: false and omits previous_response_id. A subsequent chat request must supply its message history; neither ID provides upstream chaining. If you later add chat snapshots, define their lookup and ownership semantics separately rather than treating chatcmpl- as a Responses resource.

3. Validate intent before calling Codex. Reject chat requests that require unsupported behavior, including logprobs, logit_bias, n > 1, stop, seed, and frequency or presence penalties. Reject max_tokens/max_completion_tokens, temperature, and top_p when the request requires those limits or sampling controls: the current Codex allowlist drops their Responses equivalents. Inspect ChatRequest.ExtraFields as well as typed fields, or unsupported chat parameters can bypass validation. Translate response_format only when its exact format is supported by the upstream text contract. Reject unsupported message content types rather than converting them to text.

I would make the first version deliberately narrow: text, function calls, supported reasoning output, and usage. Add paired streaming and non-streaming tests for interleaved tool calls, failed or truncated streams, terminal usage, and each rejected request field. Thanks for the detailed context.

---

✏️ Learnings added

Learnt from: weselben
URL: https://github.com/ENTERPILOT/GoModel/issues/1084

Timestamp: 2026-09-23T21:13:49.939Z
Learning: In ENTERPILOT/GoModel, the `chatgpt` provider in `internal/providers/chatgpt/` targets a Responses-only ChatGPT Codex backend. Its `newUpstreamRequest` sends `store: false` and does not forward `previous_response_id`. Responses snapshots are written on the `/v1/responses` path; serving `/v1/chat/completions` through a reverse adapter would not automatically create a Responses snapshot or support upstream ID chaining.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

You are interacting with an AI system.

[weselben]

#723