从 New API 到 ohmyapi

2026 年 9 月初，在几位好友的怂恿提议下，我添置了 GPT Pro 20x（现在已经没有 20x 啦！）并且开设了自己的 AI API 网关（俗称中转站），主要目的在于保证几位主要出资人有足够的 GPT 用量，同时将闲置额度转卖。因此，我采取了 Sub2API  转接 New API  的模式，其中 Sub2API 用于将 OpenAI 订阅账号反代成可任意调用的 API；New API 则负责将 API 按照定价转卖。后来出于很多原因，我弃用了上述两个框架，转而开发自己的 AI 网关，即 ohmyapi ，现在所有的业务均通过 ohmyapi 进行。本文将介绍笔者从 New API（和 Sub2API）迁移到 ohmyapi 的原因（也就是对 New API 的吐槽），以及开发与打磨 ohmyapi 的一些历程。

New API 的问题

New API 诞生于 2023 年，当时的名字叫做 One API，主要解决多个 AI 服务商的 API Key、接口和配额难以统一管理的问题，其核心思路是让不同模型通过一个兼容 OpenAI API 的入口访问。在它诞生的年代，最火热的模型是 GPT-3.5，大模型的能力远远不足以形成当今的 vibe coding 盛世，因此 New API 积累了优秀的「古法编程」底蕴。在 vibe coding 横行的今天，New API 的代码当然也充斥着各种 LLM 的造物，但这份底蕴确实避免了很多完全的 AI 造物的弊端。笔者在初次接触 New API 时也叹服于其美观的外表与强大的功能，但在以管理员的身份部署和使用 New API 的过程中，它的很多问题逐渐展现出来。

刚 clone 完项目，New API 就给了笔者一个下马威。暂且不提它的 Git History 有多大，单单是前端的编译阶段就让笔者苦不堪言。笔者没有细致考察过其前端所用的框架，只知道其使用了 bun 工具链。笔者在终端中输入 bun build，发现构建迟迟无法完成，在后台观察 MCSM 显示的资源用量，发现 CPU 占用率几乎为 100%，而内存也步步吃紧，这对于笔者的轻量云服务器而言实在算不上友好。New API 本身是允许二改后部署的（并且许多中转站站主也这么做了），但如此高的二改后编译成本实在让人望而却步。笔者尝试数次后，只好破费将云服务器的内存升级到 8G，才勉强完成了前端的编译，并且发誓从今往后再也不碰 New API 的前端了。

对于中转站站主而言，编辑各个模型的定价以及通过扣费的倍率（换言之，用户使用某一渠道的模型会按照官方定价乘以多少倍来扣费）是最常见的操作，而 New API 显然没有将这一操作优化到极致，具体来说，存在以下三个问题：

首先是过于复杂的定价体系，New API 在模型定价上引入了非常多的自定义概念，例如：

• 模型定价的基本单位不是美元，而是「配额点数」，换算单位为 1 美元 = 500,000 配额点数。
• 模型定价本身就有倍率体系，包含如下的倍率：
  • 模型倍率（ModelRatio） - 定义不同 AI 模型的基础计费倍数
  • 补全倍率（CompletionRatio） - 对输出 token 进行额外计费调整
  • 分组倍率（GroupRatio） - 为不同用户组设置差异化计费倍数
• 据此，基于 Token 消费的模型，其计费公式应该为：

点数消耗 = (输入token数 + 输出token数 × 补全倍率) × 模型倍率 × 分组倍率

这些内容可以参阅 New API 的文档 。笔者对其中的一些设计有自己的看法，例如：

• 配额点数为什么不是 10 的整数次幂？
• 「补全」实际上表示的是输出 token，为什么不直接称为输出倍率？
• 为什么要记录输出的价格是输入的多少倍，而不是直接记录输出的价格？

诚然，这些设计很可能是出于历史原因，例如，「补全」这一名词很显然是 LLM 刚流行时的产物，毕竟那时候 OpenAI 的端点叫做 /v1/chat/completions，但现在这个端点已经基本被 OpenAI 弃用了。但作为一个与时俱进的项目，New API 仍然没有对这些历史遗留问题进行优化，反而在其文档中继续沿用这些概念，这让笔者感到非常困惑。

