Jev 1.13 Uitgelegd: Waarom het Model Antwoordt in Labels in plaats van Zinnen

Jev 1.13 (typesafe/jev-1.13) is geen chatmodel, en de snelste manier om het te begrijpen is om te stoppen met het lezen van de specsheet zoals je elke andere leest. TypeSafe bracht het uit op 15 september 2026 als het eerste lid van een klasse die het bedrijf System One-modellen noemt: je geeft het een stukje toestand en een reeks benoemde vragen, en het geeft één getypeerd antwoord per vraag terug — een label uit een lijst die je hebt aangeleverd, een niveau op een schaal die je hebt gedefinieerd, of een waar/onwaar met een waarschijnlijkheid eraan verbonden. Geen proza, geen code, geen uitleg. Dit is geen artikel over een lancering. Het model zelf is van 15 september 2026, vijftien dagen oud en buiten het venster van zeven dagen waarover deze blog schrijft, dus het verdient geen pagina bij zijn eigen release. Wat binnen het venster gebeurde, is dat OrcaRouter op 24 september 2026 typesafe/jev-1.13 aan zijn eigen catalogus toevoegde en de modelkaart van Jev 1.13 opende op https://www.orcarouter.ai/models/typesafe/jev-1.13 — de eerste keer dat Jev aanroepbaar is via een gateway van een derde partij in plaats van alleen via het eigen endpoint van TypeSafe, en de eerste live servingdata die iemand buiten TypeSafe erover heeft gepubliceerd. Dat is de verandering die het lezen waard is: het model werd uitvoerbaar waar het dat niet was.

De praktische vorm van die verandering is klein en specifiek. Vóór 2026-09-24 betekende het adopteren van Jev een tweede leveranciersrelatie — een TypeSafe-account, een TypeSafe-sleutel, een TypeSafe-factuur, en een op maat gemaakte requestvorm om tegenaan te programmeren. Daarna zit Jev op dezelfde sleutel als de rest van een stack: één API voor 200+ modellen, 0% opslag (de lijstprijs van de provider wordt doorgegeven, dus prijsverlagingen van leveranciers zijn hier dezelfde dag live), en het model bereikbaar op typesafe/jev-1.13 via POST /v1/systemone. Je roept het nog steeds aan in zijn eigen vorm — het endpoint is niet de OpenAI chat-completions-route, en doen alsof dat wel zo is zou een 404 opleveren in plaats van een beslissing — maar het contract dat je ondertekent en de sleutel die je roteert zijn dezelfde die je al hebt.

Wat voor model is Jev?

De lanceringspost van TypeSafe zegt het in één zin: "Ons eerste publieke model is Jev, vanaf vandaag beschikbaar in early access." De post positioneert het model vervolgens als "een frontier-intelligence-functieaanroep: ongestructureerde toestand erin, getypeerde probabilistische beslissingen eruit." Dat is een terechte beschrijving van de interface, en een belangrijke, want bijna elke verkeerde verwachting over Jev komt voort uit het evalueren ervan als een klein taalmodel. Het is geen klein taalmodel. Het is een beslissingsmodel met een vaste uitvoergrammatica, en de grammatica is het product.

De interface heeft precies twee invoeren. De toestand is het materiaal dat beoordeeld moet worden: een e-mail, een supportticket, een logregel, een JSON-record, een reeks spelcoördinaten. De vragen zijn een map van benoemde items, elk met een type, zijn eigen instructies en — voor de twee gestructureerde typen — zijn criteria. Elke vraag wordt tegen diezelfde toestand geëvalueerd, en de antwoorden komen terug als één gestructureerde JSON-payload. De documentatie van TypeSafe beschrijft de vragen als gelijktijdig en onafhankelijk draaiend, en doet twee beweringen die uit dat ontwerp volgen in plaats van uit tuning: het toevoegen van vragen verandert de responstijd nauwelijks, en het toevoegen van vragen zorgt niet voor contextrot, omdat elke vraag geïsoleerd wordt beoordeeld in plaats van stroomafwaarts van de vorige.

