1.1 账号登录#

账号登录主要决定：

• 能否进入某个客户端
• 能否使用账号套餐中的功能
• 是否能同步官方云端聊天记录
• 是否能使用账号侧的 Skill、Plugin、Connector
• 是否拥有某些付费功能权限

例如：

1
ChatGPT 账号
2
Claude 账号
3
GitHub 账号

登录账号，并不代表所有请求都一定走官方模型。

1.2 客户端配置#

客户端配置决定：

• 使用哪个模型
• API 地址是什么
• API Key 从哪里读取
• 加载哪些 Skill
• 加载哪些 Plugin
• 是否加载 MCP
• 是否允许执行命令
• 是否经过 CC Switch

常见配置目录：

1
Codex：
2
~/.codex/
3

4
Claude Code：
5
~/.claude/
6

7
Claude Code 项目级配置：
8
项目目录/.claude/

1.3 模型供应商#

模型供应商决定：

• 请求真正发到哪里
• 使用哪个模型
• 费用由谁收取
• 数据经过哪个服务
• 是否需要协议转换
• 是否需要模型映射

例如：

1
OpenAI 官方
2
Anthropic 官方
3
DeepSeek 官方 API
4
第三方中转站
5
企业内部网关
6
本地模型服务

4. 会话记录#

会话记录可能保存在：

• 官方账号云端
• 当前电脑本地
• 当前 Provider 对应的本地索引
• 当前项目目录
• 某个客户端自己的数据库

因此：

同一个客户端切换 API 后，模型仍然能正常工作，但历史记录列表可能发生变化。

这不一定表示会话被删除，也可能只是切换到了另一套认证方式、Provider 或会话索引。

2.1 ChatGPT 的普通 Chat 和 Codex 不是同一种会话#

新版 ChatGPT 桌面端可能同时包含：

1
ChatGPT Desktop
2
├── ChatGPT
3
└── Codex

2.2 Codex Desktop、CLI 和 IDE 的关系#

Codex 可能有多个入口：

1
Codex Desktop
2
Codex CLI
3
IDE 中的 Codex

它们通常共享一部分本地配置，例如：

1
~/.codex/config.toml
2
项目目录/.codex/config.toml

可以共享的内容通常包括：

• 默认模型
• Provider
• MCP
• 沙箱设置
• 审批策略
• 项目级配置
• 一部分 Skill 和 Plugin 配置

但共享配置，不代表所有内容完全同步。

以下内容可能不同：

• 当前打开的会话
• 客户端缓存
• 登录状态
• UI 设置
• 本地历史索引
• 插件版本
• 当前项目是否被信任
• 不同客户端版本支持的功能

因此，更准确的说法是：

Codex Desktop、CLI 和 IDE 扩展共享主要 Agent 配置，但不保证所有会话和客户端状态完全一致，但是大部分情况是一致的。

3.1 官方账号模式#

Codex 使用官方账号时，请求路径可以简化为：

1
Codex
2
    ↓
3
ChatGPT / OpenAI 官方认证
4
    ↓
5
OpenAI 官方模型

此时通常消耗官方账号中的 Codex 额度。

3.2 第三方 API 模式#

配置自定义 Provider 后，请求路径可能变成：

1
Codex
2
    ↓
3
自定义 Provider
4
    ↓
5
第三方 API / 中转站 / 其他模型

此时：

• 费用由第三方 Provider 收取
• 请求可能不再经过 OpenAI 官方模型服务
• 模型名称和能力可能不同
• 会话索引可能按照 Provider 或认证方式区分

3.3 为什么切换后旧会话不见了#

常见影响因素包括：

1
认证方式
2
model_provider
3
项目路径
4
本地会话索引
5
客户端缓存
6
登录账号
7
客户端版本

因此，“切换 API 后旧会话不显示”不应该简单解释为：

官方域名和第三方域名不同，所以会话没了。

更准确的解释是：

切换 Provider 后，Codex 可能进入了不同的认证环境或会话索引，因此原来的会话暂时没有显示。

