什麼是 TypeSafe AI？Jev 1.13 背後的實驗室做的是決策，而非句子

TypeSafe AI 是舊金山的一間小型實驗室，他們販售一款寫不出句子的模型，而 Jev 1.13（typesafe/jev-1.13）就是這裡所說的模型。它接收一段狀態——一封電子郵件、一行日誌、一張支援單、一個 JSON blob——再加上一組具名問題，然後針對每個問題回傳一個帶型別的答案，每個答案都附有自己的信心值。沒有散文、沒有程式碼、沒有解釋，也沒有聊天框。模型本身於 2026-09-15 推出，所以它並不新，這裡也沒有任何東西是發表故事：這個頁面之所以存在，是因為一項較小、有明確日期可考的變動。在 2026-09-24，OrcaRouter 將 typesafe/jev-1.13 加入其目錄，並在自己的網址開啟該模型卡，這是 Jev 首次能透過第三方閘道呼叫，而不只是透過 TypeSafe 自家的端點。那就是這起事件，截至 2026-09-30 已發生六天，也正是為什麼一位尚未與 TypeSafe 簽約的讀者，現在可以把一個 System One 模型放到與它原本就設計要並列運作的生成式模型同一把金鑰上。這個頁面上的其他一切，都是關於打造它的那間公司的背景說明。

對時間點的誠實說明，因為這關係到其中有多少已經過驗證：Jev 在兩週多前推出，並自 2026-09-21 起全面開放使用，當時 TypeSafe 移除了等候名單。落在這七天窗口內的是路由變更，而不是模型。如果你來這裡是想看發表評測，那發表早已發生，而且已有幾篇其他文章報導過了。

一個有宣言但沒有架構圖的公司頁面

TypeSafe 在其自家的中繼描述中，將自己描述為「一座為自動化打造機器原生智慧基礎設施的 AI 實驗室」，其系統「旨在於軟體內做出決策」。其首頁標示為 Version 0.01，頁尾寫著「Made in SF」。有一份宣言主張，通往 AI 形塑經濟轉變的最短路徑，在於讓智慧變得可組合，使軟體能像呼叫函式那樣調用語意判斷；該公司自己對其計畫的總結是：先推出機器原生可組合 AI 的形式，再讓它可靠到足以實現真正的自動化，然後提供穩定到足以在其上疊加建構的更高階抽象。其標語是「我們打造的是 prod，不是 God。」團隊頁列出三位創辦人——Diogo Almeida 任執行長，Sasha Sheng 任營運長，Erik Gafni 任技術長。這就是該公司對自身所說明的全部：一個定位、一個產品、三個名字，以及關於公司本身毫無數字。

網站沒有提供的，正是工程師評估一項新依賴時最先會想找的東西。沒有架構頁面，沒有參數量，沒有訓練算力揭露，也沒有學術意義上的模型卡。TypeSafe 自家的基準測試儀表板仍標示為待定。對一家以可靠性為賣點的公司而言，資訊揭露面很單薄，而這是關於已發布內容的事實，並非對其隱瞞了什麼的指控。

System One：這個類別，以及為何借用這個名稱

Jev 是 TypeSafe 所謂 System One 模型中的第一款。這個名稱源自 Daniel Kahneman 對於快速、直覺的 System 1 思考與緩慢、審慎的 System 2 推理所作的區分，而該公司的發布文章也直接這麼說——它同時承認「System 1 思考」帶有容易出錯的言外之意，並主張這些模型可以變得比替代方案更可靠。TypeSafe 並未創造這個詞，也不擁有它。

這個類別的實務內容是一種刻意的分工：一個負責決策的模型，和一個負責撰寫的模型。你應該把算術、日期排序、計數和字串比較留在一般程式碼中，因為它們在那裡是精確的，並將語意判斷交給 Jev。它能回答的是三種問題類型：

• noul — 真/假判斷，以校準過的機率回傳

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

• 分數 — 依有序尺度評分；我們的卡片公佈 2-10 個等級，而 TypeSafe 自己的文件顯示一個以 0 為起始索引的範例，因此請將廠商的等級視為定義，並將 2-10 視為卡片所公佈的內容

每個問題都有各自的指示，而就選擇與評分而言，也有各自的標準。超過約 64K 輸入權杖的要求會在送達模型之前遭到拒絕，而且回應不會以串流方式傳送。廠商另外記載狀態預算——狀態加上單一最長問題——為 32K 權杖，這個數字比卡上所寫的 65,536 權杖上下文更窄，且並不與之矛盾。

