Jev 應用研究：從 Agent Context 到即時控制的社群案例

Jev 在 2026 年 9 月 15 日開放 early access。不到一週，社群已經把它放進 browser agent、Claude Code、Codex、generative UI、code review、codebase search、桌面操作、遊戲、無人機、資料篩選與交易迴圈。

這批專案反覆使用同一種軟體單位：decision point。程式先整理 state、列出候選行動與安全邊界，Jev 回傳 Choice、Score 或 Noul，程式再根據機率、threshold 與其他規則執行後續動作。

這個模式涵蓋的範圍已經超過 Agent 成本最佳化。它可以是模型路由器、context filter、graph navigator、UI composer，也可以每秒參與數次遊戲或控制系統的戰術判斷。研究焦點因此落在 Jev 被放在哪一層、它看見什麼 state、可選哪些 action，以及錯誤判斷會由哪一層攔住。

以下整理截至 2026 年 9 月 24 日可直接核對的官方資料與社群專案。這些專案多半只存在幾天，成熟度差異很大；文中的速度與成本數字會標明是官方資料、專案作者實測或歷史模擬。

Jev 的基本條件

TypeSafe 把 Jev 稱為第一個 System One Model。目前穩定版本仍是 jev-1.13.0，jev-latest 指向同一版本。官方 API 讓開發者一次提供一份 state 與多個問題，問題會針對同一份 state 平行評估。

截至 9 月 22 日，TypeSafe 公開價格仍是 US$0.042 / 1M input tokens，output tokens 免費；request context 是 64k tokens，state 加最長單一 question 另受 32k 限制。輸入目前只有文字，圖片、聲音與影片需要先轉成文字或結構化 state。英文是主要訓練語言，官方建議 CJK 工作負載自行評估。

TypeSafe 發表文公布的端到端時間是 70–500 ms。這是廠商數據，而且官方特別說明公開 eval 多半從服務所在的美國西岸測試。台灣端 latency 需要另外量測。

官方宣稱的「0% hallucination」指 schema matching：輸出一定落在預先定義的型別與答案空間。語意判斷仍可能出錯。TypeSafe 也公開列出長 state、複雜否定、多層 indirect reasoning、數字與日期比較等弱點。

參考：TypeSafe Models、Introducing System One Models & Jev。

社群案例地圖

下面 23 個案例來自這波社群實驗。表格中的「證據」只描述目前 repo 公開了什麼，不代表產品成熟度排名。

這些專案可以分成七種應用模式。

把 Jev 變成一般開發工具

typesafe-mcp、jev-mcp 與 SemDecide 做的是基礎接入。

typesafe-mcp 把一個 evaluate 介面暴露給 Claude Code、Claude Desktop、Codex、Pi 等 MCP client；同一次 request 可以放多個 Choice、Score、Noul。jev-mcp 再往上包成 verify、screen、find、rerank、classify、decide、extract、review、gate 等較具語意的工具。SemDecide 則把同一能力做成 CLI，讓 shell script、crawler、CI/CD 與資料 pipeline 可以用 exit code 或 JSON 結果分支。

這三個專案的意義在 API 位置。Jev 可以像 grep、jq 或 policy engine 一樣被一般程式呼叫。Agent 呼叫 MCP 時主要得到新的判斷工具；shell、proxy 或 workflow engine 在 Agent 啟動前呼叫 Jev，才會直接影響主 Agent 的呼叫量。

Model routing、動態 effort 與 Context 經濟

跟 coding agent 成本最直接相關的案例，集中在三個位置：呼叫前的 model / effort routing、context 進入前的篩選，以及 session 累積後的 compaction。

動態 reasoning effort：把「想多深」獨立成 routing decision

目前至少有四個公開實作把 Jev 用來動態調整 coding agent 的 reasoning effort。差異主要落在兩件事：多久重新判斷一次，以及 model 與 effort 是否綁在同一個決策裡。

Claude Code：request-level effort 可以直接改

satviksinha/jev-model-router 使用 Claude Code function hooks。流程在 turn.start 讓 Jev 同時回答 model tier 與 thinking effort，再在 turn.step 把結果寫進當次 request：

next({
  ...e,
  model: selectedModel,
  effort: selectedEffort,
});

這裡改的是 request-level 參數，所以同一個 Claude Code session 的不同 turn 可以使用不同 effort。repo 還把 model stickiness 與 effort 分開處理：prompt cache 依 model 區分，model switch 可能造成下一輪 cold cache；sticky policy 可以阻止低信心的 model switch，Jev 選出的 effort 仍照常套用。作者目前的設計因此把 effort 視為較適合高頻變動的控制維度。

