Jev 省 token 省在輸出歸零與狀態只送一次

Jev 不生成文字，只回傳帶機率的決策 便宜不是因為模型小，而是因為決策任務裡大部分的 token 成本本來就是浪費掉的。四個來源，由大到小。

一、輸出 token 直接歸零

LLM 做一個決策，輸出長這樣：

「這條工單提到登入失敗和重複扣款，使用者語氣急迫，
  因此我判斷應該分類為...」            ← 一段解釋
{"category": "billing", "severity": 3}  ← 才是你要的

解釋那段你不要，但你付錢了。 而且輸出 token 的單價通常是輸入的 4–5 倍，推理模型的 thinking token 也按輸出計費。

Jev 沒有輸出序列，回傳的是機率分布不是 token——輸出免費，因為根本就沒有輸出 token。

二、狀態只送一次，不是送 N 次

多問題的場景裡，這一塊比第一塊還大。

	傳統做法	Jev
依賴關係	先問類別 → 等回來 → 再問嚴重程度	五題一起問
請求數	5 次	1 次
工單內容送幾次	5 次	1 次

因為保證並行且互不干擾，連只在特定分支才有意義的問題都可以一起問（「嚴重程度」只有分類＝故障時才有用），回來後程式碼只取相關的那幾題。白問的那幾題不虧，因為狀態沒有重送。

browser-use 的瀏覽器 agent 是同一件事的極端版：把「做什麼操作」和「對哪個元素做」做成兩個 Choice 一次返回，瀏覽器協議呼叫從 1000 多次降到 100 次。

三、prompt 裡不用教格式

LLM 版的 prompt 得塞「只回傳 JSON」「不要加 markdown 圍欄」「schema 長這樣」外加幾個 few-shot 範例，每次請求都要重送。Jev 的問題是結構化參數不是散文，選項清單本身就是 schema。

四、沒有重試

LLM 吐出壞掉的 JSON → 重試 → 整筆成本再付一次。Jev 結構上不可能吐出型別錯誤，這條成本是零。

總帳與折扣

更便宜的單價（輸入 $0.042 / MTok）× 更少的輸入 × 零輸出 × 零重試。

但兩件事要記著：

• 輸入還是照算。 狀態一樣要 tokenize、一樣付錢，省的是輸出和重複傳送。狀態很大、問題很少的場景，節省幅度會明顯縮水。
• 倍率沒有宣傳的那麼高。 官方講 20–400 倍、成本 1/76；獨立審計是 5–25 倍，延遲也從官方的 70–500ms 變成海外實測的 1.6–3.7 秒。方向對，量級打折。