排查步骤：

1. 切回原来的官方 Provider
2. 完全退出并重新打开 Codex
3. 确认打开的是同一个项目目录
4. 检查是否登录了同一个账号
5. 先备份 ~/.codex/
6. 不要因为历史列表为空就直接删除配置目录

4.1 Claude Code 是代码代理本体#

Claude Code 可以运行在：

1
终端 CLI
2
VS Code
3
JetBrains
4
Claude Desktop 的 Code 页面
5
远程环境
6
云端环境

它负责：

• 读取项目
• 修改代码
• 执行命令
• 调用工具
• 加载 Skill
• 加载 Plugin
• 加载 MCP
• 读取 CLAUDE.md
• 执行 Hook

Claude Code 的用户级配置通常位于：

1
~/.claude/

项目级配置通常位于：

1
项目目录/.claude/

4.2 Claude Desktop 是桌面应用外壳#

Claude Desktop 中可能包含：

1
Claude Desktop
2
├── Chat
3
└── Code

入口不是完全相同的产品形态，也不一定读取相同的配置。

5.1 Cowork#

Cowork 更偏向通用工作流和任务协作。

它使用的 Skill、Plugin、Connector 往往来自：

1
Claude Desktop
2
→ Customize

这部分更接近账号侧配置，而不是直接读取 Claude Code CLI 的：

1
~/.claude/

所以你在 Claude Code CLI 中安装的本地 Skill，不一定会自动出现在 Cowork 中。

5.2 Code#

Claude Desktop 的 Code 页面使用 Claude Code 的代码代理能力。

本地 Code 会话通常会读取：

1
~/.claude/settings.json
2
~/.claude/skills/
3
~/.claude/plugins/
4
~/.claude.json
5
项目目录/.claude/
6
项目目录/CLAUDE.md
7
项目目录/.mcp.json

因此，Claude Code CLI 中能找到的很多内容，在 Desktop 的本地 Code 页面中通常也能找到，例如：

• 用户级 Skill
• 项目级 Skill
• Plugin
• MCP
• Hook
• CLAUDE.md
• 权限配置

但是：

共享本地配置，不代表 CLI 和 Desktop Code 的会话历史一定完全同步。

它们可能使用相同的底层引擎和配置目录，但由不同客户端维护自己的会话列表或本地状态。

5.3 为什么 Code 有 Skill，Cowork 没有#

假设本地存在：

1
~/.claude/skills/my-skill/SKILL.md

这个 Skill 通常会被下面的入口读取：

1
Claude Code CLI
2
Claude Desktop → Code → Local

但 Cowork 更可能读取：

1
Claude Desktop → Customize

所以出现下面的情况是正常的：

1
Code：能看到本地 Skill
2
Cowork：看不到本地 Skill

要让 Cowork 使用相同 Skill，通常需要在账号侧 Customize 中单独配置。

6.1 登录 Claude 账号，不代表 Claude Code 一定走官方#

可以出现下面这种组合：

1
Claude Desktop Chat
2
    → Claude 官方账号
3

4
Claude Desktop Cowork
5
    → Claude 官方账号
6

7
Claude Code CLI
8
    → CC Switch
9
    → DeepSeek API

此时：

• Claude Desktop 仍然保持账号登录
• Chat 和 Cowork 使用官方账号
• 编程任务通过 Claude Code CLI 使用第三方 API
• 不会因为登录了 Claude 账号，就强制让 CLI 使用 Claude 官方模型

6.2 Claude Desktop 第三方推理需要特别注意#

如果把整个 Claude Desktop 配置成第三方推理模式，那么受影响的可能不只是 Code。

可能变成：

1
Claude Desktop
2
├── Cowork → 第三方 Provider
3
└── Code   → 第三方 Provider

因此，下面这种分流不一定能通过“整个 Desktop 切换 Provider”实现：

1
Cowork → Claude 官方账号
2
Code   → DeepSeek

要稳定实现这种分流，通常更推荐：

1
Claude Desktop
2
└── Cowork → Claude 官方
3

