Jev – новий if/else, за який тепер платять токенами?

Коротка відповідь. Jev – це нова модель від TypeSafe AI, яка не генерує текст взагалі. Ти даєш їй стан (текст або JSON) і типізовані запитання, а вона повертає рішення: вибір зі списку, оцінку за шкалою або ймовірність «так/ні» – з каліброваною впевненістю і за 70–500 мс. Фактично це «if/else на стероїдах» для випадків, коли умова написана природною мовою. Це не заміна LLM і тим паче не заміна бізнес-логіки – це окремий, вужчий інструмент. Розбираємось, коли він доречний, а коли це просто дорогий класифікатор.

Новий if/else

Кожен із нас колись писав щось таке:

if (message.toLowerCase().includes('термінов')) {
  return 'high_priority';
}

І воно навіть працювало. Рівно до моменту, коли клієнт написав «та не горить, але бажано швидше», і твій includes() відправив його в чергу з пожежами. Або навпаки: «У МЕНЕ ВСЕ ЗЛАМАЛОСЬ І НІЧОГО НЕ ПРАЦЮЄ!!!» без жодного ключового слова спокійно осів у стандартній черзі на три дні.

П'ятнадцятого вересня 2026 року компанія TypeSafe AI вийшла зі стелсу з моделлю Jev і сміливою заявкою: спеціальна модель, яка нічого не пише, а лише приймає рішення. Запуск зібрав тред на ~1800 поінтів на Hacker News, інтеграції з'явились у Vercel AI SDK і LangChain, а компанію заснував Diogo Almeida – колишній дослідник OpenAI і один зі співавторів RLHF.

Іронія ситуації прекрасна: десятиліттями ми писали умови руками. Потім навчили величезні моделі писати умови за нас. А тепер з'явилась окрема модель, робота якої – вирішувати, в яку гілку if/else заходити. Коло замкнулося. Питання лише одне: навіщо це, якщо if/else безкоштовний?

Що таке Jev насправді

TypeSafe називає Jev «першою System One моделлю» – відсилка до Канемана з його швидкою інтуїтивною «системою 1» і повільною аналітичною «системою 2». Якщо звичайні LLM – це «система 2», яка розмірковує токен за токеном, то Jev – «система 1»: миттєва відповідь без внутрішнього монологу.

Технічно за цим стоять три речі, які компанія описує в анонсі:

• Неавторегресивна генерація. Звичайна LLM передбачає наступний токен, потім наступний, і так сотні разів. Jev видає всі відповіді за один прохід, паралельно. Звідси і швидкість: TypeSafe заявляє 70–500 мс end-to-end.
• Жодного тексту. Модель фізично не вміє генерувати рядки. На виході – лише типізовані структури з наперед заданої схеми.
• RLCD (Reinforcement Learning for Calibrated Decisions) – метод тренування, оптимізований не під «сподобатись людині», а під чесні, калібровані ймовірності. Тобто коли модель каже «впевненість 0.9», це має статистично означати ~90% влучань.

Три типи рішень

За офіційною документацією, запити до Jev складаються зі стану і набору запитань трьох типів. Усі запитання оцінюються паралельно й ізольовано за один виклик:

• Choice – «обери варіант зі списку». Повертає choice, розподіл probabilities і confidence. Класика: «який відділ має обробити цей тикет?». Обмеження: до 255 варіантів.
• Score – «оціни стан за рубрикою». Повертає score, розподіл і confidence. Наприклад: «наскільки токсичний цей коментар за шкалою 1–5?».
• Noul – «чи істинне це твердження?». Повертає одне число від 0 до 1 – ймовірність «так». Окремого поля confidence немає: у бінарного розподілу саме це число і є повним описом упевненості.

Зверни увагу, чого тут немає: генерації відповіді клієнту, реферування, «поясни свій хід думок». Jev не розмовляє. Якщо тобі потрібен текст – це до звичайних LLM, і про це чесно пише сам вендор: модель «повністю відмовляється від генерації рядків».

Jev + TypeScript: запускаємо свій перший AI-powered if/else за 10 хвилин

