「System One」作為模型類別：Jev 1.13 在其中所處的位置

「System One」是 TypeSafe 用來指稱其將一個負責決策的模型與一個負責撰寫的模型分拆開來的類別術語，而 Jev 1.13（typesafe/jev-1.13）是它的第一個成員——一個回傳具型別答案而非句子的模型。這不是新模型。TypeSafe 於 2026-09-15 推出 Jev，而本頁並非發布文章：該模型已推出十五天，超出本部落格所關注的七天窗口。在這個窗口內發生的事，是 OrcaRouter 於 2026-09-24 將該模型加入其目錄，並在 https://www.orcarouter.ai/models/typesafe/jev-1.13 開設 Jev 1.13 的模型卡——這是它首次可透過第三方閘道呼叫，而不僅限於透過 TypeSafe 自家的端點。這個類別概念是本書頁存在的原因；而服務方式的變動則是它標註為今日日期的原因。

這個類別的白話版：LLM 被問一個問題，然後寫出讓人閱讀的答案。系統一模型被問一個問題，然後回傳一個供程式分支判斷的值。TypeSafe 自己的說法是：「LLM 為人們產出詞語」，而「Jev 產出有型別的決策，更像程式碼：可靠、快速、自洽，且型別安全。」那句話把整個類別濃縮成一個子句，值得慢慢拆解，因為這四個形容詞承擔的工作量不同，而其中一個做得比其他的更多。

「更像程式碼」實際上主張了什麼

依序看待這四項主張，因為它們並不是「這樣更好」的四種重述。

• 可靠 — 輸出形狀會事先固定。你宣告問題；答案只可能以你允許的其中一個值回傳。TypeSafe 明言「模型永遠不會產生型別錯誤」，並指出這是他們的主張中，唯一「在數學上不可能」用反例否證的一項，因為不在你宣告集合中的值，不是模型能輸出的值。

• 快速——所有答案都是在單次傳遞中產生，而非逐個 token 依序生成。TypeSafe 的發布貼文將其描述為：「Jev 會並行輸出所有機率，而不是以自迴歸方式逐 token 生成。」在我們自己截至 2026-09-30 的七天服務窗口內，typesafe/jev-1.13 產生首個 token 的時間中位數為 151 毫秒，p95 為 247 毫秒。

• 自我一致——相同狀態搭配相同問題，往往會產生相同答案。用程式設計來類比能讓這件事變得易懂，但類比也正是在此處不再構成證明：編譯器的確定性是其構造本身的性質，而這裡談的卻是對某種行為的斷言。我們自己的量測才是對此事最誠實的解讀——在同一個七日區間內，我們 playground 流量上的錯誤率為 0.49%，所以它的自我一致，是像一個好函式那樣自我一致，而不是像算術那樣自我一致。

• 型別安全——而這是當中最具份量的一點。這裡的「型別安全」不是一個形容品質的形容詞；它是在說明模型相對於型別檢查器所處的位置。在一般的生成式流程中，型別系統是在模型完成之後才開始：模型寫出文字，解析器猜測其結構，驗證器進行檢查，而失敗路徑則處理猜錯的情況。System One 模型把型別宣告移到呼叫之前。我們這張卡所記載的三個基本原語就是這套型別系統：noul，一種以經過校準的機率回傳的真／假判斷；choice，從最多 255 個帶標籤的選項中挑出一個標籤；以及 score，在 2 到 10 個層級的有序量表上給出的評分。你挑選原語，提供標籤或準則，而回傳的值就是從該集合中取出。

TypeSafe 確實公布了自家文件與我們文件之間的一項差異，這值得指出而非解決：供應商的文件展示了一個以零為起始索引的 Score 範例，而我們的卡片則記載該量表為 2 到 10 個層級。兩者描述的是同一個基本類型。如果你正在建立閾值，請閱讀供應商的頁面，以確認你的 SDK 所採用的確切索引方式。

兩種不再存在的失效模式

「不使用散文」所帶來的耐人尋味結果並非美學上的。而是在於：主導正式生產生成式管線的兩項失效，在這項設計中並不存在，而不是由它加以緩解。

格式漂移是最先出現的問題。一個被要求回傳 JSON 的 LLM，大多數時候會回傳 JSON，其餘時候則回傳某種類似 JSON 的東西——結尾多出來的註解、Markdown 圍籬、被改名成同義詞的欄位、schema 要求字串時卻冒出巢狀物件。提示詞層級的修正手段（更強硬的指示、少樣本範例、在系統訊息中放入 schema）都只是在試圖維持一個模型隨時可以拋棄的形狀，因為那個形狀是請求，而不是約束。TypeSafe 的框架把這個對比說得很明白：使用字串時，「可能的輸出與結構」是被請求的，回應「需要被解析＋驗證」，而且「AI 永遠有可能脫軌」。當可能的輸出被事先宣告，漂移就無處可去。

無法解析的輸出是第二種，而它其實是同一種失敗發生在更糟的時刻——不是某個欄位回來時有點不對，而是解析器根本讀不懂的回應，還在工作流程中最不方便的時點出現。會輸出具型別值的模型，就沒有這種狀態。

