三渲二按 i2v 的整价收 50 积分，而它的上游调用数是 0

[johnnyzhang-eng]

实测

2026-08-28，同一个生产库上两条动作任务的对照：

task	路线	上游调用次数	冻结	实结
759	i2v	9	50	50
761	三渲二（资产已就绪）	0	50	50

上游调用次数取自 windup_ai_gateway_attempt，按 task_id 计数。

积分流水（user 26）：

10:38:37  冻结 50  (task 761)  余额 80→30
10:39:40  结算     (task 761)  余额 30      ← 一分没退

为什么是 0 次

三渲二在资产已就绪时，这一单不调任何生成接口：模型和骨都是之前那笔 BUILD_CREDITS 买的，出帧跑在用户浏览器里（#714 决定不在应用机起 Chromium）。我们这一侧的边际成本是对象存储的读写，不是按次计费的上游。

机制已经有了，只是没接

billing.capture_for_task(..., actual_amount=...) 支持部分结算，差额自动退回可用余额。四视图那条路已经在用它——按成功方向数按比例结：

actual_amount = frozen_amount * successful_calls // planned_calls

character_action 走三渲二时没有走这个分支，整笔冻结原样结掉。

影响

三渲二相对 i2v 的成本优势（同一资产复用、各朝向天生一致、无按次生成费）在计费上一点都没体现给用户。追加一个动作要另付 AUTORIG_CREDITS，那笔是真实上游成本、该收；但复用已烘动作的出帧任务收 50 是纯虚收。

建议

三渲二路线的 character_action 按实际上游调用数结算，复用已烘动作时 actual_amount 应为 0 或只覆盖存储成本。定价口径定下来之前，至少先让这条路和四视图那条一样走 actual_amount。

[johnnyzhang-eng]

补一笔账，量级比开这条 issue 时说的严重得多。开的时候只对比了单个动作任务（三渲二 0 次上游 vs i2v 9 次，同收 50）；放到八向的真实场景上看是这样：

i2v 路线，一个八向角色的一个动作（候选数默认 3）

步骤	算式	积分
八向立绘 sheet	10 × 4 次上游 × 3 候选	120
八向动作首帧	10 × 8 向 × 3 候选	240
八向动作视频	50 × 8 向	400
		760

八向 sheet 只调 4 次上游（其余靠镜像），这一条本身没问题。

三渲二路线，同一个角色同一个动作

建资产（图生 3D 20 + 绑骨 10，已含 walk）    30 积分
朝向                                        上游 0 次调用
                                            —— 同一网格、同一骨骼、同一采样时刻，
                                               只换相机方位角在浏览器里重渲

760 : 30，差 25 倍。而这个差价现在一分钱都没传给用户。

原因就是本 issue 说的：三渲二的动作任务复用 character_action 的计费口径，按方向收 50。所以走三渲二出八向照样收 400，尽管那 400 对应的上游调用次数是 0。

这不只是"多收了钱"。三渲二这条路线的全部价值就是「动作和朝向越多越划算」，而现行计费恰好把这个价值抹平了 —— 用户从账单上看不出选它有任何好处，于是没有理由选它，于是这条路线做了等于没做。

billing.capture_for_task(..., actual_amount=...) 的机制已经在四视图那条路上用着（按成功方向数按比例结），三渲二这条接上去就能修。

[johnnyzhang-eng]

2026-08-29 复核：未修，且今晚的端到端印证了它。

task 883 走三渲二，12 帧，上游调用次数 0（模型和骨都是之前那笔建资产买的，出帧跑在用户浏览器），仍按 character_action 的整价计费。

同一晚 #901 的方案定稿了（生产方式提到首帧之前）。那条改的是少花不该花的，本条改的是该少收的没少收，两条是同一个根的两半，建议一起排期。