RSI-Jev vs Jev 1.13: de een download je, de ander bel je

Zet RSI-Jev v6.1-VL 4B en Jev 1.13 naast elkaar en het eerste dat een aanroeper opvalt, is dat het om hetzelfde verzoek gaat. Geef een van beide een toestand en een set getypeerde vragen — een ja/nee, een kies-één-uit-k, een beoordeling-op-een-rubric — en beide retourneren een gekalibreerde waarschijnlijkheid voor elke optie, in één forward pass, zonder gegenereerde tekst die geparseerd moet worden. Dat is geen toeval: RSI-Jev is met opzet gebouwd om het wireformaat van Jev te spreken, dus een client die tegen de API van TypeSafe is geschreven, werkt ermee door een basis-URL te wijzigen. Wat niet hetzelfde is, is alles rondom de aanroep. Jev 1.13 is het gesloten commerciële model van TypeSafe, aangeboden via een endpoint waarvan je het verbruik meet; RSI-Jev v6.1-VL is een checkpoint met 4,69 miljard parameters onder Apache-2.0-gewichten dat je downloadt en op je eigen hardware serveert. Geen van beide is een rebrand van de andere, geen van beide leveranciers onderschrijft de andere, en bijna elk cijfer in deze vergelijking is afkomstig van de partij die deze heeft geproduceerd.

De datum op het onderwerp is van belang, want dit project brengt ongeveer elke dag een release uit. RSI-Jev v6.1-VL 4B werd op 2026-10-07 gepubliceerd door het project Shanghua-Gao/RSI-Jev van derden — een zichzelf verbeterende onderzoekslus die Jev-achtige beslissingsmodellen traint en elke arm publiceert die faalde, samen met degenen die wonnen. Het is de achtste release in dertien dagen op die lijn, en het is een gewogen gemiddelde van de vorige release met een tweede fine-tune van dezelfde Qwen3.5-4B-Base. Jev 1.13 is het model van TypeSafe AI, gelanceerd op 2026-09-15 en sinds 2026-09-24 opgenomen in onze eigen catalogus. Beide datums zijn hieronder van belang, want een vergelijking met een project dat dagelijks beweegt, heeft een houdbaarheid die in dagen wordt gemeten.

Wat de twee eigenlijk zijn, elk in één regel.

Jev 1.13 is een gehost beslissingsmodel achter een toegewijde endpoint — POST /v1/systemone, niet-streamend, ongeveer 64.000 tokens invoerbudget voor de state en al je vragen samen, met een prijs van $0,042 per miljoen invoertokens, waarbij uitvoer op nul wordt gefactureerd omdat er geen uitvoertokens zijn. De architectuur, het aantal parameters en de trainingscompute worden niet bekendgemaakt; TypeSafe heeft gezegd dat de details geheim worden gehouden en dat er mogelijk een paper volgt. Je draait het niet. Je roept het aan, en elke aanroep is een gemeten netwerkverzoek.

RSI-Jev v6.1-VL is de andere opzet in zijn geheel. Het is een Qwen3.5-4B-Base-toren die end-to-end is fijngetuned, met beslissingskoppen op lagen 16, 20 en 32, geserveerd vanuit een checkpoint dat op zichzelf staat en 9,7 GB groot is in bf16. Het parameteraantal is 4,69B en het is de moeite waard om te weten waar dat naartoe gaat: 3,57B in de 32 decoderlagen, 0,64B in de token-embeddings, 0,33B in de vision-toren, 0,05B in de hoofdbeslissingskop en 0,10B in de twee early-exit-koppen. Er is geen mixture of experts en geen tweede model. Je installeert het met een pip-opdracht uit de repository, start de server, en vanaf dat punt verlaat de beslissing nooit je infrastructuur.

• Wie beheert het — een gehost endpoint met verbruiksfacturering dat je niet zelf in de hand hebt versus een checkpoint van 9,7 GB op je eigen GPU, Apple Silicon of CPU.

• Prijsvorm — $0,042 per miljoen invoertokens, output gratis, betaald per aanroep versus nul aan de marge plus de kosten van de machine en de operaties.

• Invoerbudget — ongeveer 64.000 tokens per verzoek op het gehoste model tegenover 32.768 teksttokens plus een afbeeldingsbudget op het checkpoint, waarbij alles wat langer is geweigerd wordt in plaats van afgekapt.

• Gewichten en licentie — gesloten, niet-openbaar gemaakte omvang versus Apache-2.0-gewichten, MIT-code, 4,69 miljard parameters.

• Modaliteit — tekst voor Jevs contract versus tekst plus maximaal vier afbeeldingen per verzoek bij de RSI-Jev vision-releases.

• Eigendom — het commerciële model van TypeSafe AI versus een onderzoeksproject van een derde partij dat in zijn eigen licentieregel verklaart "niet gelieerd te zijn aan TypeSafe AI".

De score op het eigen bord van RSI-Jev, en waarom het slechts de helft van een vergelijking is