Теорія теорією, але руки сверблять. Нижче – повний шлях від порожньої папки до працюючого прикладу. Обидва сніпети скомпільовані проти реального SDK версії 0.6.0 у strict-режимі TypeScript; живий виклик API я не виконував (для нього потрібен власний ключ), тож приклади виводу нижче позначені як ілюстративні.

Крок 1 – ключ і залізне правило

Реєструйся на console.typesafe.ai і створи API key. Далі правило, яке не обговорюється: ключ живе лише в змінних оточення на сервері. Не в коді, не в git, не в React-компоненті. Створи файл .env і одразу додай його в .gitignore:

echo 'TYPESAFE_API_KEY=твій-ключ-сюди' > .env
echo '.env' >> .gitignore

Крок 2 – порожній проєкт за хвилину

Потрібен Node.js 20+. Далі:

mkdir jev-typescript-demo
cd jev-typescript-demo

npm init -y
npm pkg set type=module
npm install @typesafe-ai/sdk
npm install -D typescript tsx @types/node

Рядок npm pkg set type=module – не косметика: без нього TypeScript зустріне тебе помилкою TS1309 про top-level await. Я на це наступив, поки готував приклад, тож ти вже не мусиш.

Мінімальний tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "strict": true,
    "noEmit": true,
    "types": ["node"]
  }
}

Крок 3 – перший AI if/else

Створи first.ts. Задача максимально життєва: визначити, чи повідомлення термінове.

import { noul, TypeSafeClient } from '@typesafe-ai/sdk';

const client = new TypeSafeClient(); // ключ бере з process.env.TYPESAFE_API_KEY

const message = process.argv[2] ?? 'Та не горить, але бажано швидше.';

const { answers, usage } = await client.systemOne({
  state: message,
  questions: {
    isUrgent: noul('Чи потребує це повідомлення термінової реакції?', {
      true: 'Щось зламалось, хтось втрачає гроші або доступ прямо зараз',
      false: 'Питання може почекати стандартної черги',
    }),
  },
});

const probability = answers.isUrgent.noul; // number від 0 до 1

if (probability > 0.7) {
  console.log(`🔥 Терміново (${(probability * 100).toFixed(0)}%) – будимо чергового`);
} else if (probability > 0.4) {
  console.log(`🤔 Незрозуміло (${(probability * 100).toFixed(0)}%) – хай гляне людина`);
} else {
  console.log(`😴 Не горить (${(probability * 100).toFixed(0)}%) – у звичайну чергу`);
}

console.log(`Витрачено токенів: ${usage.input_tokens} (вихідні – безкоштовні)`);

Запуск:

npx tsx first.ts "У нас упав прод і клієнти дзвонять!"

Що повертає модель: об'єкт answers, де кожен ключ відповідає твоєму запитанню. Для Noul це одне число noul від 0 до 1 – одночасно і відповідь, і впевненість (у бінарного розподілу інших ступенів свободи просто немає). Плюс usage із витраченими токенами. Вивід виглядатиме приблизно так (ілюстративно – без ключа реальний запуск повертає 401, що я особисто перевірив):

🔥 Терміново (91%) – будимо чергового
Витрачено токенів: 43 (вихідні – безкоштовні)

Вітаю: твій if/else тепер має власний API key. Залишилося додати йому Kubernetes.

Крок 4 – додаємо відділ: Choice і Noul разом

Одне запитання – це розминка. Сила systemOne у тому, що всі запитання оцінюються паралельно за один виклик. Створи triage.ts:

import { choice, noul, TypeSafeClient } from '@typesafe-ai/sdk';

const client = new TypeSafeClient();

