Där Jev 1.13 brister: TypeSafe:s egen lista över begränsningar

Jev 1.13 (typesafe/jev-1.13) släpptes den 15 september 2026, vilket placerar det två veckor utanför de senaste sju dagarna, så dess lansering är inte nyheten. Den daterade händelsen är den 24 september 2026: det är dagen då OrcaRouter lade till typesafe/jev-1.13 i sin katalog och öppnade ett modellkort för det – det första serving-stödet för Jev i en tredjepartsgateway, efter en tvåveckorsperiod då det enda sättet att anropa det var TypeSafes egen slutpunkt. Det spelar roll här av en specifik anledning. Jev är ovanligt genom att dess leverantör publicerar en lista över sätten det misslyckas på, och en lista man bara kan läsa är mycket lättare att hoppa över än en modell man faktiskt kan anropa.

Den här sidan är den listan, begränsad till vad TypeSafe självt säger, samt driftsgränserna och notan.

TypeSafe publicerar sin egen ojämnhetslista

docs.typesafe.ai har en sida med titeln Jev 1.13 ojämnheter. Den gäller uttryckligen jev-1.13, har ett granskningsdatum den 2026-09-17 och inleds med leverantörens egen formulering: "Jev är inte perfekt. Här är några ojämna kanter som vi känner till i jev-1.13. Många av dessa kommer att åtgärdas i senare versioner." Därefter följer nio namngivna lägen, vart och ett med ett konkret fall och åtgärden "I stället:". Inget nedan är antaget och inget är förmildrat – ordalydelsen är TypeSafe:s, och där företaget ger sitt eget exempel är siffrorna i det deras.

Bokstavlig läsning: det svarar på frågan du skrev

Avgränsande ord, negationer och underförstådda villkor läses bokstavligt. En fråga besvaras utifrån orden i instruktionen, "medan en person kanske skulle ha läst avsikten bakom instruktionerna."

Leverantörens diagnostik är den användbara delen: när du tittar på ett felaktigt svar och kommer på dig själv med att förklara vad du egentligen menade, är den förklaringen den saknade halvan av instruktionen. Åtgärderna är att ange det exakta villkoret i instruktionerna, lägga gränsfallen i kriterierna och, där tolkning är genuint oundviklig, dela upp frågan i två bokstavliga frågor och kombinera dem i kod.

Matematik och siffror: det är inte en miniräknare

TypeSafe säger rent ut att implementera matematisk logik i kod. Tre specifika fel ligger bakom det:

• Att räkna är opålitligt. Detta omfattar tecken i ett ord, förekomster av en term i ett textavsnitt och poster i en lång lista. "Modellen känner igen formen på ett svar i stället för att räkna, och felet växer med storleken på det som räknas." Leverantörens eget test för huruvida man alls ska fråga: om ett reguljärt uttryck eller en parser kan hitta enheten, hör räkningen hemma i kod och modellen tillför ingenting.

• Numeriska representationer presterar sämre än semantiska. Frågor om att använda hexvärden är sämre än samma frågor med engelska färgnamn; givet RGB-tripplar eller hex kan Jevic inte bedöma huruvida två värden ligger nära varandra. Samma gap syns i lågnivåkod – assembly eller binärkodade instruktioner – jämfört med högnivåspråk. Konvertera eller gruppera i kod, och behåll modellen för den del som verkligen är en bedömning.

• Poängutdata förmedlar inte exakta magnituder. Leverantören anger att Jevs poängnivåer är svaga i numerisk kalibrering. En förväntan kan användas för att testa om något passerar ett tröskelvärde; den kan inte användas för att rekonstruera talet genom att interpolera mellan de två närmaste nivåerna. Det är ett bestämt nej för en hel klass av felanvändning — att läsa en poäng som en mätning.

Datum och tid: datum läses som text, inte som kvantiteter

Att ordna två datum, mäta avståndet mellan dem eller avgöra huruvida ett av dem faller inom ett fönster är opålitligt, och det försämras ytterligare vid blandade format, relativa referenser och domängränser såsom kvartal, avvecklingsfönster och periodiseringsperioder.