4
Claude Code CLI / IDE
5
└── DeepSeek API

7.1 CC Switch 做什么#

CC Switch 可以管理：

• Claude Code Provider
• Claude Desktop Provider
• Codex Provider
• Gemini 等其他 Agent
• API Key
• Base URL
• 模型名称
• 本地路由
• 请求日志
• 故障转移
• 协议转换
• 模型映射

它本质上不是账号同步工具。

它主要解决的是：

当前客户端的模型请求应该发给哪个 Provider。

7.2 路由总开关#

路由总开关的作用是：

1
启动 CC Switch 本地代理服务

例如：

1
http://127.0.0.1:15721

仅打开总开关，并不代表所有软件都会自动经过 CC Switch。

7.3 不同 Agent 的独立开关#

底下的独立开关决定：

1
哪个客户端真正使用 CC Switch 本地路由

例如：

1
路由总开关：开
2
Claude：开
3
Codex：关
4
Gemini：关

实际效果：

1
Claude Code → CC Switch
2
Codex       → 不经过 CC Switch
3
Gemini      → 不经过 CC Switch

因此：

总开关负责启动服务，Agent 独立开关负责接管对应客户端。

7.4 Claude 和 Claude Desktop 是两个不同入口#

在 CC Switch 中：

1
Claude

通常对应 Claude Code：

• Claude Code CLI
• VS Code 中的 Claude Code
• JetBrains 中的 Claude Code
• 读取 ~/.claude/ 的本地代码代理

而：

1
Claude Desktop

对应 Claude Desktop 的第三方推理配置。

两者不能混为一谈。

8.1 方法一：直接配置环境变量#

macOS / Linux：

1
export ANTHROPIC_BASE_URL="https://你的接口地址"
2
export ANTHROPIC_AUTH_TOKEN="你的 API Key"
3
export ANTHROPIC_MODEL="你的模型名称"
4

5
claude

Windows PowerShell：

1
$env:ANTHROPIC_BASE_URL="https://你的接口地址"
2
$env:ANTHROPIC_AUTH_TOKEN="你的 API Key"
3
$env:ANTHROPIC_MODEL="你的模型名称"
4

5
claude

具体的 Base URL 和模型名称，应以供应商当前文档为准。

8.2 方法二：通过 CC Switch 配置#

操作步骤：

1. 打开 CC Switch
2. 左侧选择 Claude
3. 点击添加 Provider
4. 选择预设 Provider，或添加自定义 Provider
5. 填写 API Key
6. 检查 Base URL
7. 检查模型名称
8. 保存
9. 启用该 Provider
10. 根据 Provider 需要决定是否开启路由
11. 完全退出旧的 Claude Code 进程
12. 重新运行 claude

请求路径可能是：

1
Claude Code
2
    ↓
3
CC Switch
4
    ↓
5
第三方 API

8.3 什么时候需要开启 Claude 路由#

需要以下能力时，通常需要开启：

• 请求日志
• 自动故障转移
• 协议转换
• 模型映射
• 多 Provider 统一入口
• 本地代理

设置：

1
路由总开关：开
2
Claude：开

如果 Provider 可以被 Claude Code 直接访问，而且不需要 CC Switch 转换，也可以使用直接模式。

8.4 如何验证 Claude Code 已切换成功#

建议同时检查：

1. Claude Code 中的状态信息
2. CC Switch 请求日志
3. 第三方 Provider 控制台用量
4. 官方 Claude 账号额度是否变化
5. 测试请求使用的模型名称

不要仅凭界面显示的 “Sonnet” 或其他名称判断，因为中间可能存在模型映射。

9.1 通过 Claude Desktop 自身配置#

部分版本可以在开发者或故障排查设置中配置第三方推理。

通常需要填写：

1
Gateway / Base URL
2
API Key
3
认证方式
4
模型或模型映射

配置后需要：

1. 完全退出 Claude Desktop
2. 确认后台进程已经结束
3. 重新打开 Claude Desktop
4. 新建测试会话
5. 检查 Provider 用量

