默认就开
整流器总开关、自动重试、Thinking 签名整流、Thinking Budget 整流、usage、stop_reason、tool 参数。
仪表盘版 · 更直观
CC Switch 增强版能力地图
这版把原来的长说明改成“看一眼就懂”的仪表盘风格：顶部看总体定位，中间看图表和流程， 下面看能力分布、维护边界和推荐开关策略。
这不是第二个网关，而是一个“少量高价值兼容修复 + 可配置回退”的本地保险层。
总览 KPI
用四个指标先看清这版增强的重点。
原版能力占比
80%
新增整流能力
20%
建议默认开启
7 项
发布状态
已发布
一句话：
这版核心不是“堆功能”，而是把最容易出兼容问题的地方做成可开关、可按范围生效、可回退的稳定层。
结构占比图
用一个环形图看这版增强里，哪些部分是最核心的。
原版 ccs 主能力：配置管理、切换、MCP、Skills、基础代理
请求侧整流：thinking、cache_control、beta 清理
响应侧整流：usage、stop_reason、tool 参数
配置层：范围、模式、预设
发布层：fork、tag、release、macOS/Windows 包
明确边界：不做完整网关
能力条形图
用条形图直接看哪些整流能力更值得默认开启。
条越长，越适合默认开启；条越短，越适合在遇到具体报错时按需开启。
推荐链路图
把职责分开，看起来更直观，也更容易维护。
Claude Code / VSCode 插件
→
ccs 整流器增强版
→
sub2api / 上游模型
直观理解：
Claude Code 只负责发请求，ccs 负责“修一下再过”，sub2api 负责“把请求送到对的上游”。
版本时间线
从功能增强到打包发布，按阶段看进度。
1. 兼容整流设计
先把 thinking、cache_control、beta、usage、stop_reason 这些容易冲突的点整理出来。
2. 设置页产品化
加入总开关、模式、范围、预设和自定义列表，让整流能力可配置。
3. 测试与验证
补后端测试、类型检查、编译检查，并验证真实链路不会破坏原有功能。
4. 打包发布
独立 fork，打测试版 tag，上传 macOS DMG 和 Windows EXE 给同事试用。
能力矩阵
哪些能力适合 ccs，哪些不适合，一眼能看出来。
| 能力 | 适合程度 | 说明 |
|---|---|---|
| Claude Code 字段整流 | 适合 | 本地代理兜底，和 ccs 定位一致。 |
| usage / stop_reason / tool 参数 | 适合 | 提升兼容响应识别率，日常最有用。 |
| thinking / cache_control / beta 清理 | 按需 | 遇到第三方接口冲突时再开。 |
| 账号池 / 路由 / 调度 | 不适合 | 这是 sub2api / CPA 的职责。 |
| 计费 / quota / 复杂治理 | 不适合 | 维护成本高，不适合塞进 ccs。 |
默认推荐开关
先开最稳的，再按报错情况加开清理项。
按需再开
Cache Control 清理、Thinking 顺序整流、anthropic-beta 清理、严格模型范围、严格供应商范围。
建议：
如果你主要用 GPT Claude-compatible 上游，优先开“GPT 混合预设”；如果是官方 Anthropic，上游稳定时保持“稳定预设”。
发布与维护状态
这部分已经落地成可分发版本，不只是概念图。
Fork
独立仓库维护增强版。
Tag
v3.14.1-rectifier-preview
Release
已上传 macOS DMG 与 Windows EXE。
平台
macOS 为 aarch64，支持 M 系列。
维护边界
保持它“像保险”，不要把它变成又一个大网关。
- 保留增强分支：长期维护
rectifier-preview，不要污染原版主线。 - 跟随上游：上游更新后合并，重点关注 proxy、settings、locale 的冲突。
- 固定验证：每次更新后跑
pnpm typecheck和cargo check。 - 继续真实链路测试：Claude Code → ccs → sub2api 的长上下文和工具调用。