mirror of
https://github.com/zhayujie/chatgpt-on-wechat.git
synced 2026-07-18 20:17:09 +08:00
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:
@@ -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>
|
||||
|
||||
Reference in New Issue
Block a user