TypeSafe's eigen ontwerprichtlijnen zijn het herhalen waard, omdat ze de duidelijkste uitleg vormen van waar het model voor bedoeld is. Houd elke vraag atomair en goed afgebakend — "het soort beoordeling dat een zeer deskundig persoon in een paar seconden zou kunnen maken." Als een beslissing uitgebreid redeneren vereist of echt meerdere onafhankelijke factoren combineert, splits deze dan op in afzonderlijke vragen en combineer ze weer in je eigen code. Hun voorbeeld: in plaats van één prompt "beoordeel deze startup-pitch", vraag afzonderlijk naar marktomvang, technische haalbaarheid en differentiatie, en pas vervolgens je eigen weging toe. De reden dat dit belangrijk is, is dat de weging dan in een coëfficiënt zit die je kunt wijzigen, in plaats van in een prompt die je moet herschrijven.

Het model is gesloten in alle opzichten die ertoe doen voor een ingenieur die over risico redeneert. Jevs architectuur, aantal parameters, rekenkracht voor training en gewichten zijn niet gepubliceerd. Er is geen repository met gewichten in de TypeSafe GitHub-organisatie — de elf openbare repositories daar zijn tooling, SDK's, workflows en drie niet-gerelateerde forks, en geen enkele daarvan is het model.

"Typed" is het hele product

De OrcaRouter-modelkaart publiceert de drie primitieven en, belangrijker nog, de limieten voor elk daarvan. Elke vraag die je Jev stelt, heeft precies een van drie vormen:

• noul — een waar/vals-oordeel, teruggegeven met een gekalibreerde waarschijnlijkheid in plaats van een kale boolean, zodat "waarschijnlijk waar" en "zeker waar" onderscheidbare waarden zijn.

• choice — kies één van maximaal 255 gelabelde opties, waarbij elke optie zijn eigen criteriatekst heeft zodat het model weet wat je labels van elkaar onderscheidt.

• score — beoordeel op een geordende schaal van 2–10 niveaus, met de niveaudefinities die als criteria worden verstrekt.

De lanceringspost van TypeSafe is ongewoon direct over de garantie: het '0%'-cijfer voor schema-mismatch in zijn grafieken "is niet empirisch. Schema-matching is gegarandeerd, dus we kunnen met vertrouwen 0% aan de grafieken toevoegen." Wanneer je antwoordruimte een gesloten set is die je hebt aangeleverd, zit een teruggegeven waarde ofwel in de set, ofwel kwam die niet van het model — er is geen derde uitkomst waarin het model iets plausibels in de verkeerde vorm schreef en je regex het stilletjes accepteerde.

De drie typen zijn ook de reden dat een beoordelaar Jev niet kan evalueren zoals die een chatmodel evalueert. Er is geen MMLU-Pro-score om te vergelijken, geen schrijfvoorbeeld om te lezen, geen redeneerspoor om te inspecteren. De enige vraag die er echt toe doet, is of het getypte antwoord juist is, en of de waarschijnlijkheid die eraan is gekoppeld eerlijk is. Beide zijn meetbaar, maar alleen afgezet tegen jouw data en jouw labels.

Eén gedocumenteerd verschil is het vermelden waard in plaats van het op te lossen: TypeSafe's eigen documentatie toont een Score-voorbeeld dat vanaf nul wordt geïndexeerd, terwijl de OrcaRouter-kaart de schaal publiceert als 2–10 niveaus. De leverancier documenteert niveaus; onze kaart publiceert 2–10. Als je een rubric bouwt bovenop Score, lees dan de niveaudefinities in je eigen reactie in plaats van een index aan te nemen.

Waarom er geen outputtokens zijn om te factureren

