【开源】Metapi V1.2更新：支持正则匹配模型添加群组、增强路由匹配、支持个别站点开启代理、下游多 Key 限额／白名单策略、支持无账号URL+Key、Zeabur一键部署、文档中心上线并优化UX
- 内容介绍
- 文章标签
- 相关推荐
写在前面
继Metapi开源后，受到佬友们的热情关注，才短短上线两天github已经突破250个star，感谢热心佬友们的支持和建议
【开源】Metapi：中转站的中转站，一个 Key 聚合 New API / One API / OneHub 等多个站点，定时自动签到，适用于个人管理公益站等等 开发调优V1.2已更新，佬友们可以拉取最新docker镜像体验 佬友们好，今天来分享一个自己搓的开源项目。 不知道佬友们有没有和我一样的困扰——手上注册了一堆 AI 中转站（其实都是公益站）：New API 的、DoneHub 的、还有基于New API魔改的AnyRouter 的……每个站点一个 Key、一个余额、一套模型列表。 日常使用的时候： 想用 Claude，去 A 站看看余额够不够 …
star-history-2026321832×1324 151 KB
下面带来Metapi V1.2.0 新特性介绍
1 支持正则匹配模型创建群组
这个功能有许多佬友想要，现在可以用 exact / glob / re:regex 三种方式做模型匹配，批量把各种上游模型聚合成一个下游模型名，适合做统一别名和大规模模型管理。
同时支持映射预览，配置前就能看到命中结果，避免误配。
比如图里把sonnet-4-5和opus-4-5放到一个名叫claude-opus-4-6的群组里，cc里/model opus实际用的就会是sonnet-4-5或opus-4-5
image2205×1316 386 KB
15e843a207b72ad3ed7f55ee39a459882477×1009 410 KB
2 路由匹配与容错增强
路由链路做了进一步优化，包含命中逻辑增强、失败后的自动重试与冷却避让。
同时补齐了 OpenAI Responses 相关能力，并增强了不同上游端点之间的切换与兼容处理，减少同模型不同站点协议不一致带来的失败。
3 支持分组多 Key，下游策略更细粒度
除了全局 PROXY_TOKEN，现在支持项目级多 Key 管理。
每个 Key 可独立配置过期时间、费用上限、请求上限、模型白名单、群组白名单、站点权重，适合多项目拆分使用，比如cc专门建一个key里面放opus，大龙虾建个openclaw key放一些量大管饱模型。
image928×299 24.7 KB
image659×1012 46.6 KB
4 支持无账号 URL + Key 接入
部分场景如有佬友发了个公益key的情况下，不再强依赖账号体系，可直接通过 URL + Key 方式接入，减少配置步骤，当然也就无法查看余额，无法签到。
9b2c09aa93a5dc87cf5619d1ef795a3f1879×985 75.1 KB
5d9ffad1c4535bf8ee704af6ab285bb41909×1059 166 KB
5 支持个别站点开启代理
很多佬友反应说机器在国内，有些中转站在国外无法访问，于是加了出战代理功能，可按站点维度单独配置代理，不再是全局一刀切
image1923×558 29.4 KB
6 Zeabur 一键部署
新增 Zeabur 模板，项目主页和项目文档都加上了按钮，点击一键开箱部署；同时完善 Release 启动脚本和兼容性处理，降低佬友们的托管门槛。
image1413×1132 72.2 KB
image1823×1308 184 KB
7 项目文档中心上线
文档上线，后续会继续完善文档，佬友们再也不用担心不会用了！
image2140×1272 300 KB
image1791×1299 260 KB
8 UX 持续优化
本次还包含一批交互和界面细节优化，比如搜索功能通过ctrl+k快捷开启，搜索站点后快速定位并高亮，站点账号支持按余额排序或自定义排序，也支持置顶操作，某些报错提示比如令牌过期，更清晰更友好了！
image1825×825 114 KB
image1828×735 79 KB
写在后面
这次更新就这么多了，目前项目就我一个人在维护，还有很多佬友的建议和问题没能及时修复，先更新这些吧
大家爽用，有问题或建议反馈依旧在话题下随便发，或者去github发issue
GitHub：GitHub - cita-777/metapi: 把你在各处注册的 New API / One API / OneHub / DoneHub / Veloera / AnyRouter / Sub2API 等站点， 汇聚成 一个 API Key、一个入口，自动发现模型、智能路由、成本最优
文档站： Metapi 项目文档网页
Docker Hub：1467078763/metapi - Docker Image
如果觉得有用，给帖子点个赞，给项目点个 Star 就是最大的支持了
网友解答：--【壹】--：
估计得伪造或者冒充 Claude Code CLI 指纹去绕过上游限制，不太行，如果上游专门做检测了去绕就不太好，也可能封号，只能每天签签到了
--【贰】--：
支持大佬
--【叁】--：
第二点，是的，如果可以，还希望可以调整模型的权重，比如我就想让gemini这个模型，走薄荷这个公益站的，cc的haiku走a站，sonnet走anyroute这种。
第三点，比如鸭佬的这个站点。https://free.duckcoding.com
他就不允许在cc之外用，我用metapi反代这个站点会直接被拒绝
--【肆】--：
支持一下，虽然感觉有点复杂。
--【伍】--：
\https://\free.duckcoding.com\/console/topup
--【陆】--：
感谢佬友的长文回复
关于1，目前主要是考虑到如果有佬友一个站点有多个账号，比如有佬友会把他和他好朋友的号一起绑然后他们两一起用，捆绑的话就只能单站点对应单账号了，newapi访问令牌的获取方式在文档的快速上手部分贴图配文了哦，用户id的话大部分站点需要手动填写，但比如wong佬的站点又可以自动获取到用户id，也许后面可以改成id放在令牌旁边可选填写，能自动获取id的不填也能过，不能自动获取的就必须填，这样两种站点都能考虑到，只用传统url+key方式的话是无法获取余额等账号信息的，如文章第四点所示，可以获取到模型也可以正常路由使用的，不过后面的展示可以优化下，取消这类方式的签到和刷新余额按钮
关于2，是指加入站点层级的优先级权重吗
关于3，是指anyrou这种cc专供中转站吗，目前的话anyrout接入metapi后能聊天也能在cc中使用的
--【柒】--：
很不错，试了几个类似的项目，佬这个最好了，支持！
--【捌】--：
佬太强了，开发效率惊人，一会试一下。
顺便问一下支持转发 codex 的 compact 请求吗？之前试过 octopus 不支持会404，用 codex 的时候还是不能用聚合站。
--【玖】--：
支持佬友～～～
--【拾】--：
首先感谢佬友的开源。
我昨天在内网部署了佬友的这个项目，提几个我自己的小建议或者想法吧~
1、需要先添加站点再添加账号，个人认为是否会存在不便，可否一同添加？另外一个问题，在添加账号的指引里，除了access toekn易获取外，new-api的访问令牌的获取方式是否可以写明一下，个人拙见~再一个就是填写new-api的访问令牌时，绝大多数的网站都需要用户填入用户id，我们这个项目的用户id是先检验一次后，发现要填入id才出现让用户填写，是否可以前期就支持填入？并且直接作为可选项？其次，添加账号到检测成功，期间的等待时间过长，不过这也有可能和对方站点有关，我暂时先提出来~然后就是对于没有添加访问令牌后，只使用api的情况下，对账号的检测会经常失败，这可能会影响到后续模型的路由？是否可以优化一下这个问题，即使只使用api-key，检测的方法是不是可以优化呢
2、可否支持用户自己手动调整某个渠道下的模型，他的权重，目前就是用户自己拖动到T0-T2，我想能不能有个手动填写或者滚轮，允许用户自己调整权重？
3、个人愚见，当前项目作为中转站的中转，聚合多个api站点的情况下，能否解决上游检测是否在cc中使用这样的机制呢，不过这样可能会带来一些问题，比如富可敌国不允许除cc外使用这种，可能会对项目带来冲击？不过这只是个人想法~
--【拾壹】--：
不能，他直接拒绝了，直接返回说仅允许在cc中使用
--【拾贰】--：
对，而且还可能引起上游的方案，所以我只能说算损招
--【拾叁】--：
已经用上了
--【拾肆】--：
支持一下，点个star
--【拾伍】--：
有人机验证的咋办啊，能手动过人机验证，或者手动输入过完验证的参数吗？
--【拾陆】--：
佬更新的好快，本来还想今天提个支持key url导入的rp，结果已经实现了
--【拾柒】--：
在cc里用metapi的url和key，路由那边把鸭佬的的优先级调到最高，能在cc里用不，还是必须要在cc里改成鸭佬站点的url和key
--【拾捌】--：
太强了，大佬
--【拾玖】--：
目前还没想到人机验证怎么过好可以用反检测浏览器解决，但太吃性能
写在前面
继Metapi开源后，受到佬友们的热情关注，才短短上线两天github已经突破250个star，感谢热心佬友们的支持和建议
【开源】Metapi：中转站的中转站，一个 Key 聚合 New API / One API / OneHub 等多个站点，定时自动签到，适用于个人管理公益站等等 开发调优V1.2已更新，佬友们可以拉取最新docker镜像体验 佬友们好，今天来分享一个自己搓的开源项目。 不知道佬友们有没有和我一样的困扰——手上注册了一堆 AI 中转站（其实都是公益站）：New API 的、DoneHub 的、还有基于New API魔改的AnyRouter 的……每个站点一个 Key、一个余额、一套模型列表。 日常使用的时候： 想用 Claude，去 A 站看看余额够不够 …
star-history-2026321832×1324 151 KB
下面带来Metapi V1.2.0 新特性介绍
1 支持正则匹配模型创建群组
这个功能有许多佬友想要，现在可以用 exact / glob / re:regex 三种方式做模型匹配，批量把各种上游模型聚合成一个下游模型名，适合做统一别名和大规模模型管理。
同时支持映射预览，配置前就能看到命中结果，避免误配。
比如图里把sonnet-4-5和opus-4-5放到一个名叫claude-opus-4-6的群组里，cc里/model opus实际用的就会是sonnet-4-5或opus-4-5
image2205×1316 386 KB
15e843a207b72ad3ed7f55ee39a459882477×1009 410 KB
2 路由匹配与容错增强
路由链路做了进一步优化，包含命中逻辑增强、失败后的自动重试与冷却避让。
同时补齐了 OpenAI Responses 相关能力，并增强了不同上游端点之间的切换与兼容处理，减少同模型不同站点协议不一致带来的失败。
3 支持分组多 Key，下游策略更细粒度
除了全局 PROXY_TOKEN，现在支持项目级多 Key 管理。
每个 Key 可独立配置过期时间、费用上限、请求上限、模型白名单、群组白名单、站点权重，适合多项目拆分使用，比如cc专门建一个key里面放opus，大龙虾建个openclaw key放一些量大管饱模型。
image928×299 24.7 KB
image659×1012 46.6 KB
4 支持无账号 URL + Key 接入
部分场景如有佬友发了个公益key的情况下，不再强依赖账号体系，可直接通过 URL + Key 方式接入，减少配置步骤，当然也就无法查看余额，无法签到。
9b2c09aa93a5dc87cf5619d1ef795a3f1879×985 75.1 KB
5d9ffad1c4535bf8ee704af6ab285bb41909×1059 166 KB
5 支持个别站点开启代理
很多佬友反应说机器在国内，有些中转站在国外无法访问，于是加了出战代理功能，可按站点维度单独配置代理，不再是全局一刀切
image1923×558 29.4 KB
6 Zeabur 一键部署
新增 Zeabur 模板，项目主页和项目文档都加上了按钮，点击一键开箱部署；同时完善 Release 启动脚本和兼容性处理，降低佬友们的托管门槛。
image1413×1132 72.2 KB
image1823×1308 184 KB
7 项目文档中心上线
文档上线，后续会继续完善文档，佬友们再也不用担心不会用了！
image2140×1272 300 KB
image1791×1299 260 KB
8 UX 持续优化
本次还包含一批交互和界面细节优化，比如搜索功能通过ctrl+k快捷开启，搜索站点后快速定位并高亮，站点账号支持按余额排序或自定义排序，也支持置顶操作，某些报错提示比如令牌过期，更清晰更友好了！
image1825×825 114 KB
image1828×735 79 KB
写在后面
这次更新就这么多了，目前项目就我一个人在维护，还有很多佬友的建议和问题没能及时修复，先更新这些吧
大家爽用，有问题或建议反馈依旧在话题下随便发，或者去github发issue
GitHub：GitHub - cita-777/metapi: 把你在各处注册的 New API / One API / OneHub / DoneHub / Veloera / AnyRouter / Sub2API 等站点， 汇聚成 一个 API Key、一个入口，自动发现模型、智能路由、成本最优
文档站： Metapi 项目文档网页
Docker Hub：1467078763/metapi - Docker Image
如果觉得有用，给帖子点个赞，给项目点个 Star 就是最大的支持了
网友解答：--【壹】--：
估计得伪造或者冒充 Claude Code CLI 指纹去绕过上游限制，不太行，如果上游专门做检测了去绕就不太好，也可能封号，只能每天签签到了
--【贰】--：
支持大佬
--【叁】--：
第二点，是的，如果可以，还希望可以调整模型的权重，比如我就想让gemini这个模型，走薄荷这个公益站的，cc的haiku走a站，sonnet走anyroute这种。
第三点，比如鸭佬的这个站点。https://free.duckcoding.com
他就不允许在cc之外用，我用metapi反代这个站点会直接被拒绝
--【肆】--：
支持一下，虽然感觉有点复杂。
--【伍】--：
\https://\free.duckcoding.com\/console/topup
--【陆】--：
感谢佬友的长文回复
关于1，目前主要是考虑到如果有佬友一个站点有多个账号，比如有佬友会把他和他好朋友的号一起绑然后他们两一起用，捆绑的话就只能单站点对应单账号了，newapi访问令牌的获取方式在文档的快速上手部分贴图配文了哦，用户id的话大部分站点需要手动填写，但比如wong佬的站点又可以自动获取到用户id，也许后面可以改成id放在令牌旁边可选填写，能自动获取id的不填也能过，不能自动获取的就必须填，这样两种站点都能考虑到，只用传统url+key方式的话是无法获取余额等账号信息的，如文章第四点所示，可以获取到模型也可以正常路由使用的，不过后面的展示可以优化下，取消这类方式的签到和刷新余额按钮
关于2，是指加入站点层级的优先级权重吗
关于3，是指anyrou这种cc专供中转站吗，目前的话anyrout接入metapi后能聊天也能在cc中使用的
--【柒】--：
很不错，试了几个类似的项目，佬这个最好了，支持！
--【捌】--：
佬太强了，开发效率惊人，一会试一下。
顺便问一下支持转发 codex 的 compact 请求吗？之前试过 octopus 不支持会404，用 codex 的时候还是不能用聚合站。
--【玖】--：
支持佬友～～～
--【拾】--：
首先感谢佬友的开源。
我昨天在内网部署了佬友的这个项目，提几个我自己的小建议或者想法吧~
1、需要先添加站点再添加账号，个人认为是否会存在不便，可否一同添加？另外一个问题，在添加账号的指引里，除了access toekn易获取外，new-api的访问令牌的获取方式是否可以写明一下，个人拙见~再一个就是填写new-api的访问令牌时，绝大多数的网站都需要用户填入用户id，我们这个项目的用户id是先检验一次后，发现要填入id才出现让用户填写，是否可以前期就支持填入？并且直接作为可选项？其次，添加账号到检测成功，期间的等待时间过长，不过这也有可能和对方站点有关，我暂时先提出来~然后就是对于没有添加访问令牌后，只使用api的情况下，对账号的检测会经常失败，这可能会影响到后续模型的路由？是否可以优化一下这个问题，即使只使用api-key，检测的方法是不是可以优化呢
2、可否支持用户自己手动调整某个渠道下的模型，他的权重，目前就是用户自己拖动到T0-T2，我想能不能有个手动填写或者滚轮，允许用户自己调整权重？
3、个人愚见，当前项目作为中转站的中转，聚合多个api站点的情况下，能否解决上游检测是否在cc中使用这样的机制呢，不过这样可能会带来一些问题，比如富可敌国不允许除cc外使用这种，可能会对项目带来冲击？不过这只是个人想法~
--【拾壹】--：
不能，他直接拒绝了，直接返回说仅允许在cc中使用
--【拾贰】--：
对，而且还可能引起上游的方案，所以我只能说算损招
--【拾叁】--：
已经用上了
--【拾肆】--：
支持一下，点个star
--【拾伍】--：
有人机验证的咋办啊，能手动过人机验证，或者手动输入过完验证的参数吗？
--【拾陆】--：
佬更新的好快，本来还想今天提个支持key url导入的rp，结果已经实现了
--【拾柒】--：
在cc里用metapi的url和key，路由那边把鸭佬的的优先级调到最高，能在cc里用不，还是必须要在cc里改成鸭佬站点的url和key
--【拾捌】--：
太强了，大佬
--【拾玖】--：
目前还没想到人机验证怎么过好可以用反检测浏览器解决，但太吃性能