Jev 1.13 的破綻所在：TypeSafe 自身的限制清單

Jev 1.13（typesafe/jev-1.13）於 2026-09-15 發布，這讓它落在最近七天之外已兩週，因此它的推出並非重點。有確切日期的事件是 2026-09-24：那一天 OrcaRouter 將 typesafe/jev-1.13加入其目錄，並為它開設了模型卡——這是 Jev 首次在第三方閘道中獲得服務支援；在此之前兩週，唯一能呼叫它的方式只有 TypeSafe 自家的端點。這在這裡之所以重要，有一個具體原因。Jev 的特別之處在於，其供應商公布了一份它各種失敗方式的清單，而一份只能閱讀的清單，遠比一個你實際能呼叫的模型更容易被略過。

本頁就是那份清單，只保留 TypeSafe 自己所述的內容，再加上運作限制與帳單。

TypeSafe 發佈自家的鋸齒狀清單

docs.typesafe.ai 刊載了一篇標題為 Jev 1.13 的鋸齒邊緣 的頁面。它明確適用於 jev-1.13，載有審閱日期 2026-09-17，並以供應商自己的說法開頭：「Jev 並不完美。以下是我們所知 jev-1.13 的一些鋸齒邊緣。其中許多將在後續版本中修正。」接著列出九個具名模式，每個都附有具體案例與「改為：」的補救方式。以下沒有任何內容出於推論，也沒有任何內容被軟化——措辭出自 TypeSafe，而當該公司提供自己的範例時，其中的數字也是他們的。

字面上解讀：它回答的是你寫下的問題

範圍界定詞、否定詞及隱含條件皆按字面解讀。問題是根據指令中的字詞來回答，「而人則可能讀出指令背後的意圖。」

供應商的診斷才是有用的部分：當你看著一個錯誤答案，卻發現自己在解釋你真正想表達的意思時，那個解釋就是指令中缺失的那一半。補救之道是：在指令中說明確切的條件，在評分標準中納入邊界案例，而在詮釋確實無可避免時，把問題拆成兩個字面問題，並在程式碼中將它們合併。

數學與數字：它不是計算機

TypeSafe 直白地表示要在程式碼中實作數學邏輯。其下存在三個具體的失敗：

• 計數並不可靠。這涵蓋單字中的字元數、段落中某個詞彙出現的次數，以及長清單中的項目數量。「模型辨識的是答案的形狀，而不是逐一計數；而且錯誤會隨著被計數對象的規模而增加。」廠商自己用來判斷到底該不該問的測試是：如果正規表達式或剖析器能找到單位，計數就該交給程式碼，模型加不了任何價值。

• 數值表示法的表現不如語意表示法。使用十六進位值詢問顏色，會比使用英文顏色名稱詢問相同問題更差；給定 RGB 三元組或十六進位值時，Jev 無法可靠判斷兩個值是否彼此接近。同樣的落差也出現在低階程式碼——組合語言或二進位編碼指令——相較於高階語言。在程式碼中進行轉換或分桶，並把模型保留給真正需要判斷的部分。

• 分數輸出並不帶有精確的量值。廠商表示，Jev 的分數等級在數值校準方面很薄弱。期望值可以用來測試某事物是否通過閾值；但不能藉由在兩個最接近的等級之間進行內插來重建該數值。這對一整類誤用——把分數當作量測值來解讀——是斷然不可接受的。

日期與時間：日期會以文字讀取，而非以數量讀取

排序兩個日期、測量它們之間的距離，或判斷其中一個是否落在某個時間窗口內，都是不可靠的，而且遇到混合格式、相對參照，以及像季度、結算窗口與應計期間這類領域界線時，還會進一步惡化。

建議的拆分方式很乾淨。擷取是一種判斷，所以交給模型來做。日期的每個組成部分都是一個小型的封閉集合——十二個月、三十一種可能的日、一段有界的年份範圍——這讓擷取變成從列舉選項中做選擇，而不是自由形式的解析，也讓你有個地方可以放入明確的「未說明」，這樣缺漏的部分會被回報，而不是被猜測。程式碼負責組裝這些部分，並掌管之後的一切，包括排序、持續時間、偏移量與星期幾。

間接表達：雙重否定與多餘的跳轉會犧牲準確性

帶有雙重否定或層層間接的指令，回答起來較不可靠。關於某項屬性的屬性問題，或需要經過好幾層推理的問題，會犧牲準確性。補救方法是盡可能直接地撰寫指令，並直接指名狀態中的相關部分，而不是描述它們。

充滿無關細節的龐大狀態會犧牲準確性

準確度會隨著狀態因與決策無關的內容而不斷增長而下降。無關的細節會成為干擾項，而龐大的狀態則讓人更難判斷是輸入的哪一部分產生了錯誤答案。TypeSafe 在結語中自己的提醒說得很直白：「Jev 會受到上下文腐化的影響，因此狀態中的無關素材會讓你的準確度付出代價。」