repo 的限制也很具體。Claude Code subagent loop 目前沒有 turn.start，因此 Agent tool 產生的 subagent 不會經過這個 router；主 session 收到 subagent completion notification 後產生的新 turn 才會再次 routing。若目標是 coordinator 動態 high / xhigh，這個限制影響較小；若要連 worker / subagent 一起動態調 effort，需要另一層 integration。

作者在 2026-09-20 用 shipped criteria 跑了一組 prompt spread，單次 Jev routing latency 約 402–839 ms。這是 routing probe，不是 task-quality benchmark。

Codex：per-call routing 與 route lease

0xNatoshi/jev-codex-router 的粒度更細。它會在每個 model call 判斷 route，包含 tool call 之後的 continuation。Jev 一次回答四個獨立 Choice：

1. 下一個 call 是否落入 mandatory high-end policy；
2. 最低足夠的 capability tier；
3. 最低足夠的 thinking depth；
4. route lease：one_call、tool_chain 或 user_turn。

route lease 決定同一個 routing decision 可以維持多久。乾淨的同一工具 continuation 可以沿用 tool_chain；一個 user turn 內的後續 model call 可以沿用 user_turn。新的 user turn、error、compaction、tool chain 改變或 lease TTL 到期都會觸發重新判斷。

這個設計把 routing frequency 變成 Jev 自己要回答的問題。對 coordinator 特別有用：執行同一個既定計畫時可以維持一段時間，進入 replan、architecture decision 或 risk review 時再重新判斷。Jev 看到的是 bounded decision dossier，完整 canonical conversation 仍送給實際執行模型。

作者公布的舊版 7 日歷史重播包含 237 個真實 Codex turns、684M input tokens，其中 98.3% 是 cached reads。把原始 token usage 固定後重新定價，全 Astra baseline 是 US$871，當時 policy 是 US$349，差距 59.9%。這是歷史成本模擬；任務沒有用不同 route 重跑，因此 task quality、counterfactual token volume 與實際 quota savings 仍需要 live measurement。

Codex 簡化版：continuous score 直接映射 effort

tiandee/codex-jev-router 架一個 local Responses API proxy，每個 fresh turn 先取得 Jev routing result，再轉送到 Codex。

它的 effort policy 很容易檢查：

reasoning_required < 0.30  → low
reasoning_required < 0.60  → medium
reasoning_required < 0.85  → high
otherwise                  → max

這種作法適合作為實驗 baseline，因為 policy 只有一個 continuous signal 和三個 thresholds。研究時可以直接觀察 threshold 移動後，high / max 使用比例、rework rate 與完成品質怎麼變化。

Codex cache-aware 版本：thread pin 與 per-turn 可切換

gholtzap/jev-codex-model-and-effort-router 預設 routing_mode = thread。Jev 在 thread 第一個 task 選出 model 與 effort，後續 turn 維持同一組設定，讓該 thread 持續使用同一個 model cache。

需要更細粒度時可以切成：

jev-codex config set routing_mode turn

這時每個 turn 都重新 routing。它也能把 live Codex allowance 送給 Jev；quota 壓力高時，policy 會傾向滿足 capability floor 的較低強度 route。

這個 repo 把一個常被忽略的問題變成顯式設定：routing 的頻率本身會影響成本。模型切換、Jev latency、cache reuse 與 task phase 都需要一起算。

動態 effort 的研究問題

這四個實作已經足以形成一個獨立研究方向。

第一，effort 可以和 model tier 解耦。若 coordinator 已固定使用同一模型，Jev 只需要回答「這一輪需要 high 還是 xhigh」。這種 effort-only router 保留單一 model 的 cache locality，也減少 model capability 差異造成的 confound。satviksinha 的實作已經刻意讓 sticky policy 只限制 model switch，effort 每 turn 仍可更新。

第二，重判粒度需要符合工作 phase。per-call 最敏感，也增加 Jev calls 與 route jitter；thread pin 最穩定，也可能讓後半段工作沿用已不合適的 effort。0xNatoshi 的 route lease 提供中間層：one_call、tool_chain、user_turn。這種 phase-scoped routing 比固定「每 turn 都重判」更值得在 coordinator 上測試。

第三，動態 effort 的主要評估單位應是 escalation quality。若只在 high / xhigh 之間切換，可記錄：

• xhigh selection rate；
• high → xhigh 的 precision / recall；
• xhigh turn 的實際 rework reduction；
• Jev routing latency；
• reasoning token / quota 差異；
• task completion rate；
• 同一類任務在 high 與 xhigh 的 counterfactual replay。