De prijsstelling is de zuiverste uitdrukking van de architectuur. Jev kost $0,042 per miljoen inputtokens op OrcaRouter, en het outputtarief is $0,000000 per miljoen — geen korting, geen lanceringspromotie, maar de afwezigheid van een meetbare hoeveelheid. Een generatief model wordt gefactureerd voor de tekst die het schrijft; Jev schrijft geen tekst. Het retourneert een label, een niveau en een waarschijnlijkheid. Er valt niets te tellen aan de outputzijde, dus daar wordt niets in rekening gebracht.

TypeSafe vermeldt hetzelfde getal vanuit de andere richting op zijn homepage — "$42 Per Billion input tokens" — en verbindt daaraan een vergelijkingsclaim: "238x Lower input price than Claude Fable 5.1". Die vergelijking is, net als alles else op de homepage, afkomstig van de leverancier zelf en door niemand gereproduceerd. Maar de rekensom waarop ze rust, kan een lezer gemakkelijk tegen de eigen factuur controleren, en dat is het nuttige deel. Het volume van een beslissingsworkload wordt vrijwel volledig bepaald door hoeveel state je erin stopt, en state is goedkoop op een manier waarop gegenereerde tokens dat niet zijn.

De kopcijfers van de leverancier zijn groter dan de prijsregel en verdienen dezelfde etikettering. TypeSafe adverteert met "193,6x sneller, 444,6x goedkoper" met een voetnoot die dit beperkt tot "workflows voor System One-taken", en publiceert daaronder een uitgewerkt voorbeeld: TypeSafe AI tegen $0,000081 voltooid in 0,114s tegenover LLM's tegen $0,013880 voltooid in 8,566s. De lanceringspost zelf geeft het risico van de framing toe — de 193,6x en 444,6x worden beschreven als waarschijnlijk "aan de bovenkant van de winsten in de echte wereld" te zitten — en merkt op dat de zij-aan-zijdemo een "sterk vereenvoudigde" query gebruikte met voor mensen leesbare sleutels die door de leverancier waren gekozen om "ons model in een gunstig daglicht te stellen." Geen van deze cijfers is onafhankelijk gerepliceerd, en de eigen benchmarkkaart van de leverancier is nog steeds gemarkeerd als in afwachting.

Wat "gekalibreerd" betekent, en wat RLCD is

TypeSafe noemt zijn trainingsmethode zelf: "Reinforcement Learning for Calibrated Decisions (RLCD)". RLCD is een eigen term van TypeSafe, geen algemeen machine-learningacroniem dat ouder is dan het bedrijf, en het optimalisatiedoel ervan staat in de vergelijkingstabel van het lanceringsbericht als "gekalibreerde beslissingen: antwoorden met epistemisch eerlijke waarschijnlijkheden op System One-taken." Het contrast dat dezelfde tabel trekt, is met RLHF, dat optimaliseert voor menselijke voorkeur — teksten en chatreacties die beoordelaars waarderen — en RLVR, dat optimaliseert voor outputs die programmatisch geverifieerd kunnen worden. RLCD optimaliseert voor een derde ding: de waarschijnlijkheid die eraan wordt verbonden dat een antwoord de eigen onzekerheid van het model accuraat weergeeft.

In de praktijk is 'gekalibreerd' een bewering over de betrouwbaarheidsscores, geen garantie dat de antwoorden juist zijn. Een gekalibreerd model dat 0,8 aangeeft op een set vragen, zou voor die set in ongeveer 80% van de gevallen gelijk moeten hebben; het kan bij een individuele vraag nog steeds fout zitten. Dat onderscheid is de eerlijke manier om de regel op de homepage van TypeSafe te lezen: "Nul hallucinaties — Elke Jev-beslissing komt met een betrouwbaarheidsschatting, zodat je software kan handelen wanneer de betrouwbaarheid hoog is en kan escaleren wanneer dat niet zo is." Het is een bewering over een betrouwbaarheidsschatting, geen bewijs van nul fouten, en het tegenwicht is onze eigen data: over de zeven dagen die eindigden op 2026-09-30 meet onze kaart een foutpercentage van 0,49% op Jev-verkeer via OrcaRouter — een cijfer dat eerder in hetzelfde venster 0,57% aangaf, omdat het wordt berekend over een voortschrijdend venster van zeven dagen live playground-verkeer in plaats van een vaste testset. Beide feiten horen in dezelfde alinea: de betrouwbaarheidsscores zijn de kern van het model, en het model faalt in ons verkeer nog steeds bij ongeveer één op de tweehonderd aanroepen.

Het kalibratieverhaal verklaart ook een latencygedrag dat anders op een bug zou lijken. In de launchpost van TypeSafe staat: "Voor keuzes met een hogere cardinaliteit hanteren we een tweetrapsysteem waarbij we onafhankelijk scoren en vervolgens een expliciete keuze maken, vandaar de incidentele vertraging." Een keuze met 255 opties is niet één voorwaartse vergelijking; de leverancier scoort en kiest dan. Als je ziet dat een request tegen een grote labelset opvallend langer duurt dan een noul, dan is dat het gedocumenteerde mechanisme, niet congestie.

Hoe noem je het vandaag?

Op OrcaRouter is het model typesafe/jev-1.13, genaamd "TypeSafe: Jev 1.13" in de catalogus, met een context_length van 65.536 tokens en precies één ondersteund endpointtype: systemone. Je roept het aan met POST /v1/systemone op je OrcaRouter-sleutel, waarbij je een modelveld, een state-veld (string, object of array) en een questions-map meestuurt waarin elke entry een type (noul, choice of score), de bijbehorende instructies en de criteria bevat. Responses zijn één enkele gestructureerde JSON-payload en worden niet gestreamd — er is geen streamingmodus om voor te kiezen.

De eigen bewoording van de kaart voor het contract is "tekst in, gestructureerde JSON uit", en de gepubliceerde limieten zijn de limieten waartegen je moet ontwerpen: niet-streaming, tot ongeveer 64K invoertokens over de gecombineerde status en vragen, waarbij verzoeken boven die limiet worden geweigerd voordat ze het model bereiken. De catalogusvermelding geeft de lijstprijs weer als $0,042 per miljoen invoertokens en toont het voltooiingstarief als nul. Dat zijn de cijfers van de leverancier, ongewijzigd doorgegeven — de proportionele vorm van hoe wij prijzen: 0% opslag op de lijsttarieven van de provider.

Er circuleren twee tokenbudgetten voor dit model en die zijn niet met elkaar in conflict, dus houd ze gescheiden. Het getal 65.536 is de context_length van de kaart en staat gedocumenteerd als ruwweg 64K aan invoer, over state plus vragen samen. Het cijfer 'ongeveer 32.000 tokens' dat eerdere OrcaRouter-artikelen noemen, is alleen het statebudget — de ruimte die je materiaal krijgt voordat de vragen hun deel opeisen. Als je een verzoek budgetteert, is het statebudget het getal dat de payload die je bouwt begrenst; het gecombineerde getal is het plafond voor de hele aanroep.

Wat Jev niet kan, duidelijk gesteld

Het kan geen proza schrijven, samenvatten, vertalen of converseren. Dat is het ontwerp, geen beperking om je voor te verontschuldigen: in de lanceringspost staat dat Jev "het genereren van strings opgeeft", en op TypeSafe's eigen jaggedness-pagina wordt "Generatie" genoemd als een benoemde faalmodus, met daarnaast de instructie "Gebruik een generatief model". Geforceerde generatie is traag en slecht. Als je pipeline een geschreven samenvatting nodig heeft, is Jev het verkeerde onderdeel en geen enkele hoeveelheid promptkunst verandert dat.

Het is geen vervanging voor een generatief model. De workflow waartoe Jev behoort, bevat twee modellen: een generatief model dat leest, schrijft en redeneert in tekst, en Jev dat ernaast zit en de getypeerde calls in milliseconden uitvoert. Dat is de eerlijke voorstelling van zaken bij elke kostenvergelijking op de homepage van de leverancier — de kolom "LLMs" is geen concurrent die wordt verdrongen, het is de andere helft van hetzelfde systeem, en de reden dat de combinatie interessant is, is dat de beslissingshelft nu op dezelfde sleutel zit als de generatieve helft in plaats van achter een eigen contract.

En "gekalibreerd" betekent niet correct. Het betekent dat het getal dat aan een antwoord is gekoppeld, leesbaar moet zijn als een waarschijnlijkheid. Een 0,62 op een noul is het model dat je vertelt dat het niet zeker is, wat nuttige informatie is die een kaal ja/nee teniet zou hebben gedaan — en het is geen belofte dat het ja juist is. Escalatielogica gebouwd op het vertrouwen is het beoogde patroon; het antwoord als grondwaarheid behandelen is dat niet.

De cijfers eerlijk lezen.

Elke prestatie-indicator op onze kaart komt uit ons eigen verkeer via de playground van OrcaRouter over een voortschrijdend venster van zeven dagen, niet uit de benchmark van de leverancier, en het venster verschoof terwijl dit stuk werd geschreven — zie het als een momentopname, niet als een specificatie. Voor de zeven dagen eindigend op 2026-09-30: mediane tijd tot eerste token 151 ms, p95 247 ms, outputdoorvoer rond 349 tokens per seconde, foutpercentage 0,49% en 76,2 miljoen geleverde tokens. De dagelijkse p50 over het venster bedraagt achtereenvolgens 175, 170, 163, 161, 170, 147 en 143 ms — een licht verbeterende lijn. De p95 van 2.448 ms op 09-28 is een echte eendaagse uitschieter in die reeks, en die als de norm aanhalen zou even onjuist zijn als die volledig weglaten oneerlijk zou zijn.

Nog een kanttekening bij het verkeerscijfer: 349 outputtokens per seconde klinkt als de doorvoer van een generatief model, totdat je bedenkt dat Jev geen gegenereerde tekst produceert. De meter meet wat onze playground aan de responszijde telt voor een gestructureerde payload, en hij is nuttig voor het opsporen van degradatie tussen dagen, in plaats van voor het vergelijken van Jev met een chatmodel.

Dat zijn onze cijfers. De cijfers van de leverancier zijn de 193,6x, de 444,6x, het uitgewerkte voorbeeld van $0,000081 en de 238x-vergelijking met Claude Fable 5.1 — allemaal van TypeSafe zelf, geen ervan onafhankelijk gereproduceerd, allemaal door hun eigen voetnoten specifiek beperkt tot System One-taakworkflows. De enige prestatieclaim van TypeSafe die helemaal geen benchmark is, en meer waard is dan de vermenigvuldigers, is een structurele claim: omdat de antwoorden getypeerd zijn, heeft de integratie geen parsestap en geen schemavalidatiestap, en dat is een kostenpost die in geen enkele latentietabel voorkomt.

Wat is open, en wat niet

Gecontroleerd op 2026-09-30: de TypeSafe GitHub-organisatie publiceerde elf repositories. Geen enkele bevat Jev. Degenen die ertoe doen voor een ontwikkelaar die het model integreert, zijn allemaal MIT of Apache-2.0: skills (MIT), system-one-adapter-python (MIT, beschreven als een "Drop-in TypeSafeClient-vervanging ondersteund door LLM-API's"), typesafe-sdk-js (MIT), typesafe-sdk-python (MIT), daggerverse (Apache-2.0), WorkflowEvals (Apache-2.0, met workflowcode gepubliceerd op evals.typesafe.ai), n8n-nodes-typesafe-ai (MIT), typesafe-ai.github.io en pulumi-clickhouse. Sterrenaantallen en pushdatums veranderen, dus als je dit later leest, controleer het opnieuw in plaats van de lijst te vertrouwen.

