spring-projects/spring-ai

Spring AI is worth a look if you are already building on Spring and want model calls, retrieval, and tool use to look like ordinary typed service code. Teams not on the Spring stack should think harder before adopting its abstractions.

The problem

A Java team wants to add a chat endpoint, retrieval over internal documents, and a couple of tool calls to an existing service. The usual path is a pile of thin vendor SDK wrappers: one shape for OpenAI, another for Bedrock, different handling for streaming, and bespoke code to turn model output back into a domain object. Spring AI changes that step by putting those interactions behind Spring-style interfaces and Boot auto-configuration, so a controller can call a typed client and receive a mapped object. What changes is the integration layer — provider plumbing gives way to configuration and interfaces — while the application code stays recognizable Java.

What's different

The mechanism is a portable API across model and vector-store providers, with model-specific options still reachable where needed. Structured output maps responses to POJOs, and a fluent ChatClient, plus an Advisors layer for recurring patterns, makes ordinary call sites read like other Spring clients. Tool calling, MCP support, chat memory with pluggable stores, RAG, an ETL pipeline for document ingestion, and observability hooks mean the common pieces of an AI feature are provided rather than assembled. The trade-off is abstraction debt: you inherit Spring AI's vocabulary, lifecycle, and upgrade schedule, and provider-specific behavior can still leak when you need an option the portable API does not expose. The payoff is consistency across providers and less glue code; the cost is another dependency layer between your app and the vendor.

Who should try it

A good fit is a Spring Boot team that already ships Java services and wants an LLM feature to follow the same configuration, testing, and observability conventions as the rest of the system — especially if there is a real chance of switching or mixing providers. It also suits teams that want retrieval and tool calling without designing their own portable interfaces. A poor fit is a small script or a non-Spring JVM service where the framework's conventions would be overhead, or a team that needs a provider feature this layer does not model and would end up fighting it. Check the version pairing first: 2.x targets Spring Boot 4.x, while 1.1.x targets Spring Boot 3.5.x, so an existing Boot 3.5 codebase should not assume the main branch applies.

Requirements and limitations

The first constraint is the version matrix: pick the branch that matches your Boot generation, and check upgrade notes before cross-version moves. Second, this is a framework, not a hosted service — it still needs a model provider account or a local runtime such as Ollama, plus keys or endpoint configuration; the Getting Started guide is the real entry point. Third, vector stores and chat-memory backends are integrations you must operate or provision, so RAG features bring storage and indexing upkeep beyond the code. Setup is mostly dependency selection through Boot starters; ongoing upkeep is tracking Spring AI releases and the provider APIs behind them.

HotRepo's take

HotRepo only records one daily-board appearance: 2026-10-27, ranked 9th on the new-repository board with 9,588 stars and +6 that day. That single dated snapshot cannot support any claim about momentum or persistence. The practical decision point is the Boot version pairing above — verify it against your project before investing in the APIs.