首先在程式碼中檢索並篩選，並僅傳送問題所需的欄位。若無法在請求之前進行篩選，廠商建議使用 noul 來篩選相關性，然後評判留下的結果。

狀態中的對抗性內容會改變答案

狀態即資料，而 jev-1.13 預設並不將其視為具敵意。被注入的指令、刻意誤導的框架，或為自身分類辯護的文字，都可能改變結果。這是唯一一種模式，供應商明確將修正定位為未來工作——「我們預期未來會改善這一點」——而在此期間的建議是：準則要明確，並在把整合推到眾多使用者面前之前，徹底測試該整合。

矛盾的指令和準則會讓它困惑。

當指令和準則要求不同的事情時，模型可能會感到困惑。TypeSafe 的例子是一個 noul，其中 true 對應到 no，false 對應到 yes，這比以一致方式表述的同一個問題表現更差。指令是將準則視為指令的延伸，並以一般人都能讀懂和理解的語言將兩者對齊。

它並不保證結構不變量

這是這種模式最可能弄壞一套建立於沒人寫下來的假設之上的系統。Jev 就一般意義而言極其一致——語意相似的輸入會產生數量上相似的輸出——但你可能預期會成立的那些結構性恆等式並不保證成立。廠商公布了兩個已詳細說明的案例。

• 一個問題，兩種問題類型。「客戶是在要求退款嗎？」以 noul 方式提問，以及以是/否選擇方式提問，在工單「我對合身度不滿意。我這裡有哪些選項？」上，會回傳 noul 為 0.22，以及選擇為是 0.01、否 0.99、信心度 0.97。這些都是同一個問題的答案。

• 一個問題及其否定。「客戶是在要求退款嗎？」以及「客戶是在要求退款以外的東西嗎？」，在工單上以兩個 nouls 提出：「同一筆訂單我被收了兩次費用。有人可以查一下嗎？」，分別回傳 0.72 和 0.47。它們總和為 1.19。

補救措施是可操作的，而非修辭性的：不要依賴預期的結構不變性，不要將針對某個 noul 調校出的閾值套用到某個選擇上，也不要要求模型在彼此分離的問題之間遵守算術恆等式。原因是，選擇是相對的——它確定的是哪個選項——而每個 noul 都是絕對的，且對所有這些選項都可能回傳低值。

生成：它沒有被訓練來寫作

jev-1.13 並未經過生成文字的訓練。你可以透過串接選擇來強制輸出，而 TypeSafe 直接表示這「不會運作良好，而且會非常慢」。就擷取而言，建議是用正規表達式或生成式模型抽出候選值，再讓 Jev 挑選正確的那一個；或者——當答案空間有限時——把擷取轉為對選項的選擇，而不是要求直接給出該值本身。

選擇題的 255 個選項上限

一道選擇題，一個 Jev 整合，並不是鋸齒狀的邊緣，而是產品的形狀。這些值得被區分出來，因為再多的提示詞工程也改變不了它們：

• 不生成文字。它回傳的是決策，不是文章。那是設計，不是缺陷。

• 沒有對話。Jev 是結構化決策模型，而非聊天模型。你傳送一個狀態和一組具名問題；它會針對每個問題回傳一個結構化答案。沒有需要納入設計考量的輪流發言機制。

• 不支援多模態輸入。輸入僅限文字——字串、JSON 物件或文字值陣列，不含影像、音訊或視訊。非文字素材必須先預處理成文字或結構化欄位，才能成為狀態的一部分。

• 非串流回應。只有單一結構化回應，沒有串流模式。這個之所以無關緊要，原因和值得說明它的理由相同：沒有東西可以串流。一個具型別的決策——帶有機率的布林值、從一組標籤中選出的一個標籤，或量表上的一個等級——並沒有任何值得逐 token 揭露的部分形式。

• 英文是主要語言。其他語言（包括 CJK 文字系統）雖會處理，但效果不盡相同。TypeSafe 的建議是：在依賴 Jev 處理非英文工作負載之前，先以自己的內容測試；並在路由時仰賴信心。

選擇題的 255 個選項上限

選擇題會從最多 255 個帶標籤的選項中挑選一個，而這個上限是硬性限制。TypeSafe 也用供應商自己的話解釋了為什麼大型選項集會跑得較慢：「對於基數較高的選擇，我們會採用兩階段系統，先獨立評分，再做出明確選擇，因此偶爾會變慢。」所以，大型選項集的延遲成本是結構性的，而非偶發性的，而且是供應商親口告訴你它從何而來。

我們針對 typesafe/jev-1.13 的自家服務視窗，於 2026-09-30 從模型卡讀取，顯示了在我們自家流量為期七天中的實際樣貌：中位數為 151 毫秒、p95 為 247 毫秒、每秒 348 個輸出 token，以及在已服務的 7,620 萬個 token 中錯誤率為 0.49%。每日中位數在一個狹窄區間內變動——從 2026-09-24 到 2026-09-30 分別為 175、170、163、161、170、147 與 143 毫秒——但 2026-09-28 的每日 p95 為 2,448 毫秒，約為其前後兩天的十倍。我們無法將那個單日離群值歸因於選項基數，也不會這麼做；誠實的解讀是尾端確實存在，而對延遲敏感的工作流程應針對尾端而非中位數來設計。