其次是繁琐的操作流程。不得不说，渠道的添加是非常方便的，直接在控制台首屏的「渠道」入口输入渠道名称、API Key 并选择可用模型即可添加。但当笔者试图调用模型时，New API 则会报错「该模型未配置定价」。于是笔者又去寻找给模型配置定价的入口，结果发现，可用渠道给模型设置定价的入口并不在第一屏，而是需要点进系统设置视图，并且展开一个选项卡后才能看到。点进之后，笔者发现 New API 已经密密麻麻内置了数百个模型的定价，但仔细一看，发现这些模型的年代集中于 2023～2024 年，而真正的新模型的定价还需要重新添加。好在是模型定价页面提供了一个从 models.dev 等渠道拉取定价的选项，笔者还是成功配置了新模型的定价，但整个过程实在是繁琐至极。笔者不禁要问，New API 的开发者真的有自己使用过吗？如果有，为什么不将这些操作流程优化到极致呢？

最后便是落后的差异化定价模型。可以看到，New API 的差异化定价模型是基于用户组划分的——用户位于不同的组别，能够访问到不同的渠道，从而享受不同的定价。但在当下的中转站实践中，我们会经常接入不同倍率的上游渠道，例如渠道 A 的倍率是 0.2x，而渠道 B 的倍率是 0.3x。在 New API 的差异化定价模型中，如果要实现不同的渠道定价，我们只能创建倍率分别为 0.2x 和 0.3x 的两个用户组，把渠道 A 和 B 分别绑定到这两个用户组上，然后再将用户同时分配到这两个用户组上，从而用户可以选择不同的渠道并享受不同的定价。这一设计或许也有历史原因，但在倍率与渠道强绑定的当下，这种设计显然是过时了的，亟需一个更为灵活的差异化定价模型，这也是直接导致笔者最终决定弃用 New API 的原因。

可以看出，上面所说的大部分问题都来源于 New API 的历史包袱，可谓是成也历史，败也历史。基于种种不佳的使用体验，笔者逐渐萌生了开发自己的 AI 网关的想法。

ohmyapi 的诞生

2026 年 10 月初，笔者开始了 ohmyapi 的开发。它始于一个很简单的想法：用最少的代码复刻 AI 网关的核心功能，同时优化定价体系、操作流程和差异化定价模型，并且有意设计为方便扩展的（即使还没有观察到 ohmyapi 的第二位用户）。此外，也采用笔者更加熟悉的 Node.js 作为后端开发语言。

ohmyapi 的第一个版本由 GPT-6.1 Sol 编写，它保留了 New API 的核心功能，并且将定价体系简化为：

• 计费基本单位是 USD 的 1/1,000,000；
• 不内置模型定价，所有模型的信息从 models.dev 拉取；
• 扣费倍率直接同渠道绑定。

此外，ohmyapi 的一个重要抉择是砍掉端点/协议转发，这也就意味着经由 ohmyapi 的渠道会原样保留其请求端点和协议（例如 OpenAI 的 /v1/chat/completions / /v1/responses、Anthropic 的 /v1/messages）而不进行转换。协议转换是一个很大的课题，并且有许多潜在的影响用户体验的坑，New API 和 Sub2API 的大量代码都在进行这方面的工作，但在 AI Coding Harness 盛行的当下，大多数开源 Harness 都原生支持各种主流的调用协议，因此端点转换就不那么重要了。

笔者对 ohmyapi 的前端进行了大量的测试和优化。给 GPT 的 Prompt 是「模仿 Stripe 的前端风格」，这一点 GPT 做得很好，写出的前端基本上是能看的地步，但也仅停留于「能看」的地步。笔者在开发初期尤其优化了添加渠道的体验：

• 填写 API Key 之后即可从上游拉取模型，可按需进行取舍；
• 添加渠道后，页面提示部分或全部模型尚未定价，引导用户前往模型定价页面；
• 模型定价页面提供 从 models.dev 导入 按钮，并且点击后自动选中尚无定价的模型；
• 对于提供阶梯定价或峰谷定价的模型（如 GPT、DeepSeek），提供可选的预设，并且根据模型名称判断是否默认启用。

