Spring AI 2.0.1 has shipped as the first maintenance release on top of the 2.0.0 GA baseline, fixing over 80 issues reported after teams adopted 2.0. Key upgrade-relevant changes: deprecated Mistral AI chat model constants were removed, the Redis chat memory autoconfiguration module was renamed, OpenAI tool-calling strict mode now defaults to false to fix 400 errors on optional tool parameters, media builders use typed overloads, DeepSeekApi was revised for consistency, and the Couchbase vector store now uses the Spring Boot-managed client. New features include configurable tool call limits with a ToolCallLimitExceededException, configurable tool resolution fallback behavior, Google GenAI ToolChoice support and image generation, and page-range support in PagePdfDocumentReader.
Table of contents
CVEs fixed in this releaseBefore you upgradeNew in this releaseReliabilityDocumentation, dependencies, and buildContributorsGet startedResourcesQuestions this post answers
Why is my Spring AI OpenAI tool call failing with a 400 error after upgrading to Spring AI 2.0.1?
Spring AI 2.0.1 changed OpenAI tool-calling strict mode to default to false, because previously the generated tool schemas marked optional parameters by omitting them from required, which strict mode rejects, causing any tool with an optional parameter to fail with a 400 error. Strict mode is now opt-in; enable it explicitly only if your schemas conform to its rules. Track breaking changes like this OpenAI tool-calling default on daily.dev before they break your Spring AI upgrade.
What breaking changes do I need to handle when upgrading from Spring AI 2.0.0 to 2.0.1?
Most applications can upgrade by simply bumping the version, but a few changes need attention: deprecated Mistral AI chat model constants were retired and must be replaced with a supported model name, the Redis chat memory auto-configuration module was renamed so its artifact id must be updated in the build file, and the Couchbase vector store now uses the Spring Boot-managed Couchbase client instead of creating its own. Developers planning a Spring AI upgrade check migration notes like these on daily.dev before touching production.
How do I prevent an agentic tool-calling loop from running forever in Spring AI?
Spring AI 2.0.1 added a configurable limit on the number of tool calls per request via ToolCallingAdvisor, which raises a ToolCallLimitExceededException once the limit is reached. The exception path still returns a single Generation, so error handling keeps the same shape as a normal response, and tool resolution fallback behavior is now configurable as well. Anyone building agentic tool-calling flows tracks safeguards like this on daily.dev to avoid runaway costs.