async function triage(message: string) {
  const { answers } = await client.systemOne({
    state: message,
    questions: {
      department: choice('Який відділ має обробити це звернення?', {
        billing: 'Оплати, підписки, рахунки, повернення коштів',
        technical: 'Помилки, збої, щось не працює',
        account: 'Доступ, email, паролі, налаштування профілю',
        other: null,
      }),
      isUrgent: noul('Чи потребує звернення термінової реакції?'),
    },
  });

  // TypeScript сам знає, що department.choice – це
  // 'billing' | 'technical' | 'account' | 'other'. Спробуй одрукуватись
  // у switch нижче – компілятор упіймає.
  const department = answers.department;
  const urgent = answers.isUrgent.noul > 0.7;
  const needsHuman = department.confidence < 0.6;

  if (needsHuman) {
    return { queue: 'human-review', urgent } as const;
  }

  switch (department.choice) {
    case 'billing':
      return { queue: 'billing', urgent } as const;
    case 'technical':
      return { queue: urgent ? 'oncall' : 'technical', urgent } as const;
    case 'account':
      return { queue: 'account', urgent } as const;
    case 'other':
      return { queue: 'triage-inbox', urgent } as const;
  }
}

console.log(await triage('Не можу зайти в акаунт, а через годину демо клієнту!'));

npx tsx triage.ts

Найприємніша частина тут – типи. SDK використовує const generics: ключі, які ти передав у choice(), стають літеральним union-типом відповіді. answers.department.choice – це не string, а рівно 'billing' | 'technical' | 'account' | 'other', тому switch вище – вичерпний, і одруківка в назві гілки не переживе компіляцію. У Choice, на відміну від Noul, є окреме поле confidence і повний розподіл probabilities по всіх варіантах – саме на confidence ми вішаємо рішення «віддати людині».

Це іграшкова версія того, що в наступному розділі виросте в production-приклад із fallback-ами й обробкою помилок – не повторюватимусь, там усе є.

Крок 5 – типові граблі

• Забутий ключ. Без TYPESAFE_API_KEY перший же виклик впаде з AuthenticationError (401). SDK кидає типізовані помилки – APIError, RateLimitError, APITimeoutError – лови їх, а не загадковий unknown.
• Ключ у браузері. Спроба створити TypeSafeClient у React-компоненті на клієнті – і SDK відмовиться працювати: у конфігу є прапорець dangerouslyAllowBrowser, який за замовчуванням false, і назва в нього така не випадково. Правильна схема для Next.js: фронт шле текст на свій Route Handler (app/api/triage/route.ts) або викликає Server Action, а ключ живе тільки на сервері. Для чистого React – той самий принцип із будь-яким бекендом.
• Відсутність обробки помилок. Дефолтний таймаут – 10 секунд, ретраїв – 2. Зовнішній сервіс у критичному шляху без try/catch і плану Б – це інцидент, який просто ще не стався.
• Пороги «зі стелі». 0.5 усюди – майже завжди неправильно. Поріг залежить від ціни помилки в конкретній гілці: про це детально в розділі про production нижче.
• Сліпа довіра. Типізована відповідь – не означає правильна. Але про це вже вся друга половина статті.

Крок 6 – міні-челендж

Домашка на 15 хвилин, щоб помацати модель руками:

1. Додай у triage.ts категорію spam з описом на кшталт «реклама, фішинг, нерелевантні розсилки».
2. Прожени три повідомлення і подивись не лише на choice, а й на весь розподіл probabilities:
   • «Вітаємо! Ви виграли мільйон, перейдіть за посиланням» – очікувано spam?
   • «Після оновлення застосунок вилітає на старті» – technical, але наскільки термінове?
   • «ТЕРМІНОВО!!! забув пароль» – капс кричить, а чи кричить ймовірність?
3. Посунь поріг isUrgent з 0.7 до 0.4, потім до 0.85 – і подивись, як ті самі повідомлення мігрують між гілками.

Реальні відповіді моделі наводити не буду – у мене немає твого ключа, а вигадувати цифри в статті про калібровані ймовірності було б особливо іронічно. Проганяй – і побачиш свої.

Спробуй сам: твій if/else тепер із AI

Читати про різницю між правилами і моделлю – одне, а потикати її пальцем – інше. Нижче – інтерактивне демо: чотири готові повідомлення клієнтів і два підходи поруч. Лівий стовпчик – справжній детермінований класифікатор на ключових словах, який виконується прямо в твоєму браузері. Правий – наперед підготовлені результати в стилі Jev для тих самих повідомлень (реальний API зі статті не викликається – і чому саме, демо чесно пояснює).