这大概是所有的前端优化中最值得笔者称道的一个；而其余的都属于细节上的优化，笔者只提最具有代表性的一个：对组件的灵活运用。例如，对于属于同一结构体的若干字段，AI 经常偷懒性地使用 ·、/（尤其是 ·）这些分隔符在同一个 Text 组件里并列展示，而不是考虑使用人类开发的组件库中丰富的视觉语言来进行视觉上的区分，于是我们经常会看到这种布局：

渠道 A · OpenAI · 0.2x
渠道 B · OpenAI · 0.3x

这作为一个原型界面当然可以接受，而且不得不说，使用 · 进行分割恰恰是成本最低并且不容易在视觉上显得「丑陋」的排布方式；但如果放在生产环境，这样的布局就显得不够专业了。这一点很难通过 prompt 工程进行纠正，笔者尝试在 AGENTS.md 中加入这类指示，结果后来开发时，AI 又一股脑地把所有信息都放在 Badge 组件里了。诸如此类的如何灵活使用视觉语言的决策，人类都尚且需要测试若干方案并且反复比对，AI 更是难以胜任。笔者对 AI 所写的展示部分进行了多轮微调，才形成了最终的视觉效果。

偿还技术债

整个开发过程中，GPT-6.1 Sol 的表现很难说令人满意，它在网站构建之初留下了许多匪夷所思的设计，给笔者埋下了许多的技术债，后来这些都被笔者用 Opus 5.5 一笔一笔偿还了。这些技术债中，其中最严重的一个莫过于使用 tokenizer 带来的密集计算瓶颈，进而导致的站点假死了。

起初，笔者认为 ohmyapi 对预占费用的估算实在太过离谱，所有 token 均按照其能命中的最高定价规则进行计算，导致预占费用远高于实际消耗的费用。这当然让网关在计费的时候「不会犯错」，但显然不是用户愿意看到的，否则就会在账户内还存在几块钱余额的时候就无法使用模型了。GPT-6.1 Sol 对此的修改方案是采用 js-tiktoken 进行 token 计数，这样，对 token 数量以及缓存率的估算都会更加准确。10 月 16 日，笔者两次观察到 ohmyapi「假死」，即站点可以正常响应，但对其进行的模型 API 请求直接返回 503。AI 在简单调查后得出了以下的结论：

它不只是算得慢，问题在于每一条流式响应都在热路径上做同步 BPE（OutputTokenEstimate.append 每满 4096 字符就编码一次）。而它的结果只在一种很少见的情况下被用到：客户端断开、后台读取又超时，并且上游已经提前报了输入用量。OpenAI 的 Chat/Responses 只在结尾才报输入用量，所以这条估算路径在 OpenAI 上基本走不到，为一条罕见路径，在热路径上付全额代价，这是早期设计反复出现的模式。

单纯的计算瓶颈并不直接导致 ohmyapi 停止响应外界请求，更重要的是 GPT-6.1 Sol 采取了计费租约的机制，而这一机制会把一次短暂抖动放大成全站中断：

一条专用连接持有 PostgreSQL advisory lock，健康检查 select 1 的超时是 5s。事件循环一被 tokenizer 卡住，检查就超时，进程判定自己失去所有权。这就是昨天那条崩溃链。

在与 Opus 5.5 简要讨论之后，笔者发现 tokenizer 是为了把预占从”按上限冻结”改成”按估算用量冻结”而引入的，但在实际使用中，中转站站主是可以接受微量的负余额的；而计费租约机制更是毫无必要，所有状态流转本来就有 row lock 和状态校验进行保护。因此，笔者决定彻底去除 tokenizer 和计费租约机制，从而也没有再出现过 ohmyapi 假死的情况。

此外，Opus 5.5 在排查中还发现了其他会造成宕机的问题和过度设计的问题，按照其提供的小标题一一列举如下：

• 用量观察上限默认 128 MiB，然后在事件循环里同步解析
• 每个计费请求约 50 次数据库往返，同一组授权查 3～4 遍
• 预占（hold）是最重的机制，却拦不住超支
• 许多配置项只能取一个值，但在数据库中却占用一个 column
• 对请求的拒绝过于苛刻，预估器看不到内容就直接拒绝
• 管理操作的幂等仪式
• ……

