# OpenAI Decisions API vs Jev: «AI-powered if/else» стає окремою категорією

> OpenAI випустила Decisions API: контекст + скінченний набір відповідей замість генерації тексту. Порівнюємо категорію з Jev від TypeSafe і пояснюємо, коли decision model краща за LLM.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-10-15
- Категорія: AI в роботі розробника
- Canonical: https://cookiesoftware.io/blog/openai-decisions-api-vs-jev

---

OpenAI представила Decisions API на DevDay у limited preview, а з 6 жовтня розкотила його в public beta. Ідея до болю знайома, якщо ти читав [наш розбір Jev](/blog/jev-ai-typesafe): даєш контекст і скінченний набір наперед визначених відповідей, отримуєш рішення – для класифікації, роутингу або вибору наступної дії агента. Без генерації тексту. Тобто «AI-powered if/else» за три тижні перетворився з жарту про один стартап на категорію, в якій тепер грає і OpenAI. Розбираємось, що це означає і як між ними обирати, не вигадуючи порівнянь, яких поки не існує.

## Що саме анонсували

За описом OpenAI, Decisions API «фокусує інтелект Luna на конкретному наборі заданих користувачем питань зі скінченними наперед визначеними відповідями». Контекст передається текстом або зображеннями; на виході – відповідь зі списку, яку твій код використовує напряму: класифікувати контент, змаршрутизувати запит, обрати наступну дію агента.

Головна цифра зі слайда DevDay: близько **150 мс проти 1.6 с** у стандартного виклику GPT-6 Luna – приблизно десятикратне прискорення. Важливе уточнення, яке я повторюю в кожній такій статті: це vendor-заявка з презентації, а не незалежний бенчмарк. Незалежних замірів на момент написання немає.

## Чому це логічний рух, а не копіювання заради копіювання

LLM чудово генерує текст. Але якщо чесно подивитись на production-систему, велика частина AI-викликів у ній не потребує тексту взагалі:

- `billing | technical | sales` – роутинг звернень;
- `allow | review | block` – модерація і гейтинг;
- `agent_a | agent_b | ask_user` – вибір наступного кроку в агентському циклі.

У таких задачах natural language generation – зайва surface area: повільніша, дорожча, з ризиком «майже валідного» виводу, який ще треба парсити й валідувати. Про це ж, по суті, була вся друга половина статті про Jev: типізоване рішення з обмеженого набору – інший клас задач, ніж вільний текст.

Тому поява другого великого гравця – найкраща новина для самої ідеї. Категорії з одним вендором не існує; категорія з TypeSafe і OpenAI – вже ринок.

## Jev vs Decisions API: чесне порівняння (поки що – категорійне)

Спокуса написати «хто переміг» велика, але нечесна: Decisions API щойно вийшов у beta, його характеристики й ціни можуть змінитися, а публічних незалежних порівнянь немає. Що можна чесно порівняти вже зараз – підходи:

| Вимір | Jev (TypeSafe) | Decisions API (OpenAI) |
|---|---|---|
| Архітектура | Окрема «System One» модель, неавторегресивна, тренована під калібровані ймовірності | Сфокусований режим поверх інтелекту Luna |
| Вихід | Типізовані Choice/Score/Noul з confidence і розподілом | Відповідь зі скінченного набору |
| Контекст | Текст/JSON | Текст і зображення |
| Екосистема | Власний SDK + інтеграції (Vercel AI SDK, LangChain) | Рідна інтеграція в OpenAI-стек |
| Статус | GA, публічний прайс | Public beta з 6 жовтня |

Зауваж, чого в таблиці немає: точності, калібровки, реальної latency під навантаженням і вартості на твоїх обсягах. Бо цих даних поки не існує ніде, крім вендорських слайдів.

## Як обирати, коли обидва доступні

Так само, як ми радили в [статті про evals](/blog/ai-agent-evals): власний набір із 200–500 розмічених прикладів із твого продукту і чотири виміри – accuracy, калібровка (якщо вендор віддає ймовірності – перевір, чи «0.9» означає ~90% влучань), latency p95 і повна вартість на місячному обсязі. Плюс два нечислові фактори: ergonomics SDK у твоєму стеку і vendor lock-in – якщо ти вже глибоко в екосистемі OpenAI, інтеграційна ціна Decisions API нижча; якщо цінуєш незалежність шару рішень – окремий вендор має свій сенс.

## Трирівневий стек, до якого все йде

Найкорисніша рамка з цієї новини – не «яку модель купити», а як виглядатиме здорова архітектура рішень:

1. **Deterministic rules** – там, де ознаки формальні. Безкоштовно, пояснювано, миттєво.
2. **Decision model** – там, де рішення залежить від сенсу неструктурованого вводу, але простір відповідей скінченний.
3. **Reasoning/generative model** – там, де потрібні міркування, план або текст.

Просити frontier-LLM вирішувати кожен boolean у системі – це рівень зрілості «у нас є молоток». Трирівневий стек – рівень «ми знаємо вартість кожного удару». Ширший контекст про те, де AI в роботі розробника доречний взагалі, – у [базовій статті про AI-інструменти](/blog/ai-dlia-prohramista).

## Три передчасні рішення

1. **Мігрувати на beta-API критичний шлях.** Public beta означає: семантика й ціни можуть змінитись. Пілот – так, критичний роутинг платежів – зарано.
2. **Вірити слайду замість власного eval.** «10x швидше» виміряно вендором на вендорській задачі. Твоя задача – інша.
3. **Викидати правила.** Decision model не замінює детерміновану бізнес-логіку – вона замінює LLM-виклики там, де тексту не треба.
4. **Ігнорувати калібровку.** Якщо API не віддає впевненість або вона некалібрована – у тебе немає сигналу «віддати людині», і це архітектурна діра.

## Порахуй свої приховані класифікатори

Відкрий свій код і знайди всі місця, де ти викликаєш LLM, а потім парсиш із відповіді одне слово чи категорію. Порахуй їх. Кожне з них – кандидат на decision model, і тепер у тебе два вендори на вибір і один чесний спосіб обрати: виміряти самому.