feat(web): integrate custom providers into the provider credentials section

- Merge the separate custom-providers section into the unified provider
  grid; "Custom" in the add-provider picker now acts as an add-new action
  (trailing + mark) and opens the dedicated modal, supporting multiple
  OpenAI-compatible endpoints
- Simplify the custom provider modal: drop the default-model field, add
  an inline delete button, align colors with the theme
- Keep the legacy single "custom" card visible (models page, chat
  dropdown and legacy config page) while custom_api_key/custom_api_base
  is still in use, so existing single-provider setups don't disappear
- Unify user-facing wording from "vendor" to "provider" in UI and docs
- Restructure custom provider docs (zh/en/ja) around Web console and
  config file usage
This commit is contained in:
zhayujie
2026-06-12 18:03:33 +08:00
parent 63bfab03f6
commit 6b5ee245ae
15 changed files with 234 additions and 400 deletions

View File

@@ -1,51 +1,21 @@
---
title: Custom
description: Custom vendor configuration for third-party API proxies and local models
description: Custom provider configuration for third-party API proxies and local models
---
For model services accessed via the OpenAI-compatible protocol or locally deployed models, such as:
For model services accessed via the OpenAI-compatible protocol, such as:
- **Third-party API proxies**: call multiple models through a unified API base
- **Local models**: models deployed locally with tools like Ollama, vLLM, LocalAI
- **Local models**: models deployed locally with tools like Ollama, vLLM
- **Private deployments**: model services deployed inside an enterprise
<Note>
Difference from the `openai` vendor: when a custom vendor is selected, switching models via `/config model` does not automatically switch the vendor type — the custom API address is always used.
</Note>
## Web Console
## Text Chat
Recommended. On the "Models" page of the Web console, click "Add Provider" and pick "Custom", then fill in the name, API Base and API Key. Multiple custom providers can be added; after adding one, select it together with a model in the "Main Model" card to enable it.
### Third-party API proxy
<img width="900" src="https://cdn.jsdelivr.net/gh/zhayujie/cowagent-assets@main/screenshots/en/web-console-custom-model-config.png" />
```json
{
"bot_type": "custom",
"model": "",
"custom_api_key": "YOUR_API_KEY",
"custom_api_base": "https://{your-proxy.com}/v1"
}
```
| Parameter | Description |
| --- | --- |
| `bot_type` | Must be set to `custom` |
| `model` | Model name; any model name supported by the proxy service |
| `custom_api_key` | API key provided by the proxy service |
| `custom_api_base` | API endpoint provided by the proxy service; must be OpenAI-compatible |
### Local models
Local models usually do not require an API key — only the API base needs to be filled in:
```json
{
"bot_type": "custom",
"model": "qwen3.5:27b",
"custom_api_base": "http://localhost:11434/v1"
}
```
Common local deployment tools and their default endpoints:
Default endpoints of common local deployment tools:
| Tool | Default API Base |
| --- | --- |
@@ -53,17 +23,9 @@ Common local deployment tools and their default endpoints:
| [vLLM](https://docs.vllm.ai) | `http://localhost:8000/v1` |
| [LocalAI](https://localai.io) | `http://localhost:8080/v1` |
### Switching Models
## Configuration File
Switching models under a custom vendor only changes `model` — `bot_type` and the API endpoint remain unchanged:
```
/config model qwen3.5:27b
```
## Configuring Multiple Custom Providers
If you need to configure several OpenAI-compatible third-party services at once (e.g. SiliconFlow, Qiniu), use the `custom_providers` list and activate one by setting `bot_type` to `"custom:<id>"`:
You can also edit `config.json` directly: define multiple providers in the `custom_providers` list and set `bot_type` to `"custom:<id>"` to activate one of them:
```json
{
@@ -71,17 +33,17 @@ If you need to configure several OpenAI-compatible third-party services at once
"custom_providers": [
{
"id": "3f2a9c1b",
"name": "siliconflow",
"api_key": "YOUR_SILICONFLOW_KEY",
"api_base": "https://api.siliconflow.cn/v1",
"model": "deepseek-ai/DeepSeek-V3"
"name": "ProviderA",
"api_key": "YOUR_API_KEY_A",
"api_base": "https://api.a.com/v1",
"model": "deepseek-v3"
},
{
"id": "a1b2c3d4",
"name": "qiniu",
"api_key": "YOUR_QINIU_KEY",
"api_base": "https://api.qnaigc.com/v1",
"model": "deepseek-v3"
"name": "ProviderB",
"api_key": "YOUR_API_KEY_B",
"api_base": "https://api.b.com/v1",
"model": "qwen3-max"
}
]
}
@@ -89,16 +51,12 @@ If you need to configure several OpenAI-compatible third-party services at once
| Parameter | Description |
| --- | --- |
| `custom_providers` | List of custom providers; each item has `id`, `name`, `api_key`, `api_base`, and an optional `model` |
| `bot_type` | Set to `"custom:<id>"` to activate a specific provider; `id` is the provider's unique identifier |
| `id` | Server-generated short identifier (8-char hex); used as the primary key for each provider |
| `name` | User-facing display label can be freely renamed without breaking anything |
| `model` | Optional; when set, this model is used instead of the global `model` field |
| `custom_providers` | List of custom providers; each item has `id`, `name`, `api_base`, `api_key` (optional) and `model` (optional) |
| `bot_type` | Set to `"custom:<id>"` to activate the corresponding provider |
| `id` | Unique identifier (8-char hex); auto-generated when adding via the Web console, or any unique string when editing manually |
| `name` | Display label, can be renamed freely |
| `model` | Model used by this provider, takes effect when activated |
<Note>
The `id` is auto-generated by the web console when you add a provider — you don't need to create it manually. If editing `config.json` by hand, use any unique 8-character hex string (e.g. run `python3 -c "import uuid; print(uuid.uuid4().hex[:8])"`).
</Note>
<Note>
When `bot_type` is exactly `"custom"` (no colon suffix), CowAgent uses the legacy single-provider `custom_api_key` / `custom_api_base` fields, so existing configurations keep working without any changes.
The legacy single-provider configuration (`bot_type` set to `"custom"` with `custom_api_key` / `custom_api_base`) remains fully compatible and keeps working without any changes.
</Note>