Feature request: OpenAI responses API support

[cwong15]

OpenAI's Responses and Conversations APIs offer some significant benefits. Two tracks come to mind:

• server-side persistence
• server-side tools

Conversation persistence is a nice feature: it gives you memory without any DB infrastructure. All you need is the "previous response ID" to pass back between invocations. You don't need to send the conversation. Not needing a DB for persistence is a big win.

I can understand that taking advantage of server-side tools might give you pause because you want control over the tool loop. But using the API's response ID internally in your loop and providing that ID in your agent's response is a different issue.

[igordayen]

@cwong15 - you may be interested to take a look at embabel dice repo, it deals with persistence in depth. please take a look at dice README.md, thank you

[igordayen]

All you need is the "previous response ID"

• could you please provode snippet of usage with OpenAI API, thanks

[cwong15]

Thanks for following up, Igor. I think I may have expressed my request poorly. By conversation persistence I mean the basic persistence of the LLM conversation, such as what we capture with a chatbot. The dice project seems to have a much more advanced persistence use cases. I'm talking about something much more basic.

Here is a typical conversation "turn" when we have a followup message sent to a chatbot. Notice that conversationHistory contains only one message. Even if this is a continuing response from the user, I don't need to supply the entire conversation: all I need is the previousResponseId. This is because the conversation is persisted and cached on the OpenAI server. And I get back another responseId that I can use for the next invocation.

        List<ResponseInputItem> conversationHistory = new ArrayList<>();
        conversationHistory.add(createUserMessage(textContent));
        ResponseCreateParams.Builder paramsBuilder = ResponseCreateParams.builder()
            .model(actualModel(model))
            .instructions(systemPrompt)
            .inputOfResponse(conversationHistory)
            .tools(toolRegistry.getAllToolDefinitions());

        // Add previous response ID if this is a follow-up request
        if (previousResponseId != null) {
            paramsBuilder.previousResponseId(previousResponseId);
        }
        
        var response = openAiClient.responses().create(paramsBuilder.build());
        var responseId = response.previousResponseId();     

[igordayen]

Even if this is a continuing response from the user, I don't need to supply the entire conversation: all I need is the previousResponseId

thanks @cwong15 - yes, its clear now.
how urgent is fthis eature for you, is post 1.0 GA release ok with you?

There is another issue #1594 which is although specific to Anthropic, may resonate with you.

[cwong15]

This is not urgent. Thanks for responding.

[arnabnandy7]

@igordayen I want to pick this up next. If you are ok please assign me.

[igordayen]

@igordayen I want to pick this up next. If you are ok please assign me.

@arnabnandy7 - thank you; please discord communication.

[igordayen]

@arnabnandy7 , @cwong15
#1758 - related?
thanks

[arnabnandy7]

@arnabnandy7 , @cwong15
#1758 - related?
thanks

@igordayen yes, this is related. #1758 was the forcing bug (*-pro models only serve over /v1/responses), fixed in #1874 via OpenAiResponsesChatModel. But that PR deliberately scoped out the stateful half the doc comment on the class says persistence and server-side tools are "deliberately unused" since Embabel drives its own tool loop. So this issue's still open; #1874 just laid the transport groundwork.

Here's how I'd split it, with scoping for the first piece:

Track 1: conversation persistence via previous_response_id

• Add a small OpenAiResponsesChatOptions : ChatOptions by delegate wrapping OpenAiChatOptions, carrying a previousResponseId: String? field. Keeps us from touching Spring AI's own class.
• OpenAiResponsesChatModel.createParams() sends it via builder.previousResponseId(...) when present.
• toChatResponse() adds the returned response.id() into ChatResponseMetadata under a new key (openai.responseId or similar), so callers can persist and replay it.
• Null previousResponseId means zero behavior change, existing full-history callers are unaffected.
• What I'd leave out of this first PR: trimming Prompt.instructions down to just the delta once persistence kicks in. Right now toInputItems maps the entire instruction list on every call, once a session has a stored response.id, resending the full history either double-counts context or fights with previous_response_id. That's a session/memory-layer change (wherever conversation history gets assembled today) and I think it deserves its own PR and review once the options/metadata plumbing is in.

Track 2: server-side tools, opt-in per agent/model, additive to (not replacing) the existing tool loop. Lower priority and a bigger design surface on its own. Response parsing already separates ResponseFunctionToolCall from other output items, so this is mostly about not erroring on server-side tool output instead of treating it as unrecognized.

I'll follow the OpenAiResponsesAdapterIT pattern for tests on Track 1. Wanted to flag the scope cut (persistence plumbing vs. history-trimming) before writing any code, let me know if you'd rather see those bundled into one PR instead of split.

[igordayen]

Thanks, @arnabnandy7
Compiling list of post 2.0.0 releases and mapping issues to releases.

[arnabnandy7]

Thanks, @arnabnandy7
Compiling list of post 2.0.0 releases and mapping issues to releases.

@igordayen sure take your time, you can let me know when to start on this and if you would agree on the design/flow as I mentioned above. I'll pick it up.