feat(model): add support for multiple chat models

[lkk214]

Description

• Add an optional title field (defaults to model_name if empty) to HttpModelConfig to customize model name display and avoid conflicts between identical names from different providers

• Maintain backward compatibility with the single chat model configuration, while adding support for multiple models, each with independent settings (e.g., rate_limit, prompt_template)

Configuration Examples

Single Model (Legacy Format)

[model.chat.http]
title = "single_chat"  # <-- New optional field
kind = "openai/chat"
api_endpoint = "http://192.168.1.234:11344/v1"
model_name = "starcoder:1b"
supported_models = ["starcoder:1b", "qwen2.5-coder:1.5b"]

Multiple Models (New Format)

[[model.chat.http]]  # <-- Array syntax
kind = "openai/chat"
api_endpoint = "http://192.168.1.234:11344/v1"
model_name = "deepseek-chat"

[[model.chat.http]]
title = "dp-chat"  # <-- Unique display name
kind = "openai/chat"
model_name = "deepseek-chat"
api_endpoint = "https://api.deepseek.com/v1"
api_key = "sk-xxxxxxxx"
supported_models = ["deepseek-chat", "deepseek-reasoner"]

[zwpaper]

Hi @lkk214, thanks for the contribution, this is really a big changes, may I ask what is your scenarios by add multiple http models?

we depend on the models in many place, It's not safe to do such a big refactor in short time

[lkk214]

Hi @zwpaper,thanks for your review! Here’s the rationale for multi-model support:

• Task-specific optimization: Different models excel at different tasks (e.g., code analysis, doc generation, vulnerability detection). Multi-model configs let users switch models per use case.

• Cost/performance trade-offs: Users may combine large (high-quality) and small (cost-efficient) models, dynamically choosing based on task complexity.

• Real-time comparison(A/B testing): Developers can compare model outputs for specific scenarios - especially useful when evaluating large models, and find the results they want across multiple model outputs

• Extended flexibility: While we currently support multi-model switching under a single API endpoint, this PR extends support to cross-provider models (e.g., local + cloud models). Backward compatibility is maintained for single-model users.

Moreover, we already support multiple http model providers, such as deepseek, openrouter, etc. It would be a better improvement if we can support multiple model configurations, at least we can use them at the same time.

[zwpaper]

Thank you for the comprehensive reply. However, as models become increasingly powerful and versatile, it seems less essential to employ distinct models for various applications.

Tabby relies heavily on the model's usage; we may need to discuss further before implementing such a significant change.

May I inquire if this is utilized in your business scenario?

[lkk214]

@zwpaper Thanks for your reply. I use multiple models in my work. Although a single model can solve most problems, I prefer to find satisfactory answers from multiple models.

This is more like an enhancement than a core change. It won’t affect previous configurations—it simply provides more possibilities for model configuration.

I understand your concerns. Compared to this change, which might impact the core functionality, maintaining code stability is far more important—it’s absolutely critical.

This PR may not be a high priority for Tabby. If the team decides not to merge it, I can close it or leave it as-is for future reference. This can be closed anytime if needed.