Het cijfer waarmee het project opent, is de Decision Index 0.3-score: 50,98 voor v6.1-VL 4B, tegenover 46,23 voor de voorgaande release. Dat is een volledige run van de standaardconfiguratie — 140.178 requests, dekking 1,0 — en op het eigen openbare scorebord van het project, gedateerd 2026-10-06, evenaart het het beste 4B-model op dat bord (50,98 tegen 50,82 van ezjev 4B s2, wat de kit als een gelijkspel bij 0,25 beschouwt) en staat het op de 27e plaats van 113 in totaal. Op de oudere Decision Index 0.2.1 bedraagt het 50,74 tegenover 46,24 van v6.0-VL. Zijn suite van vijftien benchmarks, gerapporteerd zonder de open_jev_ood taak waarvan is vastgesteld dat die overlapt met trainingsrijen, is 0,793, en zijn held-outset is 0,729.

Elk van die cijfers is van RSI-Jev zelf, gemeten op RSI-Jevs testomgeving. De Decision Index is een openbare benchmarklijst, maar er is geen meting van Jev 1.13 op te vinden, omdat de suite van het project is gebouwd om open beslissingscheckpoints te scoren en Jev een gesloten endpoint is. Dus de verleiding om 50,98 tegenover Jevs 0,727 op de typed-decisions benchmark te zetten en een winnaar uit te roepen, is precies de fout die je moet vermijden: die twee getallen komen uit verschillende testomgevingen, verschillende steekproefgroottes en verschillende data, en niemand heeft één testomgeving over beide modellen laten lopen.

De enige head-to-head die bestaat, is die van Laya, niet die van RSI-Jev.

Er is één gepubliceerde vergelijking die wél een Jev-getal naast een open checkpoint zet, en die is door geen van beide partijen hier uitgevoerd. Convai Innovations, de makers van het Laya decision model, hebben de door TypeSafe gepubliceerde cijfers voor Jev 1.13.0 naast hun eigen cijfers in een tabel gezet en wezen zelf op de beperkingen: de Jev-cijfers zijn door derden gepubliceerd en zijn nooit door Convai gemeten, de steekproefgroottes en prompts verschillen, en de leverancier vermeldt zijn eigen benchmarks voor het model niet. Die tabel is de moeite waard om te lezen voor kalibratie, niet voor een oordeel — en RSI-Jev staat er helemaal niet in, omdat RSI-Jev nog niet bestond toen deze werd gepubliceerd.

Wat het wel laat zien, is de vorm van de vraag 'gehost versus open' die een lezer daadwerkelijk afweegt. Het gehoste model is in het voordeel waar de optieruimte groot is en het model een brede verzameling antwoorden stabiel moet houden; de open modellen winnen op ruwe latentie per aanroep omdat er geen netwerk in het pad zit. Niets in dat patroon vertelt je welk van deze twee specifieke modellen beter is voor jouw taak, en het eerlijke standpunt is dat het antwoord nog niet publiekelijk bestaat.

Wat het checkpoint oplevert wat het endpoint niet kan

Het sterkste argument voor RSI-Jev is geen score. Het is dat de gewichten op je schijf staan. Voor een routeringsbeslissing op basis van een medisch dossier, een juridisch document of de accountgeschiedenis van een klant is "de data verlaat nooit het gebouw" geen voorkeur die je inruilt tegen een benchmarkpunt — het is een harde eis, en geen enkele gehoste endpoint, tegen welke prijs dan ook, voldoet daaraan. Dezelfde eigenschap heft de rate limit op: de eigen documentatie van de leverancier voor het gehoste model vermeldt dat de limieten dynamisch worden aangepast en zonder kennisgeving kunnen veranderen, en een zelfgehost checkpoint heeft geen dergelijk plafond, afgezien van je hardware.

Het tweede dat het checkpoint oplevert, is dieptecontrole, en dat is ongewoon. Omdat de beslissingskoppen op drie diepten zitten, een inspanning-instelling bepaalt hoeveel lagen een verzoek mag gebruiken: laag stopt bij laag 16 met een mediaan van ongeveer 23 ms, gemiddeld bij 20 met 27 ms, hoog bij 32 met ongeveer 40 ms, en auto antwoordt bij de eerste uitgang die zelfverzekerd genoeg is, met gemiddeld 19,5 van de 32 lagen op de suite van het project. Die latenties zijn de eigen cijfers van het project, gemeten op één H200 in bf16, en mogen niet worden vermengd met welk gehost cijfer dan ook — een lokale forward pass en een getarifeerde API-aanroep zijn niet dezelfde meting, en de eigen documentatie van RSI-Jev is expliciet dat de eerdere vergelijking met de gepubliceerde latentie van Jev lokaal GPU-werk tegenover een netwerkround-trip zette.

