DeepSeek's API now supports the OpenAI Responses API format, using base_url https://api.deepseek.com, enabling DeepSeek models (deepseek-v4-flash, deepseek-v4-pro) to be used directly within Codex. The documentation details streaming via server-sent events, a full list of supported event types, and a compatibility matrix covering request parameters, input item types, tools, and response fields, noting which OpenAI Responses API features are fully supported, partially supported, or silently ignored.
Table of contents
Integrating DeepSeek Models into Codex Calling DeepSeek Models via the Responses API Streaming Compatibility Details Questions this post answers
How do I use DeepSeek models with OpenAI Codex?
DeepSeek's API now supports the Responses API format used by Codex, so you can point Codex at DeepSeek by setting the base_url to https://api.deepseek.com and configuring it with the OpenAI SDK. Models deepseek-v4-flash and deepseek-v4-pro are available, and the OpenAI SDK (pip3 install openai) works with minimal configuration changes. daily.dev surfaces integration guides like this for developers wiring new models into Codex.
Which Responses API parameters does the DeepSeek API support?
DeepSeek supports core Responses API parameters including model, input, instructions, stream, temperature (0.0-2.0, ignored in thinking mode), top_p, max_output_tokens, and top_logprobs (0-20). Tools support is partial: function and web_search work, others are ignored. Unsupported parameters like previous_response_id, conversation, store, and background are silently ignored rather than causing errors. Developers comparing API compatibility across model providers can track these details on daily.dev.
What happens when I send an unsupported Responses API parameter to the DeepSeek API?
Unsupported parameters are silently ignored and do not cause errors, which means existing Responses API clients can connect to DeepSeek without modification. Examples of ignored parameters include parallel_tool_calls, max_tool_calls, previous_response_id, conversation, store, background, metadata, include, prompt, service_tier, and stream_options. daily.dev helps developers stay ahead of quiet API compatibility gaps like this one.