Waar Jev 1.13 breekt: TypeSafe's eigen lijst met limieten

Jev 1.13 (typesafe/jev-1.13) werd uitgebracht op 2026-09-15, waardoor het twee weken buiten de laatste zeven dagen valt, dus de release is niet het verhaal. De gedateerde gebeurtenis is 2026-09-24: dat is de dag waarop OrcaRouter typesafe/jev-1.13 aan zijn catalogus toevoegde en er een modelkaart voor opende — de eerste ondersteuning voor serving van Jev in een gateway van een derde partij, na twee weken waarin de enige manier om het aan te roepen het eigen endpoint van TypeSafe was. Dat is hier om één specifieke reden van belang. Jev is ongewoon doordat de leverancier een lijst publiceert van de manieren waarop het faalt, en een lijst die je alleen kunt lezen is veel gemakkelijker over te slaan dan een model dat je daadwerkelijk kunt aanroepen.

Deze pagina is die lijst, beperkt tot wat TypeSafe zelf zegt, plus de operationele limieten en de rekening.

TypeSafe publiceert zijn eigen jaggedness-lijst

docs.typesafe.ai bevat een pagina met de titel Jev 1.13: ruwe kantjes. Deze is expliciet van toepassing op jev-1.13, heeft een reviewdatum van 2026-09-17 en opent met de eigen bewoordingen van de leverancier: "Jev is niet perfect. Hier zijn een paar ruwe kantjes die wij kennen in jev-1.13. Veel hiervan zal in latere versies worden opgelost." Er volgen negen benoemde modi, elk met een concreet geval en een oplossing onder "Instead:". Niets hieronder is afgeleid en niets is verzacht — de bewoordingen zijn van TypeSafe, en waar het bedrijf zijn eigen voorbeeld geeft, zijn de cijfers daarin van hen.

Letterlijke lezing: het beantwoordt de vraag die je schreef

Bereikbepalende woorden, ontkenningen en impliciete voorwaarden worden letterlijk genomen. Een vraag wordt beantwoord op basis van de woorden in de instructie, "terwijl een persoon misschien de bedoeling achter de instructies zou hebben gelezen."

De diagnostiek van de leverancier is het nuttige deel: wanneer je naar een fout antwoord kijkt en jezelf erop betrapt dat je uitlegt wat je werkelijk bedoelde, dan is die uitleg de ontbrekende helft van de instructie. De oplossingen zijn: de exacte voorwaarde in de instructies vermelden, grensgevallen in de criteria opnemen, en waar interpretatie werkelijk onvermijdelijk is, de vraag opsplitsen in twee letterlijke vragen en ze in code combineren.

Wiskunde en getallen: het is geen rekenmachine

TypeSafe zegt ronduit om wiskundige logica in code te implementeren. Drie specifieke fouten liggen daaraan ten grondslag:

• Tellen is onbetrouwbaar. Dit geldt voor tekens in een woord, het aantal keren dat een term in een passage voorkomt, en items in een lange lijst. "Het model herkent de vorm van een antwoord in plaats van te tellen, en de fout groeit met de omvang van wat wordt geteld." De eigen test van de leverancier om te bepalen of je het überhaupt moet vragen: als een reguliere expressie of een parser de eenheid kan vinden, hoort de telling in code thuis en voegt het model niets toe.

• Numerieke representaties presteren slechter dan semantische. Vragen over kleuren met hexwaarden zijn slechter dan dezelfde vragen met Engelse kleurnamen; gegeven RGB-triples of hex kan Jev niet betrouwbaar beoordelen of twee waarden dicht bij elkaar liggen. Dezelfde kloof is te zien bij low-levelcode — assembly, of binair gecodeerde instructies — tegenover high-leveltalen. Converteer of verdeel in buckets in code, en houd het model voor het deel dat echt een beoordeling is.

• Score-uitvoer bevat geen exacte grootten. De leverancier stelt dat de scoreniveaus van Jev zwak zijn in numerieke kalibratie. Een verwachting kan worden gebruikt om te testen of iets een drempel haalt; deze kan niet worden gebruikt om het getal te reconstrueren door te interpoleren tussen de twee dichtstbijzijnde niveaus. Dat is een hard nee tegen een hele categorie misbruik: het lezen van een score als een meting.

Datum en tijd: datums worden als tekst gelezen, niet als hoeveelheden

Het ordenen van twee datums, het meten van de afstand ertussen, of het bepalen of een ervan binnen een venster valt, is onbetrouwbaar, en het gaat nog verder achteruit bij gemengde formaten, relatieve verwijzingen en domeingrenzen zoals kwartalen, afwikkelingsvensters en toerekeningsperioden.

