[
https://issues.apache.org/jira/browse/CAMEL-23969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Omar Atie reassigned CAMEL-23969:
---------------------------------
Assignee: Omar Atie
> camel-openai: support the OpenAI Responses API
> ----------------------------------------------
>
> Key: CAMEL-23969
> URL: https://issues.apache.org/jira/browse/CAMEL-23969
> Project: Camel
> Issue Type: New Feature
> Components: camel-openai
> Affects Versions: 4.21.0
> Reporter: Federico Mariani
> Assignee: Omar Atie
> Priority: Major
> Labels: ai
>
> The Responses API is OpenAI's successor to Chat Completions and the only
> surface for the hosted built-in tools. The pinned SDK (4.41.0) fully supports
> it: {{responses().create/createStreaming/retrieve/delete/cancel/compact}},
> structured outputs ({{text(Class)}}), {{inputTokens().count()}}, and a rich
> tool palette ({{WebSearchTool}}, {{FileSearchTool}}, {{Tool.Mcp}}
> (server-side MCP), {{Tool.CodeInterpreter}}, {{ComputerTool}},
> {{FunctionTool}}, ...). camel-openai currently only speaks Chat Completions.
> Proposal (incremental):
> # New operation {{openai:responses}} with the existing chat ergonomics:
> String/file/image body handling, {{systemMessage}} (as {{instructions}}),
> {{model}}, {{temperature}}, {{maxTokens}} ({{maxOutputTokens}}),
> {{jsonSchema}}/{{outputClass}} structured output, token-usage and response-id
> headers. Streaming is deliberately out of scope for the initial
> implementation: Camel has no clear end-to-end streaming story for producer
> responses today (the chat operation's {{Iterator}}-body approach works for
> {{split(streaming())}} but sets no response headers and cannot bridge to an
> outbound SSE response), so it should be reconsidered only once that pattern
> is settled.
> # Server-side conversation state: {{previousResponseId}} option/header —
> offloads the conversation-memory bookkeeping that is currently client-side
> (and buggy, see the conversation-memory ticket from this review).
> # Built-in hosted tools via options (e.g.
> {{builtinTools=web_search,file_search}}, {{Tool.Mcp}} pass-through for
> server-side MCP) — note these run on OpenAI's side and do not overlap with
> the component's client-side MCP loop.
> # Function tools: defer wiring Camel-route tools until the unified tool
> abstraction lands for camel-openai (CAMEL-23382 step 6), then implement it
> for both chat-completion and responses so tool dispatch has a single code
> path.
> Intended usage:
> {code:java}
> // drop-in basic usage, same ergonomics as chat-completion
> from("direct:ask")
> .to("openai:responses?model=gpt-5&systemMessage=You are a support
> assistant")
> .log("Answer: ${body} responseId: ${header.CamelOpenAIResponseId}");
> // multi-turn conversation with SERVER-side state: one header in, one header
> out —
> // no client-side message-list bookkeeping (contrast with conversationMemory
> today)
> from("direct:chat-turn")
> .setHeader(OpenAIConstants.PREVIOUS_RESPONSE_ID,
> variable("lastResponseId"))
> .to("openai:responses?model=gpt-5")
> .setVariable("lastResponseId", header(OpenAIConstants.RESPONSE_ID));
> // hosted built-in tools: the model searches the web on OpenAI's side, one
> round trip,
> // no agentic loop in the component (complements, does not replace,
> client-side MCP)
> from("direct:research")
> .setBody(constant("Summarize this week's Apache Camel releases"))
> .to("openai:responses?model=gpt-5&builtinTools=web_search")
> .log("${body}");
> {code}
> Scope judgment from the gap analysis: this is the largest and most
> future-proof missing SDK feature; conversely {{beta().assistants()}} should
> be skipped (superseded by Responses), and
> {{fineTuning()}}/{{evals()}}/{{admin()}} are management-plane concerns that
> don't fit integration routes.
> _This issue was drafted by Claude Code on behalf of Federico Mariani_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
