Jev i modele System One: co to jest i kiedy zamiast LLM

Jev od TypeSafe AI to model, który nie potrafi napisać zdania. Dostaje tekst albo JSON i listę pytań, a oddaje wybraną opcję, liczbę i rozkład prawdopodobieństwa. Wątek premierowy na Hacker News zebrał 1989 punktów, a w ciągu dwóch tygodni powstały co najmniej trzy otwarte klony.

Krótka odpowiedź na pytanie, czy to hype: Jev to ogólny klasyfikator zero-shot, dobrze opakowany w API, tani i szybki. Sam pomysł nie jest nowy, a najgłośniejsze liczby z premiery (“193.6x szybciej, 444.6x taniej”) pochodzą z testów samego TypeSafe. Niezależne pomiary pokazują coś skromniejszego, ale dalej użytecznego: trafność zbliżoną do małych LLM-ów przy koszcie niższym kilka do kilkudziesięciu razy, zależnie od tego, z czym porównujesz.

Od razu jedno zastrzeżenie. Jev jest za waitlistą i nie miałem do niego dostępu. Wszystko poniżej opiera się na dokumentacji TypeSafe, niezależnych pomiarach, kodzie klonów i dyskusji na HN. Tam, gdzie liczba pochodzi od producenta, piszę to wprost.

Podstawowe fakty

Kim jest Almeida: współautor pracy o InstructGPT z 2022 roku, w OpenAI pracował nad RLHF, InstructGPT, ChatGPT i GPT-4. Na blogu sam pisze, że pomagał budować metody, dzięki którym modele zaczęły wykonywać polecenia. TypeSafe na swojej stronie nazywa go współtwórcą RLHF i dopisuje wcześniejszy epizod w Google Brain - to są sformułowania firmy, nie niezależna biografia.

Co to jest model decyzyjny

TypeSafe nazywa tę klasę System One Models, od podziału z książki Daniela Kahnemana Thinking, Fast and Slow: System 1 to szybkie, intuicyjne osądy, System 2 to wolne rozumowanie. Jev ma robić to pierwsze. Dokumentacja opisuje dobre pytanie jako takie, na które kompetentna osoba odpowie w kilka sekund, jeśli ma przed sobą właściwy kontekst. Nazwa “Jev” pochodzi od ekonomisty Williama Stanleya Jevonsa i jego paradoksu: tańsza inteligencja ma oznaczać więcej jej użycia, a nie mniejsze rachunki.

Mechanika jest prosta. Wysyłasz state (tekst albo JSON) i mapę pytań. Każde pytanie ma jeden z trzech typów:

Przykład z quickstartu TypeSafe, skrócony o pytanie typu score:

// Request: POST https://api.typesafe.ai/v1/systemone
{
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP.",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this",
      "criteria": {
        "billing": "Payment or subscription issues",
        "technical": "Bugs or integration problems",
        "sales": "Pricing or account questions"
      }
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}

// Response (fragment)
{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "technical",
      "confidence": 0.78,
      "probabilities": { "technical": 0.85, "sales": 0.0, "billing": 0.15 }
    },
    "is_urgent": { "type": "noul", "noul": 1.0 }
  }
}

“Type-safe” znaczy tu tyle: przestrzeń odpowiedzi deklarujesz z góry. choice może być tylko jednym z kluczy w criteria, prawdopodobieństwa sumują się do 1, a SDK w Pythonie i TypeScripcie typuje odpowiedzi na podstawie pytań. Nie ma parsowania stringa i nie ma odpowiedzi “Oto moja analiza…”.

Dwie rzeczy, które łatwo przeoczyć, a mają konsekwencje w kodzie.

confidence nie jest osobną oceną modelu, tylko statystyką z rozkładu. Dokumentacja pisze wprost, że jest “wyliczana z prawdopodobieństw”. Dla choice z K opcjami to (p_max - 1/K) / (1 - 1/K), co opisuje README klonu Kev, powołując się na referencyjny adapter TypeSafe. Rozkład 0.85 / 0.15 / 0.0 daje więc 0.78, jak w przykładzie wyżej. noul nie ma confidence w ogóle. Jeśli progujesz decyzje, proguj świadomie na tym, co jest w odpowiedzi.

