把 Trae 桌面端的模型接进任意 OpenAI 客户端（二）：做成本地大模型网关之后
内容提要
作者将 Trae 桌面端模型代理重写为本地大模型网关，统一接入 Trae、DeepSeek、Kimi、Ollama 等渠道。客户端只需一个 baseURL 和 key，模型 id 通过前缀区分渠道。网关负责解析 id、选择渠道、转发请求并记录用量，支持 key 权限控制、SQLite 用量统计和客户端配置导入。核心思路是把 Trae 仅作为模型来源之一，对外提供统一的 /v1 端点。
延伸解读
从代理到网关：思路转变的关键
作者最初只做 Trae 的协议转换代理，但实际使用中同时接入 DeepSeek、Kimi、智谱、Ollama 等多个渠道，每个渠道都有独立的地址、密钥和模型名，客户端配置繁琐。重写后，方向从“翻译”转为“收口”：所有渠道注册到同一网关，对外只暴露一个 baseURL 和一套鉴权，模型 id 通过前缀区分来源。这种转变让 Trae 降级为渠道之一，而非项目核心。
统一模型 id 与客户端体验
网关要求所有模型 id 带渠道前缀，例如 trae-cn/glm-5.3、deepseek/deepseek-chat、ollama/llama3.1。客户端只需配置一个 baseURL 和一把 key，通过 /v1/models 获取可用模型列表，无需关心背后是哪家服务。网关内部负责解析 id、选择渠道、转发请求并记录用量。这种设计让客户端配置一次即可长期使用，避免了多套配置反复切换的麻烦。
权限控制与用量统计的实用价值
做成网关后，原先“凑合能用”的功能有了系统化答案。key 从简单的有无状态升级为可限制访问特定渠道或模型；每次请求的用量会写入 SQLite，管理台可查看汇总、分布和最近记录。此外，管理台支持直接唤起 CC Switch、opencode 等客户端的官方导入，opencode 还有脚本自动写入实时模型目录。这些功能单独看都不复杂，但组合起来才更像一个完整的网关产品。
适用场景与注意事项
作者指出，如果只是偶尔在别的工具里用一下 Trae，轻量代理就足够；但若想长期维护一个“什么模型都能接、所有客户端只配一次”的本地入口，网关思路更合适。项目仅适用于自己已登录的账号，需遵守 Trae 服务条款，不得用于绕过计费或多人共享。实现思路和部分代码参考了开源仓库，版权与署名见 LICENSE 与 THIRD_PARTY_NOTICES.md。
Q&A
本地大模型网关和之前的代理模式有什么区别？
代理模式主要做“翻译”，尽量原样透传上游协议；网关模式则是“收口”，不管上游是 Trae、OpenAI 兼容服务、Anthropic、Gemini 还是 Ollama，对客户端来说都只是同一个地址、同一个模型列表、同一套鉴权。
这个网关如何统一管理多个模型渠道？
所有渠道都注册在同一个网关里，模型 id 统一带前缀，例如 trae-cn/glm-5.3、deepseek/deepseek-chat、ollama/llama3.1。客户端只认一个 baseURL，配一把 key，从 /v1/models 拉到什么就调什么，不需要知道模型背后是哪家。
网关支持哪些 key 权限控制功能？
之前 key 只有“有”和“没有”两种状态，现在可以限制某个 key 只能访问某些渠道、某些模型。
用量统计是怎么实现的？
每次请求都会落到 SQLite，管理台能看到汇总、分布和最近记录。
如何将网关配置导入到其他客户端？
管理台可以直接唤起官方导入，opencode 也有脚本自动写入实时模型目录。
这个项目适合什么场景使用？
如果只是想偶尔在别的工具里用一下 Trae，一个轻量代理就够了。但如果想在自己的电脑上长期维护一个“什么模型都能接、所有客户端都只配一次”的入口，网关这个思路更顺。