Het derde punt zijn de afbeeldingen. Jevs contract is tekst in, gestructureerde JSON uit. De RSI-Jev vision-releases nemen één tot vier afbeeldingen per verzoek als base64-data-URL's, waarbij de state naar elk verwijst met een marker, en v6.1-VL scoort 0,834 op de held-out-afbeeldingsset van het project. Als uw beslissing is "vertoont de foto zichtbare schade?", dan is dat een mogelijkheid die het gehoste contract helemaal niet biedt.

Wat je opgeeft is ook reëel, en het project publiceert het. Calibratie werd in deze release slechter, niet beter: de uiteindelijke verwachte calibratiefout is 0,048 op laag 32 en 0,055 met auto, tegenover 0,036 en 0,024 voor de vorige release. De standaard enkele drempel van 0,95 wordt expliciet onbevestigd meegeleverd — het is de terugvaloptie van een selectieregel waarvan de eigen keuze, 0,85, de dieptelimiet van het project op de helft van zijn ontwikkeldata niet haalde. De vroege uitgangen lezen alleen tekst, dus elke vraag met een afbeelding doorloopt alle 32 lagen ongeacht de inspanning. En vijf van de trainingsbronnen voor afbeeldingen zijn niet-commercieel of alleen voor onderzoek, waarbij het project ronduit stelt dat het niet vaststaat of gewichten die op niet-commerciële data zijn getraind, die voorwaarden overnemen.

Waar je de gehoste moet aanroepen, en waar niet.

Dit is het deel van de vergelijking waarbij wij belang hebben, dus het is de moeite waard om precies te zijn. Wij serveren het commerciële model van TypeSafe als typesafe/jev-1.13 op het toegewijde systemone-endpoint — een POST naar /v1/systemone in plaats van de OpenAI chat-completions-vorm, niet-streaming, tegen de context van 65.536 tokens die onze catalogus vermeldt. Het is dezelfde request- en antwoordvorm die RSI-Jev implementeert, van het model waarvan het project het contract kopieert. RSI-Jev zelf hosten wij niet; er is geen rsi-jev-id en geen shgao-id in onze catalogus, en een lezer die dat model wil, downloadt het.

De reden dat dat onderscheid hier van belang is, is nauw en concreet. Een beslissingslaag vormt zelden het geheel van een workflow — meestal staat die naast een generatief model dat het antwoord, de samenvatting of de code schrijft. Dat betekende historisch gezien twee contracten. Voor het gehoste deel hoeft dat niet langer zo te zijn: Jev 1.13 staat op dezelfde sleutel als 200+ andere modellen tegen de lijstprijs van de provider, doorgegeven met 0% opslag, dus als TypeSafe een tarief wijzigt, is die wijziging dezelfde dag nog live aan onze kant in plaats van in de volgende factuurcyclus. Het zelfgehoste deel had dat probleem nooit, want jij bent de provider. De zuivere manier om tussen beide te kiezen is eerst het commerciële contract uit te proberen op een handvol van je eigen gelabelde gevallen, te kijken of het out-of-the-box gedrag goed genoeg is om tegen te automatiseren, en pas daarna uit te zoeken of het zelf draaien van een 4,69B-checkpoint de operationele last waard is.

Welke je eigenlijk zou moeten kiezen

Kies RSI-Jev v6.1-VL 4B als de beslissing binnen je perimeter moet blijven, als je een beslissing nodig hebt op basis van zowel een afbeelding als tekst, als je optiesets in de honderden lopen (het checkpoint laat tot 5.120 opties per vraag toe), of als je diepte en latentie per verzoek wilt afstemmen. Weet bij aanvang dat je een project adopteert dat acht keer is veranderd in dertien dagen, dat de nieuwste release kalibratie heeft ingeruild voor nauwkeurigheid, en dat de eigen kaart de onderdelen van het exitbeleid noemt die het niet kon bevestigen.

Kies Jev 1.13 als je wilt dat de beslissing werkt zonder een servingstack, als je waarde hecht aan een endpoint dat iemand anders draaiende houdt, en als de prijs van $0,042 per miljoen inputtokens — zonder outputtokens om te meten — goedkoop is in verhouding tot je aanroepvolume. Weet voordat je hiermee begint dat je een gesloten model aanroept waarvan de omvang niet bekend is, waarvan de rate limits zonder kennisgeving kunnen veranderen, en waarvan de gepubliceerde benchmarks niet iets zijn dat je opnieuw kunt uitvoeren.

Wat beide gemeen hebben, is nuttiger dan wat hen scheidt, en het is de reden dat een vergelijking als deze überhaupt de moeite van het opschrijven waard is. Geen van beide modellen genereert tekst, dus geen van beide introduceert de klasse van fouten die ontstaat bij een model dat vergeet een accolade te sluiten of een veld verzint. Beide retourneren waarschijnlijkheden, en in beide gevallen is de waarschijnlijkheid het deel dat je op je eigen gelabelde data moet valideren voordat je er automatisering op baseert — de latentie is al gecommoditiseerd, en de confidencewaarde is wat per deployment verdiend moet worden. Aan welke kant van de download-versus-call-scheidslijn je ook belandt, test eerst de kalibratie.