第四，subagent coverage 要單獨處理。Claude Code function hook 目前只完整涵蓋主 session turn；多 Agent 系統若希望每個 worker 都有動態 effort，需要在 worker harness、proxy 或 dispatch layer 另做 routing。

對固定強模型 coordinator，一個值得先測的最小 policy 可以只有兩個 action：

ordinary execution / status / local follow-through
→ high

global judgment / conflict resolution /
replanning / architecture / independent audit
→ xhigh

Jev 只負責對當前 coordinator state 做這個 bounded choice。初期採 shadow mode，把 Jev 選擇與現有固定 effort 並排記錄，再用 rework、人工升級與任務成功率校準 threshold。這個實驗比同時改 model + effort 更容易歸因。

Winnow：工具輸出進 context 前先過濾

Winnow 攔截大型 Read、Bash、Grep 結果，切成 block 後詢問 Jev：「這段對目前任務是否需要？」低於 threshold 的內容會換成短 stub、摘要與 recall key，之後仍可取回。

作者以自己的 Claude Code transcripts 建立 300 個案例、1,515 個 blocks。公開 writeup 報告 Jev 的 expected calibration error 為 0.14，字詞 baseline 為 0.31；每 case median latency 86 ms，300 cases 的 Jev 成本 US$0.036。

較保守的問題措辭與 0.1 threshold 在作者的 sample 中可以隱藏約 4.6% 的大型工具文字，沒有出現 model-produced hand labels 判為必要的 block。後續人工稽核只有 20 個 blocks，而且與原標記的一致率很低；live session 只檢查了 6 個 genuine stubs。這份資料的價值是展示 calibration 方法，樣本規模仍很小。

fast-jev-compaction：把舊工具紀錄當成 Context GC

fast-jev-compaction 接管 Claude Code 的 /compact 與 auto-compaction。它保留文字訊息的原文，讓 Jev 對舊的 tool call 與 tool result 分別判斷是否還需要。

預設策略有三種結果：

keep result
→ tool call + result 完整保留

keep call
→ tool call 保留，result 只留開頭與截短註記

drop
→ tool call + result 刪除

最新幾則訊息會固定保留。預設 state ceiling 約 25k estimated tokens；questions 太多時會分批 request，同一份 state 也會跟著重送。Jev 失敗或壓縮幅度不足時，plugin 退回 Claude Code 內建 summary。

這個做法把 context compaction 改成 retention policy。保留項目維持 verbatim，可避免重新摘要時改寫檔案路徑、錯誤訊息或操作限制。代價是刪除判斷可能讓 Agent 之後重新讀取工具結果，而且 README 目前沒有提供 end-to-end token savings benchmark。

Winnow 與 fast-jev-compaction 剛好位在 context lifecycle 的兩端：前者控制資料進場，後者清理已累積的工具紀錄。兩者都值得用 session-level telemetry 評估。

Code review 與完成證據

Jev Review 把 focused diff 送給 Jev，取得 correctness、complexity、tests、security 等結構化訊號。coding agent 再根據這些訊號決定是否修改或升級 review。

Canny 的架構更值得注意。它用 append-only ledger、hooks 與實際檢查結果建立 completion evidence；deterministic gate 掌握阻擋權，Jev 用來判斷完成聲明與規則風險。即使沒有 TypeSafe API key，deterministic gate 仍可運作。

這種分工提供了一個適合高風險工作流的模式：

tests / typecheck / tool evidence
              ↓
       deterministic ledger
              ↓
           Jev judge
              ↓
      policy / escalation

模型提供語意訊號，程式掌握硬性證據與 side effect。這個安排也適合 CI gate、部署授權與多 Agent handoff。

搜尋、圖導航與 Generative UI

Blink 把 codebase search 做成 walker allocation。Jev 對目前目錄下的檔名與資料夾名評分，高機率路徑取得更多 walkers；walkers 持續往下，最後以到達各檔案的比例排序結果。這種搜尋直接從檔案樹開始探索，成本隨探索深度與候選節點增加。

neo4jev 把同一想法放進 Neo4j。每個 node 的 outgoing relationships 都變成 Choice options，同一 request 再加一個 Noul 判斷「目標到了嗎？」。回傳機率可以驅動 beam search，讓 semantic judgment 直接參與 graph traversal。

Vercel Labs 的 json-render 則把 Jev 用在 generative UI。實驗介面讓 Jev 從準備好的 fields、data、actions 與 component catalog 中選擇組合方式。這部分目前仍標示 experimental，而且需要 source build；它展示的是另一種 bounded generation：UI 的合法元素由程式先限定，模型負責組合。