Pytania są oceniane równolegle i w izolacji. Nie widzą się nawzajem, a dodanie kolejnego pytania według TypeSafe prawie nie zmienia czasu odpowiedzi. Płacisz tylko za wejście. To odwraca intuicję z LLM-ów: zamiast jednego sprytnego promptu “oceń ten ticket”, zadajesz dziesięć atomowych pytań i łączysz odpowiedzi w kodzie. W jednym z cookbooków TypeSafe 13 pytań o ten sam dokument w jednym wywołaniu wyszło 12.2x taniej i 10x szybciej niż 13 osobnych wywołań. Koszt spada, bo dokument nie jest wysyłany 13 razy. Czas liczono przy wywołaniach puszczanych jedno po drugim, więc przy równoległych różnica byłaby mniejsza, co autorzy sami zaznaczają.

Heurystyka, którą z tego wyciągam: jeśli w prompcie masz ochotę napisać “pomyśl krok po kroku”, to nie jest pytanie do Jeva. Rozbij je na mniejsze albo zostaw dla modelu z rozumowaniem.

A structured outputs w zwykłym LLM?

Gwarancja typu sama w sobie nie jest nowością. Structured outputs w API Claude, także w Haiku 4.5, obiecują “gwarantowane typy pól” przez constrained decoding. To samo daje strict: true na narzędziach, o którym pisałem przy migracji na Sonnet 5.5.

Różnica leży gdzie indziej. Jev oddaje rozkład prawdopodobieństwa dla każdej opcji jako normalne pole odpowiedzi, nie płacisz za wyjście, a wiele pytań idzie w jednym przebiegu. TypeSafe dokłada do tego tezę, że constrained decoding “ogłupia” LLM-y. Tego nikt niezależnie nie pokazał, a jedyny test, który znalazłem (niżej), wypadł odwrotnie: małe LLM-y ze schematem były minimalnie trafniejsze od Jeva.

Obietnice producenta a to, co zweryfikowano

Najciekawsze są dwa niezależne testy.

Suraj Phanindra porównał Jeva 1.13 z Claude Haiku 4.5, GPT-5.6 Luna i dwoma modelami DeepSeek na routingu ticketów bankowych z CLINC150 (etykiety od ludzi, 30 kolejek, 3 x 300 ticketów, pięć poziomów obciążenia). LLM-y miały constrained output przez mechanizmy dostawców i minimalne rozumowanie. Wynik na ticketach mieszczących się w 30 kolejkach: Jev 92.2%, Luna i Haiku po 93.6%, przy p ok. 0.09, czyli różnica w granicach szumu. Jev był ok. 35x tańszy na wywołanie niż Haiku w cenach listowych. Gdy dał wszystkim modelom wystarczająco dużo równoległych slotów, przewaga kosztowa Jeva nad kolejnym modelem spadła do ok. 3x. A przy cenach z cache DeepSeek V4.1 Flash wyprzedzał Jeva przy 2-20 ticketach na sekundę.

Good Start Labs (mieli wczesny dostęp od lipca) użyło Jeva jako sędziego na 6003 punktach kontrolnych rubryki. Jev zgadzał się z pięcioma LLM-ami w 86-92% przypadków, a LLM-y między sobą w 88-95%. Koszt miliona ocen: $160 Jev, $260 DeepSeek V4.1 Flash, $400 GPT-5.6 Luna, $33 000 Claude Fable 5.1. Autorzy traktują Jeva jako “kolejnego czytelnika, nie ostatnie słowo”.

Te same proporcje widać w evalach samego TypeSafe, jeśli czytać je uważnie. “Accuracy” to tam zgodność ze średnią GPT-6 Astra i Claude Fable 5.1, a nie prawda. Jev ma 67.8%, dokładnie tyle co Sonnet 5 w trybie workflow, i mniej niż Opus 5 (73.1%). Różnica jest w koszcie: $0.0004 kontra $0.1174 na przypadek.