輸入的帳單就是整份帳單

在 Jev 上，輸出計費為零，這有時被解讀為「Jev 是免費的」。事實並非如此，因為輸入會按量計費，而大型狀態不會只因為輸出端什麼都沒有就免費。供應商價格為每百萬個輸入 token $0.042——TypeSafe 標示為每十億 $42 的正是同一個數字——而 OrcaRouter 以 0% 加成原樣傳遞供應商標價，因此供應商降價當天就會反映在這裡。

以下是使用供應商自己的費率，對實際形狀造成的影響：

• 一個小請求。一張 1,200 個 token 的支援工單，加上大約 300 個 token 的評分標準與問題，共計 1,500 個輸入 token，每次呼叫費用為 $0.000063。

• 大型請求。一份 55,000 詞元的合約，加上問題後讓請求達到 60,000 詞元，是 40 倍的詞元量，所以每次呼叫為 $0.0025——每次呼叫仍然很小，但對於同一個答案而言，比第一個案例大了 40 倍。

• 以用量計。每次呼叫 60,000 個 token，每天 10,000 次呼叫，就是每天 6 億個輸入 token，也就是十億的 0.6 倍，所以每天 $25.20，30 天的一個月約 $756。同樣的呼叫次數，若是用於 1,500 個 token 的要求，每天是 1,500 萬個 token：每天 $0.63，每月約 $18.90。

最後兩行之間的落差不是定價花招，而是計量狀態。這就是為什麼 context-rot 區段中的過濾建議不僅是準確度措施——精簡狀態也是唯一能讓帳單變動的槓桿。

已公佈的操作限制，讓大家不必猜測

TypeSafe 的模型頁面會公布具體數字，因此規劃者不必自行推斷這些數字：

• 輸送量與速率。根據 docs.typesafe.ai/models.md，每秒 100K 個 token 以及每秒 40 個請求。超過任一限制的請求會傳回 429 Too Many Requests；廠商的用戶端 SDK 預設會以退避方式重試，並且在回應帶有 retry-after 標頭時遵循該標頭。

• 限制會變動。供應商表示，速率限制會動態調整，且隨著容量上線，「可未經通知即變更」；自訂與企業方案則可提供更高的限制。請把 100K/40 當作目前的數字，而非合約承諾。

• 上下文預算。請求預算大約是 64,000 個詞元，涵蓋合併的狀態與所有問題——模型卡公布的是 65,536——而廠商的模型頁面另行將狀態加上單一最長問題的上限設為 32,000 個詞元。第二個數字是狀態預算，不是第一個數字的較小版本；兩者都是真實的，且彼此並不矛盾。

• 別名會在你腳下變動。jev-latest 和 jev-preview 目前都指向 jev-1.13.0，而廠商表示目前沒有可用的預覽組建。別名會在新版本發布時隨之變動，因此如果你已針對特定版本調校過信心閾值，請固定使用帶版本編號的 ID，並依自己的步調再行升級。

您的使用案例需要呈現什麼樣子

從頭到尾讀完，供應商自己的清單所描述的是一個狹窄但有用的工具。當判斷是有界的，而算術不是模型的工作時，Jev 才適合：這筆記錄是否符合政策、這四十個標籤中哪一個適用、這在五級量表上讀起來如何——在你自行篩選過的狀態上提問，並搭配字面指示以及與之一致的準則，而且每一個計數、比較和日期測量都在其周邊以程式碼完成。

當任務需要計數、排序或日期運算時，當它需要多步推理時，當輸入材料不是文字時，當狀態是一座乾草堆而問題是一根針時，或當來源的任何方面帶有敵意時，它就不適合。這些不是提示中的缺口；它們是模型無法運作的地方，而 TypeSafe 正是提出此說法的一方。

在你把它接上之前，還有一件事值得知道：Jev 的呼叫方式有個必須坦白說明的差異。在 OrcaRouter 上，型錄是透過專用的 systemone 端點 POST /v1/systemone 來觸及 Jev，而不是透過 OpenAI chat-completions 的形式。這是你在撰寫請求時一項真實的差異，也是舊有說法「Jev 說自己的請求格式」的正確版本。其餘一切都與帳戶上任何其他模型相同——一把金鑰通行 200+ 個模型，我們不收取按 token 計費的費用，且若某條路由出問題會自動容錯移轉。TypeSafe 於 2026-09-21 移除了等候名單；供應商自家的首頁仍將 Jev 描述為早期存取，而其自家的基準測試頁面仍標示為待定，因此本頁上唯一的效能數據，是我們自己測得的服務數據，以及供應商自家的說法（已標示為其所述）。