Den rekommenderade uppdelningen är ren. Extraktion är en bedömningsfråga, så låt modellen sköta den. Varje komponent i ett datum är en liten sluten mängd – tolv månader, trettioen möjliga dagar, ett begränsat antal år – vilket gör extraktionen till ett val bland uppräknade alternativ i stället för fri parsning, och ger dig en plats att lägga ett uttryckligt ”inte angivet”, så att en saknad del rapporteras i stället för att gissas. Koden sätter samman delarna och äger allt därefter, inklusive ordning, varaktighet, offset och veckodag.

Indirektion: dubbla negationer och extra hopp kostar noggrannhet

Instruktioner som innehåller dubbla negationer eller flera lager av indirektion besvaras mindre tillförlitligt. En fråga om en egenskap hos en egenskap, eller en som kräver flera steg av resonemang, kostar noggrannhet. Botemedlet är att skriva instruktioner så direkt som möjligt och att namnge de relevanta delarna av tillståndet i stället för att beskriva dem.

Ett stort tillstånd fullt av irrelevanta detaljer kostar noggrannhet

Noggrannheten sjunker i takt med att tillståndet växer med innehåll som inte har med beslutet att göra. Orelaterade detaljer fungerar som en distraktion, och ett stort tillstånd gör det svårare att avgöra vilken del av indata som gav ett felaktigt svar. TypeSafes egen påminnelse i slutnoten är krass: "Jev lider av kontextröta, så orelaterat material i tillståndet kostar dig noggrannhet."

Hämta och filtrera i koden först, och skicka endast de fält som frågan behöver. När filtrering före begäran inte är möjlig föreslår leverantören att man använder en noul för att filtrera på relevans och sedan bedömer de kvarvarande.

Adversariellt innehåll i tillståndet flyttar svaret

Tillstånd är data, och jev-1.13 behandlar det inte som fientligt som standard. En injicerad instruktion, en avsiktligt vilseledande inramning, eller text som argumenterar för sin egen klassificering kan förskjuta resultatet. Detta är det enda läget där leverantören uttryckligen framställer korrigeringen som framtida arbete – ”Vi förväntar oss att förbättra detta i framtiden” – och den tillfälliga rekommendationen är att vara tydlig med kriterierna och att testa integrationen grundligt innan den sätts framför många användare.

Motstridiga instruktioner och kriterier förvirrar det.

När instruktionerna och kriterierna efterfrågar olika saker kan modellen bli förvirrad. TypeSafes exempel är en noul där sant mappas till nej och falskt mappas till ja, vilket presterar sämre än samma fråga formulerad konsekvent. Instruktionen är att behandla kriterierna som en förlängning av instruktionen och samordna de två i ett språk som en vanlig person kan läsa och förstå.

Strukturella invarianter som det inte garanterar

Detta är det läge som med störst sannolikhet bryter ett system som byggts på något ingen har skrivit ned. Jev är extremt konsekvent i vanlig mening – semantiskt likartade indata ger kvantitativt utdata – men strukturella identiteter som du kanske förväntar dig ska hålla garanteras inte. Leverantören publicerar två fall.

En fråga, två frågetyper. "Ber kunden om återbetalning?" ställd som en noul och ställd som ett ja/nej-val, på ärendet "Jag är inte nöjd med passformen. Vilka alternativ har jag här?" ger en noul på 0,22, och ett val: ja 0,01, nej 0,99, konfidens 0,97. Det är svar på samma fråga.

• En fråga och dess negation. "Ber kunden om en återbetalning?" och "Ber kunden om något annat än en återbetalning?", ställda som två noder på ärendet "Jag blev debiterad två gånger för samma order. Kan någon titta på det här?", returnerar 0,72 och 0,47. De summerar till 1,19.

Åtgärderna är operationella, inte retoriska: förlita dig inte på förväntad strukturell invarians, överför inte en tröskel som är injusterad på en noul till ett val, och kräv inte att modellen uppfyller aritmetiska identiteter mellan separata frågor. Anledningen är att ett val är relativt — det avgör vilket alternativ — medan varje noul är absolut och kan visa sig låg för alla dem.

Generering: den tränades inte för att skriva