這是一個結構性論證，而且應當如此表述。它完全沒有說明個別答案是否正確——選擇題可能選錯標籤，而 noul 可能回傳true，而且信心十足，即使誠實答案是假的。消失的是解析器原本會抓到的那一類失敗。這是一種真實且有用的縮減，並不等同於「答案正確」這個主張。

為什麼價格是一種形狀，而不是折扣

這個模型每百萬個輸入 token 定價 $0.042，輸出則以 $0 計費；而那個零並不是費率，它是模型只吐出三個 token 答案、沒有可供計量的輸出量所形成的副產品，因此按輸出計費根本無處可附著。計費型態就是一筆按輸入 token 計收的費用，加上一個決定。我們的目錄以 0% 加成原樣轉嫁供應商的牌價，所以 $0.042 是 TypeSafe 的數字，而不是我們自訂的數字；而供應商一旦調價，當天就會生效。

把這兩種形態並排比較，差異不是百分比之別。生成式管線的成本，取決於模型說了多少：同樣的決策，冗長的答案就是比簡潔的答案更貴；而思維鏈推理模型會為它在回答前思考所消耗的 token 計費，無論答案是否因此變得更好。System One 呼叫的成本，則取決於你給它看了多少——也就是狀態與問題。對著一份長文件問一個問題，你就要為整份文件付費。把四十個問題打包，對著同一份狀態提問（我們卡片上的輸入預算是合計狀態與問題共 65,536 個 token，大約 64K；如果你在早先的 OrcaRouter 文章裡看過「大約 32,000 個 token」這個數字，那只是狀態預算本身，不是另一個相互競爭的總量），你只需為那份文件付一次費，就能拿回四十個決策。

這就是為什麼對這類系統而言，正確的單位是每次決策成本，而非每個詞元成本——也是為什麼其計量走向與大多數團隊的預期正好相反。典型的生成式成本削減做法是「讓模型少說一點」。但在這裡，根本沒有什麼可少說的。

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 倍」。這一切都要當成廠商的說法，而不是實測結果：發布貼文坦承「我們公布的評估通常是從西岸的筆電上跑出來的」，也承認「我們無法證明這不是靠補貼；我們需要長期表現來證明我們定價的永續性（我們預期價格會下降，而非上漲）」。這兩項讓步都是廠商自己說的，而它們正是看待頁面上每一個倍數時應有的框架。

校準是這個想法的後半部分。

如果這個類別只是「結構化輸出」，那它描述的就會是多了幾道步驟的函式呼叫。讓它自成一個類別的關鍵在於，每個答案都附帶一個機率，而這些機率就是訓練目標。TypeSafe 將這個方法稱為「校準決策強化學習」（Reinforcement Learning for Calibrated Decisions，RLCD）——這是他們自己的稱法，不是通用縮寫——而發布文章中的比較表將它與 RLHF 和 RLVR 並列：RLHF 最佳化的是人類評分者偏好的內容，RLVR 最佳化的是可透過程式檢查的輸出，RLCD 最佳化的則是「在系統一任務上給出知識論上誠實的機率答案」。

實務上的差異在於這個機率是用來做什麼的。在生成式流程中，信心估計是第二次生成：你問模型它有多確定，它寫出一個數字，而這本身也是帶有相同失效模式的行文。在這裡，機率與決策在同一輪中一起回傳，而它就是妳用來分支的依據。TypeSafe 自己對這種效益的說法是，一個能在 95% 的情況下完成任務、卻「不會說出自己什麼時候落在那 5%」的模型，無法用來自動化該任務；而信心值提供了一個放置升級處理的位置，無論是升級給真人，還是升級給推理模型。

TypeSafe 的首頁將此表述為「零幻覺」，並解釋每一項決策都帶有信賴度估計，讓軟體能在「信賴度高時採取行動，信賴度不高時升級處理」。請仔細解讀這句話：這是一項關於信賴度估計的主張，而不是聲稱任何答案永遠不會出錯。我們自己的卡片則是制衡的一方——在截至 2026-09-30 的七天內，錯誤率為 0.49%，這是根據我們自己的流量、由我們自行測量。那個數字是滾動視窗，不是固定測試集：幾天前同一個視窗的讀數是 0.57%，而且它還會再變動。

系統一與系統二並列之處

「快／慢」這套詞彙的歷史遠早於 TypeSafe。它出自康納曼的快思慢想，而且在 TypeSafe 出現之前許多年，就已被 AI 研究者借用——早在 TypeSafe 存在以前，「系統二」這個標籤就已套用在思維鏈與審慎推理模型上，而 TypeSafe 並未宣稱自己創造了這兩個詞。他們所做的，是把這組區分套用到產品界線上，而非提示模式上。

• 系統二推理模型在回答前會花費更多算力，並在需要這種能力的問題上表現得更好。它的輸出仍然是自然語言文字，而額外的算力會以輸出 token 計費。

