想尝试 Claude + Codex + DeepSeek/Qwen/... 协同多子代理，大家目前用的什么方案？

[OumaeKumiko]

想法

正在从单纯使用 claude/codex 干活，额度用完切到另一边，发展到协同使用，因为 Fable 和 gpt5.6sol 确实太贵了。

而且我非常讨厌 GPT 的说话风格（充满伪人感🤮），5.6 系列还有强烈的过度完成、简单任务被复杂化的倾向。

其他模型说话风格都还不错，尤其是 Claude ，Fable 做规划也确实好用，但就是贵。所以想着能不能让强模型当大脑，指挥 DeepSeek / Qwen / GLM 等便宜模型去干活，省下一大截钱。

最终目标就是，只在一个对话窗口里操作，不换窗口、不手动切模型。让窗口里的 Fable/GPT 自动分配「规划 / 质疑 / 执行 / 检查」等任务给其它模型，干完活自动反馈，我就在这个窗口里处理。

方案列表

目前搜到几种方向，让大模型查了一番进行对比如下，但是心里也没底，想问问大家真实在用哪套、体验如何、稳不稳定：

1. Claude Code + CCR （ Claude Code Router ）

   内部把 DeepSeek / Qwen / Kimi / GLM / 本地模型路由进去，再用 /agent 或 agent 定义文件指定不同模型当 sub-agent 。

   另外，前段时间 openai 的 Tibo 提过 CLIProxyAPI （ https://x.com/thsottiaux/status/2076119366647894371 )，评论区有人说因为这个被封，但被封的好像是极少数，很多人长期在用没问题，所以有点犹豫……

2. Claude Code + headless OpenCode / OpenCode MCP / Codex CLI

   或者用插件/MCP 在 Claude Code 里直接调用 Codex 或 OpenCode 当 worker 。

3. Codex 为主 + 插件/路由联动其它大模型。我看官方没有插件，都是第三方的实现。

4. 其它方案（ OpenCode 原生多模型 Agent Teams 、Claudexor 类统一工作区、CLIProxyAPI 等）。

[MonkeyD1]

试试这个吧 https://pi.dev

[OumaeKumiko]

@MonkeyD1 #1 还是不习惯在终端里操作，感觉用 GUI 更方便 而且我看说连 claude 只能用 api 付费，这太可怕了😰

[yuangui]

试试我搞的这个，协同开发： https://github.com/xyva-yuangui/agent-bridge

[gynophobia]

orca / herdr

[zeyangstudies]

proma 感觉挺好用，基于 pi 的，可以切换模型

[musi]

如果 CCR 使用过程中有问题可以站内艾特我，另外后面 CCR 也会有 agent 路由的功能

[OumaeKumiko]

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

[musi]

@OumaeKumiko 没有遇到过有反馈封号的，另外我自己在用 CCR 代理 codex ，没有接到 cpa 中

[OumaeKumiko]

@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 上。

[OumaeKumiko]

@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]

@OumaeKumiko #8 gpt 的 models catlog 不代表实际的上下文长度，只是官方在 codex 这个场景会有些取舍，你可以查看实际的 api 的上下文长度，这些模型在 openrouter 的的上下文都是 1M

[musi]

@OumaeKumiko #10 ，ai 分析的还是有问题
ccr 作为一个网关是可以聚合不同的上游和模型的，你可以直接导入本地的 cc 认证，然后在你需要的时候切换就行

[OumaeKumiko]

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