一、这条链路要解决什么问题
你手里有 Codex、Claude 或者 ChatGPT 的订阅账号，电脑上的 DeepSeek Harness（DSH）默认走 DeepSeek 官方模型源。想让自己的订阅变成 DSH 的模型源，中间缺的就是一个「翻译层」——把订阅账号的能力包装成 DSH 认得的标准接口。这条链路由两个项目拼成：
一个是 CLIProxyAPI，Go 写的，55,909 星、MIT 协议，定位是「为各种 CLI 提供 OpenAI/Gemini/Claude/Codex 兼容 API 接口的代理服务器」。它把你的 Codex OAuth、Claude Code、Gemini CLI、Grok、Kimi、Devin 这些账号统一暴露成一个默认 8317 端口的本地网关。
另一个就是今天的主题 Factory48/dsh-cliproxyapi-provider，JavaScript 写的一个 DSH 插件，84KB、创建才 3 天、0 星。它的活儿很小：让 DSH 0.2 把 CLIProxyAPI 当成一个可用的模型源，自动拉模型目录，把上下文长度、图片输入、思考等级这些能力元数据同步进 DSH 的模型列表。
先说清它的形态，免得跑偏：它不是独立工具，是 npm 风格的 DSH 插件包（@router-for-me/dsh-cliproxyapi-provider，v0.1.0），private: true 不发布到 npm，只能从 GitHub 装；Node 要 22 以上。它自己不做推理转发——请求最终还是由 DSH 内置的 llm-pi-ai 插件发出去，这个插件只负责「注册并配置 provider 条目」，源码注释里写得很直白：内置的 llm-pi-ai 仍然是 provider 路由的唯一所有者。
（图注1：浏览器端填地址、服务端拉目录、CLIProxyAPI 统一转发，插件只做「同步能力元数据」这一段）
二、它具体做了哪七件事
把源码逐行读完，这个 84KB 的仓库实际干的活是这七件，每一件都有具体参数。
第一，自动模型发现。向 {BaseURL}/models?client_version=dsh-cliproxyapi-provider 发请求，读的是 Codex 风格的模型目录（顶层 models 数组）。
第二，能力元数据同步，这是最见功力的地方。上下文窗口按 max_context_window → context_window → 默认 262144 逐级取值；最大输出按 max_output_tokens → max_completion_tokens → max_tokens → 默认 32768。图片输入能力的判定很克制：只有目录里 input_modalities 明确包含 image 才开启，字段缺失就按「未知」处理，绝不臆测支持。思考等级把线上的 none 映射成 off、ultra 映射成 max，如果一个模型只声明了 off，整个能力字段会被直接省略——因为 DSH 的 llm-pi-ai 拒绝只含 off 的能力表。
第三，协议固定走 OpenAI Responses，不是 Claude Messages 也不是 Gemini 原生。
第四，凭据走 DSH 的凭据系统存，引用名叫 DSH_CLIPROXY_API_KEY；网关没开鉴权就允许留空，此时用占位 Bearer 顶替。
第五，定时刷新加指数退避：默认 5 分钟拉一次，拉取超时 15 秒，重试从 3 秒起翻倍、上限 60 秒，目录响应体上限 4MiB。
第六，浏览器和服务端之间有个握手：客户端先写一个带特殊 header 的「引导态」配置，服务端看到后接管，把完整能力回写进去，客户端等 header 消失才算同步完成，30 秒没等到就提示「已保存但能力未同步」。
第七，过滤与去重：目录里 visibility: "hide" 的模型不出现在列表，同 slug 去重。
（图注2：字段逐级取值、图片能力不臆测、握手 30 秒超时，默认参数一栏可作速查表）
三、怎么装、怎么用
装分两步。
先起 CLIProxyAPI 本体。它的上游仓库是 router-for-me/CLIProxyAPI，Go 写，最新 release v8.0.38，可以用 Docker 或 release 二进制跑，默认端口 8317（config.yaml 里 server.port 可改）。起来之后用 --codex-login 之类的参数完成你要接的那个账号的 OAuth。
再装这个 DSH 插件。仓库 README 给的命令是这样的：
npx @deepseek-ai/dsh plugin --profile web add github:router-for-me/dsh-cliproxyapi-provider
先停一下——这就是这篇稿子要专门拦你一下的地方：这条命令装的是上游仓库，不是 Factory48 这份 0.2 适配版。上游的依赖锁在 DSH 0.1.1-rc.2 一代，而 Factory48 这份锁在 0.2.0-rc.2。如果你的 DSH 已经升到 0.2，按 README 装完得到的很可能是个「不兼容 0.2」的旧版插件。正确的写法应该是：
npx @deepseek-ai/dsh plugin --profile web add github:Factory48/dsh-cliproxyapi-provider
npx @deepseek-ai/dsh web
注意卸载时包名仍是上游那个 @router-for-me/dsh-cliproxyapi-provider（这份仓库没改 package.json 的 name），这是它「独立副本而非 fork」的证据之一。
装完进 DSH 侧边栏「插件」页，选 CLIProxyAPI，填 Base URL（本机就是 http://127.0.0.1:8317/v1），API Key 在网关没开鉴权时留空，保存。模型列表会自动出现并每 5 分钟刷新一次。
举个具体场景：你接的是 Codex 订阅，保存之后目录里会出现像 gpt-6.1-sol 这样的条目，上下文 872,000、支持图片输入、带思考等级——这些字段都是从 CLIProxyAPI 的模型目录同步过来的，DSH 界面里就能直接选了。
四、什么情况下别用它
几个前提不满足就别硬上。
DSH 版本得对。它的 peerDependencies 精确锁在 @deepseek-ai/cordis ^4.0.4 和 dsh 各包 0.2.0-rc.2。npm 上 DSH 当前 latest 是 0.2.1-rc.2，也就是说 DSH 再往前走一格，这个锁死的插件很可能失效，而它没有发布机制可以跟进（private，npm 上 404）。
协议得对。它只走 Responses 协议、只解析 Codex 风格目录。你在 CLIProxyAPI 里接了 Claude 或 Gemini 账号，那些模型能不能被这个插件发现，取决于 CLIProxyAPI 是否把它们也按 Codex 目录格式吐出来——这一点仓库没写，也没有实测，别赌。
账号合规是红线。用订阅账号喂本地网关属于个人用法，但把接出来的 API 对外共享、转售或多人拼车，基本都踩各家服务条款，风险自己评估。
还有一件事要说在前面：这条链路我目前只做了静态源码调研，没有在真实的 DSH 0.2.1-rc.2 加一个跑起来的 CLIProxyAPI 实例上把「装插件、填地址、出模型、能对话」整条链实测走一遍。所以下面这些是按源码和仓库文档推出来的预期行为，你真装的时候如果某一步对不上，优先怀疑的是 CLIProxyAPI 当前版本的 /models 输出格式，而不是插件本身——它读的是 Codex 风格目录，上游改目录字段它就要跟着改。
五、用之前必须知道的六件事
第一，README 指错仓库。这是全篇最重要的一条。README 的安装命令写的是上游 router-for-me/，而本仓库是 Factory48/ 的 0.2 适配独立副本。装之前把仓库名换成 Factory48，否则 0.2 用户大概率装到不兼容的旧版。
第二，没有 LICENSE 文件。GitHub API 对它返回 license: null，仓库里确实没有 LICENSE 正文，package.json 里那个 "license": "MIT" 只是声明字段，不等于授权文本。默认状态下，复制、修改、再分发都没有明确授权；个人 clone 自用实践上通常没人追究，但没有任何豁免。想改、想分发、想商用，先找作者要书面许可。上游 router-for-me 那份同样没有 LICENSE 文件。
第三，它是一份「缝合」的独立副本，不是官方分支。提交历史很清楚：前 3 个提交是上游原作者（2026 年 8 月），后 3 个是一个叫 chliny 的作者 9 月起针对 DSH 0.2 打的补丁（适配 API、升级 provider、恢复能力同步）。上游至今没有跟进 0.2，这两边的维护是分叉的。
第四，同一题解有好几份。GitHub 上搜 dsh-cliproxyapi-provider 能搜出 5 个仓库，其中 ChadCSong 的版本带 MIT LICENSE 且 10 月 19 日还在推，pd90506 的版本也是 MIT。如果你没有必须用 Factory48 这份的理由，带完整授权文本且更新的版本是更稳妥的选择。
第五，供应链面：插件会向你填的任意 Base URL 发 GET 请求并带上你填的 API Key，URL 只校验协议合法、不校验主机。Base URL 只填你信任的本地或内网地址。
第六，没有社区兜底。0 星、0 issue、上游也才 3 星，DSH 官方仓库只开 Discussions 不开 issues。出了问题没有 issue 区可以搜答案，反馈基本靠自己读源码。这份仓库里 3 个测试文件加 249 行的 catalog/index 测试倒是写了，属于作者给自己兜的底，不是社区验证。
六、把这条链路讲透：谁在什么位置
最后用一段话把四方各自动能讲一遍。你在 CLIProxyAPI 里接的是账号层（Codex OAuth、Claude 会话之类），它把账号能力翻译成 8317 端口的兼容 API；DSH 里装的本插件是「目录同步器」，它不改路由、不转发请求，只把 CLIProxyAPI 的模型能力表搬进 DSH 的设置里；真正发请求的是 DSH 内置的 llm-pi-ai 插件，走 Responses 协议打回 CLIProxyAPI。理解了这个分工，你会发现这种「小插件大生态」的组合方式正是 DSH 0.2 的设计意图——官方只管路由骨架，能力扩展全部外挂在第三方插件上。
这个模式的代价也在上面讲过了：每个外挂都是锁版本的、分叉维护的、授权参差的。用之前先把「它跟着哪个 DSH 版本、谁在维护、许可到底是什么」三件事查清楚，再谈接不接。
热门跟贴