每一個 pricing model 都喺講 value 由邊度嚟。Per-seat pricing 話 value 係 access。Per-message 或 per-token pricing 話 value 係 activity。兩者都易量度，但都會靜靜獎勵錯嘅嘢 — 一個登入咗但冇解決任何事嘅 seat 照樣收費；一個講好多 message 但從未關閉 case 嘅 integration 照樣推高 bill。
Threada 量度一樣更難被玩弄、亦更接近重點嘅嘢：automated resolution。
佢量度啲咩
Automated resolution 係一個 WorkItem 或 runtime outcome，喺冇 human takeover 或 operator 手動回覆之下完成。工作入嚟，system 將佢帶到一個 defendable conclusion，冇人需要插手完成。呢個係我哋喺 billing 同 usage dashboards 報告嘅 unit，亦係 enterprise meter 所計嘅 unit。
定義刻意嚴格。如果 operator 要接手並手動回覆，呢個就唔係 automated resolution — 係 assisted work，唔應該當成 platform 自己關閉咗。Meter 只會喺 platform 真係做完工作時先跳。
點解 outcomes 先係誠實嘅收費基礎
Pricing unit 應該同 customer 對 success 嘅定義對齊。喺 governed operations，success 唔係「有人用咗 tool」或者「model 產生咗好多文字」。Success 係 routine work 做得啱，只有真正 exceptions 先去到人手上。Product 存在嘅原因，就係 automate routine，並 route 真正困難嘅 case 畀人。
按 automated resolution 收費，令我哋嘅 incentive 同呢個目標站喺同一邊：
- 我哋喺工作 關閉 時先得到回報，而唔係工作只係 轉嚟轉去。一個 model 產生十份冇人可以用嘅 drafts，唔值錢；一個經得起 review 嘅 resolution 先係有價值。
- Customer 可以做誠實嘅數。Cost per resolved item 係 operations leader 可以同人手處理同一 item 嘅 fully loaded cost 比較嘅數。喺「我哋收費嘅嘢」同「我哋話幫你節省嘅嘢」之間冇 translation layer。
- 佢抗拒 vanity metrics。你唔可以靠發更多 messages 或加 seats 去谷大 meter。數字上升嘅唯一方法，係更多工作真係被 resolved。
誠實 metering 需要誠實 counting
Meter 有幾誠實，取決於佢點 count。兩個承諾令我哋保持正直。
第一，我哋 count outcomes，而唔係樂觀。 Resolution 會喺 WorkItem 透過 governed path 到達 completed terminal state 時記錄 — receipt 完整保留。如果 proposal 喺 connector 失敗，或者 item 要 operator 救返，唔會被靜靜四捨五入到 resolved column。Lifecycle states 係 explicit，meter 會誠實讀取。
第二，我哋對 transition 坦白。 內部以前喺 platform 成熟期間，usage 曾經由 message caps meter。今日我哋明確講清楚，呢啲 caps 會 map 到 automated-resolution meter，並喺 usage dashboards 報告 resolutions，而唔係將 unit 藏喺 proxy 後面。叫出真正 unit 嘅名 — 並顯示畀你睇 — 係 records-and-receipts posture 嘅一部分，同樣治理成個 product。
free tier 對 model 講咗啲咩
Free tier 每月 capped 喺 1,000 個 automated resolutions 同 100 個 knowledge assets，daily document caps 由 monthly limit 推算。呢個 cap 嘅形狀本身已經係 statement：free tier 對 resolutions generous，因為 resolutions 係值得畀你 prove out 嘅嘢。我哋寧願你發現 platform 係咪真係關閉到你嘅工作，而唔係只係坐得低好多 seats。
除咗 volume，plans 應該被理解成 capability bundles — governance depth、approval 同 policy controls、automation scope、connector classes、compliance posture — 而唔只係更大嘅數字。Meter 話你知完成咗幾多工作。Plan 話你知做呢啲工作時有幾多 control 同 reach。
Metering outcomes 比 metering messages 難。佢要求 platform 定義、追蹤、並承擔「resolved」嘅意思。我哋認為呢個難度正正係重點。一個可以喺 line-item level 同你討論嘅 meter，先係尊重 buyer 嘅 meter — 而 automated resolution 係 operations team 真係可以 defend 嘅數。