Drie van de elf zijn forks van niet-gerelateerde projecten en bewijzen niets over hoe Jev werkt: een vLLM-fork die voor het laatst in mei 2025 is gepusht, een LLaDA-fork uit juni 2025 — LLaDA is een niet-gerelateerde release van een diffusietaal模型 — en een Pulumi-provider voor ClickHouse Cloud. Het is verleidelijk om architectuur uit een fork-lijst af te lezen. Doe dat niet: niets aan Jevs ontwerp volgt uit die drie, en in het bijzonder is Jev geen diffusiemodel, hoezeer de aanwezigheid van een LLaDA-fork dat ook zou kunnen suggereren.

Het eerlijke antwoord in één regel op "is Jev open source" is dat de tooling open is en het model niet. Dat is een normale regeling voor een gehost frontier-model, en het is de regeling die je moet aannemen wanneer je rond Jev plant: een API met een gepubliceerde prijs, een gedocumenteerd contract en een niet-gepubliceerd aantal parameters.

Waar de leverancier zegt dat Jev onbetrouwbaar is.

TypeSafe publiceert zijn eigen jaggedness-pagina voor jev-1.13, voor het laatst beoordeeld op 2026-09-17, met daarin waar het model faalt. Die is ongewoon openhartig en het is de juiste plek om een sectie over beperkingen te beginnen, omdat het de eigen lijst van de leverancier is en niet die van een concurrent:

• Letterlijke lezing — het neemt de formulering letterlijk. Afbakeningswoorden, ontkenningen en impliciete voorwaarden worden niet afgeleid; het "beantwoordt de vraag die je hebt geschreven, niet de vraag die je bedoelde." De oplossing van de leverancier is om voor elke optie de exacte voorwaarde en de criteria op te schrijven.

• Wiskunde en getallen — het is geen rekenmachine, en het telt niet betrouwbaar. Houd rekenkundige bewerkingen in code.

• Vergelijking van datums en tijden — datums worden als tekst gelezen, niet als geordende grootheden, dus ordening, hiaten en vensters zijn onbetrouwbaar, en dat wordt erger bij gemengde formaten.

• Indirectie — dubbele negaties en multi-hop-redeneringen verminderen de nauwkeurigheid. Verminder het aantal hops en verwijs naar de relevante toestand.

• Grote state vol irrelevante details — niet-relevante inhoud werkt als afleiding en de nauwkeurigheid daalt naarmate de state groeit. Filter eerst.

• Adversariële inhoud — de toestand wordt niet als vijandig behandeld, waardoor geïnjecteerde instructies of misleidende framing antwoorden kunnen beïnvloeden.

• Tegenstrijdige instructies en criteria — wanneer de twee om verschillende dingen vragen, kan het model "in de war raken."

• Common-sense-structuurinvarianten — P(noul) en 1 − P(niet noul) zijn niet gegarandeerd consistent. Bevraag elke beslissing op één manier en handhaaf identiteiten in code.

• Generatie — al behandeld, en het advies van de leverancier zelf is om een generatief model te gebruiken.

Twee hiervan verdienen nadruk. De adversariële is belangrijk omdat Jevs hele waardepropositie het beoordelen van niet-vertrouwd materiaal is, en een toestand die instructies bevat kan een antwoord veranderen; als jouw toestand van gebruikers afkomstig is, is dat een prompt-injectieoppervlak met dezelfde vorm als elk ander. Die met de structurele invarianten is belangrijk omdat een "gekalibreerd" model je uitnodigt om te rekenen met zijn waarschijnlijkheden, en de leverancier zegt je niet te veronderstellen dat de berekening sluitend is.

Waartoe het lanceringsbericht zich wel verbindt, en waartoe niet.