Z tego wychodzi uczciwa wersja obietnicy: Jev nie wygrywa trafnością. Wygrywa ceną i opóźnieniem przy trafności podobnej do małych modeli. Mnożniki rzędu 200-400x to wynik TypeSafe na własnych workflowach, wobec modeli uruchomionych z domyślnym rozumowaniem. Wobec tanich modeli liczby z tego samego źródła są dużo skromniejsze: SiliconANGLE cytuje ze strony TypeSafe $0.39 za 1000 workflowów wobec $3.31 dla GPT-5.6 Luna, czyli ok. 8.5x.

Co pokazała społeczność

“Jev w 25 liniach Pythona”

Wpis NobodyWho z 22 września to deklarowana parodia, ale pokazuje sedno. Autor ładuje Qwen3-0.6B w GGUF przez llama-cpp-python, wstawia do promptu opcje A/B/C i czyta logity tych trzech tokenów z ostatniej pozycji:

logits = model.scores[model.n_tokens - 1]
token_ids = [model.tokenize(text=label.encode(), add_bos=False)[0] for label in labels]
choice_logits = numpy.asarray([logits[token_id] for token_id in token_ids])
logprobs = choice_logits - numpy.logaddexp.reduce(choice_logits)
probabilities = numpy.exp(logprobs)
# Probabilities: {'Legitimate': 0.031, 'Spam': 0.084, 'Phishing': 0.885}

To jest znana od lat technika “LLM jako klasyfikator przez logprobs”. Autor sam wylicza, czego tu brakuje: treningu pod kalibrację, danych, API. W komentarzach na HN padły dwie praktyczne uwagi. Model czatowy “chce” pisać prozę, więc prawdopodobieństwo tokenów odpowiedzi może się rozmywać. A przez maskowaną uwagę w dekoderze opcje lepiej wstawić przed analizowany tekst, żeby model wiedział, czego szuka, zanim go przeczyta.

Otwarte klony: Kev, Jeff, Ollaya

Wszystkie te porównania są na zbiorach autorów klonów, więc nie są kontrolowane. Ciekawsze jest co innego: format state + pytania Choice/Score/Noul w dwa tygodnie stał się de facto standardem interfejsu. Jeśli piszesz kod pod ten kształt, masz lokalny fallback bez przepisywania integracji. SDK TypeSafe przyjmuje base_url, co Kev pokazuje w README.

Argument Arcturus Labs

John Berryman (wcześniej pracował przy GitHub Copilot) stawia tezę, że Jev to w środku najpewniej zwykły LLM, z którego czyta się prawdopodobieństwa tokenów. OpenAI robi to od lat przy tool calling: pierwszy token po assistant decyduje, czy będzie wywołanie narzędzia, kolejne wybierają narzędzie. Więc OpenAI może zarówno skopiować Jeva, jak i wbudować “szybką ocenę z prawdopodobieństwem” w swoje modele. Fosą TypeSafe mają być dane i sposób treningu, nie architektura. Berryman dodaje, że sam znalazł już domeny, w których prawdopodobieństwa Jeva “się nie trzymają”.

Pierwsza część tej tezy sprawdziła się po tygodniu. 29 września, na DevDay, OpenAI ogłosiło Decision API zbudowane na modelu Luna: zwraca odpowiedzi z predefiniowanej listy z oceną pewności, według The New Stack w ok. 150 ms. Na razie jest w ograniczonym preview, bez cennika i bez informacji, ile opcji obsłuży jedno żądanie. Aktualizacja z 8 października: według źródeł wtórnych od 6 października to publiczna beta, a cena ma wynosić $0.10 za milion tokenów wejścia. Tego sam nie potwierdziłem. Porównanie Jeva z Clef od Cloudflare, Strands Decider 2B z AWS, pplx-decider od Perplexity i Decisions API znajdziesz w osobnym wpisie.

Dla mnie wniosek praktyczny jest taki: wiąż architekturę z interfejsem decyzji, nie z dostawcą. Dwa tygodnie po premierze Jeva są już otwarte klony z tym samym API, a według The New Stack także odpowiedź jednego z największych dostawców.

Co mówił wątek premierowy na HN

• Jeden z najwyżej umieszczonych komentarzy: “can’t hallucinate” brzmi źle, bo model nie zwróci złego typu, ale może zwrócić całkowicie błędną wartość poprawnego typu.
• 70-500 ms kontra 3-329 s to porównanie jabłek z pomarańczami, jeśli LLM w tym czasie rozumuje.
• “To po prostu klasyfikator zero-shot.” CEO TypeSafe odpowiedział na to: “exactly right!”.
• Porównania z DeBERTa zero-shot, GLiClass i klasyfikatorami NLI, które robią podobną rzecz od lat, lokalnie.
• Eval TypeSafe mierzy zgodność z dwoma frontier modelami, a nie z prawdą.
• Demo z Doomem działa na ustrukturyzowanym stanie gry, nie na obrazie. TypeSafe to przyznaje w przypisie.

Gdzie model decyzyjny pasuje w pipeline agenta

Zasada z dokumentacji jest dobra niezależnie od tego, czy użyjesz Jeva: kod trzyma sterowanie, model odpowiada na wąskie pytania. CEO TypeSafe opisał to na HN najkrócej: choice to match, score to sortowanie, noul to if. Jev jest semantycznym if-em.

Tak widzę miejsca, w których taki model ma sens w typowym agencie:

Punkty 1, 2, 5 i 6 mają gotowe przepisy w dokumentacji TypeSafe: cookbooki o guardrails, sprawdzaniu cytatów i ekstrakcji po regexie oraz wzorzec intent routing. Vercel w changelogu podaje jako przykłady wybór następnego narzędzia lub subagenta i decyzję “kontynuuj, ponów, zapytaj użytkownika, zatrzymaj”. Według TechCrunch inżynierowie Vercel zastąpili Jevem klasyfikator bezpieczeństwa komend oparty na Lunie.

Moja propozycja, której nie ma w dokumentacji: triage czerwonego CI - flaky test, realny błąd czy problem infrastruktury. Tu trzeba uważać na dwie rzeczy z listy słabości Jeva. Po pierwsze, długi state pełen nieistotnych szczegółów obniża trafność, więc nie wklejaj całego logu, tylko wycięty fragment wokół błędu i nazwę kroku. Po drugie, treści adwersarialne potrafią przesunąć odpowiedź, a log z PR-a z forka to dane od obcej osoby.

Trzy reguły, które przenoszą się na każdy model decyzyjny:

• Progi zależą od ryzyka, nie od modelu. Dokumentacja TypeSafe pokazuje to na przykładzie: poniżej 0.5 pewności zawsze człowiek, operacja tylko do odczytu może iść przy średniej pewności, przelew dopiero powyżej 0.9. Dokładnie tak samo ustawiłbym bramkę przed destrukcyjnym narzędziem agenta.
• Przypnij wersję modelu. Alias jev-latest przesuwa się przy nowym wydaniu, a razem z nim Twoje progi tracą sens. TypeSafe sam to zaleca.
• Mierz odsetek automatyzacji przy budżecie błędów, a nie samą trafność. Pytanie brzmi: jaki procent decyzji mogę puścić bez człowieka, żeby błędów było najwyżej 5%? Kev raportuje dokładnie tę metrykę. Szerzej o mierzeniu pracy agentów pisałem w tekście jak mierzyć pracę agentów AI.

Te punkty kontrolne to nic innego jak “kontrole” z frameworka agent engineering, tylko tańsze w wykonaniu. A jeśli budujesz agenta na zarządzanym harnessie Codexa, model decyzyjny pasuje raczej do Twojej warstwy wokół niego niż do środka.

Jev, mały LLM ze schematem czy klasyczny klasyfikator

Policzmy koszt na cenach z tabeli. Założenia: 1000 decyzji po 1000 tokenów wejścia, 20 tokenów wyjścia w LLM-ie (np. {"department":"technical"}), bez cache i bez rozumowania:

• Jev: 1M tokenów x $0.042 = $0.042
• GPT-6 Luna: $0.10 za wejście + 20K tokenów x $0.50/1M = $0.01, razem $0.11, czyli ok. 2.6x więcej
• Claude Haiku 4.5: $1.00 + $0.10 = $1.10, czyli ok. 26x więcej