三個案例的共同點是 dynamic candidate set。Jev 每一步看到當下可選的節點、檔案或 UI 元件，再輸出機率。這使 typed decision 可以處理比固定分類器更動態的搜尋空間。

Browser 與 Desktop：先把畫面變成結構化 state

jev-ultrafast 由 Browser Use 團隊開發。預設 loop 不讀 screenshot，程式從 DOM / ARIA control 建立動態 action space，Jev 在一次 request 中選 operation 與 target。需要 TYPE_TEXT 時，再由小型文字模型產生實際字串。

作者公開的 Google Flights matched comparison 只有三組交替 runs。兩個版本都通過 3/3，median task time 從 9.450 秒降到 7.092 秒，下降 25%；median browser protocol calls 從 1,092 降到 101。作者也明確寫出三組樣本不足以支持廣泛的 reliability claim。

agent-desktop 走相似方向，把 OS accessibility tree 轉成可操作的結構。Jev skill 每回合讀取 screen state，選 operation 與 target，執行後再觀察。完整 accessibility tree 可以留在工具層，不必塞回呼叫它的主 Agent context。

agent-desktop README 報告 progressive skeleton traversal 在 dense app 上可減少 78–96% 的 tree tokens；這項數字量測的是 observation representation。Jev 本身帶來的節省比例需要另外量測。

這兩個案例顯示，computer use 的成本很大一部分取決於 state representation。DOM、ARIA 與 accessibility tree 已經提供結構時，可以先壓成候選 control，再讓低延遲模型做 action selection。

即時控制：Jev 放在戰術頻率

遊戲與 robotics 的案例讓 Jev 的 latency 特性更清楚。

typesafe-mario 直接讀 emulator RAM，把位置、速度與遊戲狀態整理成 JSON，再讓 Jev 選 controller macro、判斷 jump usefulness 與 danger score。畫面辨識與精確 timing 留在程式層。

jev-drone 的頻率分層更完整：

500 Hz   geometric controller
 50 Hz   guidance + safety
 15 Hz   camera → symbolic scene
~2.5 Hz  Jev tactical judgment

Jev 讀取由 depth / segmentation 整理出的 symbolic scene，選 hold、gap left/right、climb、brake、reacquire 等 maneuver。低層 flight controller 與 safety reflex 持續由一般程式掌握。典型約 65 秒的 flight 會產生約 110 次 Jev calls；repo 也記錄了 tunnel 實驗尚未穩定通過的限制。

OneVOneJev 則把 decision loop 拉到大約每秒 9 次，讓 Jev 持續決定 FPS 中的移動、瞄準與開火。

這類系統通常採 multi-rate architecture。物理穩定、安全 constraint 與精確時間控制放在高速 deterministic loop；Jev 參與較慢的 tactical layer。這比單純追求「模型每秒能呼叫幾次」更能說明低 latency judgment model 的軟體位置。

資料與領域判斷

Jev Curate 把 Choice、Score、Noul 套進 JSONL / Parquet streaming pipeline，對訓練資料做品質、相關度與風險篩選。README 宣稱 1,500+ rows/sec；repo 目前沒有提供足以獨立驗證這個 throughput 數字的 benchmark，因此本文只把它記為專案宣稱。

killmyidea 是更單純的 structured scoring demo。一次 request 平行問 10 個問題，其中 8 個是 0–4 Score，另外判斷 category 與 idea 是否足夠清楚；程式再依固定 weights 與 thresholds 算出 KILL、FIX、SHIP。repo 提供 synthetic benchmark harness，這些結果反映自訂 rubric 的一致性，不構成市場驗證或創業成功預測。

jev-trader 把 Jev 放進更高頻的金融實驗。它每個 Monad block 約 300 ms 讀一次 Kuru MON-USDC order book，讓模型回答 buy / sell，再建立 post-only limit order。沒有 private key 時會 dry-run，預設 model 也是 mock；配置 wallet 與 Jev 後可以送出真實訂單。這個案例證明 decision latency 可以進入 block-level loop，repo 沒有提供足以支持策略獲利能力的風險調整 benchmark。

截圖中的 Prism 被描述成用 Jev 判斷 toxic flow、市場壓力與 mean reversion。9 月 22 日重新查看目前 main 時，README 已改成 rule-based liquidity agent，decision overlay 使用本地 agent harness，repo 頁面也找不到 Jev。這可能是快速迭代造成的版本差異，因此本文不把截圖中的 Prism 描述當成目前實作狀態。

從案例看出的共通架構

這批案例可以用一個簡單流程概括：