De aanbevolen opsplitsing is netjes. Extractie is een kwestie van beoordeling, dus laat dat aan het model over. Elk onderdeel van een datum is een kleine gesloten verzameling — twaalf maanden, eenendertig mogelijke dagen, een begrensde reeks jaren — waardoor extractie een keuze wordt uit opgesomde opties in plaats van vrije-vormparsing, en je een plek krijgt om een expliciete "niet vermeld" te zetten, zodat een ontbrekend onderdeel wordt gemeld in plaats van geraden. Code stelt de onderdelen samen en beheert alles daarna, inclusief volgorde, duur, offset en weekdag.

Indirectie: dubbele ontkenningen en extra stappen gaan ten koste van de nauwkeurigheid.

Instructies met dubbele ontkenningen of gelaagde indirectie worden minder betrouwbaar beantwoord. Een vraag over een eigenschap van een eigenschap, of een vraag die meerdere redeneerstappen vereist, gaat ten koste van de nauwkeurigheid. De remedie is om instructies zo direct mogelijk op te schrijven en de relevante onderdelen van de toestand te benoemen in plaats van ze te beschrijven.

Een grote toestand vol irrelevante details gaat ten koste van de nauwkeurigheid.

De nauwkeurigheid daalt naarmate de state groeit met inhoud die niets met de beslissing te maken heeft. Niet-relevant detail werkt als een afleider, en een grote state maakt het moeilijker om te bepalen welk deel van de invoer een fout antwoord heeft veroorzaakt. De eigen herinnering van TypeSafe in de afsluitende noot is onverbloemd: "Jev lijdt aan contextrot, dus niet-relevant materiaal in de state kost je nauwkeurigheid."

Haal eerst op en filter in code, en stuur alleen de velden die de vraag nodig heeft. Waar filteren vóór het verzoek niet mogelijk is, stelt de leverancier voor om een noul te gebruiken om op relevantie te filteren en vervolgens de overgeblevenen te beoordelen.

Adversariële inhoud in de toestand verplaatst het antwoord.

State is data, en jev-1.13 behandelt het niet standaard als vijandig. Een geïnjecteerde instructie, een bewust misleidende framing, of tekst die pleit voor zijn eigen classificatie kan het resultaat veranderen. Dit is de enige modus waarin de leverancier de oplossing expliciet als toekomstig werk presenteert — "We verwachten dit in de toekomst te verbeteren" — en het tussentijdse advies is om expliciet te zijn in de criteria en de integratie grondig te testen voordat je het aan veel gebruikers voorlegt.

Tegenstrijdige instructies en criteria verwarren het.

Wanneer de instructies en de criteria om verschillende dingen vragen, kan het model in de war raken. Het voorbeeld van TypeSafe is een noul waarin waar aan nee wordt gekoppeld en onwaar aan ja, wat slechter presteert dan dezelfde vraag die consistent is geformuleerd. De instructie is om de criteria te behandelen als een uitbreiding van de instructie en de twee op elkaar af te stemmen in taal die een gemiddeld persoon kan lezen en begrijpen.

Structurele invarianten die het niet garandeert

Dit is de modus die het meest waarschijnlijk een systeem breekt dat is gebouwd op een aanname die niemand heeft opgeschreven. Jev is uiterst consistent in de gebruikelijke zin — semantisch vergelijkbare invoer levert kwantitatief vergelijkbare uitvoer op — maar structurele identiteiten waarvan je zou verwachten dat ze gelden, zijn niet gegarandeerd. De leverancier publiceert twee uitgewerkte cases.

• Eén vraag, twee vraagtypen. "Vraagt de klant om een terugbetaling?" gesteld als een noul en gesteld als een ja/nee-keuze, op het ticket "Ik ben niet tevreden met de pasvorm. Wat zijn mijn opties hier?" geeft een noul van 0,22, en een keuze van ja 0,01, nee 0,99, zekerheid 0,97. Dat zijn antwoorden op dezelfde vraag.

• Een vraag en de ontkenning ervan. "Vraagt de klant om een terugbetaling?" en "Vraagt de klant om iets anders dan een terugbetaling?", gesteld als twee nouls op het ticket "Ik ben twee keer in rekening gebracht voor dezelfde bestelling. Kan iemand dit onderzoeken?", leveren 0,72 en 0,47 op. Ze tellen op tot 1,19.

De remedies zijn operationeel, niet retorisch: vertrouw niet op verwachte structurele invariantie, neem een drempelwaarde die op een noul is afgestemd niet mee naar een keuze, en houd het model niet aan rekenkundige identiteiten tussen afzonderlijke vragen. De reden is dat een keuze relatief is — ze bepaalt welke optie — terwijl elke noul absoluut is en voor allemaal laag kan uitvallen.

Generatie: het was niet getraind om te schrijven

