Use OpenAI Responses API instead of the Chat Completions API

[raftaar1191]

OpenAI has introduced the Responses API (POST /v1/responses) as the new, unified endpoint that consolidates functionality from both Chat Completions and Assistants/Threads APIs.

Advantages of using the Responses API

• Unified design: One endpoint for chat, tools, and multimodal interactions.
• Built-in memory: Supports store:true and conversation.id, which means conversations can persist without resending the full message history. This can significantly reduce token usage and costs for long-running chats.
• Native tool handling: Cleaner definition of tools and structured tool_call outputs, easier to validate and safer than current function-calling prompts.
• Multimodal ready: Accepts text, images, and audio in the same request.
• Consistent output: Always returns a response object with output[], usage, status, etc., which simplifies logging and debugging.
• Future direction: OpenAI is evolving the Responses API, while Chat Completions is effectively a legacy path for new projects.

Disadvantages / Migration Considerations

• Newer API: Responses API is less mature; not all SDKs or plugins in the ecosystem support it fully yet.
• Learning curve: Output parsing is slightly more complex (output[] vs. choices[0].message.content).
• Migration cost: Projects already using Chat Completions will need refactoring to adapt request/response handling.
• Community ecosystem: Most tutorials and sample code still target Chat Completions.

Proposal

Evaluate adding support for the Responses API in this client library, either:

1. As a replacement for Chat Completions, or
2. As an additional option, allowing developers to choose between chat.completions and responses.

This would ensure the library stays aligned with OpenAI’s current API direction and provides WordPress developers with a future-proof integration option.

[felixarntz]

See my reply in #101 (comment) on why we went with the Chat Completions API instead of the Responses API. It has to do with interoperability, as the Chat Completions API has become sort of a "standard" that many providers have implemented.

Your issue is totally valid, although I'd personally question some of the concrete advantages you mention - e.g. multimodal input and tool call support is similarly present in the Chat Completions API. Anyway, it's clear that the Responses API is the recommended way to go from OpenAI perspective, and more so, for Google and Anthropic, the interoperability layer for the Chat Completions API is clearly a second-class API, with several gaps compared to their first-class APIs.

I think it makes sense to keep this issue focused on the Responses API, and open two separate issues to support the primary Google Gemini API and the Anthropic API. Still, it should be considered an overarching effort, where we'd want to make an update for all three of these providers, not just for one.

There are still some major questions to answer on how we want to distribute provider implementations long-term, whether they should be bundled (like now) or separate packages (and if so, how?). I think until we have aligned on an approach, building out support for the more bespoke first-class APIs from each provider would be a bit premature.