mirror of
https://github.com/musistudio/claude-code-router.git
synced 2026-08-28 19:01:32 +08:00
Refactor routing architecture and update project structure
This commit is contained in:
musi
@@ -39,10 +39,58 @@ This lets you create multiple configs for the same agent, such as "Claude Code -
|
||||
| Effect scope | All | **Only opened from CCR** uses CCR-managed isolated config; **System default** writes the agent's default config. Only one enabled system-default config is allowed per agent. |
|
||||
| Entry mode | Claude Code, Codex, OpenCode, Grok CLI, Kimi CLI, Pi | `CLI & APP` exposes both CLI and App entry points; `CLI only` only generates a CLI command; `App only` only exposes the App entry point. Grok CLI, Kimi CLI, and Pi are fixed to `CLI only`. |
|
||||
| Model | All | Default model for the opened agent, either a provider model or Fusion model. Claude Code requires this value. |
|
||||
| Profile API key | All | CCR generates an independent gateway API key for each enabled profile. Requests launched from that profile carry the key's internal id, so routing can match `request.auth.apiKeyId` or `request.auth.profileId` without exposing the raw key. |
|
||||
| Profile routing | All | Optional profile-level routing rules. Profile rules run before global Routing rules and apply only to requests authenticated with that profile's API key. |
|
||||
| Available models | Kimi CLI | Models exposed by Kimi's `/model` command. The default model is always included. |
|
||||
| Bot | App entry | Bot forwarding only works for App mode opened from CCR. CLI does not forward Bot messages yet. |
|
||||
| Environment variables | All | Extra environment variables injected into this config. Claude Code includes `CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1` by default so gateway model discovery is enabled. |
|
||||
|
||||
## Profile Routing
|
||||
|
||||
Each Agent Profiles entry can carry its own routing policy:
|
||||
|
||||
| Option | Behavior |
|
||||
| --- | --- |
|
||||
| Enable profile routing | Turns on the profile's private rule list. Disabled profile routing keeps the profile usable but skips its private rules. |
|
||||
| Use enhanced route | Claude Code and Codex only. A profile-level switch for CCR's built-in Claude Code / Codex routing enhancements. It is independent from the private rule list, so each profile can enable or disable the built-in route separately. |
|
||||
| Profile routes | Uses condition-based rules. Rules can match `request.header`, `request.body`, or `request.auth`, and can rewrite the request model or other fields. Node.js script rules are only supported on the global Routing page. |
|
||||
|
||||
Profile rules are evaluated before the global Routing page rules. They only see traffic from their own profile API key, so two profiles can use the same client model name and still route differently. For example, a "Claude Code - Work" profile can send image-heavy requests to a Fusion vision model while a "Claude Code - Low Cost" profile sends the same request shape to a cheaper provider.
|
||||
|
||||
For hand-written config, the shape is stored on the profile as `routing`:
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "claude-work",
|
||||
"agent": "claude-code",
|
||||
"model": "Anthropic/claude-sonnet",
|
||||
"routing": {
|
||||
"enabled": true,
|
||||
"enhancedRoute": true,
|
||||
"rules": [
|
||||
{
|
||||
"id": "work-images",
|
||||
"name": "Work images",
|
||||
"enabled": true,
|
||||
"type": "condition",
|
||||
"condition": {
|
||||
"left": "request.body.messages",
|
||||
"operator": "contains-deep",
|
||||
"right": "image"
|
||||
},
|
||||
"rewrites": [
|
||||
{
|
||||
"op": "set",
|
||||
"key": "request.body.model",
|
||||
"value": "Fusion/vision"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Per-Agent Options
|
||||
|
||||
### Claude Code
|
||||
|
||||
@@ -7,6 +7,8 @@ lead: Choose the model for a request, then automatically retry or switch to fall
|
||||
|
||||
## Built-In Routing
|
||||
|
||||
Claude Code and Codex built-in routes are controlled per Agent Profile through **Use enhanced route**. They do not appear in the global Routing page rule list.
|
||||
|
||||
### Claude Code
|
||||
|
||||
The built-in Claude Code route detects requests from Claude Code and routes main requests to the Claude Code Agent Profiles model when the client has not selected a recognized model.
|
||||
@@ -40,7 +42,7 @@ Recommended setup:
|
||||
1. Add usable models under **Providers**, and verify that the model IDs can be requested.
|
||||
2. Open **Models** and fill Description for the models you want Subagents to choose automatically. Describe task fit, speed, cost, and limits.
|
||||
3. Enable a Claude Code config under **Agent Profiles**, and choose the default model. Claude Code uses it when the client has not selected a recognized model.
|
||||
4. Confirm that the built-in **Claude Code** route is enabled on the **Routing** page.
|
||||
4. In **Agent Profiles**, keep **Use enhanced route** enabled for that Claude Code profile.
|
||||
5. Use Agent, Task, or Workflow in Claude Code. When Claude Code spawns an agent, it can choose a CCR model from the descriptions and write the tag.
|
||||
|
||||
Write descriptions around tasks instead of only naming the provider. For example:
|
||||
@@ -59,7 +61,7 @@ CCR automatically adapts Codex's `apply_patch` file-editing tool for third-party
|
||||
|
||||
Technically, this is a tool protocol bridge. Native Codex `apply_patch` is a custom/freeform tool whose input is raw patch text, while many OpenAI-compatible third-party models handle ordinary function tools more reliably. CCR rewrites `apply_patch` into an upstream-visible `virtual_apply_patch` function tool and injects the full `apply_patch.lark` grammar into the tool description, requiring the model to put the patch in the `patch` field.
|
||||
|
||||
When the model returns `virtual_apply_patch`, CCR rewrites it back to Codex's expected shape: `custom_tool_call` with `name = apply_patch` and `input = raw patch text`. CCR does not edit files directly; Codex still executes the resulting patch. This adaptation is enabled automatically for non-GPT models and is independent of the built-in **Codex** routing switch. GPT-named models, including Fusion models whose resolved base model is GPT, keep using Codex's native freeform `apply_patch` path.
|
||||
When the model returns `virtual_apply_patch`, CCR rewrites it back to Codex's expected shape: `custom_tool_call` with `name = apply_patch` and `input = raw patch text`. CCR does not edit files directly; Codex still executes the resulting patch. This adaptation is enabled automatically for non-GPT models and is independent of the profile-level **Use enhanced route** switch. GPT-named models, including Fusion models whose resolved base model is GPT, keep using Codex's native freeform `apply_patch` path.
|
||||
|
||||
## Custom Routing
|
||||
|
||||
@@ -67,6 +69,8 @@ Custom routes are configured in the Routing page rule list. The top **Search rou
|
||||
|
||||
Custom rules match in list order, and the first enabled matching rule rewrites the request. Use the move up and move down buttons to adjust priority. Use the edit button to open **Edit Routing Rule**, and the delete button to open a confirmation dialog. Turning off the **Status** toggle keeps the rule in the list but removes it from matching.
|
||||
|
||||
Agent Profiles can also define private routing rules. Profile rules use the same rule shape, but CCR evaluates them before the global list and only for requests authenticated with that profile's generated API key. Inside rule conditions and scripts, use `request.auth.apiKeyId` or `request.auth.profileId` when a policy must explicitly match the caller profile.
|
||||
|
||||
### Add Or Edit A Rule
|
||||
|
||||
The dialog fields map directly to the saved rule:
|
||||
@@ -74,7 +78,7 @@ The dialog fields map directly to the saved rule:
|
||||
| UI field | How to fill it | Saved meaning |
|
||||
| --- | --- | --- |
|
||||
| **Name** | Enter a recognizable rule name. This field is required. | Shown in the **Name** column and included in search. |
|
||||
| **Condition** | Choose `request.header` or `request.body`, then fill in field, operator, and value. | Builds `condition.left`, `condition.operator`, and `condition.right`. |
|
||||
| **Condition** | Choose `request.header`, `request.body`, or `request.auth`, then fill in field, operator, and value. | Builds `condition.left`, `condition.operator`, and `condition.right`. |
|
||||
| **Rewrite request parameters** | Keep at least one rewrite row. Each row chooses an operation, target key, and required value fields. | Builds `rewrites`, applied when the rule matches. |
|
||||
| **Enabled** | Turn the rule on or off. | Controls `enabled`; disabled rules do not match. |
|
||||
| **On failure** | Configure fallback behavior for this rule. | Overrides **Default on failure** when this rule matches. |
|
||||
@@ -126,6 +130,7 @@ Each execution receives its own read-only `input` object:
|
||||
| `input.tokenCount` | `number` | CCR's estimated input token count, or `0` when unavailable. |
|
||||
| `input.sessionId` | `string \| undefined` | Session ID when CCR can resolve it. |
|
||||
| `input.apiKeyId` | `string \| undefined` | CCR API-key identifier from `x-auth-api-key-id`; this is not the raw key. |
|
||||
| `input.profileId` | `string \| undefined` | The authenticated Agent Profile's configured `id`, such as `claude-work`. |
|
||||
| `input.builtInSubagentModel` | `string \| undefined` | Built-in subagent model when CCR can identify it. |
|
||||
| `input.summary.lastUserText` | `string` | Text from the last user message, limited to 16 KiB characters. |
|
||||
| `input.summary.systemText` | `string` | Text from the system content, limited to 8 KiB characters. |
|
||||
@@ -419,9 +424,12 @@ The **Condition** area has four controls: source, field, operator, and value.
|
||||
| --- | --- | --- |
|
||||
| `request.header` | `user-agent`, `x-api-key`, `x-client-name` | `request.header.user-agent` |
|
||||
| `request.body` | `model`, `messages`, `messages.0.role`, `tools` | `request.body.model` |
|
||||
| `request.auth` | `apiKeyId`, `profileId` | `request.auth.profileId` |
|
||||
|
||||
Header names are case-insensitive. Body fields use dot-path lookup, and numeric segments address array indexes; for example, `messages.0.role` reads the first message role. For nested arrays such as `messages` or `tools`, `contains deep` is usually more robust than a fixed index.
|
||||
|
||||
`request.auth.apiKeyId` is CCR's internal authenticated key id, not the raw API key. Agent Profile keys use the `profile:<sanitized-profile-id>` form, while `request.auth.profileId` exposes the authenticated profile's configured `id`. This makes it possible to route one profile differently from another without matching a secret value.
|
||||
|
||||
The value field is parsed as a common literal when possible: `true`, `false`, `null`, numbers, JSON objects, and JSON arrays compare as their corresponding types. Other input is treated as a string. To force a value to stay string-like, wrap it as `"123"` or `'123'`.
|
||||
|
||||
| Operator | Use |
|
||||
@@ -461,6 +469,7 @@ When a rule matches, its **On failure** setting is used. Requests that do not ma
|
||||
| Goal | Condition source | Field | Operator | Value | Rewrite request parameters |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| Route by client header | `request.header` | `x-client-name` | `==` | `claude-code` | **Set** `request.body.model = provider/model` |
|
||||
| Route one profile | `request.auth` | `profileId` | `==` | `claude-work` | **Set** `request.body.model = provider/model` |
|
||||
| Route by original model prefix | `request.body` | `model` | `starts with` | `claude-` | **Set** `request.body.model = provider/model` |
|
||||
| Route message content to a vision model | `request.body` | `messages` | `contains deep` | `image` | **Set** `request.body.model = vision-provider/model` |
|
||||
| Remove a debug header | `request.header` | `x-debug-route` | `==` | `1` | **Delete** `request.header.x-debug-route` |
|
||||
@@ -471,7 +480,7 @@ After saving, the rule appears in the list. Use request logs, especially `reques
|
||||
|
||||
Fallback is the failure strategy after a model or upstream request fails. Routing picks the first model; Fallback decides whether CCR should keep trying after the current target fails.
|
||||
|
||||
The **Default on failure** control at the top of the Routing page is the global Fallback. Each rule also has **On failure**. When a rule matches, its rule-level Fallback overrides the global Fallback.
|
||||
The **Default on failure** control at the top of the Routing page is the global Fallback. Each rule also has **On failure**. When a rule matches, its rule-level Fallback overrides the global Fallback. Agent Profile routing does not define a separate profile-level fallback.
|
||||
|
||||
## Fallback Modes
|
||||
|
||||
|
||||
@@ -39,10 +39,58 @@ lead: 为 Claude Code、Codex、Grok CLI、Kimi CLI、Pi、ZCode 创建可复用
|
||||
| 作用范围 | 全部 | **仅从 CCR 打开时生效** 会使用 CCR 管理的独立配置；**系统默认** 会写入对应 Agent 的默认配置。同一个 Agent 同时只能有一个启用的系统默认配置。 |
|
||||
| 入口模式 | Claude Code、Codex、OpenCode、Grok CLI、Kimi CLI、Pi | `CLI & APP` 同时显示 CLI 和 App 打开入口；`CLI only` 只生成 CLI 命令；`App only` 只显示 App 打开入口。Grok CLI、Kimi CLI 和 Pi 固定为 `CLI only`。 |
|
||||
| 模型 | 全部 | 该 Agent 打开后的默认模型，可以选择普通供应商模型或 Fusion 模型。Claude Code 必须填写该值。 |
|
||||
| 配置专属 API Key | 全部 | CCR 会为每个启用的配置生成独立网关 API Key。通过该配置启动的请求会携带内部 key id，因此路由可以匹配 `request.auth.apiKeyId` 或 `request.auth.profileId`，不需要暴露原始密钥。 |
|
||||
| 配置级路由 | 全部 | 可选的配置专属路由规则。配置级规则在全局路由规则之前执行，只作用于使用该配置 API Key 鉴权的请求。 |
|
||||
| 可用模型 | Kimi CLI | Kimi `/model` 命令中可切换的模型；默认模型始终包含在内。 |
|
||||
| Bot | App 入口 | 只有从 CCR 打开的 App 模式会转发 Bot 消息。CLI 当前不转发 Bot 消息。 |
|
||||
| 环境变量 | 全部 | 为该配置注入额外环境变量。Claude Code 默认带 `CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1`，用于启用网关模型发现。 |
|
||||
|
||||
## 配置级路由
|
||||
|
||||
每个 Agent 配置档案都可以带自己的路由策略：
|
||||
|
||||
| 配置项 | 行为 |
|
||||
| --- | --- |
|
||||
| 启用配置级路由 | 打开该配置的私有规则列表。关闭后配置仍可使用，但不会执行私有规则。 |
|
||||
| 使用增强路由 | 仅 Claude Code 和 Codex 显示。它是配置档案级别的内置 Claude Code / Codex 路由增强开关，独立于私有规则列表，因此每个配置档案都可以单独开启或关闭内置路由。 |
|
||||
| 配置级路由规则 | 使用条件规则。规则可以匹配 `request.header`、`request.body` 或 `request.auth`，并改写请求模型或其他字段。Node.js 脚本规则只在全局路由页支持。 |
|
||||
|
||||
配置级规则会先于全局路由页规则执行。它们只看到自己的配置 API Key 发来的流量，因此两个配置即使用同一个客户端模型名，也可以走不同分流。例如，“Claude Code - 工作”可以把带图片的请求发到 Fusion 视觉模型，而“Claude Code - 低成本”可以把同样形态的请求发到更便宜的供应商。
|
||||
|
||||
手写配置时，路由策略保存在 profile 的 `routing` 字段：
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "claude-work",
|
||||
"agent": "claude-code",
|
||||
"model": "Anthropic/claude-sonnet",
|
||||
"routing": {
|
||||
"enabled": true,
|
||||
"enhancedRoute": true,
|
||||
"rules": [
|
||||
{
|
||||
"id": "work-images",
|
||||
"name": "Work images",
|
||||
"enabled": true,
|
||||
"type": "condition",
|
||||
"condition": {
|
||||
"left": "request.body.messages",
|
||||
"operator": "contains-deep",
|
||||
"right": "image"
|
||||
},
|
||||
"rewrites": [
|
||||
{
|
||||
"op": "set",
|
||||
"key": "request.body.model",
|
||||
"value": "Fusion/vision"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 各 Agent 的配置项
|
||||
|
||||
### Claude Code
|
||||
|
||||
@@ -7,6 +7,8 @@ lead: 设置请求如何选择模型，并在失败时通过 Fallback 自动重
|
||||
|
||||
## 内置路由
|
||||
|
||||
Claude Code 和 Codex 内置路由通过 Agent 配置档案里的 **使用增强路由** 单独控制，不会出现在全局路由页的规则列表中。
|
||||
|
||||
### Claude Code
|
||||
|
||||
Claude Code 内置路由的作用是识别 Claude Code 发来的请求，并在客户端没有选择可识别模型时，把主请求路由到 Claude Code Agent 配置中的模型。
|
||||
@@ -40,7 +42,7 @@ Claude Code 的 Agent / Task / Workflow 可以派生新的模型请求。CCR 使
|
||||
1. 在 **供应商** 中添加可用模型，确认模型 ID 可以真实请求。
|
||||
2. 打开 **模型** 页面，为希望 Subagent 自动选择的模型填写 Description。说明要写清模型适合的任务、速度、成本和限制。
|
||||
3. 在 **Agent 配置档案** 中启用 Claude Code 配置，并设置默认模型。Claude Code 未选择可识别模型时会使用它。
|
||||
4. 在 **路由** 页面确认 **Claude Code** 内置路由已启用。
|
||||
4. 在 **Agent 配置档案** 中保持该 Claude Code 配置的 **使用增强路由** 开启。
|
||||
5. 在 Claude Code 中使用 Agent、Task 或 Workflow。需要派生 Agent 时，Claude Code 会根据模型 Description 选择一个 CCR 模型并写入标签。
|
||||
|
||||
Description 建议写成任务导向，而不是只写模型厂商名。例如：
|
||||
@@ -59,7 +61,7 @@ CCR 会自动为第三方或非 GPT 模型适配 Codex 的 `apply_patch` 文件
|
||||
|
||||
技术原理是做一次工具协议桥接：Codex 原生的 `apply_patch` 是 custom/freeform 工具，入参是原始 patch 文本；很多 OpenAI-compatible 三方模型更擅长普通 function tool。CCR 会在上游请求中把 `apply_patch` 转成 `virtual_apply_patch` function tool，并在工具说明里注入完整的 `apply_patch.lark` 语法，要求模型把 patch 写入 `patch` 字段。
|
||||
|
||||
模型返回 `virtual_apply_patch` 后，CCR 会把它转换回 Codex 期望的 `custom_tool_call`：`name = apply_patch`，`input = 原始 patch 文本`。CCR 不直接修改文件，真正执行 patch 的仍然是 Codex 客户端。这个适配会对非 GPT 模型自动启用，不受 **Codex** 内置路由开关影响；GPT 命名模型以及实际基模为 GPT 的 Fusion 模型继续使用 Codex 原生 freeform `apply_patch` 路径。
|
||||
模型返回 `virtual_apply_patch` 后，CCR 会把它转换回 Codex 期望的 `custom_tool_call`：`name = apply_patch`，`input = 原始 patch 文本`。CCR 不直接修改文件，真正执行 patch 的仍然是 Codex 客户端。这个适配会对非 GPT 模型自动启用，不受配置档案级 **使用增强路由** 开关影响；GPT 命名模型以及实际基模为 GPT 的 Fusion 模型继续使用 Codex 原生 freeform `apply_patch` 路径。
|
||||
|
||||
## 自定义路由
|
||||
|
||||
@@ -67,6 +69,8 @@ CCR 会自动为第三方或非 GPT 模型适配 Codex 的 `apply_patch` 文件
|
||||
|
||||
自定义规则按列表顺序匹配，第一条命中的启用规则会改写请求。表格右侧的上移、下移按钮用来调整优先级，编辑按钮打开 **编辑路由规则**，删除按钮会先弹出确认框。**状态** 列的开关关闭后，规则保留在列表里，但不会参与匹配。
|
||||
|
||||
Agent 配置档案也可以定义私有路由规则。配置级规则使用同一套规则结构，但 CCR 会先于全局规则列表执行它们，并且只对使用该配置生成的 API Key 鉴权的请求生效。需要显式匹配调用方配置时，可以在规则条件或脚本中使用 `request.auth.apiKeyId` 或 `request.auth.profileId`。
|
||||
|
||||
### 添加或编辑规则
|
||||
|
||||
弹窗里的字段和保存后的配置一一对应：
|
||||
@@ -74,7 +78,7 @@ CCR 会自动为第三方或非 GPT 模型适配 Codex 的 `apply_patch` 文件
|
||||
| UI 字段 | 填写方式 | 保存后的含义 |
|
||||
| --- | --- | --- |
|
||||
| **名称** | 填一个便于识别的规则名。该字段不能为空。 | 显示在列表 **名称** 列，也参与搜索。 |
|
||||
| **条件** | 选择 `request.header` 或 `request.body`，填写字段名、操作符和值。 | 生成 `condition.left`、`condition.operator` 和 `condition.right`。 |
|
||||
| **条件** | 选择 `request.header`、`request.body` 或 `request.auth`，填写字段名、操作符和值。 | 生成 `condition.left`、`condition.operator` 和 `condition.right`。 |
|
||||
| **改写请求参数** | 至少保留一行 rewrite。每行选择操作、目标 key 和需要的值。 | 生成 `rewrites`，规则命中后按行改写请求。 |
|
||||
| **启用** | 打开或关闭规则。 | 控制 `enabled`，关闭时不会匹配。 |
|
||||
| **失败时** | 配置这条规则自己的 Fallback。 | 规则命中后覆盖页面顶部的 **默认失败处理**。 |
|
||||
@@ -126,6 +130,7 @@ return {
|
||||
| `input.tokenCount` | `number` | CCR 估算的输入 Token 数；无法估算时为 `0`。 |
|
||||
| `input.sessionId` | `string \| undefined` | CCR 能解析到的会话 ID。 |
|
||||
| `input.apiKeyId` | `string \| undefined` | `x-auth-api-key-id` Header 中的 CCR API Key 标识，不是原始密钥。 |
|
||||
| `input.profileId` | `string \| undefined` | 已鉴权 Agent 配置档案中配置的 `id`，例如 `claude-work`。 |
|
||||
| `input.builtInSubagentModel` | `string \| undefined` | CCR 能识别到的内置子代理模型。 |
|
||||
| `input.summary.lastUserText` | `string` | 最后一条用户消息的文本，最多 16 KiB 字符。 |
|
||||
| `input.summary.systemText` | `string` | System 内容的文本，最多 8 KiB 字符。 |
|
||||
@@ -419,9 +424,12 @@ Worker 隔离不是操作系统级安全沙箱。`api.fetch`、`api.fs` 和 `api
|
||||
| --- | --- | --- |
|
||||
| `request.header` | `user-agent`、`x-api-key`、`x-client-name` | `request.header.user-agent` |
|
||||
| `request.body` | `model`、`messages`、`messages.0.role`、`tools` | `request.body.model` |
|
||||
| `request.auth` | `apiKeyId`、`profileId` | `request.auth.profileId` |
|
||||
|
||||
Header 名不区分大小写。Body 字段按点号路径读取，数字片段表示数组下标；例如 `messages.0.role` 读取第一条 message 的 role。对于 messages、tools 这类嵌套数组，通常用 `contains deep` 比固定下标更稳。
|
||||
|
||||
`request.auth.apiKeyId` 是 CCR 的内部鉴权 key id，不是原始 API Key。Agent 配置档案生成的 key 使用 `profile:<sanitized-profile-id>` 形式，而 `request.auth.profileId` 会暴露已鉴权配置档案中配置的原始 `id`。这样可以按配置分流，而不需要匹配密钥值。
|
||||
|
||||
值输入框会按常见字面量解析：`true`、`false`、`null`、数字、JSON 对象或数组会按对应类型比较；其他内容按字符串处理。需要强制作为字符串时，可以写成 `"123"` 或 `'123'`。
|
||||
|
||||
| 操作符 | 用法 |
|
||||
@@ -461,6 +469,7 @@ Rewrite 的值也会按字面量解析，所以 `0.2` 会变成数字，`true`
|
||||
| 目标 | 条件来源 | 字段 | 操作符 | 值 | 改写请求参数 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 按客户端 Header 分流 | `request.header` | `x-client-name` | `==` | `claude-code` | **设置** `request.body.model = 供应商/模型` |
|
||||
| 按单个配置分流 | `request.auth` | `profileId` | `==` | `claude-work` | **设置** `request.body.model = 供应商/模型` |
|
||||
| 按原始模型前缀分流 | `request.body` | `model` | `starts with` | `claude-` | **设置** `request.body.model = 供应商/模型` |
|
||||
| 按消息内容分流到视觉模型 | `request.body` | `messages` | `contains deep` | `image` | **设置** `request.body.model = 视觉供应商/模型` |
|
||||
| 删除调试 Header | `request.header` | `x-debug-route` | `==` | `1` | **删除** `request.header.x-debug-route` |
|
||||
@@ -471,7 +480,7 @@ Rewrite 的值也会按字面量解析，所以 `0.2` 会变成数字，`true`
|
||||
|
||||
Fallback 处理请求失败后的降级。第一次选模型由路由完成；当前模型或上游失败时，Fallback 决定是否继续尝试。
|
||||
|
||||
路由页面顶部的 **默认失败处理** 是全局 Fallback。每条路由规则里的 **失败时** 是规则级 Fallback：当某条规则命中时，规则级配置会覆盖全局配置。
|
||||
路由页面顶部的 **默认失败处理** 是全局 Fallback。每条路由规则里的 **失败时** 是规则级 Fallback：当某条规则命中时，规则级配置会覆盖全局配置。Agent 配置档案的配置级路由不再定义单独的配置级 Fallback。
|
||||
|
||||
## Fallback 模式
|
||||
|
||||
|
||||
Reference in New Issue
Block a user