To uproszczenie działa na korzyść LLM-ów, bo zakłada ten sam prompt. W teście Suraja wymuszone tool use u Anthropic wysyłało ok. 780 tokenów wejścia więcej niż prompt dla Luny, bo nazwy 31 kolejek pojawiały się dwa razy: w instrukcji i w definicji narzędzia. W drugą stronę działa cache: Jev według zespołu TypeSafe na HN zawsze liczy pełną stawkę za wejście. Jeśli każde pytanie niesie ten sam długi dokument polityki, LLM z cache może odwrócić rachunek, co widać w wyniku DeepSeek V4.1 Flash u Suraja.

Wniosek: wobec Luny Jev jest tańszy mniej więcej 2-3 razy, wobec Haiku ok. 25-35 razy. Aktualizacja z 8 października: 7 października wyszedł Claude Haiku 5.5 za $0.10 / $0.50, więc wobec najnowszego Haiku różnica wynosi już tylko ok. 2.6-3.4x, a w Batch API ok. 1.3x. Liczby o Haiku 4.5 powyżej opisują jego cenę z dnia publikacji. Mnożnik 444.6x ze strony głównej TypeSafe opisuje inne porównanie niż to, przed którym stoisz, wybierając model do routingu. Jak rozdzielać tanie i drogie modele w agencie, opisywałem przy Opus 5.5 vs GPT-6 Sol i Luna.

Kiedy nie używać Jeva

• Gdy wynik ma być tekstem. Odpowiedź dla klienta, podsumowanie, kod. Jev nie generuje, a ekstrakcję robi tylko jako wybór spośród kandydatów, których dostarczysz.
• Gdy chodzi o liczby, liczenie i daty. TypeSafe w liście słabości jev-1.13 pisze wprost: arytmetyka w kodzie, porównywanie dat w kodzie, liczenie elementów w kodzie. Model czyta daty jak tekst.
• Gdy decyzja wymaga kilku kroków rozumowania. Podwójne negacje, “właściwość właściwości”, wnioskowanie w kilku krokach. Tu zostaje model z rozumowaniem.
• Jako jedyna bariera przed prompt injection. Dokumentacja przyznaje, że treść napisana, by sterować modelem, “może przesunąć odpowiedź”. Jev może być jedną z warstw, nie całą obroną.
• Na polskich danych bez własnego evala. Angielski jest głównym językiem treningu. Zanim puścisz Jeva na polskie tickety, zbierz choćby 200 oznaczonych przykładów i sprawdź trafność oraz to, gdzie wypadają progi.
• Gdy dane nie mogą wyjść z UE albo potrzebujesz zero data retention na zwykłym koncie. Usługa działa w USA. ZDR jest dla klientów enterprise, a przez Vercel AI Gateway można go włączyć per żądanie. Polityka prywatności nie podaje konkretnego okresu przechowywania danych, podaje tylko, że nie trenują na Twoich danych.
• Gdy potrzebujesz SLA dzisiaj. To early access. Limity “mogą się zmienić bez uprzedzenia”, a zaraz po premierze API na chwilę przestało obsługiwać ruch z powodu popytu.
• Gdy masz dużo oznaczonych danych i stałą taksonomię. Wtedy klasyczny klasyfikator albo fine-tune otwartego modelu (Kev podaje ok. $1 za przebieg treningu Kev-4B na H100) daje lokalny model bez rachunku za każde wywołanie.
• Gdy decyzję trzeba potem wyjaśnić audytorowi. Jev nie mówi, dlaczego wybrał daną opcję. Dostajesz tylko rozkład.

Moja rekomendacja na dziś: zapisz się na waitlistę, ale projektuj pod interfejs, nie pod dostawcę. Zadaj Jevowi i swojemu obecnemu modelowi te same pytania na tych samych danych, policz odsetek automatyzacji przy dopuszczalnym poziomie błędów i koszt tej automatyzacji. Jeśli Jev wygrywa - świetnie. Jeśli nie, masz gotowy kształt API pod Kev albo Ollayę.

FAQ

Czym jest Jev od TypeSafe AI?

