Support task-specific AI model selection
Summary
Allow users to optionally assign different AI models to different Assistant task types instead of using one shared language model for all text-based AI capabilities.
For example, users could select one model for Assistant chat and another model for translation.
Background
The current AI model configuration already allows selecting dedicated models for several specialized AI capabilities, such as image generation or speech-to-text.
However, many text-based Assistant tasks currently share the same configured language model. This means that tasks with very different requirements—such as conversational assistance and translation—must use the same model.
Problem
Different AI tasks benefit from different types of language models.
For example:
- A chat model is typically optimized for reasoning, conversation, and instruction following.
- A translation model is often smaller, faster, and specifically optimized for multilingual translation.
- Future Assistant capabilities may also benefit from specialized models with different strengths.
Using specialized models has become increasingly common, especially with OpenAI-compatible backends that expose multiple models optimized for different workloads.
This distinction is especially valuable for self-hosted AI deployments, where multiple local models are commonly available and selected according to their strengths, hardware requirements, and performance characteristics.
Describe the solution you'd like
Allow separate model selection for different Assistant task types.
Example:
Default text model:
qwen3-14b
Translation model (optional override):
translategemma-4b-it
The same concept could later be extended to additional Assistant task types, for example:
- Translation
- Summarization
- Text correction
- Document analysis
- Future Assistant capabilities
Backwards compatibility
Existing installations should continue working without any changes.
A simple fallback mechanism could preserve the current behavior:
if task-specific model exists:
use task-specific model
else:
use default text model
Users who do not configure task-specific models would experience exactly the current behavior.
Why this matters
Modern AI deployments increasingly rely on multiple specialized models instead of a single general-purpose model.
OpenAI-compatible backends such as:
- Ollama
- LocalAI
- vLLM
- llama.cpp servers
- other OpenAI-compatible inference servers
can expose multiple models simultaneously.
Allowing task-specific model selection would enable users to combine the strengths of specialized models while keeping a single AI provider configuration inside Nextcloud.
Besides local deployments, hosted AI providers could also benefit by assigning models with different costs, latency, or capabilities to different Assistant tasks.
In addition, this provides a scalable foundation for future Assistant capabilities without requiring additional AI provider configurations or changes to the provider architecture.
Additional context
The Assistant framework already distinguishes between different task types internally.
This proposal does not require changes to AI providers themselves. It simply extends the configuration layer by allowing optional task-specific model overrides while preserving the existing provider architecture and maintaining full backwards compatibility.
One possible implementation could be to keep the current default text model as a fallback while exposing optional per-task model overrides in the AI provider configuration.
This would make the feature completely optional, preserve the existing behavior for all current installations, and provide a flexible foundation for future task-specific AI capabilities.
Thank you very much for considering this feature.
Describe alternatives you've considered
- routing via yaml file in LocalAI did not work (translate=>use gemma) though the created pseudomodell was
recognized
- local machine translation app is no option, as NC AIO runs on a Raspberry PI and the AI Backends are provided
by much stronger hardware in the same LAN only when needed
Support task-specific AI model selection
Summary
Allow users to optionally assign different AI models to different Assistant task types instead of using one shared language model for all text-based AI capabilities.
For example, users could select one model for Assistant chat and another model for translation.
Background
The current AI model configuration already allows selecting dedicated models for several specialized AI capabilities, such as image generation or speech-to-text.
However, many text-based Assistant tasks currently share the same configured language model. This means that tasks with very different requirements—such as conversational assistance and translation—must use the same model.
Problem
Different AI tasks benefit from different types of language models.
For example:
Using specialized models has become increasingly common, especially with OpenAI-compatible backends that expose multiple models optimized for different workloads.
This distinction is especially valuable for self-hosted AI deployments, where multiple local models are commonly available and selected according to their strengths, hardware requirements, and performance characteristics.
Describe the solution you'd like
Allow separate model selection for different Assistant task types.
Example:
The same concept could later be extended to additional Assistant task types, for example:
Backwards compatibility
Existing installations should continue working without any changes.
A simple fallback mechanism could preserve the current behavior:
Users who do not configure task-specific models would experience exactly the current behavior.
Why this matters
Modern AI deployments increasingly rely on multiple specialized models instead of a single general-purpose model.
OpenAI-compatible backends such as:
can expose multiple models simultaneously.
Allowing task-specific model selection would enable users to combine the strengths of specialized models while keeping a single AI provider configuration inside Nextcloud.
Besides local deployments, hosted AI providers could also benefit by assigning models with different costs, latency, or capabilities to different Assistant tasks.
In addition, this provides a scalable foundation for future Assistant capabilities without requiring additional AI provider configurations or changes to the provider architecture.
Additional context
The Assistant framework already distinguishes between different task types internally.
This proposal does not require changes to AI providers themselves. It simply extends the configuration layer by allowing optional task-specific model overrides while preserving the existing provider architecture and maintaining full backwards compatibility.
One possible implementation could be to keep the current default text model as a fallback while exposing optional per-task model overrides in the AI provider configuration.
This would make the feature completely optional, preserve the existing behavior for all current installations, and provide a flexible foundation for future task-specific AI capabilities.
Thank you very much for considering this feature.
Describe alternatives you've considered
recognized
by much stronger hardware in the same LAN only when needed