他們的論點，用他們自己的話來說

TypeSafe 對這個論點的陳述比任何摘要都更好，所以以下逐字引用：「LLMs 為人產出詞語。Jev 產出的是帶型別的決策，更像是程式碼：可靠、快速、自我一致，而且型別安全。」其背後的訓練方法也是他們的，而這個術語值得精確標明出處，正因為它在別處被採用，彷彿它是通用詞彙。TypeSafe 稱之為 Reinforcement Learning for Calibrated Decisions，或稱 RLCD，並將其與 RLHF 和 RLVR 對比：後兩者最佳化的是人類偏好或可經程式驗證的獎勵，而 RLCD 的目標，用該公司的說法，是「在 System One 任務上，以知識論上誠實的機率來作答」。請將 RLCD 視為 TypeSafe 自創的術語，而不是文獻中既有的縮寫。

他們主打的那組數字，以及是誰選擇了工作負載。

首頁最顯眼的是「快 193.6 倍，便宜 444.6 倍」，並以註腳指向 System One 任務的工作流程。其下方則是一個實例：TypeSafe AI 為 $0.000081、0.114 秒，對照 LLM 的 $0.013880、8.566 秒。再往下是「每十億個輸入 token 為 $42。輸入價格比 Claude Fable 5.1 低 238 倍。」還有一個標題為「零幻覺」的段落；仔細檢視會發現，那是關於信心估計的主張，而不是零錯誤的證明：每個 Jev 決策都帶有信心估計，因此軟體可以在信心高時採取行動，並在信心不高時升級處理。這四項全都是 TypeSafe 的數字，且是在 TypeSafe 自行選擇的工作負載上，沒有任何一項經過獨立重現。發布貼文本身表示，團隊預期其 193.6 倍與 444.6 倍會落在真實世界增益的高標，並指出這些工作流程是由自家能力團隊打造，參考答案則由競爭對手的模型產生。我們自己在同一模型上的七天服務資料顯示，錯誤率為 0.49%；這是在不同工作負載上的不同測量，也是把「零」解讀為絕對值時，誠實的平衡參照。

他們尚未發布的內容

Jev 的架構、參數量、訓練算力與權重皆未公開，該公司 GitHub 組織中也沒有權重儲存庫。於 2026-09-30 查核時，該組織有十一個公開儲存庫；其中較具實質份量的是工具類，全採 MIT 或 Apache-2.0 授權——一個 agent-skills 儲存庫、一套 Python SDK、一套 TypeScript SDK、一個由其他 LLM API 支援的 drop-in 用戶端轉接器、一組 Dagger 模組集、一些已發布的工作流程評估程式碼、一個 n8n 節點，以及該組織自家的網站。星號數與推送日期會變動，所以請在當天自行查看，而不是依這頁的記錄。

十一者中有三個是無關專案的 fork：vLLM、LLaDA，以及一個 ClickHouse Cloud 的 Pulumi provider。它們是他人作品的 fork，對 Jev 如何建構毫無說明——尤其是對 Jev 基於擴散這一點毫無說明。對於 Jev 是否開源，一句話的答案是：工具是開放的，模型則不是。

他們自己所承認的

發布貼文中的兩則坦承，比大多數廠商的但書更有價值，因為它們點出了證據薄弱的確切環節。關於價格：「我們無法證明它沒有受到補貼；我們需要長期資料來證明我們定價的永續性（我們預期價格會下降，而不是上升）。」關於速度：「我們公布的評測通常是從我們在西岸的筆電上執行（這也是我們服務目前的所在地）。」還有第三則，對任何要在其上開發的人更有用：對於高基數的選擇集合，Jev 執行一套兩階段系統，先獨立評分，再做出明確選擇，「因此偶爾會變慢」。這是廠商在解釋為什麼延遲在不同問題類型之間並非一致，而這種事你通常得從支援討論串才會知道。

截至今日，你實際上可以在哪裡打電話給它

透過 TypeSafe 自家的 API，該模型已正式開放，而首頁仍沿用供應商自己的「early access」說法——這個措辭目前仍適用，值得保留；至於「waitlisted」則已淘汰：文件公布了具體的運作限制（每秒 100K tokens、每秒 40 次請求，超過任一項就會出現 429，並由 SDK 進行退避），完全沒有等候名單的字眼。另外，自 2026-09-24 起，也可透過 OrcaRouter 使用。