需要注意：

Claude Desktop 的第三方推理可能影响整个 Desktop，而不只是 Code 页面。

9.2 通过 CC Switch 配置 Claude Desktop#

操作步骤：

1. 打开 CC Switch
2. 左侧选择 Claude Desktop
3. 添加第三方 Provider
4. 填写 API Key
5. 填写或确认 Base URL
6. 配置模型名称
7. 如有需要，开启模型映射
8. 启用该 Provider
9. 根据模式开启本地路由
10. 完全退出 Claude Desktop
11. 重新打开

9.3 直接模式#

直接模式适合：

• Provider 原生兼容 Claude Desktop 所需协议
• 不需要模型名称转换
• 不需要 CC Switch 持续代理
• Provider 能直接处理对应请求

请求路径：

1
Claude Desktop
2
    ↓
3
第三方 Provider

启用完成后，CC Switch 不一定需要一直运行。

9.4 模型映射模式#

第三方模型名称可能与 Claude Desktop 期望的模型角色不同。

例如：

1
Claude Desktop 显示：Sonnet
2
实际模型：第三方模型 A

CC Switch 可以完成：

1
Sonnet 角色名
2
    ↓
3
模型映射
4
    ↓
5
第三方真实模型名

请求路径：

1
Claude Desktop
2
    ↓
3
CC Switch 本地路由
4
    ↓
5
第三方 Provider

这种模式下通常需要：

1
路由总开关：开
2
Claude Desktop：开
3
CC Switch：保持运行

10.1 使用目标#

假设你希望：

• 普通聊天继续使用 Claude 账号
• Cowork 使用 Claude 官方能力
• 代码任务使用 DeepSeek 等第三方 API
• Codex 继续使用自己的官方账号
• 避免额度和会话来源混乱

推荐结构：

1
Claude Desktop
2
├── Chat   → Claude 官方账号
3
└── Cowork → Claude 官方账号
4

5
Claude Code CLI / VS Code / JetBrains
6
└── CC Switch → 第三方 API
7

8
Codex
9
└── OpenAI 官方账号

10.2 推荐的 CC Switch 开关#

1
路由总开关：开
2

3
Claude：开
4
Claude Desktop：关
5
Codex：关
6
Gemini：关

实际含义：

1
Claude Code → CC Switch → 第三方 API
2

3
Claude Desktop → Claude 官方账号
4

5
Codex → OpenAI 官方

这是最容易理解、最不容易串线的方案。

10.3 为什么不推荐直接把整个 Claude Desktop 切到第三方 API#

因为这样可能导致：

• Chat 也走第三方
• Cowork 也走第三方
• Code 也走第三方
• 官方账号功能和第三方推理混合
• 云端功能可能受限制
• 会话保存位置发生变化
• 很难判断额度扣在哪里

如果主要目的是节省编程额度，更推荐只让 Claude Code CLI 或 IDE 走第三方 API。

11.1 查看 CC Switch 请求日志#

如果请求经过 CC Switch，日志中通常可以看到：

• 请求来源
• Provider
• 模型
• 状态码
• Token
• 时间
• 上游地址

11.2 查看第三方 API 控制台#

发送一个测试请求后检查：

• 是否出现新的 API 调用
• Token 是否增加
• 余额是否变化
• 时间是否与测试请求一致

11.3 查看官方账号额度#

同时观察：

1
Claude 官方额度
2
Codex 官方额度
3
第三方 API 余额

若第三方用量增加，而官方额度没有变化，通常说明请求走的是第三方 Provider。

11.4 完全重启客户端#

切换 Provider 后，旧进程可能仍保留旧环境变量或旧配置。

建议：

1
退出当前会话
2
完全关闭客户端
3
确认后台进程结束
4
重新打开客户端
5
新建测试会话

11.5 不要只看模型显示名称#

经过模型映射后，界面显示：

1
Sonnet

不代表实际上游一定是 Claude Sonnet。

可能是：

1
Sonnet
2
    ↓
