Federico Mariani created CAMEL-23969:
----------------------------------------
Summary: 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
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)