我們所提供的內容值得精確說明，因為呼叫形式正是差異所在。目錄項目為 typesafe/jev-1.13，名稱為 TypeSafe: Jev 1.13，支援的端點類型為「systemone」——因此它是透過 POST /v1/systemone 觸及，而非 OpenAI 聊天完成形式；非串流，輸入文字並輸出結構化 JSON，合併狀態與問題後最多約 64K 輸入 token。輸入為每百萬 token $0.042，輸出計費為零，因為沒有輸出 token 需要計量：具型別的決策並非散文。這是供應商定價原樣傳遞、0% 加成，適用於與目錄中其他 200+ 個模型相同的金鑰——一個 API 對應 200+ 個模型，0% 加成（供應商定價原樣傳遞，因此供應商降價當天這裡就生效）。如果你閱讀 TypeSafe AI 的原因是，想在把正式生產路徑交付給它之前，先了解 Jev 的校準在你自己的資料上是否站得住腳，那麼將它與你已經信任的生成式模型並行運行，是找出答案的便宜方式；當 Jev 回傳的信心偏低時，容錯移轉到那個模型，是將其推出上線的便宜方式。

我們自己截至 2026-09-30 該區間的七日服務數據，這些是我們從自家流量得出的數字，而非供應商的基準：p50 151 毫秒、p95 247 毫秒、每秒約 349 個輸出 token、0.49% 錯誤率，以及 76.2M 個已服務 token。該區間每日的 p50 分別為 175、170、163、161、170、147、143 毫秒，因此中位數一直在小幅下滑。系列中的某一天，09-28，p95 為 2,448 毫秒——這是資料中真正的離群值，不是常態，也不是用來規劃延遲預算的數字。這些數據每日滾動更新；卡片是資料來源。

根據 TypeSafe，模型較弱的地方

廠商為 Jev 1.13 發布了一份鋸齒狀落差頁面，最後審閱於 2026-09-17，其中比多數發布資料更坦率地列出失效模式。在該模型上開發之前，這正是該讀的頁面，而它自己的清單如下。Jev 回答的是你寫下的問題，而不是你真正想問的問題，因此範圍界定詞、否定詞和隱含條件都必須明確寫出。它不是計算器：它在數學問題上的表現比語意問題差。它將日期讀作文本，而非有序量值，因此排序、間隔和視窗歸屬都不可靠，而且混用格式時更糟。雙重否定與多跳間接推論會損害準確度。當狀態因無關細節而增長時，準確度會下降——頁面說它「會受到脈絡腐化影響」——因此先在程式碼中過濾才是解決辦法。狀態預設被視為資料，而非敵意內容，因此注入的指令可能左右答案。指令與準則不相符會使它混淆。結構不變量不受保證：noul 與 choice 輸出不必彼此對應，而一個問題加上其否定也不必加總為一，因此不應在兩者之間移植閾值。而且它未經訓練來生成文字——強迫它透過連鎖選擇來生成「效果不會好，而且會非常慢」。

路由變更進入第六天，如何解讀 TypeSafe AI

該公司提出了一項強烈、具體且可證偽的主張：在需要的是判斷、而非長篇大論的那一類工作上，一個窄域決策模型可以比通用模型更快、更便宜，也更值得信賴。這項主張看似合理，也有一部分能自我佐證——那些信心估計確實是實質的設計差異，價格是真的，而我們在自己流量上量測到的延遲，也與供應商所稱的處於同一量級。缺的是能讓外部人士查核其餘部分的那一塊：沒有架構、沒有參數、沒有權重、沒有獨立基準測試，還有一個該公司自己都說無法證明能否持續的價格。失效模式有被記錄下來，這比大多數實驗室做得更多，也是認真看待這個模型的唯一最佳理由。

如果你正在決定是否值得關注：在你已經標註好的輸入上執行 Jev，但把標籤隱藏起來，然後看看它的信心數值是否能區分出它答對的案例與答錯的案例。那項測試幾乎不花成本，每百萬個輸入 token 只要 $0.042，而且它是唯一能回答你真正想問的問題的方法。如果你正在決定是否要信任這家公司：揭露資訊就是如此，而誠實的答案是，目前的證據就是供應商的說法，加上你自己所產生的一切。