Особливо звертай увагу на четвертий сценарій: там ключові слова сідають у калюжу найцікавішим способом.

Живий приклад: тріаж підтримки на TypeScript

Класичний сценарій: у сервіс підтримки падає повідомлення, треба визначити відділ, терміновість і чи потрібна людина. Спершу – як ми всі це писали:

type Routing = { department: string; urgent: boolean };

function routeTicketOldSchool(text: string): Routing {
  const lower = text.toLowerCase();

  const urgent =
    lower.includes('термінов') ||
    lower.includes('не працює') ||
    lower.includes('зламал');

  if (lower.includes('оплат') || lower.includes('рахунок')) {
    return { department: 'billing', urgent };
  }
  if (lower.includes('помилк') || lower.includes('баг')) {
    return { department: 'technical', urgent };
  }
  return { department: 'other', urgent };
}

Це рішення має дві чесні переваги: воно детерміноване і безкоштовне. І два фатальні недоліки: «мене розлогінило і кошик зник» не містить жодного твого ключового слова, а список синонімів, якими люди описують «все зламалось», нескінченний. Через півроку цей файл перетворюється на музей регулярок, які всі бояться чіпати.

Тепер те саме через Jev – це вже доросла версія іграшкового triage.ts із квікстарту: з fallback-ом, обробкою помилок і явною відмовою вгадувати. Повна документація SDK – docs.typesafe.ai/sdk/javascript:

import { choice, TypeSafeClient } from '@typesafe-ai/sdk';

const client = new TypeSafeClient(); // ключ бере з process.env.TYPESAFE_API_KEY

type Ticket = { id: string; text: string };

type TriageResult =
  | { action: 'route'; department: string; urgent: boolean }
  | { action: 'human'; reason: string };

async function triageTicket(ticket: Ticket): Promise<TriageResult> {
  try {
    const response = await client.systemOne({
      model: 'jev-latest',
      state: { document: ticket.text },
      questions: {
        department: choice('Який відділ має обробити це звернення?', {
          billing: null,
          technical: null,
          account: null,
          other: null,
        }),
        isUrgent: {
          type: 'noul',
          instructions: 'Чи потребує звернення термінової реакції?',
          criteria: {
            true: 'Клієнт втратив доступ чи гроші, або сервіс не працює',
            false: 'Питання може почекати стандартної черги',
          },
        },
      },
    });

    const department = response.answers.department;
    const urgent = response.answers.isUrgent.noul > 0.7;

    // Патерн confidence-gated routing з офіційної документації:
    // нижче 0.6 впевненості – не вгадуємо, а віддаємо людині.
    if (department.confidence < 0.6) {
      return { action: 'human', reason: 'low-confidence routing' };
    }

    return { action: 'route', department: department.choice, urgent };
  } catch (error) {
    // API недоступне – деградуємо до детермінованих правил,
    // а не кладемо чергу підтримки разом із зовнішнім сервісом.
    const fallback = routeTicketOldSchool(ticket.text);
    return { action: 'route', ...fallback };
  }
}

Кілька чесних приміток до коду:

• Приклад зібраний за офіційною документацією та типами SDK; я не ганяв його у production і не маю власних метрик – коли будеш впроваджувати, почни з playground у консолі TypeSafe.
• Поріг 0.7 для Noul – не магія, а компроміс із гайда по порогах: піднімай його, коли хибне «так» дороге (дарма розбудити чергового), опускай, коли дороге пропущене «так» (не помітити реальну пожежу).
• try/catch тут не декорація. Зовнішній сервіс у критичному шляху – це нова точка відмови, і твій fallback має бути написаний до першого інциденту, а не після.

Різниця з if/else концептуальна: ти більше не перелічуєш формулювання, якими люди описують проблему. Ти описуєш критерії рішення, а розпізнавання формулювань – проблема моделі.

Де це реально застосовують

1. Роутинг в AI-агентах. Найпопулярніший кейс у гайдах Vercel: агентський цикл на кожній ітерації вирішує «який інструмент викликати далі», «продовжити, перепитати чи зупинитись». Ці рішення відбуваються десятки разів на сесію, і ганяти заради кожного велику LLM – дорого і повільно. AI SDK 7 виставляє Jev через експериментальний evaluate API. Обмеження: якщо рішення потребує міркування на кілька кроків – це знову задача для «системи 2».