jev-1.13 är inte tränad för att generera text. Du kan tvinga fram utdata genom att kedja val, och TypeSafe säger direkt att detta ”inte kommer att fungera bra och kommer att vara mycket långsamt”. För extrahering är rådet att plocka ut kandidatvärden med ett reguljärt uttryck eller en generativ modell och låta Jev välja det korrekta, eller – när svarsutrymmet är begränsat – att göra om extraheringen till ett val bland alternativen i stället för att fråga efter själva värdet.

Taket på 255 alternativ för valfrågor

En fråga om val: en Jev-integration är inte en taggig kant, den är produktens form. Dessa är värda att skilja ut eftersom ingen mängd jug-arbete ändrar dem:

• Ingen textgenerering. Den returnerar ett beslut, inte prosa. Det är designen, inte en defekt.

• Ingen konversation. Jev är en strukturerad beslutsmodell snarare än en chattmodell. Du skickar ett tillstånd och en uppsättning namngivna frågor; den returnerar ett strukturerat svar per fråga. Det finns ingen turtagning att ta hänsyn till i utformningen.

• Ingen multimodal inmatning. Inmatning är endast text – sträng, JSON-objekt eller array av textvärden, utan bild, ljud eller video. Icke-textmaterial måste förbearbetas till text eller strukturerade fält innan det blir en del av tillståndet.

• Icke-strömmande svar. Det finns ett enda strukturerat svar och inget strömmande läge. Anledningen till att detta inte spelar någon roll är samma anledning som gör det värt att nämna: det finns inget att strömma. Ett typat beslut – en boolean med en sannolikhet, en etikett ur en mängd, eller en nivå på en skala – har ingen partiell form som är värd att avslöja token för token.

• Engelska är det primära språket. Andra språk, inklusive CJK-skrifter, hanteras men inte lika bra. TypeSafe råder dig att testa på ditt eget innehåll innan du förlitar dig på Jev för en icke-engelsk arbetsbelastning, och att luta dig mot konfidens vid routning.

Taket på 255 alternativ för valfrågor

En urvalsfråga väljer ett av upp till 255 märkta alternativ, och det är ett absolut tak. TypeSafe förklarar också varför stora urvalsuppsättningar går långsammare, med leverantörens egna ord: "För val med högre kardinalitet använder vi ett tvåstegssystem där vi först poängsätter oberoende och sedan gör ett explicit val, därav den tillfälliga långsamheten." Så latenskostnaden för en stor uppsättning alternativ är strukturell snarare än tillfällig, och det är leverantören som berättar var den kommer ifrån.

Vårt eget serveringsfönster för typesafe/jev-1.13, läst från modellkortet 2026-09-30, visar hur det ser ut i praktiken över sju dagar av vår egen trafik: en median på 151 ms och en p95 på 247 ms, 348 utdatatoken per sekund och en felfrekvens på 0,49 % över 76,2 miljoner betjänade token. Dygnsmedianerna rör sig inom ett smalt band – 175, 170, 163, 161, 170, 147 och 143 ms från 2026-09-24 till och med 2026-09-30 – men den dagliga p95:an för 2026-09-28 är 2 448 ms, ungefär tio gånger så hög som dagarna på vardera sidan om den. Vi kan inte tillskriva den enskilda dagens avvikelse valkardinalitet, och kommer inte att göra det; den ärliga tolkningen är att svansen finns, och ett latenskänsligt arbetsflöde bör utformas mot svansen snarare än medianen.

Den inmatade fakturan är hela fakturan.

Utdata faktureras till noll hos Jev, vilket ibland tolkas som "Jev är gratis." Det är det inte, eftersom indata mäts och ett stort tillstånd är inte gratis bara för att det inte finns något på utdatasidan. Leverantörens pris är $0,042 per miljon indata-tokens — samma siffra som TypeSafe anger som $42 per miljard — och OrcaRouter för vidare leverantörens listpris med 0 % påslag, så en prissänkning från leverantören slår igenom här samma dag.

Här är vad det gör med en realistisk form, med leverantörens egen sats:

• En liten begäran. Ett supportärende på 1 200 tokens plus ungefär 300 tokens bedömningsmall och frågor är 1 500 indatatoken, vilket blir 0,000063 USD per anrop.

• En stor förfrågan. Ett kontrakt på 55 000 token plus frågor som gör att förfrågan uppgår till 60 000 token är 40 gånger så många token, så $0,0025 per anrop — fortfarande litet per anrop, och 40 gånger större än det första fallet för samma enda svar.