3
CC Switch 映射
4
    ↓
5
第三方模型

最可靠的依据是请求日志和 Provider 控制台。

误区一：登录账号后一定消耗官方额度#

错误。

账号登录负责身份和功能权限，Provider 决定请求实际发给谁。

误区二：Skill 属于某个模型#

错误。

Skill 通常由客户端加载。

1
Claude Code
2
├── 加载 Skill
3
├── 读取项目
4
├── 读取 CLAUDE.md
5
└── 将上下文发送给模型

最后的模型可以是 Claude，也可以是其他兼容模型。

误区三：Claude Desktop Code 和 CLI 完全同步#

不完全正确。

它们通常共享本地配置和 Skill，但不保证会话历史、缓存和 UI 状态完全同步。

误区四：Claude Desktop 切换 API 只影响 Code#

不一定。

第三方推理模式可能影响 Chat、Cowork 和 Code 整个 Desktop。

误区五：CC Switch 总开关会接管所有软件#

错误。

总开关只启动本地服务。

必须打开对应 Agent 的独立开关，该客户端才会经过 CC Switch。

误区六：切换 Provider 后看不到历史，就代表历史被删除#

不一定。

可能只是：

• Provider 改变
• 登录方式改变
• 项目路径改变
• 本地索引改变
• 客户端缓存变化

先切回原配置确认，不要直接删除配置目录。

误区七：同时有账号和 API 会重复扣费#

正常情况下不会。

一次请求只会走一个实际 Provider。

真正需要防止的是：

• 误以为已经切到第三方，其实仍在使用官方
• Desktop 和 CLI 配置混淆
• CC Switch 没启动
• Agent 独立路由开关没打开
• 旧进程仍在使用旧配置

误区八：Claude 和 Claude Desktop 在 CC Switch 中是同一个配置#

错误。

1
Claude
2
    → Claude Code CLI / IDE
3

4
Claude Desktop
5
    → Claude Desktop 整体第三方推理配置

两者需要分别配置。

Codex#

1
ChatGPT Desktop
2
├── Chat
3
│   └── 普通 ChatGPT 云端聊天
4
│
5
├── Work
6
│   └── 通用研究和交付任务
7
│
8
└── Codex
9
    ├── 项目
10
    ├── Coding Agent
11
    ├── Skill
12
    ├── Plugin
13
    ├── MCP
14
    ├── CLI / IDE 共享主要配置
15
    └── 可使用官方账号或自定义 Provider

Claude#

1
Claude Desktop
2
├── Chat
3
│   └── Claude 账号侧聊天
4
│
5
├── Cowork
6
│   └── 账号侧 Customize / Skill / Plugin / Connector
7
│
8
└── Code
9
    └── Claude Code 本地引擎
10
        ├── ~/.claude/
11
        ├── 项目/.claude/
12
        ├── CLAUDE.md
13
        ├── Skill
14
        ├── Plugin
15
        ├── MCP
16
        └── Hook

CC Switch#

1
CC Switch
2
├── Claude
3
│   └── 管理 Claude Code Provider
4
│
5
├── Claude Desktop
6
│   └── 管理 Claude Desktop Provider
7
│
8
├── Codex
9
│   └── 管理 Codex Provider
10
│
11
└── 本地路由
12
    ├── 总开关：启动代理服务
13
    └── Agent 开关：决定谁经过代理

一句话结论#

Codex Desktop、CLI 和 IDE 共享主要代码代理配置，但普通 Chat 和 Codex Agent 会话不是同一套历史；Claude Desktop 的 Cowork 主要使用账号侧 Customize，而 Code 与 Claude Code CLI 共享本地配置；CC Switch 负责决定请求发给哪个模型供应商，不负责自动同步账号、Skill、Plugin 和全部聊天记录。

推荐配置速查表#

安全提醒：API Key 不要写入公开仓库，不要提交到 Git，也不要发送给不可信的中转站。涉及私有代码时，应确认实际 Provider、数据保留策略和请求日志策略。