2. Тріаж підтримки. Розібраний вище. Виграш у порівнянні з малою LLM – швидкість, ціна і калібрована впевненість замість «JSON, який теж треба валідувати». Коли НЕ треба: якщо у тебе три категорії і чіткі формальні ознаки – звичайні правила дешевші й пояснюваніші.

3. Запобіжник для coding-агентів. LangChain у своєму матеріалі показує AutoModeMiddleware: перед виконанням tool call агента Jev оцінює, чи не робить той щось ризиковане, і блокує виклик до виконання. Важлива межа, яку варто промовити вголос: імовірнісна модель не може бути єдиним запобіжником. rm -rf у проді має зупиняти детермінований allowlist і права доступу, а Jev – це додатковий шар для сірих зон, не заміна їм.

4. Оцінка виходів інших моделей. LLM-as-a-judge – звична практика, але суддя-LLM повільний і сам схильний до галюцинацій у вільному тексті. Jev у ролі судді повертає рівно те, що потрібно пайплайну: score за рубрикою і ймовірність «відповідь відповідає джерелам». Це ж основа guardrail-сценаріїв, які TypeSafe називає серед основних.

5. Модерація контенту. Noul («чи порушує це правило X?») плюс поріг, нижче якого кейс іде людині-модератору. Патерн той самий, що в тріажі: модель фільтрує очевидне, людина розбирає неоднозначне. Тут особливо важлива калібровка: некаліброване «0.93» у модерації – це юридична проблема, а не технічна.

6. Автоматизація пошти й workflow. А ось тут – чесна крапля скепсису. Якщо твій сценарій «раз на годину класифікувати листи в CRM», то виграш Jev у латентності тобі байдужий: лист і так лежить у черзі. Мала LLM зі structured output або навіть звичайний класифікатор впораються, а різницю у вартості на таких обсягах ти не помітиш. Jev починає мати сенс на великих потоках і в реальному часі – map-reduce по мільйону документів, а не по десяти листах.

Швидкість і ціна: що заявлено, а що перевірено

Цифри, які розійшлись заголовками: 193.6x швидше і 444.6x дешевше за LLM. Тут потрібна чесність, якої часто бракує оглядам:

• Це результати власних workflow-евалів TypeSafe на пропрієтарних задачах бізнес-автоматизації, зібраних власною командою. Незалежних публічних бенчмарків на момент написання немає, і компанія сама визнає можливий bias.
• Порівняння 70 мс проти «3–329 секунд у frontier-моделей» на Hacker News одразу назвали порівнянням теплого з м'яким: великі моделі в цих замірах виконують значно ширшу роботу.
• Прайс справжній і простий: $0.042 за мільйон вхідних токенів, вихідні – безкоштовно (їх там і генерувати нічого). Це на порядки нижче за frontier-моделі, але порівнювати чесно треба з малими LLM і класифікаторами, а не з найдорожчим у меню.

Концептуальна таблиця замість вигаданих чисел:

Підхід	Латентність	Вартість	Детермінізм	Обслуговування
if/else + правила	наносекунди	безкоштовно	повний	росте з кількістю правил
Класичний ML-класифікатор	мілісекунди	хостинг	ні, але стабільний	датасет + перетренування
Мала LLM + structured output	секунди	низька	ні	промпти + валідація JSON
Frontier LLM	секунди-хвилини	висока	ні	промпти, але вміє міркувати
Jev	70–500 мс*	$0.042/MTok*	ні, але калібрований	критерії замість правил

* – заявлені вендором значення, незалежно не підтверджені.

Головний trade-off не в цифрах: правила пояснювані на 100% («зайшло в цю гілку, бо substring»), Jev – ні. Якщо тобі потрібно пояснити регулятору, чому заявку відхилено, «модель була впевнена на 0.87» – погана відповідь.

Що кажуть розробники

Тред на Hacker News – обов'язкове читання перед впровадженням. Три найгучніші лінії:

