把 LLM 接入能力打包卖给不想自己管理它的人，是一门小而真实的生意：把 AI 功能打进客户项目的代理公司，替几家客户跑负载的顾问，在细分工具里内置模型调用的开发者。市面上多数"如何转售 AI API"的内容，要么夸大可行性，要么默认你去跑一个灰色中转。这篇两样都不做。
这是实话版：今天你能在托管上游之上用 key 级控制搭出什么，账怎么算，以及同样重要的——这个模式给不了你什么。
模式：一个客户，一把 key
Router One 让一个账号通过单一钱包获得通往 40+ 个受支持模型的托管上游，并允许这个账号创建很多把 API key。每把 key 带三个互相独立的控制项：
- maxSpend —— 这把 key 最多能从你钱包里花多少的硬上限
- rateLimit —— 发请求的速度上限
- tokenLimitTpm —— 每分钟 token 上限
这已经足够跑通一个干净的转售闭环：
- 每个客户创建一把 key，消费上限设成对方预付给你的额度。
- 把 key 交给客户（或嵌在你替他们运营的工具的服务端）。
- 在仪表盘上实时看每把 key 的用量——请求数、token、花费。
- 某个客户的上限用完，这把 key 停止工作。你的钱包和其他客户不受任何影响。
- 重新收款，调高上限，循环。
你的成本基线是各模型公开费率的按量付费 token 价位——和模型页上公布的每百万 token 单价完全相同——加上充值时结账页可见的 FX/通道费。你在此之上向客户收取的部分——无论对应的是选型、集成、支持还是可用性兜底——都是你的利润，并且体现在你的发票里，而不是藏在一个不透明的 token 加价里。完整搭建步骤见转售方概览。
为什么消费上限是承重墙
没有 key 级上限的转售是一台负债机器：一个客户失控的 agent 抽干共享余额，把其他所有客户一起拖下水。上限把这种系统性风险降级成单个客户的小麻烦——失控的 key 撞到自己的限额后开始报错，其余一切照常服务。同样的机制也兜住了客户把 key 泄漏出去时的损失。
第二面承重墙是拿得出手的归因。每请求 trace 按 key 记录模型、token、成本和延迟——客户对账单有异议时，你可以用数据回答，而不是空口主张。账本具体记录什么，成本追踪页写得很清楚。
这个模式给不了你什么
对自己和客户都把边界说清楚。Router One 上的 key 级转售不包含：
- 白标或自定义品牌 —— 你客户的请求打到的是 Router One 的 endpoint，不是挂着你名字的 API 表面。
- 子账号或组织体系 —— key 都活在你这一个账号里；没有客户登录、席位管理或角色系统可以分发。
- 批发价或量级折扣 —— 你和其他所有账号一样，按公开的 token 价位采购。
- 面向客户的计费 —— 给客户开票、税务、收款都是你的事，在你自己的工具里完成。
如果你的生意需要这些，你需要的是另一类产品（或者直接谈企业条款）。把 key 级控制包装成白标平台，正是转售方最后许下基础设施兑现不了的承诺的方式。
顺带一提：Router One 另有一个独立的推荐计划（被推荐用量的 5%）。如果你真正想做的是推荐基础设施而不是运营它，这是一个更轻量的选项。
适合谁
key-per-customer 模式适合掌握客户关系、自己做集成工作的运营者：在客户交付物里跑 AI 功能的代理公司、管理少数几个账户的顾问、内置按量 AI 的小工具。它刻意不适合任何向客户承诺"自有平台"的人——而这正是重点。这套能力不大，但每一块都是真的：托管上游、硬上限、每请求用量数据，以及一个你可以诚实地在上面构建利润的公开费率。
到 router.one 创建第一把客户 key；完整能力清单——包括明确的"不提供"清单——见转售方页面。