mirror of
https://github.com/musistudio/claude-code-router.git
synced 2026-07-09 17:18:24 +00:00
Revise configuration docs for agent and provider setup
This commit is contained in:
musi
parent
73bcf2e6e6
commit
371520bb4c
41 changed files with 417 additions and 133 deletions
BIN
docs/public/provider-icons/runapi.jpg
Normal file
BIN
docs/public/provider-icons/runapi.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
|
|
@ -5,12 +5,6 @@ eyebrow: Detailed Configuration
|
|||
lead: Manage API keys that clients use to access the CCR gateway, with expiration and local limits.
|
||||
---
|
||||
|
||||
## Basic Concept
|
||||
|
||||
The API Keys page manages client access keys for CCR. These keys are different from provider `API key` values and provider credential pools: API Keys control who can call CCR; provider keys control how CCR calls upstream providers.
|
||||
|
||||
When API keys are configured, clients should send `Authorization: Bearer <key>` or `x-api-key: <key>`.
|
||||
|
||||
## List Fields
|
||||
|
||||
| Field | Capability |
|
||||
|
|
|
|||
|
|
@ -5,10 +5,6 @@ eyebrow: Detailed Configuration
|
|||
lead: Forward agent messages to instant-messaging platforms or hand off active work after desktop idle.
|
||||
---
|
||||
|
||||
## What Bots Do
|
||||
|
||||
Bots forward agent messages to instant-messaging platforms and can hand off active work after the desktop has been idle.
|
||||
|
||||
## Common Modes
|
||||
|
||||
- **Forward agent messages**: mirror agent messages into IM.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ eyebrow: Detailed Configuration
|
|||
lead: Learn how CCR extensions are loaded, what they can register, and how to create, install, and debug your own extension.
|
||||
---
|
||||
|
||||
## What Extensions Are
|
||||
## Extension Types
|
||||
|
||||
CCR has two extension layers:
|
||||
|
||||
|
|
@ -177,7 +177,7 @@ The recommended flow is through the desktop UI:
|
|||
4. Save the config.
|
||||
5. Open **Server** and restart the gateway.
|
||||
|
||||
CCR stores runtime configuration in SQLite, so add extensions through the UI instead of editing the legacy JSON config file. The extension entry has this shape:
|
||||
CCR stores runtime configuration in SQLite. Add extensions through the UI; the legacy JSON config file is kept here only as a reference. The extension entry has this shape:
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -270,7 +270,7 @@ Proxy route matching rules:
|
|||
| Response is 401 | Routes require gateway API key by default; set `auth: "none"` for debug routes |
|
||||
| Code changes do not apply | Wrapper plugins are not hot reloaded; restart the gateway or CCR |
|
||||
| Port is already in use | Omit `port` in `registerHttpBackend` so CCR can allocate one automatically |
|
||||
| Proxy route is not hit | Confirm proxy mode is enabled, the certificate is installed, and host matches the real request hostname |
|
||||
| Proxy route misses requests | Confirm proxy mode is enabled, the certificate is installed, and host matches the real request hostname |
|
||||
|
||||
## Security Notes
|
||||
|
||||
|
|
|
|||
|
|
@ -5,12 +5,6 @@ eyebrow: Detailed Configuration
|
|||
lead: Customize the CCR home dashboard for system status, account balance, requests, tokens, cost, model distribution, and share cards.
|
||||
---
|
||||
|
||||
## Basic Concept
|
||||
|
||||
Overview is the CCR dashboard. It turns gateway status, provider accounts, request usage, and analysis results into draggable widgets. You can switch the time range, edit widgets, resize them, change styles, and generate shareable cards from selected data.
|
||||
|
||||
Overview depends on request logs, usage stats, and provider account usage. Some widgets require Request logs or Agent observability to be enabled in Settings. Account balance widgets require `Fetch usage` on providers.
|
||||
|
||||
## Top Controls
|
||||
|
||||
| Field | Capability |
|
||||
|
|
|
|||
|
|
@ -5,11 +5,16 @@ eyebrow: Detailed Configuration
|
|||
lead: Create reusable launch configurations for Claude Code, Codex, and ZCode, and open separate agent instances from different configs.
|
||||
---
|
||||
|
||||
## What Agent Config Is
|
||||
## Configuration Flow
|
||||
|
||||
Agent Config is the desktop app capability for managing Claude Code, Codex, and ZCode launch entries. It is not a provider or a routing rule; it is the full entry point for one agent launch: agent type, entry mode, model, effect scope, config file location, and optional Bot binding.
|
||||
1. Add at least one usable provider and model in **Provider Config**, or create the Fusion model you want to use.
|
||||
2. Open **Agent Config** and click **Add profile**.
|
||||
3. Choose the agent type, name the config, then choose the effect scope and entry mode.
|
||||
4. Select a model. The value is usually `Provider name/model name`, and Fusion models can be selected too.
|
||||
5. If the entry mode includes App, optionally bind a Bot and choose whether to forward agent messages or enable handoff.
|
||||
6. Save the config, then open it from the Agent Config card: the terminal button copies the CLI command, and the play button starts the App instance.
|
||||
|
||||
This page exists in Detailed Configuration to explain which config opens which agent instance, rather than provider, routing, or Fusion fields.
|
||||
During trial, prefer **Only opened from CCR** and always open the agent from CCR. That keeps the config limited to CCR-launched instances and avoids changing the Claude Code, Codex, or ZCode setup you open directly from the system.
|
||||
|
||||
## Multi-Instance Mechanism
|
||||
|
||||
|
|
@ -26,20 +31,80 @@ This lets you create multiple configs for the same agent, such as "Claude Code -
|
|||
|
||||
## Common Options
|
||||
|
||||
| Option | Description |
|
||||
| Option | Applies to | Description |
|
||||
| --- | --- | --- |
|
||||
| Agent | All | Claude Code, Codex, or ZCode. ZCode supports App only. |
|
||||
| Config name | All | Identifies the config in CCR and can be used as the `ccr <config-name>` launch target. Names can contain spaces; copied commands are quoted automatically. |
|
||||
| Enabled | All | Disabled configs are not exposed as active launch entries and are not applied as effective startup configs. |
|
||||
| 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 | `CLI & APP` exposes both CLI and App entry points; `CLI only` only generates a CLI command; `App only` only exposes the App entry point. |
|
||||
| Model | All | Default model for the opened agent, either a provider model or Fusion model. For Claude Code, leaving it empty keeps the Claude Code default. |
|
||||
| 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. |
|
||||
|
||||
## Per-Agent Options
|
||||
|
||||
### Claude Code
|
||||
|
||||
| Option | What it does |
|
||||
| --- | --- |
|
||||
| Agent | Claude Code, Codex, or ZCode |
|
||||
| Config name | Identifies the config in CCR and can be used as the `ccr <config-name>` launch target |
|
||||
| Effect scope | **Only opened from CCR** uses CCR-managed isolated config; **System default** writes the agent's default config |
|
||||
| Entry mode | `CLI & APP`, `CLI only`, or `App only`; ZCode supports App only |
|
||||
| Model | Default model for the opened agent, either a provider model or Fusion model |
|
||||
| Bot | App entry can bind a Bot for IM forwarding or handoff |
|
||||
| Model override | Writes `ANTHROPIC_MODEL` for Claude Code. Leave it empty to keep Claude Code's own default model. |
|
||||
| Small fast model | Writes `ANTHROPIC_SMALL_FAST_MODEL` for Claude Code lightweight tasks. Leave it empty to keep the Claude Code default. |
|
||||
| Settings file | System-default mode uses the Claude Code default settings file; Only opened from CCR creates an isolated settings file under CCR's config directory, separated by Agent Config `id`. |
|
||||
| Environment variables | Merged into the Claude Code settings `env`. CCR also writes the gateway endpoint, API key helper, and launch wrapper. |
|
||||
| Bot | Applies only to the Claude App entry. Select a saved Bot, then choose message forwarding or handoff. |
|
||||
|
||||
After Claude Code CLI is opened from CCR, it uses CCR gateway model discovery. In Claude Code CLI, enter `/model` to view and switch the models exposed by CCR, including normal provider models and visible Fusion models.
|
||||
|
||||
Claude App is **zero-config**: when CCR opens Claude App from the desktop app, CCR automatically writes the Claude App gateway config, API key, model discovery list, and isolated user-data directory. No extra user action is required; opening Claude App from CCR automatically completes all necessary configuration. If Claude App is already running, restart it or reopen it from CCR when prompted.
|
||||
|
||||
Claude App and Claude Code CLI use different model-list adapters:
|
||||
|
||||
| Entry | Model list source | Notes |
|
||||
| --- | --- | --- |
|
||||
| Claude Code CLI | CCR gateway model discovery | Use `/model` in the CLI to view the list; selected requests still go through CCR providers, routing, and Fusion. |
|
||||
| Claude App | CCR-generated Claude App inference models | Claude App needs Claude-compatible model names. CCR maps `Provider/model` and Fusion models into model entries Claude App can recognize, while display labels keep the real model meaning visible. |
|
||||
|
||||
### Codex
|
||||
|
||||
| Option | What it does |
|
||||
| --- | --- |
|
||||
| Provider ID | Writes Codex `model_provider`, defaulting to `claude-code-router`. Keep it stable and use only letters, numbers, dots, underscores, or hyphens. |
|
||||
| Provider name | Display name shown in Codex, defaulting to `Claude Code Router`. |
|
||||
| Codex model | Default Codex model. It can be a provider model or Fusion model; if left empty, CCR uses the first available default model. |
|
||||
| Show all sessions | Lets Codex show all sessions. ZCode does not expose this option. |
|
||||
| Config file | Defaults to `~/.codex/config.toml`. Only opened from CCR writes into CCR-managed isolated config directories. |
|
||||
| Environment variables | Injected into Codex CLI or Codex App. Claude Code-specific model discovery variables are not passed to Codex. |
|
||||
| Bot | Applies only to the Codex App entry. |
|
||||
|
||||
After saving, use the terminal button on the config card to copy the Codex CLI command, for example `ccr "Codex - Work"`. Use the play button to open Codex App. CCR generates `config.toml`, a model catalog file, and a middleware launcher so Codex CLI and Codex App use the same CCR model and provider information.
|
||||
|
||||
### ZCode
|
||||
|
||||
| Option | What it does |
|
||||
| --- | --- |
|
||||
| Provider ID | Writes the ZCode provider reference, defaulting to `claude-code-router`. |
|
||||
| Provider name | Display name shown in ZCode, defaulting to `Claude Code Router`. |
|
||||
| ZCode model | Default model when ZCode App opens. It can be a provider model or Fusion model. |
|
||||
| Config file | Defaults to `~/.zcode/cli/config.json`; CCR also writes ZCode v2 config and model cache. |
|
||||
| Environment variables | Injected into ZCode App and the middleware launcher. |
|
||||
| Bot | Applies only to the ZCode App entry. |
|
||||
|
||||
ZCode supports App only, so its entry mode is fixed to `App only`. The `Show all sessions` option is hidden for ZCode.
|
||||
|
||||
## CLI And App Modes
|
||||
|
||||
| Mode | How to open | Best for | Key differences |
|
||||
| --- | --- | --- | --- |
|
||||
| CLI | Click the terminal button to copy the command, then run `ccr <config-name>` in a terminal | Working inside a project directory, shell workflows, scripting | Uses the config-specific wrapper or middleware launcher; usually stays in the terminal without opening a desktop window; Bot forwarding support is pending. |
|
||||
| App | Click the play button in the CCR desktop app | Desktop windows, side-by-side instances, Bot forwarding, handoff | Uses a separate user-data directory per Agent Config; reopening the same config activates the existing window, while different configs can run in parallel. |
|
||||
| CLI & APP | One config exposes both CLI and App entry points | Reusing the same model config in both terminal and desktop App workflows | Both entries share the config name, model, effect scope, and environment variables, but launch differently. |
|
||||
|
||||
## Agent Differences
|
||||
|
||||
### Claude Code
|
||||
|
||||
Claude Code config writes a settings file. With **Only opened from CCR**, CCR creates an isolated settings file under its own config directory and opens Claude Code through a separate launch wrapper.
|
||||
Claude Code CLI config writes a settings file. With **Only opened from CCR**, CCR creates an isolated settings file under its own config directory and opens Claude Code through a separate launch wrapper.
|
||||
|
||||
When opening Claude App from the desktop app, CCR also prepares a separate user-data directory for that config. Different Agent Config entries use different directories, so multiple Claude App instances can run at the same time.
|
||||
|
||||
|
|
|
|||
|
|
@ -70,6 +70,10 @@ Choose a provider below to get started. CCR shows what will be added before savi
|
|||
<span class="provider-import-icon-shell"><img src="../../../provider-icons/siliconflow.png" alt="" loading="lazy" /></span>
|
||||
<span class="provider-import-copy"><span class="provider-import-name">SiliconFlow</span><span class="provider-import-meta">Chat Completions</span></span>
|
||||
</a>
|
||||
<a class="provider-import-button provider-runapi" href="ccr://provider?name=RunAPI&base_url=https%3A%2F%2Frunapi.co%2Fv1&protocol=openai_responses" aria-label="Import RunAPI provider">
|
||||
<span class="provider-import-icon-shell"><img src="../../../provider-icons/runapi.jpg" alt="" loading="lazy" /></span>
|
||||
<span class="provider-import-copy"><span class="provider-import-name">RunAPI</span><span class="provider-import-meta">Responses / Chat Completions</span></span>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
## Embeddable Button Component
|
||||
|
|
|
|||
|
|
@ -5,20 +5,54 @@ eyebrow: Detailed Configuration
|
|||
lead: Configure upstream model services, credentials, protocols, base URLs, and model lists.
|
||||
---
|
||||
|
||||
## Basic Concept
|
||||
## Import Local Agent Login
|
||||
|
||||
A provider is an upstream model service. One provider config describes the upstream address, protocol capabilities, model list, authentication, optional multi-key rotation, and optional account usage fetching.
|
||||
When you add a provider, CCR scans for reusable local agent login state. If usable credentials are found, the add dialog shows the matching import entry. Importing creates a normal provider plus provider plugins, so CCR can reuse the local agent authorization without requiring a pasted API key.
|
||||
|
||||
Each provider needs at least a name, API endpoint, usable protocol, model list, and one valid credential. The add/edit dialog changes which fields are visible depending on preset providers, custom endpoints, local agent login import, and advanced settings.
|
||||
### Claude Code
|
||||
|
||||
Preset providers fill common endpoints, protocols, models, and usage-fetching settings, so they are the recommended starting point. For custom providers, enter the endpoint manually. CCR uses the endpoint and API key to probe protocol compatibility and help identify whether the upstream works with OpenAI Chat, OpenAI Responses, Anthropic Messages, or Gemini Generate.
|
||||
Claude Code import reads local Claude Code OAuth credentials. When a usable access token is available, CCR can import it as a `Claude Code API` provider.
|
||||
|
||||
After import:
|
||||
|
||||
1. The protocol is `anthropic_messages`.
|
||||
2. The default model list includes `claude-sonnet-4-20250514`; you can later add or remove models in the provider model list.
|
||||
3. CCR creates OAuth provider plugins that convert requests to use the Claude Code login state.
|
||||
4. Account usage uses the Anthropic OAuth usage endpoint, so quota state can appear in the provider list, tray, and account panels.
|
||||
|
||||
If CCR only detects login traces but no usable access token, the import entry shows why it cannot be imported. Re-authenticate in Claude Code, then return to CCR and add the provider again.
|
||||
|
||||
### Codex
|
||||
|
||||
Codex import reads the local Codex auth file and model cache. When a Codex access token or refresh token is available, CCR can import it as a `Codex API` provider.
|
||||
|
||||
After import:
|
||||
|
||||
1. The protocol is `openai_responses`.
|
||||
2. The API endpoint points to the Codex backend. The model list always includes at least `gpt-5-codex` and also merges models and display names from the local model cache.
|
||||
3. CCR creates Codex OAuth provider plugins and refreshes access credentials when needed.
|
||||
4. Account usage reads Codex quota, balance, and token-stat endpoints.
|
||||
|
||||
After import, select `Codex API/model-name` in routing or Agent Config. If the model cache is stale, open Codex first so it refreshes the model list, then return to CCR to import again or edit the models.
|
||||
|
||||
### ZCode
|
||||
|
||||
ZCode import reads provider API keys, API endpoints, and model lists from local ZCode config. It can be imported as a `ZCode API` provider only when CCR finds a usable provider key and Base URL.
|
||||
|
||||
After import:
|
||||
|
||||
1. The protocol is `anthropic_messages`.
|
||||
2. Models come from local ZCode config first; if none are configured, CCR uses the ZCode runtime cache or default models.
|
||||
3. CCR creates API-key provider plugins that use the key from local ZCode config for request authentication.
|
||||
4. If the API endpoint matches a built-in CCR preset, account usage settings are reused from that preset.
|
||||
|
||||
If CCR detects ZCode login state but no usable provider API key, the import entry remains unavailable. Configure a usable model provider in ZCode first, then return to CCR and add the provider.
|
||||
|
||||
## Main Fields
|
||||
|
||||
| Field | Capability |
|
||||
| --- | --- |
|
||||
| Select preset provider | Applies a built-in provider template, including default endpoint, supported protocols, default models, icon, provider website, and sometimes account usage settings. Choose `Other / custom API endpoint` for any OpenAI, Anthropic, or Gemini compatible upstream. |
|
||||
| Import local agent login | Appears while adding a provider if CCR finds usable Claude Code, Codex, or ZCode login state on this computer. Importing creates a provider and provider plugin that reuse the local login credential instead of a normal pasted API key. |
|
||||
| Name | Internal CCR display name. It is also used by routing, model selectors, logs, and config references. Names must be unique. |
|
||||
| API endpoint | Upstream API base URL. It controls where requests are sent, and is also used for protocol probing, model discovery, icon detection, and safety checks. Preset providers hide it by default while adding, but it can be overridden in Advanced settings. Custom providers must provide it. |
|
||||
| API key | Default provider credential. When the credential pool is empty, model requests use this key. Protocol probing, model discovery, connection checks, and default usage fetching also use it. Only use a key issued for the selected endpoint. |
|
||||
|
|
@ -27,13 +61,13 @@ Preset providers fill common endpoints, protocols, models, and usage-fetching se
|
|||
| Custom models | Manually adds model IDs that discovery did not return. Use this when the provider lacks a `/models` endpoint or a new model is not in the catalog yet. |
|
||||
| Check Connection | Sends real test requests with the current endpoint, API key, protocol, and selected models. It verifies key, model name, and protocol usability. |
|
||||
| Models to check | Model selection inside the connection-check confirmation dialog. Use it to test only some models. |
|
||||
| Check results | Shows whether each model is available, which protocol matched, and the upstream diagnostic message. Passing results do not automatically add models; the main model selection remains authoritative. |
|
||||
| Check results | Shows whether each model is available, which protocol matched, and the upstream diagnostic message. Results are diagnostic. Add models through the main model selection when you want them saved. |
|
||||
|
||||
## Connectivity Checks
|
||||
|
||||
`Check Connection` sends real model requests for the models you select. It verifies whether the endpoint, API key, protocol, and model IDs are usable. The check limits generated output, but it can still create extra token usage or count against provider-side request limits.
|
||||
|
||||
If the provider bills by request, input tokens, or output tokens, select only the models you need to verify instead of checking every model at once. Check results are diagnostic only; they do not automatically change the model list or usage-fetching settings.
|
||||
If the provider bills by request, input tokens, or output tokens, select only the models you need to verify. Checking every model at once can create unnecessary usage. Review the diagnostics, then adjust the model list or usage-fetching settings manually when needed.
|
||||
|
||||
## Credentials
|
||||
|
||||
|
|
@ -90,7 +124,7 @@ This mode tries provider-hosted CCR account endpoints such as `/.well-known/ccr/
|
|||
|
||||
### HTTP JSON Request
|
||||
|
||||
Use this mode when the provider has a balance or quota JSON endpoint that does not match CCR's standard account format.
|
||||
Use this mode when the provider has a balance or quota endpoint that returns a custom JSON shape.
|
||||
|
||||
| Field | Capability |
|
||||
| --- | --- |
|
||||
|
|
|
|||
|
|
@ -16,9 +16,9 @@ CCR first decides which model the request should use, then forwards the request
|
|||
|
||||
The core shape of a rule is **Condition + Request action**. The condition decides whether the rule matches; the request action changes request fields. The most common action is setting `request.body.model` to a provider model or Fusion model.
|
||||
|
||||
## What Fallback Does
|
||||
## Fallback Handling
|
||||
|
||||
Fallback is the failure strategy after a model or upstream request fails. It does not pick the first model; it decides whether CCR should keep trying after the current target fails.
|
||||
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,10 +5,6 @@ eyebrow: Detailed Configuration
|
|||
lead: Configure the CCR gateway host, port, and Proxy mode for MITM interception and proxying into CCR.
|
||||
---
|
||||
|
||||
## Basic Concept
|
||||
|
||||
The Server page controls how the local CCR gateway listens for requests. Normal model requests usually need only `Host` and `Port`.
|
||||
|
||||
## Main Fields
|
||||
|
||||
| Field | Capability |
|
||||
|
|
|
|||
|
|
@ -5,10 +5,6 @@ eyebrow: Detailed Configuration
|
|||
lead: Configure the CCR system tray icon, balance progress, and tray window widgets.
|
||||
---
|
||||
|
||||
## Basic Concept
|
||||
|
||||
Tray settings live under Settings. They control the system tray icon and the tray window. The tray window can show providers, account balance, token trends, activity, metrics, and model share so you can check CCR status without opening the main window.
|
||||
|
||||
## Top Fields
|
||||
|
||||
| Field | Capability |
|
||||
|
|
|
|||
|
|
@ -5,19 +5,6 @@ eyebrow: Product Documentation
|
|||
lead: Learn what CCR is for, where its boundaries are, and how the docs are organized. Start with Quick Start when you want to configure it; use Detailed Configuration for fields, Bots, or Fusion.
|
||||
---
|
||||
|
||||
## What CCR Can Do
|
||||
|
||||
**Claude Code Router (CCR) is a local model gateway.** It sits between agents such as Claude Code, Codex, and ZCode and upstream model services, then centralizes model management, API keys, routing rules, logs, observability, and Bot relay.
|
||||
|
||||
CCR is useful when:
|
||||
|
||||
- you do not want to maintain the same models and keys separately in every agent.
|
||||
- you want different tasks to automatically use different models: fast models for lightweight background work, stronger models for complex tasks, and Fusion for image or web-search work.
|
||||
- you need request logs showing which provider and model handled a request, whether it succeeded, how long it took, and roughly how much it cost.
|
||||
- you want to forward long-running agent messages to Slack, Telegram, Feishu, WeCom, or other IM platforms.
|
||||
|
||||
CCR listens on the local default address `http://localhost:8080`. Once an agent points to this address, CCR can take over the request and forward it to upstream providers according to routing rules.
|
||||
|
||||
## Documentation Structure
|
||||
|
||||
The top navigation is split into four standalone pages:
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ LINE 适合把 Agent 消息接入已有的 LINE 好友、群聊或 LINE Official
|
|||
|
||||
## 你会用到哪些字段
|
||||
|
||||
CCR 里 LINE 的认证方式叫 **Bot Token**，但填的不是 Telegram 那种 token，而是下面这两个 channel 字段：
|
||||
CCR 里 LINE 的认证方式叫 **Bot Token**，这里需要填写下面这两个 channel 字段：
|
||||
|
||||
| LINE 后台里的名字 | CCR 字段 | 是否必填 | 说明 |
|
||||
| --- | --- | --- | --- |
|
||||
|
|
|
|||
|
|
@ -5,12 +5,6 @@ eyebrow: 详细配置
|
|||
lead: 管理客户端访问 CCR 网关时使用的 API Key，并为每个 Key 设置过期时间和本地限额。
|
||||
---
|
||||
|
||||
## 基本概念
|
||||
|
||||
“API 密钥”页面管理的是客户端访问 CCR 时使用的访问 Key。它不同于供应商配置里的 `API 密钥` 或 `凭据池`：这里的 Key 用来控制谁能调用 CCR；供应商 Key 用来控制 CCR 调用上游供应商。
|
||||
|
||||
如果配置了 API Key，客户端请求需要带 `Authorization: Bearer <key>` 或 `x-api-key: <key>`。
|
||||
|
||||
## 列表字段
|
||||
|
||||
| 字段 | 代表的能力 |
|
||||
|
|
|
|||
|
|
@ -5,10 +5,6 @@ eyebrow: 详细配置
|
|||
lead: 通过 IM Bot 转发 Agent 消息，或在桌面空闲后把任务接力到手机。
|
||||
---
|
||||
|
||||
## 能做什么
|
||||
|
||||
Bot 能把 Agent 消息转发到 IM 平台，也可以在桌面空闲后把任务接力到手机上继续看。
|
||||
|
||||
## 常见模式
|
||||
|
||||
- **转发 Agent 消息**：把消息同步到 IM。
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ eyebrow: 详细配置
|
|||
lead: 了解 CCR 扩展如何加载、能注册哪些能力，并从零创建、安装和调试自己的扩展。
|
||||
---
|
||||
|
||||
## 扩展是什么
|
||||
## 扩展类型
|
||||
|
||||
CCR 的扩展分为两层：
|
||||
|
||||
|
|
@ -177,7 +177,7 @@ module.exports = {
|
|||
4. 保存配置。
|
||||
5. 打开 **Server** 页面，重启网关。
|
||||
|
||||
CCR 的运行配置存储在 SQLite 中，因此推荐通过 UI 添加扩展，而不是编辑旧版 JSON 配置文件。扩展条目的配置结构如下：
|
||||
CCR 的运行配置存储在 SQLite 中。请通过 UI 添加扩展；旧版 JSON 配置文件仅用于参考。扩展条目的配置结构如下：
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ lead: 把基础模型和能力模型组合成新的可选模型，让你已经
|
|||
|
||||
Fusion 的价值在于保留基础模型的手感，同时补齐它缺少的能力。基础模型继续负责推理、写作和代码生成；CCR 在需要时调用图像、搜索或 MCP 工具，把结果整理进上下文，再交给基础模型完成回答。
|
||||
|
||||
保存后的 Fusion 模型会像普通模型一样出现在路由和配置中。它不是额外的一次手动流程，而是一个可复用的新模型：把强文本模型升级成视觉模型，把稳定代码模型升级成可联网模型，也可以把 Agent 模型接入团队内部工具。
|
||||
保存后的 Fusion 模型会像普通模型一样出现在路由和配置中。保存结果是一个可复用的新模型：把强文本模型升级成视觉模型，把稳定代码模型升级成可联网模型，也可以把 Agent 模型接入团队内部工具。
|
||||
|
||||
## 适用能力
|
||||
|
||||
|
|
|
|||
|
|
@ -5,12 +5,6 @@ eyebrow: 详细配置
|
|||
lead: 自定义 CCR 首页组件，查看系统状态、账户余额、请求量、tokens、成本、模型分布和可分享卡片。
|
||||
---
|
||||
|
||||
## 基本概念
|
||||
|
||||
“概览”是 CCR 的仪表盘页面。它把网关运行状态、供应商账户、请求用量和分析结果做成可拖拽组件。你可以切换时间范围、编辑组件、调整大小、切换样式，也可以把部分数据生成分享卡片。
|
||||
|
||||
概览依赖请求日志、用量统计和供应商账户用量。某些组件需要先在“设置”里开启请求日志或 Agent 观测，账户余额组件需要在供应商配置中开启“获取用量”。
|
||||
|
||||
## 顶部控件
|
||||
|
||||
| 字段 | 代表的能力 |
|
||||
|
|
|
|||
|
|
@ -5,11 +5,16 @@ eyebrow: 详细配置
|
|||
lead: 为 Claude Code、Codex、ZCode 创建可复用的启动配置，并通过不同配置打开不同的 Agent 实例。
|
||||
---
|
||||
|
||||
## Agent配置是什么
|
||||
## 配置流程
|
||||
|
||||
Agent配置是桌面 App 中管理 Claude Code、Codex、ZCode 启动入口的能力。它不是供应商或路由规则，而是一次 Agent 启动所需的完整入口：Agent 类型、打开方式、模型、作用范围、配置文件位置，以及可选的 Bot 绑定。
|
||||
1. 先在 **供应商配置** 中添加至少一个可用供应商和模型，或先创建需要使用的 Fusion 模型。
|
||||
2. 打开 **Agent配置**，点击 **添加配置**。
|
||||
3. 选择 Agent 类型，填写配置名称，并选择作用范围和入口模式。
|
||||
4. 选择模型。模型值通常是 `供应商名称/模型名称`，也可以选择 Fusion 模型。
|
||||
5. 如果入口模式包含 App，可以绑定 Bot，并选择是否转发 Agent 消息或开启接力。
|
||||
6. 保存后，从 Agent配置卡片打开：终端图标会复制 CLI 命令，播放图标会启动 App 实例。
|
||||
|
||||
因此详细配置里会有这个页面。它用于解释“用哪个配置打开哪个 Agent 实例”，而不是继续拆分供应商、路由或 Fusion 的字段。
|
||||
试用阶段建议选择 **仅从 CCR 打开时生效**，并且总是从 CCR 打开 Agent。这样配置只影响 CCR 启动的实例，不会改掉你系统里原本直接打开的 Claude Code、Codex 或 ZCode。
|
||||
|
||||
## 多开机制
|
||||
|
||||
|
|
@ -26,20 +31,80 @@ Agent配置是桌面 App 中管理 Claude Code、Codex、ZCode 启动入口的
|
|||
|
||||
## 常用选项
|
||||
|
||||
| 选项 | 说明 |
|
||||
| 选项 | 适用范围 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| Agent | 全部 | 选择 Claude Code、Codex 或 ZCode。ZCode 只支持 App。 |
|
||||
| 配置名称 | 全部 | 用于在 CCR 中识别配置，也会作为 `ccr <配置名称>` 的打开目标。名称可以有空格，复制命令时 CCR 会自动加引号。 |
|
||||
| 启用开关 | 全部 | 关闭后该配置不会出现在打开入口中，也不会被应用为有效启动配置。 |
|
||||
| 作用范围 | 全部 | **仅从 CCR 打开时生效** 会使用 CCR 管理的独立配置；**系统默认** 会写入对应 Agent 的默认配置。同一个 Agent 同时只能有一个启用的系统默认配置。 |
|
||||
| 入口模式 | Claude Code、Codex | `CLI & APP` 同时显示 CLI 和 App 打开入口；`CLI only` 只生成 CLI 命令；`App only` 只显示 App 打开入口。 |
|
||||
| 模型 | 全部 | 该 Agent 打开后的默认模型，可以选择普通供应商模型或 Fusion 模型。Claude Code 留空表示保留 Claude Code 默认模型。 |
|
||||
| Bot | App 入口 | 只有从 CCR 打开的 App 模式会转发 Bot 消息。CLI 当前不转发 Bot 消息。 |
|
||||
| 环境变量 | 全部 | 为该配置注入额外环境变量。Claude Code 默认带 `CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1`，用于启用网关模型发现。 |
|
||||
|
||||
## 各 Agent 的配置项
|
||||
|
||||
### Claude Code
|
||||
|
||||
| 配置项 | 作用 |
|
||||
| --- | --- |
|
||||
| Agent | 选择 Claude Code、Codex 或 ZCode |
|
||||
| 配置名称 | 用于在 CCR 中识别配置，也会作为 `ccr <配置名称>` 的打开目标 |
|
||||
| 作用范围 | “仅从 CCR 打开时生效”会使用 CCR 管理的独立配置；“系统默认”会写入对应 Agent 的默认配置 |
|
||||
| 入口模式 | `CLI & APP`、`CLI only`、`App only`；ZCode 只支持 App |
|
||||
| 模型 | 该 Agent 打开后的默认模型，可以选择普通供应商模型或 Fusion 模型 |
|
||||
| Bot | App 入口可以绑定 Bot，用于 IM 消息转发或接力 |
|
||||
| 模型覆盖 | 写入 Claude Code 使用的 `ANTHROPIC_MODEL`。留空时不覆盖 Claude Code 自己的默认模型。 |
|
||||
| 小模型 | 写入 `ANTHROPIC_SMALL_FAST_MODEL`，供 Claude Code 的轻量任务使用。留空时保留 Claude Code 默认值。 |
|
||||
| 设置文件 | 系统默认模式使用 Claude Code 默认设置文件；仅从 CCR 打开时生效会在 CCR 配置目录下按 Agent配置 `id` 生成独立设置文件。 |
|
||||
| 环境变量 | 会合并到 Claude Code 设置文件的 `env` 中。CCR 同时写入网关地址、API Key helper 和启动包装器。 |
|
||||
| Bot | 只在 Claude App 入口生效，可选择已保存 Bot，并配置转发 Agent 消息或接力。 |
|
||||
|
||||
Claude Code CLI 从 CCR 打开后，会通过 CCR 网关获取模型发现信息。进入 Claude Code CLI 后可以输入 `/model` 查看并切换 CCR 暴露的模型列表，包括普通供应商模型和可见的 Fusion 模型。
|
||||
|
||||
Claude App 是 **零配置（zero-config）**：从 CCR 桌面 App 打开 Claude App 时，CCR 会自动写入 Claude App 网关配置、API Key、模型发现列表和独立用户数据目录。用户不需要增加额外操作，直接使用 CCR 打开就会自动完成所有必要配置；如果 Claude App 已经打开，按提示重启或从 CCR 重新打开即可。
|
||||
|
||||
Claude App 和 Claude Code CLI 的模型列表适配方式不同：
|
||||
|
||||
| 入口 | 模型列表来源 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| Claude Code CLI | CCR 网关模型发现 | CLI 内使用 `/model` 查看列表；选择后请求仍走 CCR 的供应商、路由和 Fusion。 |
|
||||
| Claude App | CCR 生成的 Claude App inference models | Claude App 需要 Claude 兼容的模型名。CCR 会把 `供应商/模型` 和 Fusion 模型映射成 Claude App 可识别的模型项，并用显示名称保留真实模型含义。 |
|
||||
|
||||
### Codex
|
||||
|
||||
| 配置项 | 作用 |
|
||||
| --- | --- |
|
||||
| Provider ID | 写入 Codex 的 `model_provider`，默认是 `claude-code-router`。建议保持稳定，只使用字母、数字、点、下划线或短横线。 |
|
||||
| Provider name | Codex 中展示的供应商名称，默认是 `Claude Code Router`。 |
|
||||
| Codex model | 写入 Codex 默认模型。可以选择普通供应商模型或 Fusion 模型；留空时 CCR 使用可用模型中的默认值。 |
|
||||
| Show all sessions | 让 Codex 显示所有会话。ZCode 不提供该项。 |
|
||||
| 配置文件 | 默认是 `~/.codex/config.toml`。仅从 CCR 打开时生效会写入 CCR 管理的独立配置目录。 |
|
||||
| 环境变量 | 注入 Codex CLI 或 Codex App。Claude Code 专用的模型发现变量不会传给 Codex。 |
|
||||
| Bot | 只在 Codex App 入口生效。 |
|
||||
|
||||
保存后，Codex CLI 使用配置卡片里的终端图标复制命令，例如 `ccr "Codex - Work"`。Codex App 使用播放图标打开。CCR 会生成 `config.toml`、模型目录文件和中间层启动器，让 Codex CLI 与 Codex App 都使用同一套 CCR 模型和供应商信息。
|
||||
|
||||
### ZCode
|
||||
|
||||
| 配置项 | 作用 |
|
||||
| --- | --- |
|
||||
| Provider ID | 写入 ZCode 供应商引用，默认是 `claude-code-router`。 |
|
||||
| Provider name | ZCode 中展示的供应商名称，默认是 `Claude Code Router`。 |
|
||||
| ZCode model | ZCode App 打开后的默认模型。可以选择普通供应商模型或 Fusion 模型。 |
|
||||
| 配置文件 | 默认是 `~/.zcode/cli/config.json`，CCR 还会写入 ZCode v2 配置和模型缓存。 |
|
||||
| 环境变量 | 注入 ZCode App 和中间层启动器。 |
|
||||
| Bot | 只在 ZCode App 入口生效。 |
|
||||
|
||||
ZCode 只支持 App 打开，因此入口模式固定为 `App only`，也不会显示 `Show all sessions`。
|
||||
|
||||
## CLI 与 App 模式区别
|
||||
|
||||
| 模式 | 如何打开 | 适合场景 | 主要差异 |
|
||||
| --- | --- | --- | --- |
|
||||
| CLI | 点击终端图标复制命令，然后在终端运行 `ccr <配置名称>` | 在项目目录中运行 Agent、需要 shell 工作流、需要把命令放进脚本 | 使用对应配置的包装器或中间层启动；通常不启动桌面窗口；当前不转发 Bot 消息。 |
|
||||
| App | 点击播放图标从 CCR 桌面 App 启动 | 需要桌面窗口、多实例并存、Bot 消息转发或接力 | 每个 Agent配置使用独立用户数据目录；同一配置重复打开会激活已有窗口，不同配置可以并行打开。 |
|
||||
| CLI & APP | 同一个配置同时提供 CLI 和 App 入口 | 同一套模型配置既用于终端，也用于桌面 App | 两个入口共用配置名称、模型、作用范围和环境变量，但启动方式不同。 |
|
||||
|
||||
## 各 Agent 的差异
|
||||
|
||||
### Claude Code
|
||||
|
||||
Claude Code 配置会写入设置文件。选择“仅从 CCR 打开时生效”时，CCR 会在自己的配置目录下为这个 Agent配置生成独立设置文件，并通过独立启动包装器打开 Claude Code。
|
||||
Claude Code CLI 配置会写入设置文件。选择“仅从 CCR 打开时生效”时，CCR 会在自己的配置目录下为这个 Agent配置生成独立设置文件，并通过独立启动包装器打开 Claude Code。
|
||||
|
||||
从桌面 App 打开 Claude App 时，CCR 还会为该配置准备独立用户数据目录。不同 Agent配置使用不同目录，因此可以同时打开多个 Claude App 实例。
|
||||
|
||||
|
|
|
|||
|
|
@ -70,6 +70,10 @@ lead: 快速添加常见模型供应商，确认无误后即可保存，减少
|
|||
<span class="provider-import-icon-shell"><img src="../../provider-icons/siliconflow.png" alt="" loading="lazy" /></span>
|
||||
<span class="provider-import-copy"><span class="provider-import-name">硅基流动</span><span class="provider-import-meta">Chat Completions</span></span>
|
||||
</a>
|
||||
<a class="provider-import-button provider-runapi" href="ccr://provider?name=RunAPI&base_url=https%3A%2F%2Frunapi.co%2Fv1&protocol=openai_responses" aria-label="导入 RunAPI 供应商">
|
||||
<span class="provider-import-icon-shell"><img src="../../provider-icons/runapi.jpg" alt="" loading="lazy" /></span>
|
||||
<span class="provider-import-copy"><span class="provider-import-name">RunAPI</span><span class="provider-import-meta">Responses / Chat Completions</span></span>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
## 嵌入式按钮组件
|
||||
|
|
|
|||
|
|
@ -5,20 +5,54 @@ eyebrow: 详细配置
|
|||
lead: 配置 CCR 的上游模型服务，包括协议、基础 URL、模型列表和凭据。
|
||||
---
|
||||
|
||||
## 基本概念
|
||||
## 导入本机 Agent 登录态
|
||||
|
||||
供应商是 CCR 转发请求的上游模型服务。一个供应商配置同时描述了上游地址、协议能力、模型列表、认证方式、可选的多 Key 轮换，以及可选的账号用量读取能力。
|
||||
添加供应商时，CCR 会扫描本机已有的 Agent 登录状态。检测到可复用凭据后，添加弹窗会显示对应导入入口。导入会创建一个普通供应商和配套 provider plugin，让 CCR 复用本机 Agent 授权访问上游服务，不需要再手动粘贴常规 API Key。
|
||||
|
||||
每个供应商至少需要名称、API 地址、可用协议、模型列表和一条可用凭据。添加或编辑供应商时，弹窗中的字段会根据“预设供应商 / 自定义 API 地址 / 本机 Agent 登录态导入 / 高级设置”动态显示。
|
||||
### Claude Code
|
||||
|
||||
预设供应商会自动填入常见 API 地址、协议、模型和用量读取配置，适合优先使用。自定义供应商需要手动填写 API 地址，CCR 会根据 API 地址和 API 密钥做协议探测，帮助判断当前上游是否兼容 OpenAI Chat、OpenAI Responses、Anthropic Messages 或 Gemini Generate。
|
||||
Claude Code 导入会读取本机 Claude Code OAuth 凭据。检测到可用 access token 时，可以导入为 `Claude Code API` 供应商。
|
||||
|
||||
导入后：
|
||||
|
||||
1. 协议使用 `anthropic_messages`。
|
||||
2. 默认模型包含 `claude-sonnet-4-20250514`，后续可以在供应商模型列表中增减模型。
|
||||
3. CCR 会创建 OAuth provider plugin，把请求认证转换为 Claude Code 登录态。
|
||||
4. 账号用量会使用 Anthropic OAuth 用量接口，适合在供应商列表、托盘或账号面板里查看额度状态。
|
||||
|
||||
如果只检测到登录痕迹但没有可用 access token，导入入口会显示不可导入原因。此时先在 Claude Code 中重新登录，再回到 CCR 添加供应商。
|
||||
|
||||
### Codex
|
||||
|
||||
Codex 导入会读取本机 Codex 登录文件和模型缓存。检测到 Codex access token 或 refresh token 时，可以导入为 `Codex API` 供应商。
|
||||
|
||||
导入后：
|
||||
|
||||
1. 协议使用 `openai_responses`。
|
||||
2. API 地址指向 Codex 后端，默认模型至少包含 `gpt-5-codex`，也会合并本机模型缓存中的模型和显示名。
|
||||
3. CCR 会创建 Codex OAuth provider plugin，并在需要时刷新访问凭据。
|
||||
4. 账号用量会读取 Codex 额度、余额和 token 统计接口。
|
||||
|
||||
导入后可以直接在路由或 Agent配置中选择 `Codex API/模型名`。如果模型缓存较旧，可以先打开 Codex 让它刷新模型列表，再回到 CCR 重新导入或编辑模型。
|
||||
|
||||
### ZCode
|
||||
|
||||
ZCode 导入会读取本机 ZCode 配置中的供应商 API Key、API 地址和模型列表。只有检测到可用供应商 Key 和 Base URL 时，才能导入为 `ZCode API` 供应商。
|
||||
|
||||
导入后：
|
||||
|
||||
1. 协议使用 `anthropic_messages`。
|
||||
2. 模型优先来自 ZCode 本机配置；没有配置时会使用 ZCode 运行缓存或默认模型。
|
||||
3. CCR 会创建 API Key provider plugin，把 ZCode 本机配置中的 Key 用于请求认证。
|
||||
4. 如果 API 地址命中 CCR 内置预设，账号用量配置会复用对应预设。
|
||||
|
||||
如果只检测到 ZCode 登录态，但没有检测到可用供应商 API Key，导入入口会显示不可导入。此时需要先在 ZCode 中配置可用模型供应商，再回到 CCR 添加供应商。
|
||||
|
||||
## 主字段
|
||||
|
||||
| 字段 | 代表的能力 |
|
||||
| --- | --- |
|
||||
| 选择 预设供应商 | 套用 CCR 内置供应商模板，包括默认 API 地址、可用协议、默认模型、图标、官网链接和部分供应商的用量读取配置。选择 `其他 / 自定义 API 地址` 时，可以接入任意兼容 OpenAI、Anthropic 或 Gemini 协议的上游服务。 |
|
||||
| 导入本机 Agent 登录态 | 添加供应商时，如果 CCR 在本机发现 Claude Code、Codex 或 ZCode 的可用登录状态，会显示导入入口。导入后 CCR 会生成供应商和对应 provider plugin，用本机已有登录凭据访问上游，不需要手动粘贴常规 API Key。 |
|
||||
| 名称 | CCR 内部显示名，也是路由、模型选择、日志和配置中识别供应商的名字。名称必须唯一，建议短且稳定。 |
|
||||
| API 地址 | 上游 API Base URL。它决定请求实际发往哪里，也用于协议探测、模型列表探测、图标探测和安全校验。预设供应商添加时默认隐藏该字段，可在高级设置里覆盖。自定义供应商必须填写。 |
|
||||
| API 密钥 | 默认供应商凭据。没有配置凭据池时，模型请求会使用这条 Key；协议探测、模型探测、连通性检测和默认用量读取也会使用它。只填写由当前 API 地址对应供应商签发的 Key。 |
|
||||
|
|
@ -46,7 +80,7 @@ lead: 配置 CCR 的上游模型服务，包括协议、基础 URL、模型列
|
|||
| 添加 Key | 新增一条上游 API Key。 |
|
||||
| 启用 | 控制单条凭据是否参与请求转发和用量读取。关闭后保留配置，但不会被选中。 |
|
||||
| 名称 | 单条凭据的显示名。会出现在账号用量、日志和内部诊断里，建议写成可识别的用途或额度来源。 |
|
||||
| API 密钥 | 该凭据实际发送给上游的 Key。配置了凭据池后，CCR 会把启用的凭据展开成多个内部上游目标，并优先使用凭据池，而不是主表单的默认 `API 密钥`。 |
|
||||
| API 密钥 | 该凭据实际发送给上游的 Key。配置了凭据池后，CCR 会把启用的凭据展开成多个内部上游目标，并优先使用凭据池中的 Key。主表单的默认 `API 密钥` 只作为单 Key 配置使用。 |
|
||||
| 移除 | 删除当前凭据行。 |
|
||||
| Key 高级选项 | 展开单条凭据的调度和限额字段。 |
|
||||
| 优先级 | 凭据优先级，数字越小越优先。未填写时按凭据行顺序作为优先级。 |
|
||||
|
|
@ -90,7 +124,7 @@ lead: 配置 CCR 的上游模型服务，包括协议、基础 URL、模型列
|
|||
|
||||
### HTTP JSON 请求
|
||||
|
||||
该模式适合供应商已有自己的余额或额度接口，但返回格式不是 CCR 标准格式的情况。
|
||||
该模式适合供应商已有自己的余额或额度接口，且返回自定义 JSON 格式的情况。
|
||||
|
||||
| 字段 | 代表的能力 |
|
||||
| --- | --- |
|
||||
|
|
|
|||
|
|
@ -16,9 +16,9 @@ CCR 的路由会先决定本次请求使用哪个模型，然后再把请求交
|
|||
|
||||
路由规则的核心是 **条件 + 请求动作**。条件判断请求是否命中，请求动作修改请求字段。最常用的动作是把 `request.body.model` 设置为目标模型或 Fusion 模型。
|
||||
|
||||
## Fallback 是什么
|
||||
## Fallback 处理
|
||||
|
||||
Fallback 是请求失败后的降级策略。它不负责第一次选模型，而是在当前模型或上游失败时决定是否继续尝试。
|
||||
Fallback 处理请求失败后的降级。第一次选模型由路由完成；当前模型或上游失败时，Fallback 决定是否继续尝试。
|
||||
|
||||
路由页面顶部的 **默认失败处理** 是全局 Fallback。每条路由规则里的 **失败时** 是规则级 Fallback：当某条规则命中时，规则级配置会覆盖全局配置。
|
||||
|
||||
|
|
|
|||
|
|
@ -5,10 +5,6 @@ eyebrow: 详细配置
|
|||
lead: 配置 CCR 网关监听地址、端口，以及通过代理模式进行 MITM 劫持并代理到 CCR 的能力。
|
||||
---
|
||||
|
||||
## 基本概念
|
||||
|
||||
“服务”页面控制 CCR 本地网关如何监听请求。普通模型请求通常只需要配置 `Host` 和 `Port`。
|
||||
|
||||
## 主字段
|
||||
|
||||
| 字段 | 代表的能力 |
|
||||
|
|
|
|||
|
|
@ -5,10 +5,6 @@ eyebrow: 详细配置
|
|||
lead: 配置 CCR 系统托盘图标、余额进度条和托盘窗口组件。
|
||||
---
|
||||
|
||||
## 基本概念
|
||||
|
||||
“托盘”位于“设置”里，用于配置系统托盘图标和托盘窗口。托盘窗口可以展示供应商、账户余额、token 趋势、活跃度、指标和模型占比等信息，适合在不打开主窗口时快速查看 CCR 状态。
|
||||
|
||||
## 顶部字段
|
||||
|
||||
| 字段 | 代表的能力 |
|
||||
|
|
|
|||
|
|
@ -5,19 +5,6 @@ eyebrow: 产品文档
|
|||
lead: 了解 CCR 的定位、能力边界和文档结构。需要动手配置时，从顶部的「快速开始」开始；需要查字段、Bot 或 Fusion 时，进入「详细配置」。
|
||||
---
|
||||
|
||||
## CCR 能帮你做什么
|
||||
|
||||
**Claude Code Router（CCR）是本地运行的模型网关。** 它位于 Claude Code、Codex、ZCode 等 Agent 和上游模型服务之间，统一管理模型、API Key、路由规则、日志观测和 Bot 接力。
|
||||
|
||||
CCR 适合解决这些问题：
|
||||
|
||||
- 你不想在每个 Agent 里重复维护模型和 Key。
|
||||
- 你希望不同任务自动走不同模型：轻量后台任务用快模型，复杂任务用强模型，看图或联网任务走 Fusion。
|
||||
- 你需要在请求日志里看到请求实际去了哪个供应商、哪个模型、是否成功、延迟和成本大概是多少。
|
||||
- 你想把长时间运行的 Agent 消息转发到 Slack、Telegram、飞书、企业微信等 IM 平台。
|
||||
|
||||
CCR 默认监听本机地址 `http://localhost:8080`。Agent 只要指向这个地址，请求就可以被 CCR 接管并按路由规则转发到上游供应商。
|
||||
|
||||
## 文档结构
|
||||
|
||||
顶部栏现在对应四个独立页面：
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ A: 服务运行状态、Agent 启动方式、配置应用状态和作用范围
|
|||
|
||||
A: 请求日志会展示 `request model`、`resolved provider` 和 `resolved model`。路由配置页包含默认路由、规则顺序、匹配条件和 fallback。
|
||||
|
||||
### Q: 供应商返回 401 或 403 是什么原因？
|
||||
### Q: 供应商返回 401 或 403 怎么处理？
|
||||
|
||||
A: 相关字段包括 API Key、凭据启用状态、基础 URL、协议和额外请求头。供应商页面提供模型连通性检查。
|
||||
|
||||
|
|
|
|||
|
|
@ -1280,6 +1280,12 @@ h1 {
|
|||
--provider-brand-3: #d9e3f1;
|
||||
}
|
||||
|
||||
.doc-markdown a.provider-import-button.provider-runapi {
|
||||
--provider-brand: #070707;
|
||||
--provider-brand-2: #747474;
|
||||
--provider-brand-3: #f3f3f3;
|
||||
}
|
||||
|
||||
.doc-markdown a.provider-import-button.provider-deepseek {
|
||||
--provider-brand: #173aa8;
|
||||
--provider-brand-2: #4e69ff;
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue