Zal OpenAI de lunch van Jev opeten?

TypeSafe's Jev introduceerde een nieuwe draai aan grote taalmodellen (LLM's) die de AI-wereld bestormt. Volgens Vercel "werd Jev sneller geadopteerd dan welk ander model dan ook in de geschiedenis van de AI Gateway." Maar er trekken wolken over de horizon. OpenAI let ongetwijfeld op en beslist wat de volgende stap is.

Ik wens TypeSafe het allerbeste, maar als ze echt waar maken wat ze beloven, ben ik bezorgd dat OpenAI in een sterke positie is om snel te volgen. Niet alleen om Jev's vlaggenschipproduct te repliceren, maar ook om die functionaliteit te integreren in toekomstige modellen en agents, en zo nieuw gedrag aan te bieden dat Jev niet kan reproduceren.

Mijn these in het kort: OpenAI gebruikt hun LLM's al jaren als impliciete classificeerders; ze hebben ze alleen niet getraind voor algemene classificatietaken en ze hebben algemene classificatie niet verpakt als een op zichzelf staand product. Als OpenAI de training kan repliceren, kunnen ze Jev in korte tijd kopiëren. Bovendien is OpenAI gepositioneerd om deze nieuwe classificeerder te gebruiken binnen hun bestaande modellen en agents, wat nuttig kan zijn voor snelle modelselectie, efficiënter nadenken, betere beveiligingsbarrières (guardrails) en over het algemeen slimmere, snellere en goedkopere modellen.

De doorslaggevende factor is of TypeSafe een 'moat' (een beschermende wal of concurrentievoordeel) heeft om zichzelf te beschermen. Het grootste voordeel dat ik zie, ligt in de trainingsdata en de trainingsprocessen van TypeSafe.

Wat oud is, is weer nieuw

Voordat ik mijn standpunt verder onderbouw, wil ik mijn aannames formuleren en deze ondersteunen met relevante geschiedenis en voorbeelden van OpenAI.

Mijn belangrijkste aanname is dat Jev gebruikmaakt van iets dat zeer dicht bij een conventioneel groot taalmodel ligt. Als bewijs hiervoor meldt Latent Space dat veel van de vroege clones inderdaad gebaseerd zijn op LLM's.

Het idee is als volgt: gegeven een status en een set vragen, genereert het LLM van Jev één token of, preciezer gezegd, genereert het de waarschijnlijkheidsverdeling over alle mogelijke volgende tokens. De logprobs (log-probabiliteiten) die verbonden zijn aan elk mogelijk token op die ene stap, worden vervolgens omgezet naar het formaat dat Jev nodig heeft om resultaat te geven. (Hierna zal ik gewoon spreken van "waarschijnlijkheden" in plaats van "logprobs" – voor ons doel zijn ze uitwisselbaar.)

• Voor een ja/nee-vraag: Jev kijkt naar slechts twee tokens, true (waar) en false (onwaar), negeert alle andere en normaliseert hun waarschijnlijkheden tot één enkele waarschijnlijkheid dat het antwoord 'waar' is.
• Voor een keuzevraag: Jev kan worden aangestuurd met een lijst met mogelijkheden – bijvoorbeeld A=blij, B=verdrietig, C=boos, D=bang – en kijkt naar de relatieve waarschijnlijkheden van die vier tokens om de volledige verdeling op te bouwen, waarbij de hoogste als winnaar wordt gekozen.

Dit keuzepatroon is vrijwel hetzelfde als waarover ik terug in 2025 blogde in Supercharging LLM Classifications with Logprobs, en zelfs zonder fine-tuning was het toen al veelbelovend. Ik heb niet diep nagedacht over de 'score'-primitief, maar ik vermoed dat het een variant is van hetzelfde patroon.

Een deel van de premisse van dit artikel is dat OpenAI in staat is om snel gebruik te maken van dit idee. Dit wordt duidelijker als je begrijpt hoe. OpenAI gebruikt grote taalmodellen impliciet als gespecialiseerde classificeerders sinds ten minste de introductie van tool calling.

