Codex + DeepSeek fails: `include` field rejected in chat-translated Responses requests

[chi-cat]

Problem

When using Codex with DeepSeek through GoModel via the Responses API, requests fail with:

{
  "error": {
    "code": null,
    "message": "responses field \"include\" is only supported by native Responses providers; use an OpenAI-compatible provider or passthrough for this request",
    "param": null,
    "type": "invalid_request_error"
  }
}

Root Cause

1. Codex requirement: Codex (0.122.0+) enforces wire_api = "responses" in its configuration and automatically adds an include field to Responses API requests.

2. GoModel validation: When a Responses request reaches a chat-only provider (DeepSeek, Anthropic, Gemini), GoModel translates it to chat semantics. However, the validation in internal/providers/responses_adapter.go completely rejects the include field with an error:

   if len(req.Include) > 0 {
       return unsupportedResponsesChatTranslationField("include")
   }

3. Documentation conflict: The Codex integration guide recommends using wire_api = "responses" with DeepSeek, but this configuration is actually impossible to use because Codex will always send include, triggering the error.

Reproducible Test Case

# GoModel running on localhost:8080 with DeepSeek provider
export OPENAI_API_KEY=change-me
export DEEPSEEK_API_KEY=sk-...

docker run --rm -p 8080:8080 \
  -e GOMODEL_MASTER_KEY="change-me" \
  -e DEEPSEEK_API_KEY="sk-..." \
  enterpilot/gomodel

# Codex config
[model_providers.gomodel]
name = "GoModel"
base_url = "http://localhost:8080/v1"
env_key = "OPENAI_API_KEY"
wire_api = "responses"

# This fails
codex exec -m deepseek/deepseek-v4-pro 'Reply with exactly ok'

Error: responses field "include" is only supported by native Responses providers

Solution