jev-1.13 is niet getraind om tekst te genereren. Je kunt uitvoer forceren door keuzes aaneen te schakelen, en TypeSafe zegt direct dat dit "niet goed zal werken en zeer traag zal zijn." Voor extractie is het advies om kandidaatwaarden eruit te halen met een reguliere expressie of een generatief model en Jev de juiste te laten kiezen, of — wanneer de antwoordruimte begrensd is — de extractie om te zetten in een keuze uit de opties in plaats van om de waarde zelf te vragen.

Het maximum van 255 opties voor keuzevragen

Een keuzevraag: een Jev-integratie is geen rafelige rand, het is de vorm van het product. Het loont om deze apart te behandelen, want geen enkele hoeveelheid promptwerk verandert ze:

• Geen tekstgeneratie. Het retourneert een beslissing, geen proza. Dat is het ontwerp, geen defect.

• Geen gesprek. Jev is een gestructureerd beslissingsmodel in plaats van een chatmodel. Je stuurt een toestand en een reeks benoemde vragen; het retourneert één gestructureerd antwoord per vraag. Er is geen beurtwisseling om rekening mee te houden.

• Geen multimodale invoer. Invoer is alleen tekst — een string, JSON-object of array van tekstwaarden, zonder afbeelding, audio of video. Niet-tekstmateriaal moet vooraf worden verwerkt tot tekst of gestructureerde velden voordat het deel gaat uitmaken van de state.

• Niet-streamende antwoorden. Er is één gestructureerd antwoord en geen streamingmodus. De reden dat dit er niet toe doet, is dezelfde reden waarom het toch vermeldenswaard is: er valt niets te streamen. Een getypeerde beslissing — een boolean met een waarschijnlijkheid, één label uit een set, of een niveau op een schaal — heeft geen gedeeltelijke vorm die het waard is om token voor token te onthullen.

• Engels is de primaire taal. Andere talen, waaronder CJK-schriften, worden wel ondersteund, maar niet even goed. Het advies van TypeSafe is om je eigen content te testen voordat je voor een niet-Engelse workload op Jev vertrouwt, en om bij het routeren op confidence te leunen.

Het maximum van 255 opties voor keuzevragen

Een keuzevraag kiest een van maximaal 255 gelabelde opties, en dat plafond is hard. TypeSafe legt ook uit waarom grote keuzesets langzamer werken, in de woorden van de leverancier zelf: "Voor keuzes met een hogere kardinaliteit hanteren we een tweefasensysteem waarbij eerst onafhankelijk wordt gescoord en daarna een expliciete keuze wordt gemaakt, vandaar de occasionele vertraging." Dus de latentiekosten van een grote optieset zijn structureel in plaats van incidenteel, en het is de leverancier die je vertelt waar het vandaan komt.

Ons eigen serveervenster voor typesafe/jev-1.13, gelezen van de modelkaart op 2026-09-30, laat zien hoe dat er in de praktijk uitziet over zeven dagen van ons eigen verkeer: een mediaan van 151 ms en een p95 van 247 ms, 348 outputtokens per seconde, en een foutpercentage van 0,49% over 76,2 miljoen geleverde tokens. De dagelijkse medianen bewegen zich in een smalle band — 175, 170, 163, 161, 170, 147 en 143 ms van 2026-09-24 tot en met 2026-09-30 — maar de dagelijkse p95 voor 2026-09-28 is 2.448 ms, ongeveer tien keer de dagen aan weerszijden ervan. We kunnen die uitschieter van één dag niet toeschrijven aan keuzecardinaliteit en zullen dat ook niet doen; de eerlijke lezing is dat de staart bestaat, en een latentiegevoelige workflow moet tegen de staart worden ontworpen in plaats van tegen de mediaan.

De ingevoerde factuur is de volledige factuur

Output wordt op Jev tegen nul gefactureerd, wat soms wordt gelezen als "Jev is gratis." Dat is het niet, want input wordt gemeten, en een grote state is niet gratis louter omdat er aan de outputzijde niets is. De leveranciersprijs is $0,042 per miljoen inputtokens — hetzelfde getal dat TypeSafe als $42 per miljard vermeldt — en OrcaRouter geeft de lijstprijs van de provider door met 0% opslag, dus een prijsverlaging van de leverancier wordt hier dezelfde dag doorgevoerd.

Dit is wat dat doet met een realistische vorm, met het eigen tarief van de leverancier:

• Een klein verzoek. Een supportticket van 1.200 tokens plus ongeveer 300 tokens aan rubric en vragen is 1.500 inputtokens, wat $0,000063 per aanroep is.

