Context

Users often encounter confusion when setting spring.ai.model.chat=none, as they may not have considered other types of models beyond chat model.

related issues: - https://github.com/spring-projects/spring-ai/issues/3444 - https://github.com/spring-projects/spring-ai/issues/3561

To address this, I propose introducing a spring.ai.model.all property that allows disabling all models at once.

Current Behavior

Each module needs to be disabled manually.

For example, in the case of the OpenAI module:

spring.ai.model.chat=none
spring.ai.model.audio.speech=none
spring.ai.model.audio.transcription=none
spring.ai.model.image=none
spring.ai.model.embedding=none
spring.ai.model.moderation=none

Expected Behavior

When the property spring.ai.model.all is set, all model types should be disabled.

spring.ai.model.all=none

Comment From: dev-jonghoonpark

If the project team agree with this feature request, I'd like to implement it.

Comment From: ilayaperumalg

@dev-jonghoonpark Could you elaborate on the use case when you would disable all the models? In this case, why can't you just opt in for a specific auto-configuration you need or not use auto-configuration at all?

Comment From: dev-jonghoonpark

@ilayaperumalg

As far as I know, when using multiple models within a single application or using a single model with multiple configurations, it is commonly handled by disabling autoconfiguration.

For example, let’s assume the user is using the OpenAI module.

After configuring spring.ai.model.chat=none in the properties file, the user can configure model-specific keys in code rather than in the properties file by creating beans for each model manually.

However, in this case, the autoconfiguration of other type of models interferes with the application startup.

OpenAI API key must be set

As a result, users are forced to set spring.ai.openai.api-key even if they do not use it - or disable all types of modules.

Of course, users familiar with Spring AI are likely to quickly realize that they need to disable the other types of models. However, based on the issues mentioned above, it seems that confusion can arise in this area. Therefore, I suggest implementing this feature.

Even if it seems better not to add the feature, it would be helpful to include a sufficient explanation.