Optio 积分如何运作 — Jev API 的成本模型

公式

每个请求花费 ceil(输入 token / 1,000) 积分，最低 1 积分。输出 token 一律免费 — 一次决策只有几十个 token，而且对它们不收费。如果请求失败（上游错误、超时、提供方过载），分文不扣：积分在模型运行前预扣，失败时预扣退回。

调用前，网关按约每 token 4 字符从负载估算并预扣。调用后按模型 usage 报告中的实际输入 token 数结算，所以账本记录的是真实值而非估算。三个数字 — 预扣、实际、扣费 — 可以分别从 usage.input_tokens、usage.credits 和 ledger 看到。

按真实规模的计算示例

• 对一行工单做 yes/no 检查，约 150–300 输入 token → 1 积分。
• 客服分诊：工单加三个问题（yes/no 紧急度、路由 choice、挫折 score），约 400–500 token → 1 积分。
• 对一条带 JSON 载荷的工具调用做 Agent 护栏，state 里附一段政策，约 1,600 token → 2 积分。
• 简历筛选，state 带完整 CV，约 8,000 token → 8 积分。

这些数字里藏着一条批处理规则：因为最低消费按请求计而不按问题计，只要总量不超 1,000 token，同一状态上最多 8 个问题也只花 1 积分。把同样的工作拆成单问题调用，成本会贵出好几倍。

积分包

• Starter — $10 → 100,000 积分。每次最低消费决策 $0.0001。
• Pro — $100 → 1,000,000 积分。单价相同；优势是更高的速率上限（600 对 120 req/min、10 对 3 并发）和更少的充值次数。
• Team — $1,000 → 11,000,000 积分。含 10% 加赠和协作：受邀成员共享余额。
• 免费 — 每个新工作区自带 5 积分，且 playground 在浏览器里免费（从不消耗积分）。

积分永不过期，也不会在工作区之间移动。闲置一个月的成本是 $0 — 没有需要掐着使用的订阅。

各计划的速率上限

并发与每分钟请求数按工作区内最优计划生效：

• Free：20 req/min，1 个并发请求。
• Starter：120 req/min，3 并发。
• Pro：600 req/min，10 并发。
• Team：2,000 req/min，30 并发。
• Enterprise：6,000 req/min，100 并发 — 面议。

任一限流被触发都会返回 429，带 Retry-After 头，外加 X-RateLimit-Remaining 与 X-RateLimit-Reset — 这是让你退避重试的安全信号。

按流量做预算

计费是确定性的 — 只看 token 数 — 所以账单可预测：每日决策数 × 每次决策的平均积分。如果一半决策踩在 1 积分最低消费上且每天跑 50,000 次，那就是约 50,000 积分，按 Starter 价格约 $5/天。装载 Team 包可以把有效单价降低约三分之一（$1,000 得 1100 万积分 对 $100 得 100 万积分）。

两个省钱的使用习惯

第一，合并问题。如果一个请求在同一 state 上带一个 yes/no、一个 choice 和一个 score（客服分诊合成一个请求），它就按 1 积分最低消费只计一次费。把同样三个拆成三个请求就会计 3 积分。最多 8 个问题可以同行，所以把 state 组装一次，把你可能要分支的问题一次问完。

第二，裁剪 state，而不是问题。计费计入整个负载的输入 token，所以如果你为了提一行问题而把一份 20,000 字符的文档整个塞进 state，账单就会被它主导 — ceil(20,800/1,000) = 21 积分而不是 1。如果只有一段有用，发送前自己先抽出那一段；模型会按你的吩咐去读，但 token 数是你说了算。

什么时候 2 积分胜过 1 积分

• 一份 2,400 token 的政策文档，抓取一次、跨决策复用 — 如果你对它在一个请求里问三个问题，就是一次性付 3 积分，而不是在三次单问题调用里各重发一次（同样的工作要 9 积分）。
• 一份约 8,000 token 的简历，针对 8 条硬性要求只筛一次：单请求带 8 个问题共 8 积分；而如果 state 必须随每个请求单独携带，就是 8 次调用、每次 8 积分——
• 其实上面这个对比有其重复之处：state 只在需要它的请求里随行。真正的杠杆是 1 积分最低消费：1,000 token 以内加问题是免费的；超出之后，state 每一 KB 就是另加 0.25 积分。

账本上会出现什么

每个已结算的请求都会在仪表板写入一行 ledger：reserved（估算）、charged（实际输入 token / 1000，最低 1）、request_id，以及是哪个 API key 花的。失败请求写入零扣费的退款行，所以月底对账只是按 request_id 过滤。如果某笔扣费看起来不对，支持团队可以凭日志里的 request_id 追溯 — 把它抄给他们。