托管企业级网关
ZenMux、OpenRouter、Fireworks信任感和文档结构可以参考这些产品。但 Sub2API 第一天硬装成企业级托管不现实——运营模型还没在海外跑过，承诺太满反而丢信任。
申请工作样本 · Celeste Deng
看到你发帖找技术合伙做 token 出海后，我理解是：Sub2API 现在是个强技术项目，需要有人把它整理成海外用户看得懂、用得起来的东西。 所以我没继续做虚的营销 demo，直接把第一周我会真正负责的事拆出来了。
产品与竞品调研
我的初步判断：Sub2API 第一阶段不应该假装自己是 ZenMux/OpenRouter 这种托管企业级平台。 更锋利的切入点是给懂技术的运营者提供自托管 infrastructure，重心在成本、账号控制、OpenAI-compatible 接入和运维透明度。
信任感和文档结构可以参考这些产品。但 Sub2API 第一天硬装成企业级托管不现实——运营模型还没在海外跑过，承诺太满反而丢信任。
这里可能是 Sub2API 更切得进去的地方：用户已经感受到账号池、成本和兼容性的痛了，自己来或者用现成的。
适合看需求信号和卖点话术，但当真相源不行。稳定性和售后差异大，有的人明天就关了。
用户调研转译
早期最锋利的切入点不是「一个 API 调所有模型」，而是服务已经感受到账号池、成本控制、 OpenAI-compatible 接入和中转不稳定痛点的技术型运营者。
痛点：官方 API 成本高，第三方中转可能突然失效，自建 Sub2API / new-api 又有部署门槛。
需要：低成本、可控、能自托管，并且清楚知道部署步骤和故障边界。
→ 所以第一版产品表面如果只写漂亮卖点，没写部署步骤、账号接入、健康检查和常见失败原因，这人就走了。
痛点：多个 provider 带来多个 key、多个账单、多个 dashboard、多个 owner，以及凌晨随机故障点。
需要：统一入口、按人/按 key 的用量可见性、key rotation、fallback 行为。
→ Dashboard 如果不先给 usage、keys、logs、health、fallback state，而是放满装饰性后台功能，接不住这类人。
痛点：账号池、Token 级计费、并发限流、上游不稳定、余额、日志和告警才是真正的脏活。
需要：成熟的账号调度、计费、限流、监控、审计和运维系统。
→ 这类人很可能不是先看 Demo 再试用——他们是看 runbook 和故障处理能力。口号打不动这群人。
痛点：Cursor、Cline、Claude Code、Aider、Chat UI、Agent 框架都不该各自维护一套 provider 配置。
需要：稳定的 OpenAI-compatible Base URL、清晰的 /models 行为、可预测错误和极简接入。
→ Docs 如果先讲功能清单，而不是先给 Base URL、auth、/models、chat completions、error model 和兼容性限制，这页就没用。
不急着写页面。第一天搞清楚几件事：Sub2API 现在能做什么、不能过度承诺什么。第一批海外用户大概是谁。哪些场景可以安全公开说，哪些不能说。
参考资料
社区观点：cliproxyapi、sub2api、new2api 被放在一起比较；Sub2API 更像适合一定规模中转/分享场景，个人轻量使用可能选更小工具。
先把最朴素的路径跑通。依赖、PostgreSQL、Redis、Docker、反代、密钥、健康检查——跑通之后再写部署 checklist。公开文案等部署摸清楚了再决定怎么写。
不用想象。翻一下社区里别人怎么接 Sub2API 的——x-video-translator 怎么集成的、模型列表有什么缺口、哪个 endpoint 有坑——拿这些信号来写 docs，少凭空设计。
参考资料
真实集成案例：Edge 扩展 + 本地后端的 X 视频自动翻译字幕插件，支持接入 Sub2API 或其他 OpenAI-compatible API。
具体接入坑：xAI 的 /models 没返回 Grok Composer 2.5 Fast，但通过 hermes proxy 类方案直接指定模型名可以正常使用。
credits 怎么算、充值走什么、单次请求扣多少、上游账号是谁的、refresh token 锁在哪、sticky session 怎么处理。这些不是 UI 的事，是会出生产事故的地方。先把运营模型搞清楚，再考虑页面怎么展示。
翻一遍 GitHub issue，把真实运维痛点拉出来：真实 client IP 拿不到、env 漂移、DB 初始化失败、多实例限制不清楚——这些才是后台骨架应该解决的问题。哪个 issue 最多人踩，先做哪个。
前面几天已经跑了部署、读了 issue、摸了计费。这时候写的公开页面不再是想象，知道自己托管、私用场景、管理员合规确认、上游 ToS 风险这些边界在哪。不写成「安全无忧，完全合规」那种东西。
社区帖当需求信号看，不当技术真理。我看下来有用的模式是自托管、多账号、外部访问、工具集成和多服务共存——这些对应真实运维场景，不是虚的。
参考资料
生产级自托管信号：OpenAI 账号风险后，用 Sub2API 把订阅转成 API，在 Mac Mini 上跑多账号，并通过 Surge Ponte 做外部访问。
多服务运维信号：Sub2API 可以和 new-api、cc-switch 并行部署，但也说明实际运维复杂度会迅速上升。
真实集成案例：Edge 扩展 + 本地后端的 X 视频自动翻译字幕插件，支持接入 Sub2API 或其他 OpenAI-compatible API。
我还写了一份 API contract 样本——展示我对 endpoint 设计、billing 字段、error model 和开发者接入体验的理解。
下面这些没进某一天的具体计划，但帮我理解了周边生态和潜在坑位。
Sub2API 衍生 gateway 方向；适合作为生态信号，不作为官方事实来源。
Session 转换工具；适合理解导入需求和 token 过期风险。