@wclebb #32 我感觉千兆不太可能不够😂应该不是 2.5g 的问题

我日啊 受不了了 感觉自己亏麻了

@little_cup #14 那这样的话岂不是得维护一套很 skill 同步系统😂要不然用着用着各个 agent 的 skill 就分叉了

@wclebb #8 ssh 倒是没问题，有公网 ip 和 tailscale ，ssh 基本上不太卡

@wclebb #8 我在家里内网用高性能模式都频繁卡，鼠标消失，也不知道为啥 https://i.imgur.com/krir4IG.png

@little_cup 是把其他模型接入了 Claude Code 里面么？还是让它用的 Bash 调用的其他的 CLI ，求教，现在正在研究怎么弄

我感觉挺不错的，买了一个最高档位的，有一兆上下文。在这点上比 GPT 有优势。文风我也比较喜欢，是 Claude 类型的。

@musi #20 嗯，openai 官方文档里就写的 付费额度才是 1m

@musi #11 我自己测着 gpt 的订阅是 368k 上下文，再多就爆了

我觉得 GUI 更好用，而且 GUI 功能更多了，比如说 Computer use ，CLI 好像是没有这个功能。

@musi #17 https://i.imgur.com/krir4IG.png okok

@musi #15 啊.....应该没啥问题了，折腾两天 claude 帮我实现了在 claude.app 里，claude 订阅的请求原样透传+gpt 等其它模型在列表里面，最后说只需要 CPA 加几个脚本，CCR 用不到😂

@musi #12 opus 跟我说，「作者本人建议的替代路是「把本机 Claude Code 的登录态导入成一个供应商」——这条在你这台机器上直接死：它的 readClaudeCodeOauth() 只遍历 ~/.claude/.credentials.json 这类磁盘文件，只要第一个能解析就直接 return ，永不走钥匙串。而本机磁盘那份当时已经过期四天（打接口 401 ），活的那份在钥匙串里。」请教一下这个说法对么，它现在跟我说 CCR 没用了，就只需要 CPA+它自己写的插件和脚本 https://i.imgur.com/krir4IG.png


----

## 先纠正一个前提：你现在用的**绝大部分就是现成方案**

| 层 | 是什么 | 自建成分 |
|---|---|---|
| 第三方全部模型（ GPT/DeepSeek/千问） | **CLIProxyAPI 原封不动** | 零。账号池、协议翻译、出海代理全是它干的 |
| Claude 订阅那一支 | 一个约 200 行的插件 | 自建，但它是**为 CCR 的插件接口写的**，今天没动 |
| 进程宿主 | 150 行 Node | 今天才自建，**替换的只是 CCR 这一个角色**，端口和插件都没变 |

所以不是「大费周章重造轮子」，是**在现成方案上补了一块它们都不提供的东西**。

## 那一块是什么：「 Claude 走订阅计费」

这是你定死的需求，也是唯一逼出自建代码的那一条。两个工具各自的**源码级结论**（当初核对的是与本机版本精确一致的源码，CCR v3.0.15 / CPA v7.2.95 ）：

**CPA 单独用 → 只能按量付费，或者被判第三方**

它服务 Claude 模型只有两条路：填官方 API key （按量计费，跟你的订阅无关），或者用 Claude OAuth 登录（就是那种会被判成第三方壳的模式）。**两条都保不住订阅。** 它那个 `passthrough-headers` 名字唬人，实际是「把上游的**响应头**转发给下游」，跟凭据无关。

**CCR 单独用 → 凭据透传这个能力它没有**

- 它的 `passthrough` 是**协议格式**透传（格式一致时不翻译 body ），跟凭据无关；`provider_auth` 阶段**永远执行**，一律用 provider 自己配的 key 去认上游。也就是说客户端自己的订阅 token 根本到不了 Anthropic 。
- 社区有**四个 PR**想加这个能力（#1219 passthrough_auth 、#1295 、#1333 、#1408 ），到 2026-07-25**全部还是 open ，一个都没合并**。
- 作者本人建议的替代路是「把本机 Claude Code 的登录态导入成一个供应商」——**这条在你这台机器上直接死**：它的 `readClaudeCodeOauth()` 只遍历 `~/.claude/.credentials.json` 这类磁盘文件，只要第一个能解析就直接 return ，**永不走钥匙串**。而本机磁盘那份当时已经过期四天（打接口 401 ），活的那份在钥匙串里。

所以要「 Claude 走订阅」，必须有一段自己的代码做三件事：**正文一字不改地转发、装上长期订阅 token 、把 `anthropic-beta` 合并进去（合并不是覆盖）**。这三件现成工具都不给。

