Spring AI 2.1.0-RC1 and 2.0.2 Available Now

On behalf of the Spring AI team and everyone who has contributed, I'm happy to announce that Spring AI 2.1.0-RC1 and 2.0.2 have been released and are now available from Maven Central!

Release notes | Upgrade notes | Reference documentation

2.1.0-RC1 builds on 2.1.0-M1 and delivers most of what we promised in its "What's next" section: message parts are now produced and consumed natively by the major chat models, and session memory arrives in Spring AI itself. It also adds tool call confirmation, and extends the pre-computed embeddings support with search by query vector.

New in this release

Message Parts across providers

In M1, only OpenAiResponsesChatModel worked natively with MessagePart content. In this release the following ChatModel implementations produce and consume parts as well:

• OpenAI (Chat Completions)

• Anthropic

• Google GenAI

• Amazon Bedrock Converse

• Ollama

• Mistral AI

• DeepSeek

Reasoning, tool calls, and provider-specific blocks therefore keep their order and their opaque payloads, such as Anthropic thinking signatures and Gemini thought signatures, across a whole conversation. Code that uses the existing accessors (getText(), getToolCalls(), ...) keeps working. The message builders' setters now replace parts in place, so UserMessage.builder().text(...) followed by another call no longer leaves stale parts behind.

Two related details for OpenAI-compatible endpoints. reasoning_content is echoed back on assistant messages because some endpoints, such as DeepSeek in thinking mode, require it, while others, such as Groq, reject it. Replaying is now configurable with spring.ai.openai.chat.replay-reasoning-content (or OpenAiChatOptions.replayReasoningContent); it keeps sending the property by default, and false turns it off. And on the Responses API, the order of the parts of a user message is preserved, and file URLs are sent as file_url.

Session Memory

ChatMemory stores a flat list of messages per conversation id. Long-running conversations and agents need more than that, so Spring AI now includes a session memory, ported from the community Spring AI Session project.

A session keeps a conversation as an append-only log of events and builds the prompt from a view of that log:

• Structured events. Every message is a SessionEvent. Other event types, with names you can define yourself, can record what else happened in the same log.

• Turn-aware compaction. Triggers such as TurnCountTrigger decide when the history has grown too large, and a strategy decides what leaves the view. WindowCompactionStrategy keeps the last events, the last turns, or fits a token budget, and an optional CompactionSummarizer (ChatModelSummarizer) can summarize what is dropped. A compaction always cuts on a turn boundary, so the model never sees a tool call without its result. Compaction never rewrites the log: it appends a boundary that defines the view from then on.

• A repository SPI. InMemorySessionRepository is meant for tests, and JdbcSessionRepository supports PostgreSQL, MySQL, MariaDB and H2, with idempotent appends and version-checked compaction. A store of your own can be verified against the contract tests in spring-ai-test.

To use it with a ChatClient, add the spring-ai-starter-model-session-jdbc starter, register the session advisors, and pass a session id with every call:

@Bean
ChatClient chatClient(ChatModel chatModel, SessionService sessionService) {
    return ChatClient.builder(chatModel)
        .defaultAdvisors(SessionAdvisors.builder(sessionService)
            .compaction(new TurnCountTrigger(20), WindowCompactionStrategy.builder().lastTurns(10).build())
            .build())
        .build();
}

String answer = chatClient.prompt()
    .user("Hello!")
    .advisors(SessionAdvisors.session("session-abc"))
    .call()
    .content();

A session that does not exist yet is created on first use, and the session id is required on every call: there is deliberately no default session, since a shared one would silently merge the histories of different users. The advisors keep no state of their own, so any application instance can run any turn of a session.

ChatMemory, MessageWindowChatMemory, ChatMemoryRepository, MessageChatMemoryAdvisor, and the JDBC, Cassandra, Neo4j, MongoDB and Redis chat memory repositories are now deprecated, for removal in 3.0.0. Each deprecation names its replacement. Where there is no session counterpart yet (Cassandra, Neo4j, MongoDB, Redis, and the HSQLDB, Oracle, SQL Server and SQLite dialects), one is planned before 3.0.0. VectorStoreChatMemoryAdvisor stays, since sessions have no semantic recall counterpart yet. The advisor context key ChatMemory.CONVERSATION_ID now has a permanent home as MemoryAdvisor.CONVERSATION_ID, with the same value.

Tool Call Confirmation

Booking a flight, deleting a file or sending an email are actions a person may want to approve first. A tool can now ask for that:

class BookingTools {

    @Tool(description = "Book a flight", requiresConfirmation = true)
    String bookFlight(String flightNumber) {
        return bookingService.book(flightNumber);
    }
}

When the model calls such a tool, the tool-calling loop pauses before any call of the reply runs, and the reply goes back to your application listing the calls that wait for a decision. Your application collects a ToolCallDecision per call (allow, or deny with a message), runs the reply's calls with ToolCallingManager.executeToolCalls(prompt, reply, decisions), and sends the results as its next request. A denied call answers the model with your message instead of running.

The loop keeps no state while it waits: the pause is an ordinary response and the resumption an ordinary request, so this survives restarts as long as your application keeps the conversation. Which calls need confirmation is decided by a ToolCallConfirmationPolicy: the default reads the tool's metadata, forTools(...) names tools you do not own, such as MCP tools, and a lambda can inspect the arguments, for example to confirm only transfers over a given amount. Policies can be combined with or(...), and the spring.ai.tools.confirmation.* properties and ToolCallConfirmationPolicy beans are picked up by the auto-configuration. The feature is covered by integration tests against OpenAI, Gemini, Anthropic, Bedrock and Ollama. See Tool Call Confirmation in the reference documentation.

（节选）

原文：Spring Blog｜Spring AI 2.1.0-RC1 and 2.0.2 Available Now，2026-10-23