现在很多人的本地 AI 工作流，已经不只是“配一个 API key 然后开跑”这么简单了。

  • 有人同时接 OpenAI、Anthropic 和 Gemini；
  • 有人想让 Codex、Claude Code、OpenCode 共用一套本地入口；
  • 有人需要在不同上游之间做优先级和故障切换；
  • 有人希望把 token 消耗、延迟和请求记录留在自己机器上；
  • 还有人得处理接口格式不一致的问题。

问题是，这些需求一叠起来，本地 AI 客户端很快就会变成一堆分散配置。

  • 这个 CLI 走 OpenAI 兼容接口；
  • 那个工具要求 Anthropic 消息格式；
  • 另一个又想直接吃 Gemini；
  • 每个客户端都各自保存一套 endpoint、key 和模型映射；
  • 真出问题时，还不容易看清到底是哪一层炸了。

今天想记下的 mxyhi/token_proxy，就是在补这块空白。它不是单纯给某个模型供应商做皮肤，而是一个跑在本机上的 local AI API gateway：负责接住本地 AI 客户端，把请求路由到不同上游，按规则做转换和负载分配，并把请求、token 和延迟统计留在本地。

按 GitHub 仓库页、README 和 releases 页在 2026-06-26 的公开信息，这个仓库当前约有 74 stars、14 forks，仓库创建于 2026-01-09，最近一次公开更新出现在 2026-06-26。仓库主语言显示为 Rust，同时包含 TypeScript/Tauri 桌面界面，项目采用 Apache-2.0 许可证，最新 release 是 v0.1.115，发布时间为 2026-06-23。

项目概览

属性详情
仓库mxyhi/token_proxy
定位本地 AI API 网关与客户端接入层
Stars74
Forks14
主要技术栈Rust、TypeScript、Tauri
创建时间2026-01-09
最近公开更新2026-06-26
LicenseApache-2.0
最新版本v0.1.115
版本日期2026-06-23

它想解决的不是“代理一个接口”，而是“收口本地 AI 客户端接入”

README 对 Token Proxy 的描述挺直接：它是一个运行在本机上的 AI API gateway，面向 OpenAI、Anthropic、Gemini 这些上游，也面向 Codex、Claude Code、OpenCode 这类本地客户端。

这个定位很重要。

因为很多所谓“AI 代理层”只做了一件事：

  • 转发某一种格式；
  • 把一个 provider 包成另一个 provider；
  • 或者单纯把 key 和 base URL 换个地方保存。

而 Token Proxy 的想法更完整一些。它想把几件本来分散的事合并起来：

  • 本地统一入口；
  • 多上游配置；
  • provider 之间的优先级和负载分配；
  • 不同 API 格式之间的转换；
  • 本地 token 与请求观测；
  • 给常见 AI CLI 做一键接入。

换句话说，它更像一个 面向本地 AI 客户端的控制层，而不是单点的格式转发器。

最有意思的地方，是它把“兼容层”和“运营层”放在了一起

README 里列出来的能力，拼起来其实很像一个小型本地网关产品：

  • 支持 openai、openai-response、anthropic、gemini、kiro、codex 多类 provider；
  • 支持 OpenAI Chat / Responses、Anthropic Messages、Gemini 之间的格式转换；
  • 支持按上游优先级做 fill-first 或 round-robin 分发；
  • 支持串行、hedged、race 三种请求派发策略；
  • 支持 model alias mapping 和 response model rewrite；
  • 支持本地 access key 与上游 key 注入分离；
  • 支持 SQLite 记录 requests、tokens、latency、recent logs。

这点让我挺在意，因为很多本地 AI 工作流其实已经开始接近“微型多云接入”。

你以为自己只是让几个 CLI 指向同一个 base_url，但真实需求很快会变成：

  • 这个模型优先走哪个供应商；
  • 哪些客户端要吃 OpenAI 风格，哪些要吃 Anthropic 风格；
  • 某个上游 429 之后要不要先冷却一会儿；
  • 某些请求能不能换格式后再试另一个 provider；
  • 到底是谁消耗了多少 token。

Token Proxy 不是只管第一步，而是把这些后续问题一并考虑进去了。

它对 Codex、Claude Code 这类工具的照顾，不是停留在“理论兼容”

README 里我最喜欢的一点，是它没有只写“OpenAI compatible”然后让你自己回去折腾。

它直接把 one-click CLI setup 做进去了。

  • Claude Code：写入 ~/.claude/settings.json 相关环境变量；
  • Codex：写入 ~/.codex/config.toml 和 ~/.codex/auth.json；
  • OpenCode：写入对应配置文件和认证文件；
  • 覆盖之前会先生成备份文件。

这说明作者是真的把“本地 AI 客户端怎么接进来”当成主场景，而不是只把仓库停在“一个会监听端口的代理服务”。

