計量與結算

給你計費的那個數字，是上游廠商自己回報的用量。下面所有機制的存在，都是為了保證進入結算的確實是那個數字。

三個資料來源

估算是啟發式的——按字元類別加權，不是廠商的 tokenizer。它只用來抓數量級上的荒謬值，所以容忍度給得很寬。

交叉核對

回報值與估算值在輸入側與輸出側分別比對。偏差超過 25% 會記到賣方的信譽上，但不改金額。

快取讀取算在輸入側，所以一次高快取命中的工作階段不會被誤判成偏差。

硬性封頂

這些是會改金額的：

• 輸出依授權預算封頂。 每次派工都帶一個經簽章的預算，賣方不可能按超過授權的輸出量計費。
• prompt 依閘道自身估算的三倍封頂（或估算值 + 1,000 token，取較大者）。超出後四類計數按比例整體縮小，各類 token 之間的比例維持不變。

一個小請求被回報成九百萬 token，最終按封頂值計費，並在賣方紀錄上留下一條風控事件。

結算

每個請求一個資料庫交易：

1. 擷取凍結

   擷取預先凍結的金額，差額退回你的可用餘額。

2. 依實有資金封頂

   扣款永遠不會超過「凍結 + 可用」，餘額不可能變成負數。

3. 劃帳

   從你這邊扣款；賣方的待結算加上成交價減 8% 手續費；手續費進平台帳戶。

4. 記帳

   三條複式記帳分錄，合計必須為零。

5. 結案

   token 數、金額、手續費與延遲寫入該請求；一條帶唯一鍵的結算紀錄讓重複扣款成為不可能。

交易失敗會依退避策略重試——而且絕不會盲目重跑，因為那個唯一鍵讓重複執行變成空操作，而不是第二次扣款。

自己對帳

買賣雙方都保存本機明細，也都能拿去和伺服器比對。token 數應當一致。若不一致，以伺服器的數字為準——本機明細是給你自己稽核用的，不參與計費。

用戶端與網站上的 記錄 是同一批資料。