• Een groot verzoek. Een contract van 55.000 tokens plus vragen die het verzoek op 60.000 tokens brengen, is 40 keer zoveel tokens, dus $0,0025 per aanroep — nog steeds klein per aanroep, en 40 keer groter dan het eerste geval voor hetzelfde ene antwoord.

• Bij volume. 60.000 tokens per aanroep en 10.000 aanroepen per dag is 600 miljoen inputtokens per dag, oftewel 0,6 miljard, dus $25,20 per dag en ongeveer $756 over een maand van 30 dagen. Hetzelfde aantal aanroepen bij de aanvraag van 1.500 tokens is 15 miljoen tokens per dag: $0,63 per dag, ongeveer $18,90 per maand.

Het gat tussen die laatste twee regels is geen prijstruc, het is de gemeten toestand. Daarom is het filteradvies in de sectie over contextrot niet alleen een nauwkeurigheidsmaatregel — het inkorten van de state is ook de enige hefboom die de rekening beïnvloedt.

De gepubliceerde operationele limieten, zodat niemand hoeft te raden

De modellenpagina van TypeSafe publiceert concrete cijfers, zodat een planner ze niet hoeft af te leiden:

• Doorvoer en snelheid. 100K tokens per seconde en 40 verzoeken per seconde, volgens docs.typesafe.ai/models.md. Een verzoek dat een van beide limieten overschrijdt, retourneert 429 Too Many Requests; de client-SDK's van de leverancier proberen standaard opnieuw met backoff en respecteren de retry-after-header wanneer de respons er een bevat.

• De limieten liggen niet vast. De leverancier stelt dat rate limits dynamisch worden aangepast en "zonder kennisgeving kunnen veranderen" naarmate er capaciteit online komt, waarbij hogere limieten beschikbaar zijn voor custom- en enterprise-abonnementen. Zie 100K/40 als het huidige aantal, niet als een contract.

• Contextbudget. Het aanvraagbudget is ongeveer 64.000 tokens over de gecombineerde state en alle vragen — de modelkaart publiceert 65.536 — en de modellenpagina van de leverancier begrenst de state plus de enkele langste vraag afzonderlijk op 32.000 tokens. Dat tweede cijfer is het statebudget, niet een kleinere versie van het eerste; beide zijn reëel en geen van beide spreekt de ander tegen.

• Aliassen veranderen onder je vandaan. jev-latest en jev-preview verwijzen vandaag beide naar jev-1.13.0, en de leverancier merkt op dat er momenteel geen preview-build beschikbaar is. Een alias verschuift wanneer een nieuwe release uitkomt, dus als je confidence-drempels hebt afgestemd op een specifieke versie, pin dan de geversioneerde ID en bepaal zelf wanneer je overstapt.

Hoe jouw use case eruit moet zien

Van begin tot eind gelezen, beschrijft de eigen lijst van de leverancier een beperkt, nuttig hulpmiddel. Jev is geschikt wanneer de beoordeling begrensd is en het rekenwerk niet de taak van het model is: valt dit record binnen het beleid, welke van deze veertig labels is van toepassing, hoe leest dit op een vijfpuntsschaal — gevraagd over door uzelf gefilterde toestand, met een letterlijke instructie en criteria die daarmee overeenkomen, en met elke telling, vergelijking en datummeting in code eromheen uitgevoerd.

Het is niet geschikt wanneer de taak tellen, ordenen of rekenen met datums vereist, wanneer er meerdere redeneerstappen nodig zijn, wanneer het invoermateriaal geen tekst is, wanneer de toestand een hooiberg is en de vraag een naald, of wanneer iets aan de bron vijandig is. Dat zijn geen hiaten in een prompt; het zijn plekken waar het model niet werkt, en TypeSafe is de partij die dat zegt.

Nog één ding dat de moeite waard is om te weten voordat je het aansluit: het eerlijke verschil in hoe Jev wordt aangeroepen. Op OrcaRouter bereikt de catalogus Jev via het speciale systemone-endpoint, POST /v1/systemone, in plaats van via de OpenAI chat-completions-vorm. Dat is een wezenlijk verschil in het request dat je schrijft, en het is de correcte versie van de oudere bewering dat Jev "zijn eigen requestvorm spreekt". Al het andere is hetzelfde als bij elk ander model op het account — één sleutel voor 200+ modellen, geen kosten per token van ons, en automatische failover als een route problemen geeft. TypeSafe heeft de wachtlijst op 2026-09-21 verwijderd; de eigen homepage van de leverancier beschrijft Jev nog steeds als vroegtijdige toegang, en de eigen benchmarkpagina is nog steeds gemarkeerd als in behandeling, dus de enige prestatiecijfers op deze pagina zijn de serveercijfers die wij zelf hebben gemeten en de eigen beweringen van de leverancier, gemarkeerd als die van hen.