feat: Support multiple models per BYOK platform

[dev-miro26]

Related Issue:

Closes #1399

Description

Previously, BYOK required users to specify only one model name per platform. Switching between models (e.g., Claude Opus vs Sonnet vs Haiku on Anthropic) required manually editing the model name each time, which is tedious given that most LLM platforms offer several models with different prices and capabilities.
This PR adds support for saving and managing multiple model names per BYOK platform:

• Database: New model_types JSON column on the provider table (with migration and backfill of existing model_type values).
• Server: Provider, ProviderIn, and ProviderOut models updated. Create/update endpoints ensure model_types stays in sync with the active model_type.
• Frontend – Models settings: The single model-type text input is replaced with a multi-model chip UI. Users can add models from a suggestions dropdown (pre-populated per platform) or type custom names. Clicking a chip sets it as the active model; each chip has an X to remove it. The active model is highlighted with a star icon and green border.
• Frontend – Add Worker: When assigning a custom model to an agent, the model type field now shows a dropdown of the user's saved models for the selected platform instead of a free-text input.
• Suggested models: Added commonly used model identifiers for OpenAI, Anthropic, Gemini, DeepSeek, Mistral, Grok, Qwen, Z.ai, Moonshot, and Ernie to help users discover models without external research.
• Backward compatible: model_type remains the "active" model used by chatStore and the backend agent system. No changes to the task execution flow.

Testing Evidence (REQUIRED)

• I have included human-verified testing evidence in this PR.
• This PR includes frontend/UI changes, and I attached screenshot(s) or screen recording(s).
• No frontend/UI changes in this PR.

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Contribution Guidelines Acknowledgement

• I have read and agree to the Eigent Contribution Guideline

[dev-miro26]

Hi, @4pmtong
Could you please check this PR and left comment kinldy?

[4pmtong]

Thanks @dev-miro26 for contribution! Could @fengju0213 @a7m-1st help review it?

[fengju0213]

seems like some ui bug

[dev-miro26]

@fengju0213
Let me check and fix.

[fengju0213]

The changes were not persisted to the provider, and even when the model was modified, the old model was still being used.

[fengju0213]

i think hardcode suggestedModels may not a good approach？i think we already fetch the model from camel side？

[dev-miro26]

I will fix all issues soon!

[bytecii]

IMO we shouldn't store these model selection candidates in the database

[dev-miro26]

IMO we shouldn't store these model selection candidates in the database

[dev-miro26]

@4pmtong @fengju0213 @bytecii

I’ve updated the code. The suggestedModels (model selection candidates) are currently hardcoded because fetching model_type values requires an API key for each model_provider.

Example: If we want to get the models from OpenAI, we need an OpenAI API key:

curl https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "OpenAI-Organization: $ORGANIZATION_ID" \
  -H "OpenAI-Project: $PROJECT_ID"

So, to retrieve the models for each BYOK provider and populate suggestedModels, we would need the corresponding API key for each provider.

Could you please review it again and kindly leave any feedback?

[dev-miro26]

Hi, @fengju0213
Could you please review this PR again?