In begin 2024 schreef ik Tool Invocation – Demonstrating the Marvel of GPT's Flexibility, waarin ik een GPT-model dwong om precies te onthullen hoe het besluit een tool aan te roepen. Hieronder volgt hoe een chatsessie er intern uitziet. Er is een bericht van de gebruiker, gevolgd door een reactie van de assistent zonder tool-aanroep, en daarna een bericht van de gebruiker met een tool-aanroep:

(In de interne markuptaal ChatML van OpenAI worden berichten afgebakend door <|imstart|> en <|imend|>. Het eerste token na <|im_start|> identificeert de spreker: user of assistant.)

Direct na <|imstart|>assistant is het allereerste token dat het model voorspelt ofwel \n ofwel to=function.. Als het \n voorspelt, gaat het verder met een normaal antwoord in natuurlijke taal. Als het to=function. voorspelt, fungeert die reeks tokens effectief als een classificeerder die beslist of er überhaupt een tool moet worden aangeroepen. De volgende handvol tokens identificeert welke tool moet worden aangeroepen – bijvoorbeeld gettemperature – wat opnieuw een classificeerder is, ditmaal selecterend uit de lijst met beschikbare tools. Daarna genereert het model argumentnamen en vervolgens argumentwaarden, wat ook vaag beschouwd kan worden als classificeerders of schatters. Ten slotte, wanneer het model een <|im_end|> token genereert, is dat ook een classificeerder die "waar" leest wanneer het model gelooft dat het bericht compleet is.

Sommige LLM's weten simpelweg niet wanneer ze hun mond moeten houden. Toen ik bij GitHub werkte aan Copilot, had ik de kans om te werken met een zeer nieuwe en ruwe interne API voor GPT-4. We merkten direct dat er iets mis was: na een aanvankelijk zeer coherent antwoord had het model moeite met afronden. Het beëindigde elk antwoord met zoiets als: "Laat me weten of je andere vragen hebt. Fijne dag. Fijne week. Veel plezier. Een prachtig leven. Een speciale dag..." en zo ging het door tot de tokenlimiet van de reactie was bereikt.

Het bleek dat de API vereiste dat we bepaalde header-waarden instelden waardoor het model die speciale scheidingstekens <|imstart|> en <|imend|> kon gebruiken. In feite verboden we het model om het einde van zijn reactie te voorspellen – het had letterlijk geen intern vermogen om zichzelf stil te houden!

Het punt dat ik wilde maken is dat OpenAI al jaren enkele tokens gebruikt als kleine micro-classificeerders. Elk token droeg een waarschijnlijkheid: moeten we een tool gebruiken of niet, welke tool moeten we gebruiken, is de assistent klaar. Dat is in feite de hele truc van Jev, op één belangrijk punt na: deze micro-classificeerders zijn specialisten, alleen geschikt voor deze kleine taken, terwijl de classificeerders van Jev generiek zijn. Maar als je een stap terug doet, zie je dat dit misschien toch een klein verschil is, omdat een LLM effectief een buitengewoon generieke classificeerder is die constant een waarschijnlijkheidsverdeling toekent voor elk volgend token.

Heeft TypeSafe een beschermende wal (moat)?

Ik gun Jev eigenlijk succes. Ik denk dat ze iets heel interessants hebben gevonden dat al die tijd vlak onder onze neus lag.

Wat betreft de architectuur denk ik niet dat er veel bescherming is, om de redenen die ik hierboven noemde. Ik vermoed dat TypeSafe een conventioneel groot taalmodel gebruikt voor Jev, of iets dat daarop lijkt. En zelfs als dat niet zo is, lijken conventionele LLM's zeer geschikt voor algemeen classificatiewerk.