这些问题，在 Opus 5.5 的帮助下，笔者逐一进行了修复和优化，最终使 ohmyapi 的稳定性和性能有了提升。

思考

值得一提的是，ohmyapi 是笔者的第一个几乎让 AI 全权接管代码编写，而自己只提供决策和设计建议的产品级项目。笔者与 AI 相谈甚欢，形成了如下的工作流：

• 笔者设想一个场景和对应功能，询问 AI 实现这一功能的可行性、方案和需要注意的坑；
• AI 给出方案并且指出可能的坑，笔者进行评估和取舍；
• AI 进行实现，笔者进行测试，如果有问题，则继续反馈给 AI，直到功能实现完毕；
• 笔者撰写 Commit message，将 AI 实现的功能 commit 到 Git 仓库。

笔者向来最担心的是对项目的发展失去控制，换言之，“Lost control of what is f**king going on”，不过通过及时与 AI 讨论自己的想法，以及亲自撰写 Commit message，笔者还是能够掌控项目的方向和节奏的。笔者在开发 ohmyapi 的过程中，逐渐对「健康的 vibe coding」有了自己的理解：AI 可以在开发中承担大量的重复性工作，但人类仍然需要在设计、决策和把控项目方向上发挥主导作用。通过这种方式，AI 不仅提高了开发效率，也让笔者有更多时间去思考和优化产品的整体架构和用户体验。当然，这些话都是十分 trivial 的——甚至上面的内容是 Copilot 帮我自动补全的——但很多情况下都是 easier said than done。笔者不禁感叹于当今人类的浮躁，经常是突发奇想之后立刻告诉 AI，然后让 AI 全盘接管自己的大脑，代替自己的思考，最终得到的是一个欠测试、欠打磨的半成品。

然而不幸的是，在开源社区，正是这样的产品大行其道并且赚取了大量的 Star，更是有源源不断的人类或 Agent 用户给仓库提出各种各样的 Pull Request，然后再由仓库维护者的 Agent 进行审核和合并，AI 在代码开发上形成了一个彻底的闭环。笔者很难想象如此的维护流程会养出什么样的「LLM 奇观」，也不得不为这样的疯长式发展感到担忧，可惜这样的发展趋势已经是无法违逆了。幸而 GitHub 上能够配置自己的仓库是否接受 PR、接受什么范围内的 PR，笔者也就不用过于担心自己的仓库被 AI 盯上了虽然本来也没人在意就是。

此外，笔者在开发过程中不由得感叹，UI/UX 的优化是一个永恒的课题。截至成稿，并没有任何一个 LLM 在 UI/UX 设计上令人满意。AI 在编写前端时当然可以模仿任何开发者让其模仿的网站（如笔者就经常让其模仿 Vercel 的视觉风格），但它很难理解人类的交互习惯，即使是 Opus 5.5，也难免会写出看似美观、但实际上交互体验很差的前端代码，而这一部分必须由人类进行实操并反馈给大模型，才能让大模型按照人类的交互习惯修复前端代码，上面提到的 ohmyapi 添加渠道操作的优化就是一个很好的例子，这些操作都是笔者后来提到，AI 才逐步实现的。

让软件从一众竞品中脱颖而出的秘诀到底是什么？显然不是 Star 数量，在这个 LLM 奇观泛滥的时代，抓住一个新兴概念并且快速编写一个原型，早已成了包装自己、赚取关注度的利器；也不是所用的 AI 的智力，Opus 5.5 的智力当然更胜一筹，并且它在代码架构上的 Taste 也好过 GPT 一大截，但这并不意味着它能够 oneshot 写出让使用者满意的产品。在笔者看来，秘诀大概是作为产品设计者与开发者对代码的理解和把控能力，以及对用户体验的敏锐洞察力，还有最重要的对产品视如己出的责任感。至少，在 AGI 的车轮将科学、技术、文艺这些人类花费数千年构筑的堡垒彻底碾成齑粉之前，我们还能凭借这些东西苟且偷生吧。