Bijna elke bewering van de leverancier die in dit stuk wordt aangehaald, is terug te voeren op één pagina: de eigen aankondiging van TypeSafe, geplaatst onder Bedrijfsnieuws en gedateerd 2026-09-15, ondertekend door oprichter Diogo Almeida. Het is de twee minuten waard om die rechtstreeks te lezen, want de formulering van één regel bepaalt de voorwaarden voor alles sindsdien. "Ons eerste publieke model is Jev, vanaf vandaag beschikbaar in vroege toegang." Vroege toegang is de eigen beschrijving die de leverancier geeft van de beschikbaarheid op zijn eigen platform, en dat is een beperktere bewering dan ze lijkt — ze verplicht TypeSafe ertoe het model te serveren aan goedgekeurde gebruikers, en zegt niets over wie het nog meer mag serveren. Dat is precies het gat dat de catalogustoevoeging van 2026-09-24 dichtte, en de reden waarom de modelkaart meer ertoe doet dan het bericht voor iedereen die Jev vandaag beoordeelt.

Dezelfde pagina is even duidelijk over haar eigen beperkingen, en daarom wordt ze hierboven geciteerd in plaats van geparafraseerd. Ze publiceert geen parameteraantal, geen architectuurbeschrijving verder dan "een nieuwe modelarchitectuur", geen trainingscompute en geen gewichtenrepository, en ze geeft geen datum of voorwaarden voor algemene beschikbaarheid. Die afwezigheden zijn de planningsbeperkingen: een API met een gepubliceerde prijs aan de ene kant, en een stack waarvan je de interne werking niet kunt inspecteren aan de andere. De post kadert het model ook eerlijk genoeg om bruikbaar te zijn als een spec — "een frontier-intelligence-functieaanroep: ongestructureerde toestand erin, getypeerde probabilistische beslissingen eruit" — wat de enige zin erin is die de interface beschrijft in plaats van de ambitie.

Vragen die deze interface oproept

Wat gebeurt er als een keuzeset groter is dan 255 opties? Die wordt afgekapt — 255 gelabelde opties is het plafond voor een keuzevraag, en de tweetrapsaanpak van de leverancier (eerst scoren, dan kiezen) is wat er gebeurt naarmate het aantal toeneemt, wat ook de gedocumenteerde oorzaak is van incidentele vertragingen bij grote labelsets. Is je taxonomie groter dan dat, dan is het ontwerpantwoord: opsplitsen in meerdere vragen en weer samenvoegen in code — hetzelfde advies dat TypeSafe geeft voor samengestelde beoordelingen.

Betekent de context van 65.536 tokens dat er 65.536 tokens aan state zijn? Nee. Het gepubliceerde budget is ongeveer 64K tokens voor de gecombineerde state en alle vragen, en het cijfer "ongeveer 32.000 tokens" dat in oudere berichtgeving opduikt, is alleen het budget voor de state. Begroot uw payload op basis van het state-cijfer, niet op basis van het gecombineerde cijfer, en houd er rekening mee dat verzoeken boven de limiet worden afgewezen voordat het model wordt bereikt.

Wat te doen met dit

Jev 1.13 is om één specifieke reden het bekijken waard, en niet om een algemene reden. Als je een stap in je pipeline hebt die momenteel een chatmodel is waarvan wordt gevraagd een label terug te geven en waarvan wordt vertrouwd dat het dat in de juiste vorm doet — een router, een beoordelaar, een beleidscontrole, een rubriekscore toegepast op duizenden records — dan is die stap wat dit model vervangt, voor $0,042 per miljoen inputtokens, terwijl er aan de outputkant niets wordt gemeten. Als je een stap hebt die een geschreven antwoord nodig heeft, dan is Jev niet het gereedschap, en dat zegt de leverancier zelf ook.

Wat er de afgelopen week is veranderd, is niet het model. Het is dat het uitproberen ervan niet langer een tweede leveranciersrelatie vereist. Acht dagen geleden betekende een Jev-evaluatie een apart account en een aparte integratie; vandaag is het één model-id op een sleutel die al 200+ modellen bereikt, met de lijstprijs van de leverancier ongewijzigd doorgegeven en de getypte antwoorden die van dezelfde plek terugkomen als al het andere. Voor een model dat zo ongewoon is, vormt de mogelijkheid om het tegen je eigen labels te testen zonder je aan een nieuw contract te binden het grootste deel van de beslissing.