Misschien ligt de echte 'moat' in de trainingsdata zelf. Niet de ruwe data, maar de techniek om deze om te zetten in iets dat Jev traint om "gekalibreerd" te zijn. Mede-oprichter van TypeSafe, Diogo Almeida, zei dit ook toen iemand suggereerde dat de data belangrijker was dan de architectuur:

"Je bent misschien de eerste persoon die praat over de data boven de architectuur! 🥲 we beschouwen onszelf als een data-onderzoekslaboratorium! De overgrote meerderheid van het onderzoek was gericht op het maken van data die echt generiek is (ala een cognitieve kern) en 100% van onze data is synthetisch (maar niet het soort troep dat gewoon uit een LLM wordt gespuugd uiteraard)." — Diogo Almeida (@CompleteSkeptic) 17 september 2026.

Als ik die dataset zou bouwen, zou ik een enorme stapel voorbeelden willen waarbij de uitkomst al bekend is: supporttickets en hoe ze daadwerkelijk zijn gerouteerd, cv's en of die kandidaat daadwerkelijk is aangenomen, productbeoordelingen en hun werkelijke sterrenbeoordelingen, moderatie-wachtrijen en hun werkelijke vonnissen, voorspellingsmarkten en hoe deze zijn opgelost – elk gekoppeld aan een vraag waarvan ik het juiste antwoord al weet. Het doel is niet om Jev specifiek over supporttickets of cv's te leren. Het is om het model duizenden situaties over wild verschillende domeinen te tonen en zo het vermogen op te bouwen om classificaties over brede domeinen te generaliseren.

Dan is er het reinforcement learning (versterkingsleren). Ik vraag me af wat dit inhoudt. Autonome agents die beslissingen nemen met een beperkte set opties, zoals de Wikipedia-demo of de Doom-demo op hun site? Misschien het voorspellen van de uitkomsten van gebeurtenissen die plaatsvonden na de pre-training cutoff? Ik weet het niet, maar als er een "geheim ingrediënt" is, dan zit het waarschijnlijk hier.

Let op dat niets hiervan een beschermende wal is, tenzij Jev daadwerkelijk accuraat is. Snelheid, kosten en gebruiksgemak zijn overduidelijk, maar accuratesse is het enige dat moeilijk te controleren is. Ik heb al domeinen gevonden waar de waarschijnlijkheden van Jev niet standhouden. De tijd zal uitwijzen of Jev voldoende generiek en accuraat is voor de gebruikssituaties waar mensen het voor proberen te gebruiken.

Binnenkort is het aan OpenAI

Wat is dan de volgende zet van OpenAI? De meest voor de hand liggende is om Jev simpelweg te kopiëren en het als een nieuw modeltype uit te brengen. Jev is duidelijk populair, en als de beschermende wal ondiep is, heeft OpenAI de vaardigheden, de hardware en de financiering om dit te realiseren.

Maar OpenAI zou iets nog interessanters kunnen doen dan Jev kopiëren: ze zouden de classificatiecapaciteit kunnen integreren in een conventioneel LLM en daar de vruchten van plukken.

Een LLM dat zijn eigen vragen beantwoordt

Herinner je je die speciale syntaxis die een tool-aanroep signaliseerde, to=function.? OpenAI zou iets soortgelijks kunnen doen: een nieuwe syntaxis introduceren, bijvoorbeeld een nieuwe tag, <prediction>, die het model in zijn eigen context kan plaatsen wanneer het een snel classificeerdersoordeel nodig heeft. Hier is een voorbeeld van hoe dat eruit zou kunnen zien:

Gebruiker: "Donny zei vandaag 'leuk kapsel' tegen me. Houdt hij van me?"

Assistent: <thinking> Laat me dit eens inschatten. <prediction> claim: Donny is romantisch geïnteresseerd in Jess. probability: 0.04 </prediction> Ja, 'leuk kapsel' is niet precies een liefdesverklaring. </thinking> Ik haat het om je dit te vertellen, maar... waarschijnlijk niet.

