Jev 是開源的嗎？權重是封閉的，工具鏈則不然

不。Jev 1.13（typesafe/jev-1.13）不是開源，沒有權重儲存庫可找，而且在 TypeSafe 的 GitHub 組織裡再怎麼滑，也找不到檢查點、架構文件或參數量。真正存在的是模型周邊的軟體：十一個公開儲存庫，每一個都是 MIT 或 Apache-2.0，但沒有一個包含 Jev 本身。這就是最誠實的一句話答案——工具是開放的，模型則不是——而這也是讀者單從「封閉、託管、未發布」永遠得不到的另一半故事。有兩個日期框住了這件事。TypeSafe 在 2026-09-15 推出了這個模型，而這落在本部落格所涵蓋的七天窗口之外，所以這不是一篇發布文，其中任何內容都不應被當成發布文來解讀。有明確日期的事件是 2026-09-24，當時 OrcaRouter 將 typesafe/jev-1.13 加入自家目錄：這是 Jev 首次能透過第三方閘道呼叫，而不只是透過 TypeSafe 自家的端點。這就是本頁所依據的例外——一個在原本不能運行的地方變得可運行的模型。

這對讀者帶來的改變範圍不大，卻很實際。在 2026-09-24 之前，評估 Jev 意味著你得先建立第二個供應商合作關係，才能測試任何單一決策。在那之後，Jev 與同一工作流程的生成式那一半共用同一把金鑰：一個 API 就能存取 200 多個模型，0% 加價（供應商標價原樣透傳，因此廠商降價當天就會在此生效），並可透過 typesafe/jev-1.13 存取該模型。你仍以其自身形式呼叫它——POST /v1/systemone、非串流——因為那不是 OpenAI chat-completions 路由，但你簽署的合約與輪替的金鑰，都是你已經擁有的。

答案有兩個，且兩者缺一不可。

「Jev 是開源的嗎？」讀起來像個是非題，表現起來卻像個由兩部分組成的問題。第一部分：模型。它是封閉的。TypeSafe 並未公佈 Jev 1.13 的權重、架構、訓練算力數字或參數數量，也沒有以它命名的儲存庫。第二部分：周邊軟體。它是開放的、積極維護的，而且確實有用，而這正是為什麼尋找儲存庫的讀者不會只是無計可施。

混淆這兩者會在兩個方向上得出錯誤的結論。假設整件事是開放的，你會花一整個下午尋找一個根本不存在的檢查點。假設整件事是封閉的，那麼如果你擔心鎖定問題，就會錯過真正重要的部分——一個 MIT 授權的配接器，讓你能以具型別的決策介面為目標進行建置，並更換其背後的實作。

TypeSafe 實際上發布的內容

於 2026-09-30 讀取時，該組織有十一個公開儲存庫。星數與推送日期會變動，因此請將此視為快照，而非專案的固定屬性。除非另有註明，否則每個授權條款都是 MIT 或 Apache-2.0。

• skills — MIT，約 2.4k 顆星，最後推送於 2026-09-12。「用於搭配 TypeSafe 的 System One API 進行開發的 Agent 技能。」

• system-one-adapter-python — MIT，356 顆星，最後推送時間：2026-09-22。「以 LLM API 為後端的 TypeSafeClient 無縫替代品。」

• typesafe-sdk-js — MIT，257 顆星，最後推送於 2026-09-15。TypeSafe API 的官方 TypeScript/JavaScript 函式庫。

• typesafe-sdk-python — MIT，254 顆星，最後推送於 2026-09-26。官方 Python 函式庫；v0.7.2 當天新增了 `http2` extra，而 2026-09-21 的 v0.7.1 則新增了與 AI gate 搭配使用的範例。

• daggerverse — Apache-2.0，23 顆星，上次推送於 2026-09-25。一組 Dagger 模組。

• WorkflowEvals — Apache-2.0，7 顆星，最後推送於 2026-09-29。「evals.typesafe.ai 工作流程程式碼已發布。」

• n8n-nodes-typesafe-ai — MIT，1 顆星，最後推送於 2026-09-29。

• typesafe-ai.github.io — 未宣告授權條款，2 顆星，最後推送於 2026-06-04。

另外三個是不相關專案的分支，將於下文討論：pulumi-clickhouse、LLaDA 和 vllm。

