面向 agent Skills 的按记录计费，而非订阅档位

一句话概括：这是定价支柱：UnifAPI 为返回的记录计费，让 agent 操作者无需绑定订阅档位就能估算工作流成本。

大多数 API 市场是这样定价的：挑一个档位（Basic / Pro / Ultra），付一笔固定月费，包含 N 次请求，撞上一个硬上限，然后要么升级、要么被切断。RapidAPI 是最为人熟知的例子，也是最让人头疼的那个。

我们曾考虑照做。分档订阅在财务上的理由是实打实的——它带来可预测的 MRR，它是 SaaS 的主流模式，融资时也更好讲。但我们还是把它扔掉了。

上限的问题

分档套餐恰恰惩罚了那个本该庆祝的时刻：你的产品起飞之时。流量飙升的那一天，正是你的供应商把你切断的那一天——或者按超量价向你收取 5 倍的单次调用费。这种不对称扼杀实验、饿死增长。

上限还逼出一种规划上的虚构。你并不知道这个月需要多少条记录，却不得不假装知道、去挑一个档位。结果是：你要么为余量多付钱，要么少付钱然后被限速。

我们交付的是什么

首充赠送——预付充值，每个工作空间的首次充值可一次性获赠 2,000 积分。实时 APIs 解锁，MCP 服务器包含在内。你可以在注册前浏览 Skills；当 agent 需要工具调用时，OAuth 才会发生。

按量付费——随时充值余额。积分每个 $0.001，逐操作的最低消耗从 OpenAPI 计费契约中公布。没有月费，没有硬上限。这个月拉取一条标准记录，还是一百万条——账单都对得上。

企业版——面向需要 SLA、采购友好合同，或按记录费率享受批量折扣的团队。由销售主导，基于合同。

为什么按记录、而非按调用

调用是个糟糕的单位。一次对创作者主页端点的调用返回一条记录；一次对社交搜索端点的调用可能返回五十条帖子。按调用计费意味着一个小请求和一个大请求收费相同——这逼得供应商按最坏情况定价，也就意味着小请求在多付钱。

记录才是 agent 实际消耗的东西。模型需要读取并推理的，是那一行数据，而非 HTTP 封装。按记录计费让账单与你实际在用的东西对齐，并让这个单位在你发起任何一次调用之前就易于估算。

这对你意味着什么

按用量编预算，而非按档位。agent 基础设施最难的部分，就是搞清楚一条工作流会消耗多少。有了按记录计费，你可以先跑这个 Skill、检查记录数，再决定是否深入分析。

模型账单仍然留在你已经在用的 agent 产品里。UnifAPI 只为公开数据层计费，这让工作流在变成生产代码之前始终易于推演。

接下来读什么

定价 - 积分与充值的实时定价页面。

UnifAPI 对比 RapidAPI - 把这套定价论点应用到市场对比上。

搭一个 Reddit 调研 agent - 在一条具体工作流上展示记录计费。