很多项目的问题就在这里：网关本身能跑，但最后一步还要用户自己手动改三四处配置。等客户端一多，这套接入就很难维护。

Token Proxy 把这层接入工作显式产品化了，所以它看起来更像一个实用工具，而不是演示性质的 middleware。

它不是只做路由，还试图把可见性留在本地

另一个值得记住的点，是它把 SQLite dashboard 放进核心设计里。

README 里明确写了，本地数据库会记录：

  • 每次请求的 token；
  • cached token；
  • latency；
  • model；
  • upstream；
  • recent requests。

桌面端 dashboard 还能直接看 totals、provider 统计、时间序列和最近请求，日志面板还支持一个 30 秒的请求详情捕获窗口。

这对本地使用其实很实用。

因为一旦你同时接多个 provider 和多个客户端，最难受的不是配置文件本身，而是你根本不知道：

  • 某次超时是哪个上游慢了；
  • 某个 CLI 到底落到了哪个 provider；
  • 最近 token 消耗为什么突然涨了；
  • 哪种格式转换最常出错。

Token Proxy 的思路不是把这些事情扔给外部观测平台，而是先在本地给你一个够用的请求和 token 观察面。

它在接口边界上写得比较细，这反而让人放心

这类项目最容易出问题的地方，恰恰是接口边界不清。

比如：

  • 本地认证头和上游认证头会不会混在一起；
  • 哪些路由一定只走 OpenAI 兼容 provider；
  • /v1/messages 和 /v1/responses 分别怎么回退；
  • Gemini 原生端点是否允许跨格式回退；
  • 请求重试和 cooldown 的条件是什么。

README 在这方面写得相当具体。

它明确区分了：

  • 本地 local_api_key 的验证规则；
  • 上游 api_key 的注入规则；
  • 各类路由的 provider 选择顺序；
  • 哪些错误会触发 retry；
  • 哪些错误会触发一段时间的 cooldown。

这种“把规则写得有点啰嗦”的项目，往往比只有一句“supports multiple providers”的项目更可信。因为真正在本地接多个 AI 客户端的人，最后踩坑基本都踩在这些细节上。

CLI + Tauri 双形态，让它更像“本地控制面”而不是纯后端组件

Token Proxy 现在不是只有一个守护进程。

README 里能看到它同时提供：

  • Cargo workspace 下的 CLI；
  • src-tauri/ 里的桌面应用；
  • release 页面里的多平台打包产物。

这点挺关键。

因为有些用户要的是：

  • 纯命令行；
  • 配个 config.jsonc 就跑；
  • 不想看到桌面界面。

而另一些用户更需要：

  • 图形化管理上游；
  • 看 dashboard；
  • 直接修改配置并自动 reload。

这两类需求放在一起时，很多项目最后只服务好其中一种。Token Proxy 至少从架构上看，是在努力同时覆盖这两端。

它适合谁

我觉得 Token Proxy 比较适合这些场景：

  • 你在本地同时使用 Codex、Claude Code、OpenCode 或其他 AI 客户端；
  • 你想把多个 provider 收到一个统一入口后再做路由；
  • 你需要 OpenAI / Anthropic / Gemini 风格请求之间的转换；
  • 你希望在本地看到 token、延迟和请求轨迹；
  • 你不想把每个客户端都单独配置一套 key、base URL 和模型映射。

尤其是对已经开始把本地 AI 工具当成“日常开发工作台”的人来说，这类网关会比单独记一堆环境变量更可维护。

它的边界也要看清

当然，Token Proxy 不是：

  • 企业级统一 API 管理平台；
  • 云端托管的团队网关；
  • 零配置自动最优路由系统；
  • 真正替你处理所有安全问题的隔离层。

它更像一个 本地优先的 AI 接入与控制面：

  • 把客户端接入收口；
  • 把 provider 路由规则写清；
  • 把格式转换和负载策略交给本地网关；
  • 把观测数据尽量留在自己机器上。

如果你只是单客户端单 provider，甚至永远只打一个接口，它可能显得有点重。

但如果你的本地 AI 栈已经开始变复杂，这种工具就会很有价值。

小结

mxyhi/token_proxy 值得看的地方，不只是“它支持多少 provider”，而是它把本地 AI 使用里最容易分裂的几层重新收拢起来了：

  • 客户端接入；
  • provider 路由；
  • API 格式转换；
  • 负载均衡和失败回退；
  • token 与请求观测；
  • 常见 AI CLI 的配置落地。

如果你最近也在把多个 AI 客户端和多个模型供应商塞进同一台开发机里，那这个仓库很值得认真翻一遍。它解决的是一个越来越常见、但还没有很多工具真正做顺的本地问题。