To model, który zamiast tekstu zwraca typowane decyzje: wybór opcji z listy (Choice), pozycję na skali (Score) albo prawdopodobieństwo, że stwierdzenie jest prawdziwe (Noul). Każda odpowiedź ma rozkład prawdopodobieństwa, a Choice i Score także confidence. TypeSafe nazywa tę klasę “System One Models”, od szybkiego, intuicyjnego myślenia z podziału Kahnemana.

Czy Jev naprawdę nie halucynuje?

Nie zwróci wartości spoza zadeklarowanego schematu, ale może wybrać złą opcję, także z wysoką pewnością. Sam TypeSafe pisze w FAQ, że Jev gwarantuje kształt odpowiedzi, nie poprawność decyzji. Wykres z 0% halucynacji na blogu firma sama opisuje jako “nieempiryczny”.

Ile kosztuje Jev i czy jest tańszy od małego LLM?

$0.042 za milion tokenów wejścia, wyjście jest bezpłatne. W teście Good Start Labs milion ocen kosztował z Jevem $160, a z GPT-5.6 Luna $400 (ok. 2.5x). U Suraja Phanindry Jev był ok. 35x tańszy na wywołanie od Claude Haiku 4.5, przy trafności w granicach szumu. Mnożniki 193.6x i 444.6x to wynik TypeSafe na własnych workflowach firmy, wobec LLM-ów z domyślnym rozumowaniem, i sam producent spodziewa się, że leżą raczej na wyższym końcu realnych zysków.

Jak dostać dostęp do Jeva?

Na dziś (29 września 2026) Jev jest w early access z waitlistą na typesafe.ai. Jest też dostępny przez Vercel AI Gateway (typesafe-ai/jev) i Netlify AI Gateway. Nie sprawdzałem, czy te bramki omijają waitlistę. SDK są dla Pythona (typesafe-sdk) i JavaScript/TypeScript (@typesafe-ai/sdk).

Czy są otwarte alternatywy dla Jeva?

Tak. Kev (Jared Palmer, 0.8B-27B na bazie Qwen) i Jeff (0.8B-2B) mają API zgodne z Jevem i działają lokalnie. Ollaya to lokalny runtime dla takich modeli. Na zbiorach ich autorów największe warianty zbliżają się do Jeva, ale Jev lepiej porządkuje pewność odpowiedzi. Te porównania nie są kontrolowane.

Czy Jev działa po polsku?

Dokumentacja podaje, że angielski jest głównym językiem treningu, a inne języki są obsługiwane, “ale nie tak dobrze”. Nie znalazłem żadnych pomiarów na polskich danych. Przed użyciem na produkcji zbuduj własny eval na polskich przykładach i ustal progi pewności na nim.

Źródła: TypeSafe - Introducing System One Models & Jev (premiera, obietnice, zastrzeżenia do evali), TypeSafe - strona główna i FAQ, TypeSafe - zespół, TypeSafe Docs - Quick start, TypeSafe Docs - API, TypeSafe Docs - Models (cena, limity, język, dane), TypeSafe Docs - Confidence, TypeSafe Docs - Jev 1.13 jaggedness, TypeSafe - workflow evals, TypeSafe - Privacy Policy, arXiv - InstructGPT, SiliconANGLE - $40M seed, TechCrunch - pierwsi użytkownicy, TS2 - “445x cost claim is still self-tested”, Vercel - Jev w AI Gateway, Suraj Phanindra - What a Correct Decision Costs, Good Start Labs - Verification is the bottleneck, NobodyWho - Jev in 25 lines of Python, Kev, Jeff, Ollaya, Arcturus Labs - Will OpenAI Eat Jev’s Lunch?, The New Stack - OpenAI Decision API, Hacker News - wątek premierowy, Anthropic - Pricing (Haiku 4.5), Anthropic - Structured outputs, MarkTechPost - GPT-6 Sol i Luna (cena Luny).

EfektywnyDev pisze o AI w praktyce - o tym, co zmienia się w architekturze i w rachunku, gdy zamiast kolejnego promptu wstawiasz do kodu jedną dobrze zadaną decyzję.