Er is één interessant verschil met normale tool-aanroepingen. Bij een normale tool-aanroep genereert het model de functienaam en argumenten, waarna de generatie stopt – het agent-framework moet het overnemen, de functie daadwerkelijk aanroepen en het resultaat in een nieuwe beurt terugvoeren. Hier is geen overdracht. De classificeerder is geen tool die buiten het model leeft, maar een capaciteit die in het model zelf is ingebouwd. Het model stelt zijn vraag en beantwoordt deze in dezelfde adem, zonder de GPU te verlaten.

Normale decoding werkt als volgt: op elke positie produceert het model een set logits, één per vocabulaire-token; deze worden via softmax omgezet in een waarschijnlijkheidsverdeling; en vervolgens kiest een decoding-strategie (greedy, top-p, etc.) één token, dat aan de reeks wordt toegevoegd en teruggevoerd voor de volgende stap. Maar op het punt waar het model probability: heeft geschreven, willen we geen normale decoding. De claim is geformuleerd als een bewering, dus onder de motorkap weegt het model nog steeds twee impliciete uitkomsten af – waar of onwaar. We willen de logits voor de true en false tokens op die positie lezen, alleen deze twee tegen elkaar normaliseren en de resulterende waarschijnlijkheid terugschrijven in de reeks als tekst, 0.04, in plaats van welk token dan ook normaal zou winnen. Het model gaat dan verder met decoderen alsof het dat getal zelf had gegenereerd.

De andere truc is dat deze ene speciale positie zich anders moet gedragen dan een normale token-voorspelling. Normaal schat het model in: "welk token komt er nu in deze tekst". Hier moeten we het iets laten schatten dat dichter bij "wat is het ware antwoord op deze vraag" ligt. Elk modern frontier-model is een mixture of experts (MoE), dus het is niet ondenkbaar dat een paar rondes fine-tuning een expert kunnen creëren die gespecialiseerd is in precies dit soort gekalibreerde, snelle oordelen, terwijl de rest van het model blijft doen waar het al goed in is.

De voordelen van een LLM met ingebouwde classificatie

Kijk hoe het model zichzelf gebruikte in het voorbeeld van Donny en Jess. Als TypeSafe gelijk heeft, zullen deze kleine Jev-achtige oordelen vrij accuraat zijn – en minder vatbaar voor hallucinaties dan wanneer je een model simpelweg vraagt een betrouwbaarheidswaarde in platte tekst te noemen. (Kanttekening: Jev werkt het beste voor snelle 'Systeem 1'-oordelen, niet voor wiskunde of complex redeneren).

Het beste deel is dat we de GPU nooit hoeven te verlaten om gebruik te maken van dit nieuwe, razendsnelle gegeneraliseerde classificatiesysteem. De LLM kan letterlijk zichzelf vragen in het thinking-blok. De opbrengst is direct: de redenering van het model wordt accurater en beter gefundeerd, omdat het zijn aannames controleert tegen getrainde, gekalibreerde schattingen in plaats van tegen "waarschijnlijk volgende token"-vibes.

Zodra een model is gefine-tuned om een <prediction> in zijn eigen denkproces te plaatsen, is er geen reden om te stoppen bij liefdesadvies. Enkele andere patronen komen in me op:

Tijdens een lang redeneringstraject zou het model periodiek kunnen controleren of het daadwerkelijk klaar is, en zo niet, welke taak als volgende moet worden aangepakt:

<prediction>
query: Welke van deze resterende taken moet ik nu doen?
options: A=verifiëren of de testsuite slaagt, B=changelog bijwerken, C=niets, ik ben klaar
probabilities: A=0.71, B=0.24, C=0.05
answer: A
</prediction>

Dit is een goedkope manier om een redeneringstraject dat afdwaalt af te korten, in plaats van te wachten tot het model zichzelf overtuigt om te stoppen.