«Це ж просто дорогий BERT-класифікатор?» Найчастіший скепсис. Найкраще формулювання з треду: «It is BERT-like, but with the data, compute, and training recipe of modern LLMs». Тобто так, ідея zero-shot класифікації не нова – KDnuggets прямо пише: «Classification is not new. Intent detection is not new». Нове – пакування: zero-shot, без датасету і файнтюна, з калібровкою і за одну ціну.

«Zero hallucinations – маркетинг». І це правда, з уточненням. Jev гарантує нуль out-of-schema відповідей: він фізично не може повернути варіант поза твоїм списком. Але він може впевнено обрати неправильний варіант зі списку – що CEO TypeSafe чесно визнав у тому ж треді. «Типобезпечно» не означає «правильно»; компілятор TypeScript теж пропускає логічні баги.

«Чому не написати звичайні правила?» Бо іноді – треба написати звичайні правила, і це буде правильна відповідь. Межа проста: правила виграють, коли ознаки формальні (сума > X, домен у списку), Jev доречний, коли рішення залежить від сенсу неструктурованого тексту. Спроба покрити природну мову регулярками – це той самий if/else, тільки з нескінченним беклогом edge cases.

Заради справедливості: заголовок анонсу «нова frontier-модель у 40–400 разів дешевша» модератори HN перейменували протягом години – маркетингова упаковка запуску викликала не менше дискусій, ніж технологія.

Чи брав би я це в production

Відповідь інженера: не раніше, ніж поміряю. Ось як виглядав би чесний eval для того ж тріажу підтримки:

1. Зібрати розмічений датасет із реальних звернень: 300–500 прикладів, категорії проставлені людьми, спірні кейси – окремо.
2. Прогнати три системи: чинні правила, малу LLM зі structured output і Jev. Однакові дані, однакові категорії.
3. Поміряти чотири речі: якість (окремо false positives і false negatives – у тріажі пропущена «пожежа» коштує дорожче, ніж зайва ескалація), латентність p50/p95, повну вартість на місячному обсязі, і – найнедооціненіше – вартість підтримки: скільки годин на місяць їстиме кожен варіант.
4. Перевірити калібровку на своїх даних. Взяти всі відповіді з confidence 0.8–0.9 і подивитись реальну частку влучань. Якщо вона не ~85%, пороги з документації для тебе не працюють, і їх треба рухати за власною статистикою.
5. Спроєктувати відмову заздалегідь: що робить система, коли API лежить, коли confidence стабільно низька, коли модель систематично плутає дві категорії. Fallback-гілка з детермінованих правил + черга на людину – мінімум, без якого зовнішню модель у критичний шлях ставити не можна.

І ключова думка для сеньйорів, яку варто забрати з собою навіть якщо Jev тобі не потрібен: структурований вихід ≠ правильне рішення. Уся цінність типізації тут – у тому, що помилки стають вимірюваними і керованими порогами. Але міряти їх – досі твоя робота.

Якщо тема AI-інструментів у щоденній роботі тобі цікава ширше – у мене є розбори як використовувати AI без деградації інженерного мислення, чекліст перевірки AI-згенерованого коду і що таке MCP простими словами.

Замість висновку

Спочатку ми писали if/else руками. Потім навчили нейромережі писати if/else за нас. Тепер ми викликаємо спеціально натреновану модель, щоб вона вирішила, в яку гілку if/else зайти – і платимо за кожну умову токенами. Щоправда, вихідні токени у Jev безкоштовні, тож формально нам платити лише за те, щоб машина нас вислухала. У цьому щось є.

Якщо серйозно: Jev – цікавий приклад спеціалізації замість універсальності. Не «розумніша модель», а вужча, швидша і чесніша про власну невпевненість. Чи виживе окрема категорія «System One моделей», чи цю нішу з'їдять малі LLM – покажуть незалежні бенчмарки, яких поки що просто немає. А доти нехай рішення «чи тягнути це в прод» приймає не хайп і не скепсис, а твій власний eval на твоїх власних даних.

Бо це, на щастя, поки що детермінований процес.