• 就 TypeSafe 的定義而言，System One 模型不會為了答得更好而思考更久。它一次就回答，而它為了速度所放棄的，是產出除了具型別的值以外任何東西的能力。

• 這兩者在工作流程中是互補的，而不是在比較中相互競爭。System One 呼叫負責處理必須快速、低成本且易於理解的決策；推理模型則取得信心分數標示為不確定的案例。具型別的輸出正是讓交接保持乾淨的關鍵——你傳遞到下一階段的是值和機率，而不是一句需要重新解析的句子。

詞彙變得模糊的地方，在於把「System One model」當成其他廠商已經採用的既定類別。沒有證據支持這點，而本頁不應被解讀為如此宣稱。TypeSafe 用這個詞來指稱自家的一類模型；我們自己卡片中的免責聲明也以省略的方式表達了同一件事，只列出單一模型的單一端點類型。如果另一個實驗室開始用這個詞來指稱相同架構，那會是值得報導的事實，而且需要由他們自己的說法來報導。

我們的卡片也把鋸齒狀一併列為誠實界線的一部分，而非視為意外：九種具名的失敗模式。字面解讀與間接指涉這兩個條目，是直接從「更像程式碼」的類比衍生而來——一個回答你寫下的問題、而非你真正想問的問題的模型，就像一個完全照程式碼所述執行的函式。計數條目則不然。一個「認得答案的形狀，而不是逐項計數」的模型，根本不像程式碼；這也是為什麼 TypeSafe 自己的建議是在程式碼中計數，而在確實需要判斷時，每個項目只問一個問題，然後自己把答案加總。

兩個限制，塑造的是設計，而非分數

兩者都源自同一處：沒有字串，就沒有東西可以串流，也沒有東西可以分片傳送。

• 非串流——第一個輸出就是完成後的答案，所以 System One 呼叫是單一回應，而不是串流。問題不在於它能不能串流，而在於什麼會串流。

• 一種請求形式——模型是透過我們目錄上的 POST /v1/systemone 提供服務，而不是 chat-completions 形式，而這正是它「自有一套請求形式」這個舊說法的忠實版本。這在呼叫方式上是真正的差異：輸入的是狀態物件與具名問題對應表；輸出的是每個問題的結構化答案。你需要為它寫一個對應器，而由於輸出有型別，這個對應器就是整個整合——底下沒有防禦性解析層。

上線壓測前值得知道的一件事：延遲在不同題型之間並不是固定不變的。TypeSafe 用他們自己的說法解釋了原因——「對於基數較高的選項，我們採用兩階段系統，先各自評分，再做出明確選擇，因此偶爾會出現變慢的情況。」一個四選項的路由決策和一個兩百選項的分類，在紙上看似是同一個基本操作，在實務上的工作量卻大不相同。截至 2026-09-30 的這七天，我們的每日中位數分別為 175、170、163、161、170、147、143 毫秒。這個序列中有一天，也就是 2026-09-28，其 p95 為 2,448 毫秒——這是一個真實的單日離群值，它如實地存在於這個序列中，但並不是這個服務的典型樣貌。

在第一次整合之前，另一件需要知道的事，就是你正在連接什麼。Jev 周邊的工具是開源的，採用 MIT 與 Apache-2.0 授權——Python 與 JavaScript SDK、一個以一般 LLM API 為後端、對外呈現相同 client 的轉接器、workflow-evals 程式碼，以及一組 agent 技能，全都放在 TypeSafe 的公開儲存庫中，其星標數與推送日期最近才在 2026-09-26 與 2026-09-29 有所變動。模型則不是。並沒有權重儲存庫：Jev 的架構、參數量、訓練算力與權重都未公開，而查證此事的讀者不應被該組織中那三個屬於無關專案分叉的儲存庫所誤導——一個 vLLM 分叉、一份 2025 年的擴散語言模型發布，以及一個 Pulumi 提供者。它們全都沒有說明 Jev 是如何建構的。一句話的答案就是：工具是開放的，而模型不是。

今天就執行它，以及這對讀者而言有何改變

Jev 1.13 已在 OrcaRouter 上以 typesafe/jev-1.13 形式提供，可透過與其他 200 多個模型相同的金鑰存取，並以供應商的定價清單價格零加成轉嫁。對於一篇關於某個類別的頁面來說，這點的實際價值有限，但值得精確說明：試用 System One 模型不再需要為了一個你可能還不知道自己想要的模型，另外註冊帳號、另外申請金鑰，還要另外處理一張發票。它與同一工作流程的生成端並列——分類器與寫作者共用同一組憑證、位於同一處，還能顯示你實際呼叫的次數。

這裡沒有任何內容會改變這個模型的本質。它於 2026-09-15 推出，而 TypeSafe 仍將其描述為搶先體驗；自那之後，它的本質並未改變。2026-09-24 改變的是，讀者現在不必先承諾建立第二個供應商關係，就能了解它在實務上會讓他們付出多少成本。如果你一直在等待看看這個類別是否值得做一個原型，那正是已經改變的地方。