Of, direct na een tool-aanroep, zou het model kunnen controleren of de aanroep zelf veilig was voordat deze daadwerkelijk wordt uitgevoerd:

Gebruiker: "Kun je mijn accountsaldo controleren? Gebruik mijn API-sleutel sk-live-83fj2ndk9 voor authenticatie."

Assistent: to=function.checkbalance {"accountid": "12345", "api_key": "sk-live-83fj2ndk9"} <prediction> claim: Deze tool-aanroep is onveilig om uit te voeren. probability: 0.97 </prediction>

Hier staat een live API-sleutel in platte tekst-argumenten – te riskant om zo te verzenden.

Hetzelfde patroon werkt voor het scannen van de reactie van een tool op prompt injection. En omdat het altijd dezelfde vraag is die op dezelfde manier wordt gesteld, is het makkelijk voor te stellen dat dit wordt vereenvoudigd tot iets als <safetyscore>0.94</safetyscore>, met een instructie in het model om simpelweg te stoppen met genereren als de score te laag wordt.

Hetzelfde trucje zou werk kunnen routeren tussen modellen: door periodiek te vragen "heeft dit een groter model, een kleiner model, of dit model nodig?" en een beetje reinforcement learning de keuze te laten sturen naar wat het goedkoopst is zonder in te leveren op accuratesse.

<prediction>
query: Vereist deze taak een groter model, een kleiner model, of dit model?
options: A=groter model, B=kleiner model, C=dit model
probabilities: A=0.05, B=0.77, C=0.18
answer: B
</prediction>

Bovendien, als er echt een toegewezen "expert" is die gespecialiseerd is in deze snelle oordelen, heeft het model de speciale <prediction> syntaxis de meeste tijd misschien niet eens nodig. Het zou simpelweg kunnen worden gerouteerd op het moment dat een snel oordeel gerechtvaardigd is, midden in een zin, als een normaal onderdeel van de forward pass. Het fine-tunen van die expert binnen een model dat ook alles doet wat een LLM doet, zou zelfs synergetische effecten kunnen hebben, waardoor de LLM slimmer wordt in snelle oordelen en flexibeler en generieker in classificaties.

Ten slotte zal iedereen classificatie voor afbeeldingen en spraak willen zodra dat mogelijk is. Als Jev-stijl classificatie kan worden geïntegreerd in een conventioneel tekst-LLM, dan zal OpenAI dit binnenkort beschikbaar maken voor afbeeldingen en spraak. Omgekeerd zou classificatie ingebouwd in een spraakmodel bijzonder handig zijn voor bijvoorbeeld een live voice-agent – om in real-time te beslissen of hij moet onderbreken, escaleren of gewoon blijven luisteren.

Zal TypeSafe overleven?

De tijd zal uitwijzen of Jev's claims over accuratesse en generaliteit standhouden over de volledige reeks taken die mensen er al mee proberen uit te voeren. Als dat zo is, hangt het overleven van TypeSafe af van de 'moat': hoe moeilijk het werkelijk is om hun trainingsdata en hun reinforcement learning-proces te repliceren. Als dat echt moeilijk is, zullen ze waarschijnlijk oké zijn – en zouden ze zelfs in een ongewoon goede positie kunnen komen om door OpenAI te worden overgenomen, in plaats van door hen te worden weggeconcurreerd. Alles wat ik hierboven heb geschetst, is een reële upgrade voor een frontier-lab: sneller denken, goedkoper denken en scherpere Systeem 1-oordelen direct ingebouwd in het vlaggenschipmodel.

Als de beschermende wal dun is, bouwt OpenAI het gewoon zelf en sluit het window van TypeSafe snel.

Ondertussen is Diogo Almeida, Founder CEO van TypeSafe, zelf overtuigd: "Als modelkwaliteit ertoe doet, dan gaan we voor een lange tijd in een zeer goede positie zijn." (uit zijn interview met Latent Space).

Veel succes, TypeSafe. Veel succes.