raw world / tool output / user task
               ↓
      deterministic preprocessing
               ↓
      compact structured state
               ↓
              Jev
     Choice / Score / Noul
               ↓
   threshold / policy / evidence
               ↓
 action / branch / escalation

最穩定的設計特徵有幾個。

第一，程式先決定 action space。Browser 的 DOM controls、Neo4j 的 outgoing edges、Mario 的 controller macros、Drone 的 maneuvers 都是程式建立的合法候選。模型負責語意選擇，無效 action 從資料結構上就很難出現。

第二，state engineering 直接決定成本與品質。Winnow、fast-jev-compaction、agent-desktop、Mario、Drone 都花大量設計在「模型到底看什麼」。把原始世界壓成小而相關的 state，往往比換 prompt 更重要。

第三，機率要交給 downstream policy 使用。Threshold 的效果高度依賴工作負載。Winnow 的實驗甚至顯示 question wording 會明顯改變 probability distribution。部署前需要自己的 calibration data。

第四，高風險 action 需要獨立的 deterministic boundary。Canny 把 completion evidence 寫進 ledger；Drone 的 guidance/safety loop 始終掌握控制；金融系統也需要 position cap、risk gate、dry-run 與交易層的硬限制。Jev 的輸出在這些架構裡是訊號。

第五，Jev 的主要優勢會在高頻 decision point 累積。一次分類便宜幾乎沒有意義；每個 Agent turn、每批 tool results、每個 browser step、每個 graph hop 或每秒數次的 tactical decision 都需要語意判斷時，低 latency 與低 input price 才開始改變整體架構。

對多 Agent 工作流的直接應用

以 Straw Boss 這類 coordinator / worker 系統來看，現階段最值得實測的方向有五個。

1. Effort-only coordinator router：固定 coordinator model，只讓 Jev 在 high / xhigh 之間選擇；先用 shadow mode 量測 xhigh selection quality，再開啟自動套用。
2. Pre-turn worker routing：使用者任務先經 Jev，輸出 worker 與 model tier；記錄 wrong downgrade rate，再決定是否自動派工。
3. Context ingress filter：搜尋、log、handoff 與大型 tool result 先做 relevance 判斷，只讓高價值資料進入 worker context。
4. Context GC：長 session 中針對已完成工作的 tool calls/results 做 keep、truncate、drop，和 summary-based compaction 做 A/B test。
5. Completion gate：tests、typecheck、static analysis 先形成 evidence，Jev 判斷是否需要強 reviewer 或人工介入。

評估時應同時記錄 total model cost、Jev 自身 input tokens、p50 / p95 latency、fallback rate、context recall、重新執行工具的次數、wrong downgrade、rework rate 與最終 task success。只看 Jev API 花費會低估錯誤 routing、context 誤刪與 fallback 造成的成本。

目前的證據界線

Jev 生態目前仍處於快速原型期。上面幾個有量測資料的專案也各有明顯限制：

• jev-ultrafast 的 matched comparison 只有三組 runs，任務與瀏覽器環境都很集中。
• Winnow 的 calibration 來自單一開發者工作負載，主要 hand labels 由模型產生，人工 audit 樣本很小。
• jev-codex-router 的 59.9% 是歷史 token usage 重新定價，沒有同步驗證實際 task quality 與跨模型 cache 影響。
• 多數其餘 repo 提供的是可執行 demo、架構與作者宣稱，還沒有長期 production telemetry。

因此，現在最有價值的研究材料是架構模式與可測量假說。這些專案已經清楚展示 Jev 可以插進哪些 decision points；每一種用法能省多少成本、維持多少品質，仍需要在自己的 workload 上量測。

參考資料

官方資料

• TypeSafe AI，Models
• TypeSafe AI，〈Introducing System One Models & Jev〉
• TypeSafe AI，Documentation

社群案例

• itsmostafa/typesafe-mcp
• jkudish/jev-mcp
• sharziki/semdecide
• 0xNatoshi/jev-codex-router
• satviksinha/jev-model-router
• tiandee/codex-jev-router
• gholtzap/jev-codex-model-and-effort-router
• GhalebDweikat/winnow
• tamaratran/fast-jev-compaction
• devagrawal09/jev-review
• qkal/Canny
• ellipsis-dev/blink
• jexp/neo4jev
• vercel-labs/json-render
• browser-use/jev-ultrafast
• lahfir/agent-desktop
• fhshaik/typesafe-mario
• RomanSlack/jev-drone
• emrickgarrett/OneVOneJev
• AkashPriyadarshii/jev-curate
• monteduro/killmyidea
• jarrodwatts/jev-trader
• irfndi/prism-liquidity-agent