**至于今天为什么连 CCR 这个宿主也换掉**——不是嫌它路由做得不好，是它会自作主张改桌面 App 的配置。你今天早上 GUI 进不去网关模式，根因就是我退出 CCR 时它把 `deploymentMode` 还原成了 `1p`；它还有孤儿进程问题，制造过「我明明改了插件、也重启了、行为却没变」的假象。换成 150 行宿主后，插件和端口一个没动。

@musi #12 折腾死了，从下午折腾到现在，还没整完😂claude opus/fable 一直在帮我研究，现在进入到了，在 TUI 里面是可以正常用第三方模型以及 claude 直接连订阅，但是在 GUI 里面还是不行。他就说搜了半天也没找到现成的方案，就只能自己试。我也不知道它到底搜的对不对。

估计是因为前两周都已经重置两次了，他们觉得很亏吧。然后再加上对自己模型很自信。

@musi #6
我是想着，在 Claude Code 里，既要接第三方的大模型，又要把 Claude 本身的请求原样透传给 A\，让 Claude 调研了一番，他说目前 CCR 官方这几个月就没有接这个请求，是官方不好实现吗？ Claude 说如果官方不实现的话，他自己能照着这些写一个，给我自己用的。😂


-----------

Claude Code 只能配一个后端地址。 所以「 Claude 模型 + 第三方模型都要」这件事，必须由站在那个地址上的东西来分。
现成的网关都会把你的凭据换成自己的。CCR 的请求链路里 provider_auth 这一步是必经的——它一定用它自己配置的 key 去认证上游。而你的 Claude 订阅计费，前提恰恰是你自己的凭据原样到达 Anthropic 。
所以那个站在地址上的东西必须会做一件现成工具都不做的事：对 Claude 的请求「不作为」。 这就是插件存在的全部理由。


一、四个 PR 核实为真，都没合并
用 gh 逐个查了，标题就是我们要的东西：

PR 提交日 状态 标题
#1219 2026-02-18 OPEN 未合并 add passthrough_auth option for OAuth bearer token forwarding
#1295 2026-03-25 OPEN 未合并 multi-auth routing, security patches, and bypass fix
#1333 2026-04-15 OPEN 未合并 skip redundant Authorization header in bypass mode
#1408 2026-05-24 OPEN 未合并 add OAuth support to the built-in Anthropic transformer
五个月里四个人独立提了同一件事，维护者一个都没合。 顺带查实：v3.0.15 源码里没有 bypass mode ，那个词是这些未合并 PR 自己引入的概念，现在用不上。

@musi #6 我正在让 claude 给我研究怎么配，发现一个问题捏（站长不要封我，只是在反馈问题😂）


----


报个模型元数据的问题。我用 CCR 网关接 CLIProxyAPI 的 Codex 模型，在 Claude Code 的 /model 里看到所有 GPT 模型后面都带 [1m]，显示名还写着「(1M context)」。

抓了一下网关的 /v1/models ，返回里 capabilities.context_management.max_input_tokens 是 1050000 。但查 Codex 官方下发的模型清单（~/.codex/models_cache.json ），实际是：gpt-5.6-sol / gpt-5.6-terra / gpt-5.6-luna / gpt-5.5 / gpt-5.4-mini 都是 context_window: 272000 、max_context_window: 272000 ； gpt-5.3-codex-spark 只有 128000 ；只有 gpt-5.4 和 codex-auto-review 的 max_context_window 到 100 万（默认也仍是 272000 ）。同一个模型直接问 CLIProxyAPI ，它报的 max_input_tokens 也是 272000 ，跟官方清单一致。

看代码像是 packages/core/src/gateway/model-catalog.ts 里 GPT-5.6 那条 catalog 写死了 contextTokens: 1_050_000 / inputTokens: 1_050_000 / supports1MContext: true ，于是 model-discovery.ts 走 oneMillionContext 分支给 ID 加了 [1m]。gpt-5.6-codex 可能确实有 1M （ CLIProxyAPI 那边有个 issue #4195 就是要求报 1050000 ），但 sol/terra/luna 这几个不是。

后果是 Claude Code 以为有 100 万上下文，就不会及时触发压缩，超过 27.2 万之后要么上游报错、要么静默截断，界面上看不出发生了什么。

建议优先采用上游报的真实值（ CLIProxyAPI 的 /v1/models 里有 max_input_tokens ； models_cache.json 里有 context_window / max_context_window ），或者至少别把 gpt-5.6 那条 catalog 套到名字不同的 sol/terra/luna 上。

@musi #6 大佬回复了🐮 想请教一下 CLIProxyAPI+CCR 路由 codex 老哥收到的封号比例如何😂

而且没看到这个福利分组的充值😂