那份清單裡沒有任何一項是模型。沒有 Jev 儲存庫、沒有權重檔、沒有分詞器、沒有服務組態——沒有任何能讓你架起一份可運作副本的東西。那些 repo 只是客戶端的周邊擺設：兩個官方 SDK、一個 agent-skills 套件、一組 CI 模組、一套已發佈的評估套件、一個 n8n 節點、組織網站，以及配接器。那是一個真實且維護良好的表面，而它不是模型。

如果你想避免被鎖定，唯一重要的儲存庫

system-one-adapter-python 是對任何正在做採用決定的人來說後果最為重大的項目，而它本身的描述就道出了重點：一個「由 LLM API 驅動的 Drop-in TypeSafeClient 替代品」。

仔細讀那段內容，因為它正在做一件很特定的事。在 System One 整合中，持久資產是介面，而不是它背後的端點：你定義一份狀態和一組具名問題，然後由某個東西針對每個問題回傳一個具型別的答案。你的程式碼庫最後就是圍繞著那份契約成形。配接器會把契約與實作解耦——你持續針對具型別決策介面來建構，而產生那些決策的東西，底層是可抽換的 LLM API 呼叫。

兩點誠實的但書。轉接器不是模型：透過這條路徑由一般 LLM 產生的答案，並不是 Jev 所回傳的校準後機率，因此它是一種讓介面保持可攜的方式，而不是一種不靠 Jev 也能取得 Jev 行為的方式。而且它明確是個 TypeSafe 專案——逃生出口是由你可能正想逃離的供應商打造的；這聊勝於無，但並不等同於一個獨立的逃生出口。

這兩個分岔，以及它們所引出的推論

這十一個儲存庫中有三個是 fork。pulumi-clickhouse 是 ClickHouse Cloud 的 Pulumi 提供者，Apache-2.0，3 顆星，最後推送於 2026-07-08。另外兩個則是被當成證據來解讀的儲存庫，而這兩種解讀都是錯的。

• vllm — Apache-2.0，3 顆星，最後推送於 2025-05-23。一個高吞吐量推論與服務引擎的分支。

• LLaDA — MIT，12 顆星，最後推送於 2025-06-17。為「Large Language Diffusion Models」官方 PyTorch 實作的一個 fork。

這種偷懶的推論不言自明：他們 fork 了一個擴散語言模型的儲存庫，所以 Jev 一定是以擴散為基礎。事實並非如此，而那個 fork 完全無法說明 Jev 的架構。fork 是他人程式碼在他人授權條款之下的複製品，會留在某個組織裡，原因從它自己的最後推送日期即可明顯看出——2025 年 5 月與 6 月，比 Jev 公開發布還早了一年多，此後便未再更動。這兩個儲存庫都不屬於 TypeSafe 在九月發布的內容。如果你想知道 Jev 如何運作，TypeSafe 並沒有公開，而它組織裡的任何 fork 也填補不了這個缺口。

關閉權重實際上會讓你付出什麼代價

四件事，而且它們是具體的，而非哲學性的。

• 你無法自行託管。沒有可供執行的成品，因此供應商服務中斷或存取權限變更時，你無法透過架設自己的副本來繞過這些問題。

• 你無法稽核。TypeSafe 確實為 Jev 1.13 發布了一份鋸齒狀（jaggedness）頁面——最後審閱於 2026-09-17——其中點名模型不可靠之處：按字面解讀措辭而非意圖、任何涉及算術、日期與時間比較、間接表述與雙重否定、充滿無關細節的大型狀態、狀態中的對抗性內容、相互矛盾的指示與準則，以及它不保證的結構性不變條件，例如 true/false 答案與其等效的 yes/no 選擇彼此不一致。那頁面異常坦率，但仍舊是供應商自己在批改自己的作業。TypeSafe 以外沒有人檢驗過權重。

• 你無法微調。沒有可調適的基礎模型，因此 Jev 處理得很差的決策任務會一直處理得很差，直到供應商改變它——鋸齒狀頁面本身的補救措施是你程式碼中的變通方案，而不是訓練執行。

• 你無法將版本鎖定在供應商的別名之外。typesafe/jev-1.13 是託管名稱，因此下個月回應呼叫的，就是 TypeSafe 屆時在該名稱下提供的任何內容。

這些都不是 Jev 獨有的，也全都算不上什麼醜聞；這是託管式決策模型所做的取捨，而它的平衡點在於：你永遠不必背負檢查點、GPU 帳單或推論堆疊。在你以此為基礎打造之前，值得先知道自己站在這筆取捨的哪一邊。