• Vid stora volymer. 60 000 tokens per anrop och 10 000 anrop per dag är 600 miljoner indatatokens per dag, vilket är 0,6 miljarder, alltså 25,20 USD per dag och cirka 756 USD under en 30-dagarsmånad. Samma antal anrop mot begäran på 1 500 tokens är 15 miljoner tokens per dag: 0,63 USD per dag, cirka 18,90 USD i månaden.

Gapet mellan de två sista raderna är inte ett pristrick, det är det mätarbaserade tillståndet. Det är därför filtreringsrådet i avsnittet om kontextröta inte bara är en noggrannhetsåtgärd — att trimma tillståndet är också den enda hävstången som förändrar fakturan.

De publicerade driftsgränserna, så att ingen behöver gissa

TypeSafes modellsida publicerar konkreta siffror, så en planerare inte behöver härleda dem:

• Genomströmning och takt. 100K tokens per sekund och 40 förfrågningar per sekund, enligt docs.typesafe.ai/models.md. En förfrågan som överskrider någon av gränserna returnerar 429 Too Many Requests; leverantörens klient-SDK:er gör om försök med backoff som standard och respekterar retry-after-huvudet när svaret innehåller ett sådant.

• Gränserna rör på sig. Leverantören uppger att anropsgränserna justeras dynamiskt och "kan ändras utan meddelande" i takt med att kapacitet blir tillgänglig, med högre gränser tillgängliga på anpassade och företagsplaner. Betrakta 100K/40 som dagens siffra snarare än ett kontrakt.

• Kontextbudget. Förfrågningsbudgeten är ungefär 64 000 token över det kombinerade tillståndet och alla frågor — modellkortet anger 65 536 — och leverantörens modellsida begränsar separat tillståndet plus den enskilt längsta frågan till 32 000 token. Den andra siffran är tillståndsbudgeten, inte en mindre version av den första; båda är verkliga och ingen av dem motsäger den andra.

• Alias ändras under dig. jev-latest och jev-preview pekar båda på jev-1.13.0 i dag, och leverantören meddelar att det inte finns något förhandsbygge tillgängligt just nu. Ett alias flyttas när en ny version släpps, så om du har finjusterat konfidenströsklar mot en specifik version, lås det versionsspecifika ID:t och gör övergången enligt din egen tidsplan.

Hur ditt användningsfall behöver se ut

Läst från början till slut beskriver leverantörens egen lista ett snävt, användbart verktyg. Jev passar när bedömningen är avgränsad och aritmetiken inte är modellens uppgift: är den här posten policyenlig, vilken av dessa fyrtio etiketter är tillämplig, hur ska detta läsas på en femgradig skala — ställda mot ett tillstånd som du själv har filtrerat, med en bokstavlig instruktion och kriterier som stämmer överens med den, och med varje räkning, jämförelse och datumuträkning utförd i kod runt omkring.

Det passar inte när uppgiften kräver räkning, ordning eller datumrritmetik, när den kräver flera resonemangssteg, när indatamaterialet inte är text, när tillståndet är en höstack och frågan en nål, eller när något hos källan är fientligt. Det är inte luckor i en prompt; det är platser där modellen inte fungerar, och TypeSafe är parten som säger det.

En sak till som är värd att veta innan du kopplar upp det: den ärliga skillnaden i hur Jev anropas. På OrcaRouter når katalogen Jev via den dedikerade systemone-slutpunkten, POST /v1/systemone, snarare än via OpenAI chat-completions-formen. Det är en verklig skillnad i den förfrågan du skriver, och det är den korrekta versionen av det äldre påståendet att Jev "talar sin egen förfrågningsform". Allt annat är detsamma som för alla andra modeller på kontot — en nyckel för 200+ modeller, inga avgifter per token från oss, och automatisk failover om en rutt blir dålig. TypeSafe tog bort väntelistan den 2026-09-21; leverantörens egen hemsida beskriver fortfarande Jev som early access, och dess egen benchmark-sida är fortfarande markerad som väntande, så de enda prestandasiffrorna på den här sidan är de serving-siffror vi själva uppmätte och leverantörens egna påståenden, märkta som deras.