Jev 是什麼：把大型模型的瀏覽器操作改成毫秒級的結構化決策 | Allen 知識庫 | Allen 知識庫
版本閱讀提醒（2026-10-15）： 本文已補Jev 1.14圖片、Box與長上下文的官方文件查核，詳見文末更新。先前1.13及DOM-only示例是各自版本和程式路徑，不代表新版所有能力；Box仍是實驗功能，而且不存在目標也會回框。
Agent Architecture / System One / Browser Automation
Jev 不是更小的 ChatGPT，而是給程式用的高速判斷層
大型 LLM 擅長理解模糊目標與規劃；Jev 專門回答「現在該選哪一個、分數多少、這件事是否成立」。把每一步瀏覽器操作收斂成封閉選項後，可降低自由文字生成、解析與多輪工具呼叫的成本。
一句話解釋
Jev 是 TypeSafe 的第一個 System One model： 傳入目前狀態與型別明確的問題，它直接回傳結構化選擇、機率分布與 confidence，而不是先生成一段人類文字再讓程式解析。
能力 輸入 輸出 適合問題 Choice 候選選項 choice、每項機率、confidence 下一個動作、分類、路由 Score 有序評分級距 score、分布、confidence 風險、相關性、優先級 Noul 是／否命題 0–1 機率 條件檢查、門檻判斷
Browser Use demo 怎麼運作
瀏覽器把目前可見的 HTML／ARIA 控制項整理成編號元素表，例如按鈕、出發地、目的地與日期。
一次 TypeSafe request 同時問「要執行哪個 operation」及各 operation 對應的 target；只有被選中的 target 會執行。
操作集合被限制為 CLICK、TYPE_TEXT、SELECT、捲動、等待、完成與阻塞。
只有選到 TYPE_TEXT 時，才由小型文字模型 Mercury 2.5 產生 Zurich／London 等字串。
執行器重新檢查 DOM、新鮮度、遮擋與幾何位置；最後另做結果驗證。
關鍵： 這是一個 hybrid agent。Jev 負責大量封閉式操作決策，小型 LLM 只負責無法由候選集合直接表達的文字；它不是完全不用 LLM，也不是讓 Jev 自己自由生成整段瀏覽器腳本。
7.1 秒數字到底代表什麼
閱讀資訊
閱讀時間 39 分鐘
段落層級 62
瀏覽 77
日期 2026年9月17日 Google Flights Zürich → London 任務為 7.073 秒，包含模型請求、文字生成、瀏覽器操作、stale decision 與頁面等待。
不包含
初始瀏覽器／頁面設定與完成後的獨立驗證，不在計時範圍。
呼叫量
17 次 Jev request、10 次互動加 1 次 WAIT、2 次文字 helper；Jev 中位延遲 178 ms。
對照結果
同一份 agent 原版與最佳化版各 3 次：中位數 9.450 → 7.092 秒，改善 25%；雙尾 sign test p=0.25。
因此 demo 證明「結構化 DOM＋窄決策模型」可以非常快，但沒有證明一般網站、一般任務都快 20–200 倍 。repo 自己也明確寫出：三組配對太少，不是廣泛 agent benchmark。
20–200× faster、40–400× cheaper 怎麼看 這些是 TypeSafe 對 decision workload 的供應商主張，應理解成「封閉式判斷不必每次都叫生成式大模型」的架構潛力，而不是這個 Google Flights repo 已獨立證明的倍率。官方目前列 Jev 1.13 為每 100 萬 input tokens US$0.042，output tokens 免費；以效能報告的 90,558 input tokens 試算，Jev 約 US$0.003803，加上兩次文字 helper 的 US$0.00006272，合計約 US$0.003866。這是依公開單價重算，不是該次任務的帳單，且未含瀏覽器、基礎設施與工程成本。
Jev 生態開始長出哪些 Agent fast paths 另一則 Threads 整理了幾個 2026 年 9 月剛出現的社群 PoC。共同模式是：把高頻、封閉、可校準的判斷放到 Jev，只有開放式生成與複雜推理才升級到 LLM。
Repo／用途 已確認的做法 證據邊界 typesafe-mcp 以 MCP evaluate tool 將 Choice、Score、Noul 提供給 Claude Code、Claude Desktop、Codex；可在同一 state 上批次問多題。 證明整合介面存在，不代表 agent 會自動正確選擇何時呼叫。 jev-mcp 提供 claim verification、進 context 前 screening、semantic candidate ranking；回傳機率分布與 confidence。 Repo 稱約 150–500 ms、fraction of a cent，仍是作者／供應商環境，不是跨區 SLA。 jev-codex-router 逐 turn 判斷模型 tier、reasoning effort 與 speed mode。 237 個真實 Codex turns 的七日 replay 估算：全用 frontier US$871、route 後 US$349，約省 59.9%；這是單一操作者與 list-price-equivalent backtest。 Winnow 把大型 Read／Bash／Grep 結果切塊，先判斷與當前任務是否相關；低相關內容以摘要＋可 recall key 取代，原文不刪除。 應先用 shadow mode 與自己的 transcript replay 校準，追蹤 hidden content 的 regret rate。 jev-review 先篩 correctness、security、reliability、compatibility、test coverage，再路由進一步 review。 是 early-stage workflow，不等於已建立 precision／recall 或可取代人工資安審查。
「成本降低 60%」怎麼讀 jev-codex-router 的 BACKTEST.md 公布了方法：237 turns、684M input tokens，其中 98.3% 是 cached reads；固定每個 turn 的 token volume，以 2026-09-17 公開 API 價格重新計價。它沒有模擬切換模型造成的 prompt-cache invalidation ，也沒有證明便宜路由後輸出品質不變；作者自己註明真實節省可能更低。因此這是一個值得複製的 cost hypothesis，不是 60% 保證。
Context pruning 的安全做法
先 shadow：只記錄「本來會隱藏什麼」，不要立即改模型看到的內容。
錯誤輸出、低 confidence 與不確定區間預設保留；被隱藏內容必須可回收。
用真實 session replay 標記 recall／regret，而不是只看 token 減少率。
涉及需求、錯誤堆疊、測試失敗、安全訊號與使用者原文時提高保留門檻。
Context pruning 還沒有證明一定更快、更省 Yoshi 是另一條 Claude Code／Codex 本機 pruning proxy 路線。它的 current v12 benchmark 反而是很重要的反例：Fable diagnostic 雖減少 34.39% accumulated input，但耗時由 39.77 秒增至 210.54 秒；Sonnet mixed session 的 input reduction 為 -0.03%，耗時由 35.14 秒增至 171.99 秒，作者明確標註尚未證明 savings。Winnow 的早期 replay 較保守：300 cases／1,515 blocks 中，在 drop=0.1 設定估計只隱藏約 4.6–5% 大型結果文字；資料仍來自單一開發者 transcripts，人工標註樣本也有限。
所以 context sieve 的驗收不能只看「少送幾個 token」，必須同時測量端到端 latency、judge 費用、cache 命中、任務成功率與 recall／regret。
10 個 Jev 生態 Repo 的成熟度地圖 另一則 Threads 彙整了 10 個剛出現的專案。它們證明 Jev 的 interface pattern 正快速擴散，但多數是在 2026 年 9 月 16–17 日才建立的早期 repo；GitHub stars、demo 成片與 README 數字都不能代替 production reliability。
Repo 用途與核對結果 採用判斷 browser-use/jev-ultrafast Browser element／operation selection；Google Flights 錄影 7.073 秒。 最完整的小樣本 measurement，但不是跨站 benchmark。 TheoLeeCJ/openjev 用開源 Qwen 等模型重作「state＋typed options→probabilities」介面；RTX 3090 測 4B 模型。 沒有復現 Jev 的閉源模型或訓練 ；作者明確只重作 interface pattern。實驗中部分高速路徑會改變 argmax。vinnylarouge/jevlike 可用自備 JSONL 訓練變動候選集合的 option scorer；支援 CPU、Apple MPS、CUDA。 獨立 starter model，不知道 TypeSafe 未公開設計；效果高度依賴訓練資料與 held-out evaluation。 jarrodwatts/jev-trader 對 Monad／Kuru MON-USDC 每個 block 做 buy／sell decision；無 private key 時 dry-run，預設 model 是 mock heuristic。 展示低延遲決策 loop，不是獲利證明；實盤還有 gas、fill、inventory 與交易風險。 awesome-jev-by-typesafe 社群整理 use cases、patterns、prompts 與 starter code。 適合導航，不代表 TypeSafe 官方認證各項 claims。 typesafe-computer-use macOS screenshot＋OCR／Accessibility，再由 Jev 選 click；自由文字才叫 writing model。 作者估約 US$0.0002／decision、端到端約 1.5 秒；對照有工程能力不對等，因日期解析等 reasoning 被另外寫成 deterministic code。 jev-review 結構化篩 correctness、security、reliability、compatibility、test coverage。 適合 pre-filter，不可替代完整 code review、測試或資安審查。 gargpratyush/jev-router 保留 Claude Code／Codex 原生介面與登入，只在新 user turn 選 fast／strong model。 Repo 證明整合路徑；未提供足以外推的品質／成本 benchmark。 vlad-terin/jev-browser 在既有 browser tools 上提供 observation→selection→action→independent verification 的連續 runtime／skill。 Agent 仍需先給 bounded plan，遇到超出能力的步驟再交還 agent；不是全自主瀏覽器替代品。 droidrun/mobile-jev 透過 Mobilerun API 操作真實 Android；Uber demo 約 21 秒完成 9 actions，到付款選擇頁。 沒有完成訂單；需要 Mobilerun 與 TypeSafe keys，裝置／服務費另計。
不一定要等官方 waitlist，但接入方式不同 Vercel AI Gateway 的 live model catalog 已列出 typesafe-ai/jev，type 為 evaluation，支援 v4 specification；列價為每 input token US$0.000000042（即每百萬 US$0.042），output 為 US$0。OpenRouter 的 Decisions 目錄也已列出 ~typesafe/jev-latest 與固定版 typesafe/jev-1.13，32K context，價格同樣是 input US$0.042／百萬、output US$0。
目前免費，不是永久免費保證： TypeSafe 官方文章使用的是「Output tokens: FREE (too cheap to meter)」，公開目錄目前也確實列 US$0；但官方同時寫明，長期仍需時間證明定價可持續性。因此「永久免費」不是合約承諾，採購與產品 unit economics 必須允許未來調價。
「官方 waitlist 大約一天就過」只是貼文作者經驗，沒有可驗證 SLA。 OpenRouter、Vercel Gateway 與 TypeSafe 直連的 model slug、認證、request schema、資料政策、錯誤處理與可用性可能不同，不能把三個入口當成完全相同服務。OpenRouter 一般 language-model API catalog 沒列 Jev，是因為它被歸在 Decisions 類型；應以實際模型頁／Decisions catalog 判定，而不是只查標準 LLM 清單。
架構判斷： Jev 最可能先成為 LLM 前面的 decision plane——routing、filtering、ranking、risk gate——而不是取代 planner。真正 KPI 應同時看成本、延遲、誤路由、被刪 context 的後悔率與最終任務成功率。
它和傳統 LLM browser agent 的差異 面向 大型 LLM agent Jev fast path 強項 理解模糊需求、規劃、跨頁推理、處理例外 在有限候選中快速選操作／目標 輸出 文字、JSON、tool call；仍需驗證 型別化答案、機率分布與 confidence 上下文 可讀長頁面、圖片與歷史 適合精簡、可枚舉的結構化狀態 成本／延遲 通常較高，尤其每一步重新推理 窄決策通常更低，但依 API 定價與呼叫量 失敗模式 幻覺 selector／計畫漂移 候選集合、DOM reader 或 confidence 邊界錯誤
目前限制
預設 reader 只涵蓋常見 HTML／ARIA controls，尚非完整 accessible-name 規格。
Shadow DOM、iframe、canvas、upload、新分頁、巢狀捲動與任意鍵盤 widget 仍在 MVP 範圍外。
DONE 只是模型選擇，不能取代獨立 outcome verification。現有測試集中在 Google Flights、Wikipedia 與本地 hotel fixture；跨站可靠度尚未建立。
使用現有 Chrome profile，仍需處理權限、資料外洩、誤操作與交易前 human-in-the-loop。
對 Hermes／Browser Use 的實務意義 最有價值的整合方式不是用 Jev 取代 Browser Use，而是增加一條 fast path：
大型模型先把自然語言任務轉成 goal、限制與完成條件。
頁面可被安全枚舉時，由 Jev 連續選 operation／target。
需要輸入自由文字時再叫小型 LLM；需要跨頁推理、視覺、例外處理或低 confidence 時升級大型模型。
付款、送出、刪除、公開發布等高風險動作維持人工批准與獨立驗證。
採用判斷： Jev 很適合高頻、封閉、可驗證的 UI 操作控制層；不適合直接承擔開放世界規劃。真正的產品機會是「Planner LLM + Jev Executor + deterministic verifier」，而不是二選一。
2026-09-20 補充：Jev 落地判斷框架與 fast-jev-compaction 兩則新的 Threads 實務整理，讓 Jev 的適用範圍更清楚：它不是「更小的聊天模型」，而是放在 deterministic rules 與大型 LLM 之間的快速語意判斷層。真正值得採用的，不是展示型自動玩遊戲，而是大量、重複、答案格式固定、可用信心值分流的判斷。
上下文壓縮
fast-jev-compaction 不重寫 user／assistant 文字，而是逐一判斷舊 tool call／result 是否仍需保留；保留內容維持原文，失敗時退回 Claude Code 內建摘要。
Harness 治理
先用 regex 掃明確違規，再用向量找重複／衝突，接著交給 Jev 做逐條符合性判斷；只有低信心項目升級大型 LLM，確認過的失敗模式寫成 hook。
營運分流
待辦是否適合交給 AI、夜間新聞是否值得保留、題目與答案是否一致，都屬於「語意判斷＋封閉答案＋可分流」問題。
即時互動
郵件批次標記與語音意圖提前判斷，理論上都能受益於低延遲 decision layer；社群貼文中的成本、速度與案例數字仍需視為作者實測，不是通用 SLA。
fast-jev-compaction 核對結果
Repo 於 2026-09-17 建立，查核時約 4,067 stars、213 forks，GitHub API 標示 MIT。
每個非 pinned tool call 會同時問兩題：call 本身是否要留、result 是否必須原文保留；依 threshold 決定完整保留、只留 call 並截短 result，或整組移除。
預設保留最近 6 個 messages，Jev state 上限估算為 25K tokens，單次 request 估算上限 30K；超過時會分批提問，但每批重送完整 state。
缺少 API key、答案格式錯誤、Jev 失敗或壓縮收益不足時，Claude Code hook 會 fallback 到內建摘要。
README 明確提醒：token 只是字元估算，機率不等於安全刪除證明；精確錯誤、路徑、限制與測試證據仍可能被錯刪，因此必須 replay／shadow 驗證。
三個採用問題 問題 適合 Jev 不適合／應升級 能否用純規則可靠處理？ 規則不足、但語意類別有限 規則已足夠就不必多加模型 答案是否固定格式？ choice、score、yes/no、ranking 需要長文、創作、解釋或新資訊 需要多深的推理？ 單步判斷，可按 confidence 分流 跨步規劃、反事實、例外處理、不可逆決策
Kate 判斷： 對 Hermes 最值得先做的不是直接刪上下文，而是 shadow mode：讓 Jev 標記「可丟棄、需保留、低信心」，但不真的刪；用歷史 session replay 計算漏保留率、回溯需求與任務成功率，再決定是否啟用。Harness 清理也應採「regex → embedding → Jev → LLM → hook」的逐級升級，不讓概率模型直接改全域規則。
2026-09-20 補充：工作流文藝復興與 Awesome Jev 生態雷達 另一則 Threads 把 Jev 的架構意義說得很直接：當主模型同時背負長 Context、複雜規則、Agent 規劃與每個微小分支判斷時，系統很容易為了修正漂移而不斷堆 prompt、skill 與更大的模型。Jev 的價值不是取代 planner，而是把「判斷與選擇」拆回顯式節點，讓 workflow graph、state machine 與 deterministic policy 重新成為主角。
層 應負責 不應負責 Rules / code 格式、權限、明確限制、不可逆動作 gate 模糊語意分類 Jev / System One 封閉選項、ranking、score、Noul、confidence 自由創作、長鏈推理、跨域規劃 Planner LLM 理解目標、拆解任務、處理例外與低信心案例 每一步都重做廉價且重複的分類 Verifier / human 外部狀態回讀、重要結果與高風險批准 把模型自報 DONE 當成完成證明
Awesome Jev 雷達：169 已經是過期快照 Threads 貼文引用「169 個真實專案」，但查核時 Awesome Jev 首頁與 JSON-LD 已列 306 個 項目、17 個分類；各分類數相加也正好是 306。這不是貼文造假，而是該目錄在短時間內快速擴張，社群數字非常容易過期。
GitHub repo：logicrw/awesome-jev-projects ；查核時約 103 stars、11 forks，GitHub API 標示 MIT。
分類涵蓋 Browser & OS、CLI、Code Navigation、Context GC、Evaluation、MCP、Model Routing、Security、Voice 等。
目錄宣稱每個項目都有 commit-pinned source 與 decision point；頁面也確實提供固定來源連結與逐項 license 欄位。
目錄本身提供 skill.md、llms.txt 與 llms-full.txt，適合機器查詢，但仍是社群策展，不是 TypeSafe 官方相容性／資安認證。
採用 caveat： 「306 個被收錄」只代表可找到公開原始碼與 Jev decision point，不代表每個 repo 都成熟、維護中、授權完整或能上 production。目錄中有 Not declared、AGPL、Apache、MIT 等不同授權；安裝任何第三方 Agent Skill 前，仍要檢查 prompt、script、network、secret 與全域設定寫入行為。
對 BigIntTech 的落地順序
先盤點目前由大模型執行、但輸出其實只有分類／排序／通過與否的高頻節點。
保留既有 LLM 結果作為 baseline，Jev 先跑 shadow mode，比較 disagreement 與低 confidence。
只有可回滾、可驗證的節點才自動執行；付款、刪除、發布、權限變更維持硬 gate。
追蹤的 KPI 不只 latency／token cost，還要有誤路由率、abstention、升級率與最終任務成功率。
2026-09-21 補充：JEV Scene Lab 把 3D 生成改寫成「素材檢索＋批次決策＋確定性渲染」 歸藏展示的 形間 FORM — JEV Scene Lab ，不是文字直接生成全新的 3D mesh，也不是 diffusion／NeRF 類模型。它先準備一個 WebGL／Three.js 場景、51 種可用模型與固定控制欄位，再把使用者描述交給 TypeSafe Jev，同批判斷模型選擇、數量、空間、材質、燈光、位置、狀態與鏡頭；前端程式最後把結構化答案套用到既有場景。
社群說法 查核結果 正確解讀 一秒完成室內場景搭建 影片確實展示輸入後場景快速重排；介面顯示整輪約 1.3–1.5 秒的案例，但數字包含網路與重試。 是 demo 畫面與作者實測，不是跨地區、跨負載 SLA；應分開量測 API latency、前端套用與 WebGL render。 並發幾百次判斷 目前 live health endpoint 回傳 questionCount: 74、model: jev-1.13.0；頁面也寫「74 項判斷，同批完成」。 此版本是一個 request 內批次評估 74 個 typed questions，不是瀏覽器同時發出幾百個獨立 HTTP requests。 即時 3D 場景生成器 前端可見 51 種模型、8 種空間 layout，以及建築背景、地板、地毯、密度、鏡頭、家具數量／位置／朝向等封閉控制項。 更準確是「自然語言控制的程序化 scene assembler」：Jev 做選擇，既有資產與 deterministic code 做搭建。 可用於遊戲地圖 作者續文提出遊戲素材庫可用同樣思路快速做 demo；目前公開作品是室內展示場景。 概念可延伸，但碰撞、navmesh、可玩性、LOD、遮擋、資產授權、存檔格式與引擎整合尚未被此 demo 驗證。
實作拆解
預製資產： 頁面標示家具來源為 Kenney Furniture Kit（CC0）；不是每次從零生成 3D 幾何。固定狀態模型： 場景 state 包含 layout、architecture、floor、rug、density、camera，以及家具類型、數量、位置、朝向與材質等欄位。74 個 typed decisions： 同一份 command＋scene state 送到站內 /api/evaluate，再由後端呼叫 TypeSafe；目前 health endpoint 指向 jev-1.13.0。確定性套用： Jev 回傳結構化變更，前端的 scene code 把模型選擇轉為座標、材質、光照與相機配置。即時預覽： 輸入停頓約 420 ms 後觸發 preview；Enter 確認，並可 undo、白模對比、重置與匯出畫面。 核心價值： 當候選資產與可調參數都能枚舉時，不必讓大型生成模型慢慢輸出一份完整場景 JSON。用 Jev 對大量獨立欄位一次做封閉式判斷，再由程式保證 schema、位置規則與渲染流程，能形成低延遲「Text → Typed Decisions → Scene Graph」管線。
評論區與影片帶出的驗證點
作者續文已把 live demo 上線，並要求使用者自備 TypeSafe JEV API key。
評論者指出真正價值仍取決於 object consistency 與可編輯性；這是重要反方觀點。快速組裝不等於能穩定維持物件身份、拓撲或工程級可編輯資產。
60.4 秒影片為 1280×720 H.264，連續展示多種室內配置快速切換；它能證明 demo UI 會改變場景，但不能單獨證明所有輸入都在一秒內成功，也不能證明 production reliability。
畫面與 live endpoint 顯示的是 73／74 左右的批次判斷及約千毫秒級整輪時間；前端明確註記這是完整 request 時間，包含網路與重試，API 沒提供可獨立驗證的純模型 compute time。
安全與採用 caveat
API key： 頁面聲明 key 只存於當前頁面記憶體，但前端仍會把 key 放在 x-typesafe-key header 傳給該 demo 自己的 /api/evaluate proxy。能確認 client 沒寫 localStorage，不代表能獨立證明 proxy 不記錄；敏感或正式帳號應避免交給第三方 demo。資料： TypeSafe 隱私政策寫明不以客戶 Input 訓練／微調模型，服務託管在美國；企業 ZDR 仍需以 DPA／合約確認。語言： 官方文件說英文是主要訓練語言，CJK 可處理但品質不等；中文場景指令需自行建立測試集。信心值： calibration 是群體統計，不保證單一判斷正確。低 confidence 或互相衝突的場景欄位應 abstain／升級 LLM，而不是硬套結果。資產： demo 使用 Kenney CC0 素材；換成商業遊戲／設計公司素材庫時，要逐一處理授權、版本、metadata、縮圖、碰撞與 LOD。
對 BigIntTech 的可重用架構
遊戲／展場快速提案
把公司既有 prefab catalog 轉成有語意 metadata 的候選集合，Jev 選資產、佈局與狀態；Unity／Unreal／Three.js 負責 scene graph。
室內設計概念稿
先用封閉資產快速組裝可互動空間，再讓 image model 產生提案視覺；不要把生成圖誤當施工圖或精準 BIM。
Digital twin 狀態配置
讓 Jev 判斷設備狀態、告警級別與展示層，deterministic rules 保留安全限制、物理約束與不可逆操作 gate。
驗收指標
量測 exact field accuracy、scene constraint violations、低信心升級率、P50／P95 latency、每輪成本與人工修正次數。
Kate 判斷： 這個 demo 真正有價值的不是「AI 一秒生成 3D」，而是證明高速 decision model 可以成為大型素材庫的自然語言控制平面。適合 demo、遊戲灰盒、提案與互動配置；若要進 production，需補上 schema validator、scene constraints、資產授權、confidence gate、可重現測試與自有 proxy。
2026-09-21 補充：從 semantic if 到 probabilistic predicate——社群案例、反方實測與過度宣傳 兩篇新的 Threads 貼文把 Jev 的採用故事往兩個方向推：一篇追蹤發布不到一週即出現的社群變體與 case studies；另一篇把 Jev 包裝為工單路由、合規風控、Agent 護欄與 CRM 打分的「快思層」。核心架構方向有價值，但「150 ms」「延遲砍半」「帳單省 80%」並不是這些貼文提供了可重現 benchmark 的結論。
兩篇來源
真正重要的抽象：probabilistic semantic predicate if (semantic_condition) 過去常被拆成關鍵字、正規表示式、規則樹與大量 heuristic；Jev 類模型則把它改寫為「對一個已定義的語意條件輸出機率與封閉選項」。這不會消除 deterministic code，而是把責任重新分層：
Jev：Noul（yes/no）、Choice、Score 等快速、有界的概率判斷；
程式：schema、閾值、聚合、權限、重試、回滾與不可逆操作 gate；
LLM：長文生成、複雜推理、解釋與需要開放式輸出的尾部案例。
最合理的形態不是「用 Jev 取代所有 if」，而是 semantic predicate → calibrated probability → deterministic policy 。
高訊號實測：模型快，不代表整條流程一定更便宜 相關串文中，@oneday0013 提供了一組值得保留、但尚未附完整程式與資料集的個人實測：
留言者回報其當時測試的輸入上限為 32K；目前官方 model docs 已列 64K context。輸入仍為 text-only，檔案需先自行解析。
留言者以 Boolean／Choice／Score 描述輸出；官方 API 的正式原語名稱是 Noul（yes/no）／Choice／Score。
補充 criteria 相當於加入判定世界觀，準確度有明顯改善。
「是否為新文件開頭」直接詢問約 65%；拆成「新標題／上一頁是否結尾／是否表格」等單因子後再聚合，該案例提高到約 90%。
繁體中文可用；官方仍在 waitlist 時，Workers AI 已可取得。
端到端不一定比通用 LLM 便宜：若任務同時需要 tag＋文字描述，還要另外串模型或規則；檔案解析也有成本。
65%→90% 是單一留言者的工作負載回報，不是官方普遍 benchmark；但它指出正確的工程原則：把複合語意問題分解成接近條件獨立的 predicates，再做明確概率聚合，比期待一個模糊問題直接完美更可靠。
四個生產場景的可行性與邊界 場景 可行做法 不可省略的控制 智慧工單路由 Choice 判定部門／隊列，confidence 低時升級通用 LLM 或人工。 類別漂移、未知類別、P95 latency、錯誤路由成本、語言分層測試。 合規／個資風控 Noul／Score 作預篩或風險訊號。 不能宣稱「直接精準攔截」；需要高召回規則、人工複核、audit log、資料區域與誤判申訴。 Agent 工具護欄 在 tool call 前判斷語意風險，作為一層 probabilistic defense。 扣款、刪資料等高風險操作仍應由 deterministic allowlist、權限、額度與人工批准控制；模型判斷不能是唯一 gate。 CRM 意向打分／去重 Score 與 Choice 適合大量、低延遲排序。 需要 calibration、時間切割回測、群體偏差、漂移監控與明確 business threshold。
數字查核
150 ms： 落在官方示範的毫秒級範圍內，但貼文未提供地區、input size、question count、網路、批次大小與 P50／P95；不能把單點數字當 SLA。80% 高頻決策交給 Jev： 是架構假設，不是官方證明的 workload 比例。延遲砍半、帳單省 80%： 貼文沒有 baseline、token 分布、升級率、錯誤成本與實測帳單，屬未驗證行銷式估算。「杜絕脫韁」「精準攔截」： 過度承諾。Type-safe 只保證輸出落在定義型別內，不保證語意判斷永遠正確。不再需要 heuristic： 不成立。threshold、aggregation、abstention、fallback、policy 與安全規則本身仍是可觀測、可測試的 heuristic／decision logic。
對 BigIntTech 的落地建議
先找高量、封閉答案、錯誤可恢復的流程：信件分流、文件頁型、CRM 標籤、tool call 風險分層。
離線建立繁中 gold set，分別量 exact accuracy、calibration error、coverage、abstain rate 與高風險 false negative。
每個複合問題拆成原子 predicates，明確記錄概率合成方式，不讓模型偷偷決定 policy。
production 同時紀錄 P50／P95／P99、每 request question 數、輸入長度、成本、fallback 率與人工推翻率。
先 shadow mode，再低風險自動化；資金、刪除、權限與合規仍保持 deterministic gate＋人工核准。
判斷： Jev 的價值不是「消滅 if／heuristic」，而是把過去難以程式化的語意判斷，變成可校準、可批次、可設 threshold 的概率介面。速度與成本只有在整條流程——前處理、fallback、錯誤修正與人工複核——一起量測後才算數。
主來源複核：哪些 Jev 生態專案真的存在 名稱 查核結果 正確定位 Kev Repo 存在，2026-09-20 仍有活動。 Jev-inspired decision model，非 TypeSafe 官方模型。 Laya Repo 存在，定位為 multilingual non-autoregressive System 1 engine。 獨立開放替代方案，非官方 Jev variant。 Nimble 未找到可把此名稱與 Jev／TypeSafe 明確連結的第一方 repo。 暫列未驗證，不應與 Kev／Laya 一樣寫成已確認變體。 jevcal Repo 存在。 針對 typed decision model 的 calibration／thresholding 工具。 jev-ood-calibration Repo 存在，附獨立 OOD calibration 測試與 raw results。 社群獨立測試，不是 TypeSafe 官方 benchmark。 jev-use Repo 存在。 macOS Accessibility computer-use harness，讓 Jev 選下一個 screen action。 pi-jev-auto-mode Repo 存在。 Pi coding agent 的 tool permission classifier；自動核准尤其需要安全邊界。 jev-router Repo 存在。 替 Claude Code／Codex 每回合選模型的 router。 Huncho Repo 存在。 decisions-as-code SDK／provider layer，可接 Jev／OpenRouter／Vercel；不是模型變體。
「8 種變體」： 官方 TypeSafe 文件沒有此分類；可確認的是官方 Jev 加上獨立替代模型、SDK、router、calibration 與 computer-use 專案，不能全部叫模型變體。「快 200 種 cases」： 官方沒有確認此數字；社群索引即使收錄大量連結，也不代表逐項驗證、官方背書或 production case study。官方模型現況： 目前 docs 列 jev-1.13.0、aliases jev-latest/jev-preview、64K context、text-only、$0.042/M input tokens；型別原語為 Noul、Choice、Score。
補充：從社群 web-game 實驗到 JevHarness 的 harness 化路線 先標註證據邊界： OpenCode web-game 貼文目前是作者實驗與 prompt 展示，尚未看到可重播 repo、遊戲成品、評測紀錄或商業結果；可視為「Jev 共同決策如何被社群拿來做產品迭代」的觀察，不宜寫成已驗證的上市成功案例。
JevHarness 官方 repo 核實 項目 核實結果 採用意義 定位 TianyuCodings/JevHarness README 定義為「LLM-authored task-specific Jev harnesses」，讓 LLM 撰寫任務專用 harness：把 observation 轉成 features、構造 Jev questions／criteria，再把多個結構化答案合成 action。Jev 不負責開放式規劃；它在固定 harness 內做快速、模糊、結構化判斷。 核心模式 README 明確寫出：authoring LLM 可在開發期修改 code、questions、graph、memory；一旦 harness fixed／frozen，執行期使用固定程式與 Jev calls，不需要每個 decision 都再叫 authoring LLM 。 這補強本文原本的「Planner LLM + Jev Executor + deterministic verifier」：LLM 的深推理應前移到設計／驗證階段，runtime 只跑凍結策略。 支援模式 README 提供 Claude Code plugin 安裝、Codex skill-installer 安裝、manual clone fallback；repo 內 skill 也說明可建立、評估、選擇性演化 task-specific Jev pipelines。 可作為 harness engineering workflow，不是單一 demo script。 官方範例 Pokémon 範例宣稱 5 輪 reflection 後，selection Eval win rate 從 25%（3/12）到 75%（9/12）；selected harness 在 archived Eval run 的 full decision median 為 568 ms、個別 Jev request median 為 269 ms。 這是 repo 自帶 archived experiment，不是獨立 unseen benchmark；適合當方法展示，不可外推成一般任務保證。 GEPA／reward reflection README 說 optional GEPA integration 會用 instance frontier、同批 training batch 比較 parent/proposal、accepted proposals 再跑 Eval，並保存 ancestry 與 rejected proposals；reflection 會收到完整 trajectory、reward、node input/output、Jev questions/answers、memory 與 failures。 reward reflection 是離線改版機制，不是 production runtime 必備，也不是品質保證。沒有可靠 reward／eval／資料切分時不應啟用成自動優化。 限制與風險 GitHub API 顯示 repo license 為 null，raw LICENSE 路徑 404；README 也提醒 hosted model alias 不會 pin 未來 provider behavior，stored responses 與 fresh calls 的可重現性不同；skill 文件要求任務 contract、legal actions、reward、data split、budget、stopping condition 先定義。 採用前要補 license／法律可用性判斷，並把 eval、成本與停止條件寫成明確合約。
對「停止 loop」的實務修正 OpenCode web-game 實驗最有價值的問題不是「能不能讓 Jev 決定什麼時候停」，而是提醒我們：停止 loop 必須先被寫成可驗證判準 。Jev 可以在候選狀態中選擇「繼續／停止／升級人工」，但候選集合與門檻不能只靠一句「做到可以上市銷售」。
先定義 stop contract：例如核心 loop 可玩、無 blocker bug、首局完成率、載入時間、手機尺寸、明確 monetization／retention hypothesis、測試清單通過。
把停止條件分成 hard gates 與 soft scores：安全、支付、資料刪除、公開發布等高風險動作應是 hard gate，不應由單次 Jev confidence 直接放行。
保留 independent verifier：Jev 的 DONE 或「可上市」選擇只是一個 decision output，不能取代測試、playtest、人工產品審查與商業驗證。
避免無限自我迭代：每輪 reflection／GEPA 需要明確 budget、round limit、eval set、selection rule、成本上限與失敗退出條件。
採用判斷更新： JevHarness 讓 Jev 生態從「每一步 UI 操作選項」往「任務專用決策 harness」前進。正確姿勢是：開發期用 LLM 寫出可檢查的特徵、問題、判據、控制流與停止規則；凍結後 runtime 只執行那份 harness 與必要的 Jev calls。reward reflection／GEPA 可以做離線演化，但它需要可靠 reward、完整 trajectory、資料切分與預算控制；不能被寫成生產可靠度保證。
Threads 原文把方向寫成「Jev → Laya → Kev」，且一度誤寫成「Disclaimer AI」後更正為 Declarative AI 。這裡需要校正：目前官方來源看不到 TypeSafe／Jev 官方把 Laya 或 Kev 定義為 Jev 的下一代版本；比較準確的說法是三者都圍繞同一類 System One / typed decision 介面：輸入 state，加上一組 noul、choice、score 類型問題，輸出結構化答案與機率，而不是產生自由文字。TypeSafe 官方 API 文件描述的是 jev-latest 對 state + typed questions 的評估端點；Laya 與 Kev 則是開源／本地可跑的近似實作或相容生態，不應寫成官方線性版本演進。
Laya 官方 GitHub 與 Hugging Face 把它定位為 multilingual, non-autoregressive System 1 decision model ，支援 choice、score、noul，主張單次 forward pass 輸出 calibrated probabilities，不做文字生成。官方 README / model card 列出三個 checkpoint：convaiinnovations/laya 使用 ModernBERT-large、約 421M 參數、英文 512 context；laya-multilingual 使用 mmBERT-base、約 322M 參數、1024 context、面向 100+ languages；laya-typed-decisions 則面向 typed-decisions workflows。GitHub repo 與 Hugging Face metadata 均標示 Apache-2.0 。
部署上，Laya 是本地／開源取向：README 提供 pip install laya、Router(preload=True) 與 laya.load(...) 的本地推論範例，並主張在 T4 上單題約 32.8–39.5ms、10 題 batched 約 7.2ms/question 等數字。不過這些 benchmark 主要來自作者 README / model card：雖然寫有 MASSIVE、XNLI、17,416 questions、T4 等測試設定，也有與 Jev 對照圖，但仍應標成「作者測試／作者提供 benchmark」。它不是 TypeSafe 官方 benchmark，且任務、prompt、sample、API 包裝與 Jev 實際服務條件不一定完全一致；文章中可把它當作「開源 typed-decision 替代路線的早期證據」，不要直接寫成「Laya 已官方超越 Jev」。
Kev 官方 repo 的定位是「small Jev-like decision models you can train and run yourself」，並明確說 API matches TypeSafe 的 System One，所以可以把 TypeSafe Python SDK 指到本地 Kev server。repo README 標示 Apache-2.0 ，提供本地 server 指令，並支援 CUDA、ROCm、Apple Silicon / MLX；這是它對 Allen 最有價值的點：不是只能用遠端 Jev API，而是可在本地跑一個相容 typed-decision endpoint。
jaredpalmer/kev-0.5b 是 Hugging Face 上的原型／superseded checkpoint。官方 model card 寫明它是 LoRA adapter + pointer head on top of Qwen/Qwen2.5-0.5B ，英文、Apache-2.0，資料來自 Banking77、BoolQ、AG News、MultiNLI、SST-5、Yelp Review Full 等六個來源，held-out split 1,350 questions，model-index 的 accuracy / ECE 標示為未由 HF 驗證（verified: false）。目前 Kev repo README 與新 model cards 主推的是 0.8B、4B、9B family，基於 Qwen/Qwen3.5-0.8B-Base、Qwen/Qwen3.5-4B-Base、Qwen/Qwen3.5-9B-Base 的 PEFT / LoRA adapter，仍是 decision model，不做自由文字生成。HF metadata 顯示 license 為 Apache-2.0，datasets 擴到十個 public sources 加 programmatic policy data；0.8B / 4B / 9B 的 model-index 同樣是作者提供、verified: false。
Kev benchmark 應保守描述為「作者釋出的 frozen suites / model card 結果」，而不是第三方正式排行榜。Kev-4B card 例如列出 transfer-v4 dev / locked test、Brier、ECE、confident errors、option-order flip rate，並把 Jev 放在同表比較；這對技術判讀有參考價值，但還是同一作者實驗框架與 Jev API 對照，不等於 TypeSafe 官方背書。可寫成：Kev 的訊號是「本地化、可訓練、可重跑 evaluation 的 Jev-like decision model」，不是「Jev 的官方下一版」。
Exa 官方 demo Live Web Context for Jev 的重點是把 Exa search results 放進 Jev 的 state.search_results，讓 Jev 對同一個 typed question 分別在「有 live web evidence」與「沒有 web evidence」兩種 state 下回答。頁面文案寫得很清楚：Exa search results 會進入 evidence list，並直接放進 Jev state；同一問題會顯示 with web / before web 的比較。
因此這個 demo 應放在文章的「Jev 作為 typed decision layer，可吃外部檢索上下文」案例，而不是放在「Laya / Kev 是 Jev 後繼版本」證據。它證明的是：System 1 typed-decision 介面可以接 RAG / live web context，用檢索結果提升決策 grounding；不證明 Laya、Kev、Jev 之間有官方版本繼承關係。
原本若要寫「Jev → Laya → Kev」，建議改成：
更精確地說，Jev、Laya、Kev 是同一波 System 1 / typed-decision 模型生態的不同實作：Jev 是 TypeSafe 官方服務與 API；Laya 是 Apache-2.0、ModernBERT / mmBERT 기반的本地開源非自回歸 decision engine；Kev 是 Jared Palmer 釋出的 Apache-2.0、本地可跑、System One API 相容的 Qwen 系列 Jev-like decision model。它們可以互相比較，但目前沒有官方來源支持「Jev → Laya → Kev」這種線性版本演進說法。
這則 Threads 提供兩個值得保留的實務模式，但它是社群使用心得 ，不是 TypeSafe 官方 benchmark：
內容資產評分 ：先把歷史貼文、回覆與互動資料整理成 state，再用固定問題評估知識密度、包裝手法、流量元素、是否值得擴寫成新貼文或電子報。Plan Quality Gate ：先依規劃內容性質分流到不同判斷集，再對完整度、風險、邊界、可驗證性等指標打分；低於門檻就退回 planner 修正，而不是讓生成模型只憑一大段語意規則自我檢查。 這種做法的價值不是「數字一定正確」，而是把原本模糊的偏好轉成可重複測試的 rubric → decision → feedback loop 。同一組資料、問題、門檻與版本可反覆執行，便於比較 prompt、模型、規劃策略或內容版本。
原始內容／Plan
→ 正規化成乾淨 state（文字或 JSON）
→ 依任務類型選 rubric
→ Jev 回傳 choice / score / noul 與機率
→ 門檻／成本矩陣決定：通過、重做、人工覆核
→ 保存 outcome，定期重跑 holdout 與調整 rubric
內容 rubric ：知識增量、證據完整度、重複度、可延伸性、受眾適配、標題／開場強度。Plan rubric ：目標明確度、依賴完整度、風險揭露、驗證步驟、回滾條件、執行邊界。分流規則 ：先判斷任務類型，再載入對應問題集；避免所有任務硬塞同一份 Skill 或規則清單。回饋方式 ：把低分維度與可觀察缺口交回 planner，但不要要求模型單純「把分數弄高」；否則容易出現 reward hacking，只優化表面指標。
大量 AB 測試可以改善 rubric、prompt 與閾值，但不能取代準確度與校準。若評估器本身偏差，暴力重試只會更穩定地追逐錯誤目標。最低限度應有：
固定 holdout set ：保留未參與調參的中文、口語、長文、矛盾句與邊界案例。按錯判成本設門檻 ：把 false positive／false negative 的代價分開；高風險動作不能只看單一平均分。校準與拒答區 ：檢查預測信心是否對應實際正確率；落在保守／不確定區間時轉人工或較強模型。漂移監控 ：內容風格、語言、平台格式或上游抽取器改變時重測；不要假設一次調好的門檻永久有效。結果回標 ：保存人工決策與事後 outcome，觀察 rubric 分數是否真的預測品質，而不只是符合作者偏好。 留言中有人觀察到中文非結構性判斷的信心較保守。這是有用的測試線索，但仍是個人實測；不能用「多加其他語意指標」就視為已解決。新增指標可能降低漏判，也可能造成高度相關的重複訊號。應在中文 holdout set 上分別測量 coverage、accuracy、ECE／Brier score，以及轉人工比例。
Jev 只會依收到的 state 做快速決策。網頁、圖片、對話串或真實世界事件若沒有先被完整抽取、正規化並保留來源，模型可能對錯誤或殘缺資料給出非常快、非常整齊的結果。因此 production pipeline 應把下列項目和模型版本一起記錄：
原始來源與擷取時間；
正規化／截斷規則；
rubric 與門檻版本；
模型版本；
最終人工或業務 outcome。
結論 ：Jev 適合當可量化、可測試的 decision component，而不是把人的判斷力外包給一組分數。好的用法是讓它負責大量低成本初篩與 quality gate；高風險、低信心或資料不完整的案例仍交給人工或較強推理模型。
2026-09-28 補充：Qwen3-0.6B Jev-like live coding——架構跑通，不等於模型已訓練完成 Architecture Walkthrough / Qwen3-0.6B / Choice Invariance
把生成式 Qwen 改成候選決策器，核心不是 prompt，而是 mask、position IDs 與 scoring head
Neural Breakdown with AVB 的 4 小時 44 分直播以 Qwen/Qwen3-0.6B 為骨幹，實作 Jev-like 的候選決策 forward path：保留 tokenizer 與 Transformer hidden states，停用文字生成用的 LM head，抽取 question／choice／answer embeddings，再輸出候選 logits。直播證明了選項重新排序時 embeddings 可維持一致，但沒有完成資料訓練、accuracy、calibration 或正式 benchmark，因此不能寫成「已複製官方 Jev」。
直播實際做了什麼
基礎模型
畫面中的 model ID 是 Qwen/Qwen3-0.6B。Qwen 官方 model card 將它列為 0.6B causal language model、28 層、32,768 context、Apache-2.0；直播利用的是預訓練語言表徵，不是從零訓練 Transformer。
輸入打包
把 state／question、數個 option，以及固定 answer token 串成一個 token sequence；先逐段 tokenize，再記錄每個 choice 的 begin/end span，避免單靠字串搜尋定位特殊標記。
輸出頭
不再讓 LM head 逐 token 生成文字，而是取每個 choice 尾端 hidden state 與 answer hidden state，經額外 self-attention／projection scoring layer 產生每個候選的 logits，再接 softmax；訓練時預計用 cross-entropy 或對比式 loss。
為什麼一般 causal Qwen 會受選項順序影響 若把選項依序塞進普通 causal sequence，後面的 choice 可以注意到前面的 choice，而且每個 choice 的 absolute／rotary position 也會隨前面選項的長度改變。這會讓同一組候選只因排列不同，就得到不同 embedding 或分數。
問題 直播中的修正 目的 Choice 間的資訊洩漏 自訂 attention mask：每個 choice 只能看 state／question 與自己，不看其他 choices；answer token 則可看完整序列。 讓每個候選在相同上下文下獨立編碼。 Choice 的位置隨排序漂移 每個 choice 的 position IDs 都從同一基準重新開始；answer 區段再接續。 避免候選前後順序或長度改變其位置表徵。 Qwen3 SDPA mask 語意 實作過程先用 0/1 mask 得到錯誤行為，後來改為 additive mask：允許位置為 0、阻擋位置為 -inf。 符合 scaled dot-product attention 實際加到 attention scores 的 mask 形式。
直播約 3:52–4:14 重新排列 choices，檢查各 choice embedding 與 answer embedding，並示範移除自訂 position IDs／attention mask 後 invariance 會失效。這是很有價值的 architecture sanity check，但不是任務正確率或機率校準證明。
需要校正 Threads 的說法 社群簡化說法 較精確的解讀 「把一個 Qwen 模型改成 Jev 決策模型」 直播完成的是 Jev-like 候選決策架構與 forward pass ：choice-order-invariant encoding、embedding extraction 與 logits head；作者明確表示本場不進行正式 training。 「把分詞化講透」 重點是先逐段 tokenize 並保留 spans，方便抓 choice／answer hidden states；tokenizer 本身仍存在，並非 tokenizer-free。 「已經得到可用 Jev」 尚缺 dataset batching/collator、loss 訓練、holdout accuracy、order-flip rate、ECE/Brier calibration、延遲與吞吐 benchmark，以及失敗案例分析。 「這就是 TypeSafe Jev 的內部做法」 TypeSafe 公開文件只確認 Jev 是 System One 模型、輸出 typed probabilities、以 RLCD 訓練；沒有公開證據顯示官方 Jev 就是這個 Qwen3-0.6B 改造架構。這是教學性的近似實作，不是官方逆向工程結果。
若要把這個原型升級成可評估模型
固定 dataset split，另外保留未參與調參的 holdout；不同選項數量與長度都要覆蓋。
訓練時隨機 permutation choices，測試時對每題跑多個排列，直接量測 option-order flip rate 與 logits variance。
除了 accuracy，也量測 NLL、Brier score、ECE、confident errors 與 abstain／人工升級區間。
建立 hard negatives、語意近似候選、長 state、中文與 code-switching 測試，不要只用容易區分的 choices。
分開比較：原始 Qwen prompt classification、同 backbone 的一般 classifier、Jev-like mask/position head、官方 Jev API；硬體與 batch size 必須一致。
不要讓候選生成與候選判斷混在同一結論：這種 decision model 仍需要 deterministic code、檢索器或另一個 SLM/LLM 先提供候選集合。
對 Allen／BigIntTech 的判斷： 這場直播最值得保留的是一個可複用的 engineering pattern：把預訓練 causal LM 的 hidden states 改造成「封閉候選、單次並行打分」元件，而且用 attention mask 與 position IDs 主動消除順序偏差。它適合做本地 router、quality gate、工具選擇與低延遲分類實驗；但在沒有訓練與校準結果前，只能叫 architecture prototype，不能替代 production evaluator。
2026-09-28 補充：OpenJev-Fast 的 6× 是真的，但只在 B300 單請求暖機條件成立 CUDA Kernels / Prefix Tree / CUDA Graphs / B300
17.3 ms 的工程突破，不是所有 GPU、所有負載都能直接複製
Northwestern University 的 OpenJev-Fast 是 Open-Jev-27B-v1.1 的 drop-in local backend：模型與 request format 不變，以融合 CUDA kernels、兩層 prefix tree、tuned GEMMs 與 per-shape CUDA Graphs 取代原本 forward path。作者公開程式碼、逐步 benchmark、correctness logs 與失敗嘗試；測得單一例題相對 Open-Jev + FLA 快 6.0×，JevBench 平均 HTTP latency 快 6.1×。但目前只在 NVIDIA B300、bf16、concurrency 1、暖機後驗證，且約需 98 GiB VRAM。
「提升 6 倍」要拆成三組數字 比較 Baseline OpenJev-Fast 倍率／條件 Example request：forward + scoring head Default PyTorch 256.0 ms 17.3 ms 14.8×；539 tokens、3 questions／7 candidates，tokenization 與 HTTP 不含在內。 Example request：forward + scoring head PyTorch + FLA 103.7 ms 17.3 ms 6.0×；同 GPU、5 次 warm-up 後 30 次中位數。 231 個 JevBench tasks Original server + FLA：mean 258 ms mean 42.0 ms 6.1×；包含 tokenization、HTTP、JSON，但同機、concurrency 1、兩邊都跑第二輪暖機結果。
JevBench 的 P50／P95／最慢 task 從 150／802／1,489 ms 降至 17.4／137／208 ms。第一輪不是這麼快：新 request shape 需要 1–3 秒抓 CUDA Graph；作者報告 OpenJev-Fast 第一輪 mean 190 ms、P50 24.4 ms、最慢 3.3 秒。因此社群文案只寫「6×」方向沒錯，但一定要同時說明 warm-shape 與單請求條件。
速度從哪裡來
Fused CUDA kernels
手寫 CUDA C++／inline PTX 取代 layer 中非 matmul 操作，並實作 Gated DeltaNet 與 tree-masked attention kernels；每個 request 的 kernel launches 約從 5,000 降至 642。
Two-level prefix tree
共同 context 只算一次，每個 question 只算一次，每個 candidate 只算尾端；線性 attention 保留每個候選的完整 path，full attention 則用 ancestor mask。
GEMM + CUDA Graphs
合併 weights、split-K fp32 partial sums、逐 shape 挑選 cuBLASLt algorithm，並為 request shape cache CUDA Graph。
正確性沒有被完全犧牲，但不是 bit-identical 231 題 JevBench 中，原始 server 為 198／231，OpenJev-Fast 為 197／231。兩題 prediction 與原始版本不同，其中一題前後都答錯，另一題是 0.504／0.496 的 near-tie，優化後翻成 0.496／0.504。最長 10,722-token 測試的 probabilities 與原版最大差 0.019，但 decision 未變。
這是合理且透明的數值差異揭露，但對靠 confidence threshold 自動執行的 workflow，0.5 附近翻轉仍可能改變路由。production 應保留 safety margin／abstention band，並在自己的 threshold、資料分布與 GPU 上做回歸，而不是只驗證 top-1 accuracy。
目前限制
只為 Open-Jev-27B-v1.1／Qwen3.8-27B shapes 特化；不是通用 Jev backend。
僅在 NVIDIA B300 驗證，預設編譯為 sm_103；其他 sm_80+ GPU 路徑未測，速度不可外推。
只支援 bf16；約使用 98 GiB VRAM，80 GB GPU 目前不夠。
server 一次只處理一個 request；沒有多使用者 concurrency、batch throughput 或 tail latency 壓測。
新 shape 首次 CUDA Graph capture 增加 1–3 秒；headline 是 warmed second pass。
截至 2026-09-28，repository 前一天才建立、MIT 授權、15 stars、0 forks；benchmark logs 與 tests 已公開，但尚無獨立 B300 重現。
同一篇 Workflow 討論的留言補充：混合式架構比「全面回到節點」更精確 先前收錄的 Workflow 文藝復興 Threads，其高訊號留言其實提出兩個值得保留的修正：
不是 Agent 與節點二選一。 較合理的 production 形態是 deterministic workflow 管不可逆流程與明確規則，Jev-like router 管模糊語意 decision points，planner／高階 Agent 管例外與跨步規劃。這比「全部改回節點」或「全部交給 Agent」都更可控。開源替代已出現，但品質差距要誠實標示。 open-jev-deberta-v3-large 是獨立的 Jev-shaped DeBERTa-v3-large classifier，不使用 TypeSafe data／code，也不宣稱可比官方 Jev。model card 報告 in-domain accuracy 0.854、OOD 0.690、512-token／English-only；這證明 typed-decision interface 可用一般分類模型重現，但也直接顯示 OOD 與 context limits。 留言另聲稱 LangChain 有 ModelRouterMiddleware 專門把模型描述轉成 Jev input。查核目前 LangChain 1.4.2 的 built-in middleware，只有 model retry／fallback／call limit 與 LLM tool selector 等，未找到該 class；TypeSafe 官方 integrations 路徑也未提供對應文件。因此這項說法暫列未證實 ，不能當既有官方整合。
對 Allen／BigIntTech 的判斷： OpenJev-Fast 證明 Jev 類決策器的 latency 還有很大 systems optimization 空間，但 B300 約 98 GiB 的部署門檻不適合直接當成本優勢證明。短期應先用 API／較小 open model 驗證 decision quality 與 business ROI；只有高 QPS、低延遲、資料不能離站且 workload shape 穩定時，才值得評估客製 CUDA backend。
2026-10-15 更新：Jev 1.14 的圖片、Box 與長上下文仍有實驗界線 新增@aiposthub的DegFdnEASUK與兩則作者續文DegFeBMgfeJ、DegFelDgVGR，並保留前一則@cooljerrett的Deg0niWjx-E作為同版社群來源。已讀AI郵報連結全文及TypeSafe第一方公告、Models、Images與Box文件。公開留言coverage為partial；前一來源的解說影片未完整轉錄，遊戲、Sanity裁切與Agent Zero案例不視為本次重現結果。
正式發布版本，不等於每項功能已可正式上線 TypeSafe於2026-10-14發布Jev 1.14.0，但公告與文件仍將Images及Box列為dreamer-ready，須對相關請求加入TypeSafe-Danger-Zone-Images: true。官方不為其正式產品可靠性背書，格式、限制與準確度仍可能變動。圖片實驗支援同時涵蓋1.13與1.14；Box才要求jev-1.14.0或jev-preview，不能說1.14以前完全看不到圖片。
Box一定回框，找不到物件也不會回not found 每個Box問題只回一個框，使用top、bottom、left、right四個0至1的比例邊界。型別合法不代表目標存在或位置正確。官方明確說不存在的目標仍會回四條邊；可在同一request另問Noul檢查存在性，低存在性時不要採用Box。多物件也不是一次就完整列出所有框，須明確指定目標或另設問題。
confidence需要用自己的圖片校準，官方尚未推薦通用門檻。比例座標可以換算到相同幾何關係的圖片尺寸，但旋轉、裁切或加邊後仍要做座標轉換；不能只看合法數值就自動裁切或執行高風險動作。
262K是另開的長上下文，不是預設，也不是品質保證 本次Models文件列預設64k per-request及32k per-question，加入TypeSafe-Danger-Zone-Long-Context: true才將兩者提高到262k；這與圖片開關分開，而且1.13及1.14都可使用。官方提醒較長輸入更慢、較不準，仍建議保持精簡。單價相同不等整次請求費用相同。
2026-10-15文件列每百萬input tokens US$0.042、output tokens免費，這是查核當時的單價，不是每張圖片固定費用或永久價格。圖片在assets中上傳一次，若在多處文字重複引用，展開時仍可能出現多份，增加內容量；token、請求大小、重試與最終工作成本要分開計量。
版本別名與媒體範圍要分開 本次官方Models頁仍列jev-latest指向1.13.0、jev-preview指向1.14.0；公告預告稍後才切latest。正式比較宜固定版本ID並保存回應的model欄位，不能只記最新模型。直接音訊與影片輸入仍不在此文件的支援範圍；多張影格的圖片判斷不等原生影片理解。
採用框架：先驗存在性，再驗位置，最後才決定行動 建立固定、獲授權的圖片與人工答案，包含沒有目標、多個相似目標、遮擋、小物件、低解析度及中文指令。 分開衡量存在性誤判、選錯物件、漏框／切邊與人工修正時間，不用回傳200或有框代替任務成功。 把框畫回原圖複核；低信心、目標不明或幾何變換未驗證時回人工，而不是只重送相同請求。 外送圖片與截圖前先核對個資、保密及資料處理安排。官方不以客戶請求訓練，不等所有帳號均零留存；企業ZDR需另外確認。 這是公開規格與文件查核，沒有使用私人API key、送出圖片、呼叫付費模型、安裝SDK、改動Agent或完成定位準確率實測。官方內部評測與社群成片都沒有升級成本次獨立效能證明；上文9月的1.13／DOM demo資訊保留為歷史與特定程式路徑，不拿來限制或背書新版圖片能力。
新增來源