Jev 是什麼，既然你現在可以稱呼它了

Jev 不是聊天模型，也不會生成散文。你傳送一個狀態——待評判的素材，形式可為文字、物件或陣列——再加上一組具名問題，而它會針對每個問題回傳一個結構化答案。每個問題都屬於三種基本型態之一：

• noul — 一種真/假判斷，並附帶一項經校準的機率回傳。

• 選擇 — 從最多 255 個已標示的選項中挑選一個。

• 分數 — 依 2 至 10 個等級的有序量表進行評分。

TypeSafe 自家的文件顯示了一個以 0 為起始索引的分數範例；Jev 1.13 模型卡則公布了 2–10 個等級。兩者都是供應商自家的資料，而本頁並未憑空發明一套調和兩者的說法。

這種訓練方法是 TypeSafe 自創的說法：校準決策強化學習（Reinforcement Learning for Calibrated Decisions，RLCD），並在發布文章中相對於 RLHF 與 RLVR，從校準決策與誠實機率的軸線加以描述。RLCD 是 TypeSafe 的術語，不是通用的機器學習縮寫，應將其解讀為供應商描述，而非經獨立界定的技術。

存取已不再受限：Jev 自 2026-09-21 起已全面推出，而「waitlisted」已退役。「Early access」仍是 TypeSafe 在其首頁目前使用的說法，因此這不是一個可輕忽的說法——它單純是供應商的標籤，而且其同時公布的營運限制是具體明確的。

我們模型卡上的數字：65,536-token 上下文，供應商記載約 64K 輸入，涵蓋合併後的狀態加上問題。如果你看到 Jev 被引用較小的數字，那單指狀態預算本身，而不是另一個相互競爭的測量值，兩者不應被呈現為矛盾。價格為每百萬個輸入 token $0.042，輸出計費為零——沒有輸出 token 需要計量，因為具型別的決策不是散文。

我們自家的服務資料，取自我們自己的流量，而非供應商的基準測試；截至 2026-09-30 的七天內：p50 為 151 毫秒，p95 為 247 毫秒，每秒約 349 個輸出 token，錯誤率 0.49%，共服務 7,620 萬個 token。該期間每日 p50 依序為 175 → 170 → 163 → 161 → 170 → 147 → 143 毫秒，其中有一個真正的離群值——2026-09-28 的 p95 為 2,448 毫秒，它屬於這個序列，卻並非常態。

TypeSafe 的頭條宣稱——標明為供應商自身說法，未經獨立重現：「快 193.6 倍、便宜 444.6 倍」，並以註腳指向 System One 工作流程；一個實例：0.114 秒花費 $0.000081，而大型語言模型則是 8.566 秒花費 $0.013880；「每十億個輸入 token 42 美元」；以及「零幻覺」——這是一項關於信心的宣稱，而非零錯誤的證明——我們評測卡上的 0.49% 錯誤率才是誠實的制衡。TypeSafe 也明白表示，它無法證明其定價未受補貼，且其公開的評估一般而言是在該服務所在的西岸、以筆電執行。它自家的基準測試卡仍標示為待處理。

第三方儲存庫確實存在，而我們並不為其背書。

搜尋「jev github」最終會找到並非 TypeSafe 的儲存庫：包裝器、提示詞集合、轉接器實驗，以及任何新模型出現時都會冒出的熟悉「awesome」清單。它們不屬於廠商所發佈的內容，未經廠商審查，而且它們的星數衡量的是好奇心，而非正確性。它們或許有用；它們不是文件，而且其中沒有任何內容是關於 Jev 如何運作的陳述。

什麼會改變這個答案？

一份權重發布、一個已公開的架構，或是針對決策品質而非延遲的獨立評估。這三者中任何一個都會翻轉本頁的第一個字。在那之前，這個搜尋有一個穩定的答案，而其中值得付諸行動的部分是工具鏈：如果你正在對接的是型別化決策介面，一個可替換底層模型的 MIT 授權轉接器，就是你能重新檢視的決策與無法重新檢視的決策之間的差別。

Jev 1.13 已收錄在我們的目錄中，位於 typesafe/jev-1.13，與堆疊其餘部分使用同一個鍵，並透過專用的 systemone 端點路由，而非 chat-completions 形式。模型是封閉的，工具鏈則是開放的，而這兩部分現在都能從同一個地方存取。