Instead of rejecting the include field for chat-translated providers, filter it out silently. The field has no semantic meaning in chat translation context (it's used to control response inclusion when responses are stored server-side), so it should be dropped like other non-translatable fields.

Modified logic:

• For native Responses providers (OpenAI, xAI): forward include unchanged ✅
• For chat-translated providers (DeepSeek, Anthropic, Gemini): filter out include during conversion ✅

This is consistent with how other provider-specific fields are handled:

• Fields like top_logprobs, previous_response_id, conversation are also non-translatable but are rejected per spec
• However, include is different: it's metadata about response retrieval, not model behavior, so filtering is safe

Files to modify

• internal/providers/responses_adapter.go:
  • Remove include from validateResponsesRequestForChatTranslation() check
  • Add logic to ConvertResponsesRequestToChat() to clear req.Include before conversion

Affected users

• Codex users trying to integrate with non-native-Responses providers (DeepSeek, Anthropic, Gemini)
• Any client that auto-includes include fields in Responses requests

Related docs

• Codex guide recommends DeepSeek + Responses:

  GoModel/docs/guides/codex.mdx

  Lines 100 to 135 in cf0a8d5

  	## DeepSeek V4
  	Codex sends `POST /v1/responses`. DeepSeek exposes chat completions instead of
  	a native Responses API, so configure the first-class DeepSeek provider and let
  	GoModel translate the request.
  	```yaml
  	providers:
  	deepseek:
  	type: deepseek
  	base_url: "https://api.deepseek.com"
  	api_key: "${DEEPSEEK_API_KEY}"
  	```
  	If you previously configured DeepSeek as `type: openai`, change it to
  	`type: deepseek` for Codex. The generic OpenAI provider forwards `/responses`
  	upstream, while the DeepSeek provider translates `/responses` to
  	`/chat/completions`.
  	See the [DeepSeek guide](/providers/deepseek) for the full reasoning effort
  	mapping table (DeepSeek V4 only accepts `high` and `max`, so GoModel maps
  	`low` and `medium` up to `high`).
  	Then use the DeepSeek model name in Codex:
  	```toml
  	model_provider = "gomodel"
  	model = "deepseek-v4-pro"
  	[model_providers.gomodel]
  	name = "GoModel"
  	base_url = "http://localhost:8080/v1"
  	env_key = "OPENAI_API_KEY"
  	wire_api = "responses"
  	```

• Responses compatibility docs: https://github.com/ENTERPILOT/GoModel/blob/cf0a8d5c9f5c68abec886bc8ac612016898b7114/docs/advanced/responses-compatibility.mdx

[coderabbitai]

🔗 Related PRs

#285 - feat(providers): add deepseek responses adapter [merged]
#314 - feat(deepseek): add Passthrough support and PassthroughSemanticEnricher [merged]
#353 - feat(agents): support OpenAI Agents SDK [merged]
#395 - feat(opencode_go): add native OpenCode Go (OpenCode Zen) provider [merged]
#415 - docs(readme): move reference tables into docs and link from README [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[chi-cat]

Implemented a small project to convert responses API to chat completions API; and supplemented web search capabilities through searxng + jina reader. This is mainly used to integrate model providers like DeepSeek, which only support the chat completions API, into GoModel or use them in Codex

deepseek-responses-api

[SantiagoDePolonia]

@chi-cat This should be fixed in the latest release. Let me know how it works for you.

[chi-cat]

@chi-cat This should be fixed in the latest release. Let me know how it works for you.

The functionality in the GUI is now working properly. but

`
codex -p test_local2 exec hello
OpenAI Codex v0.145.0

workdir: ~/golang/deepseek-responses-api
model: deepseek-v4-pro
provider: chiscat
approval: never
reasoning effort: none
reasoning summaries: none
session id: 019fae86-5440-7a60-901c-ef7caa585782

user
hello
warning: Codex could not find bubblewrap on PATH. Install bubblewrap with your OS package manager. See the sandbox prerequisites: https://developers.openai.com/codex/concepts/sandboxing#prerequisites. Codex will use the bundled bubblewrap in the meantime.
warning: Model metadata for deepseek-v4-pro not found. Defaulting to fallback metadata; this can degrade performance and cause issues.
2026-07-29T15:37:50.624658Z ERROR codex_core::util: ReasoningSummaryPartAdded without active item
2026-07-29T15:37:50.625084Z ERROR codex_core::util: ReasoningSummaryDelta without active item
2026-07-29T15:37:50.625206Z ERROR codex_core::util: ReasoningSummaryDelta without active item
2026-07-29T15:37:50.625233Z ERROR codex_core::util: ReasoningSummaryDelta without active item
2026-07-29T15:37:50.625248Z ERROR codex_core::util: ReasoningSummaryDelta without active item
2026-07-29T15:37:50.625263Z ERROR codex_core::util: ReasoningSummaryDelta without active item
2026-07-29T15:37:50.625277Z ERROR codex_core::util: ReasoningSummaryDelta without active item
2026-07-29T15:37:50.625456Z ERROR codex_core::util: ReasoningSummaryDelta without active item
2026-07-29T15:37:50.625607Z ERROR codex_core::util: ReasoningSummaryDelta without active item
2026-07-29T15:37:50.697934Z ERROR codex_core::util: ReasoningSummaryDelta without active item
2026-07-29T15:37:50.697976Z ERROR codex_core::util: ReasoningSummaryDelta without active item
2026-07-29T15:37:50.697981Z ERROR codex_core::util: ReasoningSummaryDelta without active item
2026-07-29T15:37:50.697984Z ERROR codex_core::util: ReasoningSummaryDelta without active item
2026-07-29T15:37:50.948051Z ERROR codex_core::util: ReasoningSummaryDelta without active item
2026-07-29T15:37:50.948092Z ERROR codex_core::util: ReasoningSummaryDelta without active item
2026-07-29T15:37:50.948097Z ERROR codex_core::util: ReasoningSummaryDelta without active item
2026-07-29T15:37:50.948100Z ERROR codex_core::util: ReasoningSummaryDelta without active item
The user just said "hello" - this is a simple greeting. I should respond in a friendly, conversational tone without any structured formatting or sections.
2026-07-29T15:37:51.040811Z ERROR codex_core::util: OutputTextDelta without active item
2026-07-29T15:37:51.214168Z ERROR codex_core::util: OutputTextDelta without active item
2026-07-29T15:37:51.214238Z ERROR codex_core::util: OutputTextDelta without active item
2026-07-29T15:37:51.214249Z ERROR codex_core::util: OutputTextDelta without active item
2026-07-29T15:37:51.310700Z ERROR codex_core::util: OutputTextDelta without active item
2026-07-29T15:37:51.310862Z ERROR codex_core::util: OutputTextDelta without active item
2026-07-29T15:37:51.310889Z ERROR codex_core::util: OutputTextDelta without active item
codex
Hey there! 👋 How can I help you today?
tokens used
4,148
`

based on the experience of adapting to the responses interface in the deepseek-responses-api project, please keep response.output_item.added as an empty slice; otherwise, an error will occur during execution.

like this:

event: response.output_item.added
data: {"item":{"id":"rs_resp_0000000018c6cdce9a77f13e_0","status":"in_progress","summary":[],"type":"reasoning"},"output_index":0,"sequence_number":226116,"type":"response.output_item.added"}

event: response.output_item.added
data: {"item":{"id":"msg_resp_0000000018c6cdce9a77f13e","type":"message","role":"assistant","status":"in_progress","content":[]},"output_index":1,"sequence_number":226277,"type":"response.output_item.added"}

[SantiagoDePolonia]

It should be fixed with: #625
Check out the latest version 0.1.67.