[Feature Request] Update to OpenAI response api

[Wendong-Fan]

Required prerequisites

• I have searched the Issue Tracker and Discussions that this hasn't already been reported. (+1 or comment there if it has.)
• Consider asking first in a Discussion.

Motivation

Supporting the Response API is essential as it unlocks higher intelligence, lower costs, and better performance from OpenAI's reasoning models.
refer:
https://cookbook.openai.com/examples/responses_api/reasoning_items

Solution

No response

Alternatives

No response

Additional context

No response

[MuggleJinx]

Hi I have evaluated the current implementation. The current implementation directly relies on chat.completions returning a ChatCompletion type, with call sites concentrated in camel/models/openai_model.py:392–510. In contrast, the Response API returns a Response object (with segmented outputs, etc.), which has a completely different structure. This means all downstream logic would require major rewrites.

In higher-level code such as ChatAgent, assertions like isinstance(response, ChatCompletion) are used (see camel/agents/chat_agent.py:2102–2105), and responses are accessed via the old schema choices[*].message. Switching to the Response API would immediately trigger type errors.

The request input formats are also incompatible: OpenAIMessage is defined as ChatCompletionMessageParam (camel/messages/__init__.py:36–44), and the entire pipeline depends on the legacy messages list format. The Response API instead requires the new input/content fragment format, which means existing message constructors, memory management, and token accounting (see camel/utils/token_counting.py:77–119) must all be rewritten.

The codebase also makes heavy use of beta.chat.completions.parse/stream for structured parsing and streaming output (camel/models/openai_model.py:451–509). The Response API’s current responses.parse/stream interfaces are not compatible with these return types and stream managers, so parsing/stream handling wrappers would need to be redesigned.

In summary, chat.completions calls cannot simply be swapped out for responses. To support the Response API, a dedicated backend must be added, with unified rewrites of the message model, return types, streaming, and parsing flow, followed by layer-by-layer adaptation of higher-level logic.