Jev 1.13: объяснение — почему модель отвечает метками, а не предложениями

Jev 1.13 (typesafe/jev-1.13) — не чат-модель, и быстрее всего это поймёшь, если перестанешь читать её спецификацию так, как читаешь любую другую. TypeSafe выпустила её 2026-09-15 как первого представителя класса, который компания называет моделями System One: вы передаёте ей фрагмент состояния и набор именованных вопросов, а она возвращает по одному типизированному ответу на каждый вопрос — метку из предложенного вами списка, уровень по заданной вами шкале или true/false с приложенной вероятностью. Ни прозы, ни кода, ни объяснений. Это не материал о запуске. Сама модель датируется 2026-09-15, ей пятнадцать дней, и она выходит за семидневное окно, в рамках которого пишет этот блог, так что собственный релиз не заслуживает отдельной страницы. Внутри окна произошло вот что: OrcaRouter 2026-09-24 добавил typesafe/jev-1.13 в собственный каталог и открыл карточку модели Jev 1.13 по адресу https://www.orcarouter.ai/models/typesafe/jev-1.13 — впервые Jev стало можно вызывать через сторонний шлюз, а не только через собственный эндпоинт TypeSafe, и это первые живые данные о работе, опубликованные кем-либо за пределами TypeSafe. Вот это изменение и стоит прочитать: модель стала запускаемой там, где раньше не была.

Практическое выражение этого изменения невелико и конкретно. До 2026-09-24 внедрение Jev означало необходимость завести отношения ещё с одним поставщиком — аккаунт TypeSafe, ключ TypeSafe, счёт TypeSafe и особую структуру запроса, под которую нужно писать код. После этого Jev использует тот же ключ, что и остальная часть стека: один API для 200+ моделей, 0% наценки (прейскурантная цена провайдера передаётся как есть, поэтому снижения цен поставщика вступают в силу здесь в тот же день), а модель доступна по адресу typesafe/jev-1.13 через POST /v1/systemone. Вы по-прежнему вызываете её в её собственной форме — эта конечная точка не является маршрутом chat-completions OpenAI, а попытка сделать вид, что это не так, приведёт к 404, а не к решению — но договор, который вы подписываете, и ключ, который вы ротируете, — те же, что у вас уже есть.

Что за модель Jev?

В посте о запуске TypeSafe это сформулировано одним предложением: «Наша первая публичная модель — Jev, доступна сегодня в раннем доступе». Затем в посте модель описывается как «вызов функции передового интеллекта: на входе — неструктурированное состояние, на выходе — типизированные вероятностные решения». Это точное описание интерфейса, и важное, потому что почти все неверные ожидания в отношении Jev возникают из-за его оценки как небольшой языковой модели. Это не небольшая языковая модель. Это модель принятия решений с фиксированной выходной грамматикой, и эта грамматика — и есть продукт.

У интерфейса ровно два входа. Состояние — это материал, который нужно оценить: электронное письмо, обращение в службу поддержки, строка журнала, запись JSON, массив игровых координат. Вопросы — это карта именованных элементов, каждый из которых имеет тип, собственные инструкции и — для двух структурированных типов — свои критерии. Каждый вопрос оценивается по одному и тому же состоянию, а ответы возвращаются в виде одной структурированной полезной нагрузки JSON. В документации TypeSafe вопросы описаны как выполняющиеся одновременно и независимо, и там приводятся два утверждения, которые вытекают из этой архитектуры, а не из подбора параметров: добавление вопросов почти не меняет время ответа, и добавление вопросов не вызывает деградации контекста, потому что каждый вопрос оценивается изолированно, а не в цепочке после предыдущих.

Собственное руководство TypeSafe по проектированию стоит повторить, потому что это самое ясное изложение того, для чего предназначена модель. Сохраняйте каждый вопрос атомарным и хорошо ограниченным — «такое суждение, которое очень знающий человек мог бы вынести за несколько секунд». Если решение требует развёрнутого рассуждения или действительно объединяет несколько независимых факторов, разделите его на отдельные вопросы и снова объедините их в своём коде. Их пример: вместо одного запроса «оцените эту презентацию стартапа» спрашивайте отдельно о размере рынка, технической осуществимости и дифференциации, а затем применяйте собственные веса. Это важно потому, что тогда веса находятся в коэффициенте, который вы можете изменить, а не в запросе, который приходится переписывать.

Модель закрыта во всех смыслах, которые важны для инженера, рассуждающего о риске. Архитектура Jev, количество параметров, вычислительные ресурсы для обучения и веса не опубликованы. В организации TypeSafe на GitHub нет репозитория с весами — одиннадцать публичных репозиториев там — это инструменты, SDK, рабочие процессы и три не связанных с этим форка, и ни один из них не является моделью.

«Typed» — это весь продукт

Карточка модели OrcaRouter публикует три примитива и, что важно, ограничения для каждого из них. Каждый вопрос, который вы задаёте Jev, относится ровно к одной из трёх форм:

• noul — суждение «истинно/ложно», возвращаемое с калиброванной вероятностью, а не как просто булево значение, поэтому «вероятно истинно» и «несомненно истинно» — различимые значения.

• choice — выбор одного из до 255 помеченных вариантов, каждый вариант несёт собственный текст критериев, чтобы модель знала, чем отличаются ваши метки.

• score — оценивайте по упорядоченной шкале из 2–10 уровней, где определения уровней даны в качестве критериев.

Следствием этого ограничения является то, что из прозы нечего извлекать и нечего проверять на соответствие схеме, которой, как вы надеялись, следовала модель. Пост TypeSafe о запуске необычно прямо говорит о гарантии: показатель несоответствия схеме „0%“ на его графиках «не является эмпирическим. Соответствие схеме гарантировано, поэтому мы можем уверенно добавить 0 на графики». Когда пространство ответов — это замкнутое множество, которое вы задали, возвращённое значение либо принадлежит множеству, либо оно пришло не от модели — нет третьего исхода, при котором модель написала что-то правдоподобное в неправильной форме, а ваш regex тихо это принял.

Эти три типа — ещё и причина, по которой рецензент не может оценивать Jev так, как он оценивает чат-модель. Нет ни балла MMLU-Pro для сравнения, ни образца письменной работы для чтения, ни трассировки рассуждений для изучения. Единственный вопрос, который что-либо значит, — правилен ли типизированный ответ и честна ли привязанная к нему вероятность. И то и другое измеримо, но только на ваших данных и ваших метках.

Одно документированное различие стоит отметить, а не устранять: в собственной документации TypeSafe приведён пример Score с индексацией от нуля, тогда как карточка OrcaRouter публикует шкалу как 2–10 уровней. Поставщик документирует уровни; наша карточка публикует 2–10. Если вы создаёте рубрику на основе Score, читайте определения уровней в собственном ответе, а не предполагайте индекс.

Почему нет выходных токенов для выставления счёта

Ценообразование — самое чистое выражение архитектуры. Jev стоит $0.042 за миллион входных токенов на OrcaRouter, а ставка за выход — $0.000000 за миллион: не скидка, не промоакция к запуску, а отсутствие измеримого количества. Генеративная модель оплачивается за текст, который она пишет; Jev не пишет текст. Он возвращает метку, уровень и вероятность. На стороне вывода нечего подсчитывать, поэтому там ничего не взимается.

TypeSafe приводит то же число с другой стороны на своей главной странице — «$42 за миллиард входных токенов» — и прилагает к нему сравнительное утверждение: «В 238 раз ниже цена входных токенов, чем у Claude Fable 5.1». Это сравнение, как и всё остальное на главной странице, принадлежит самому поставщику и никем не воспроизведено. Но арифметику, на которой оно основывается, читателю легко проверить по собственному счёту, а это и есть полезная часть. Объём рабочей нагрузки при принятии решений почти полностью определяется тем, сколько состояния вы подаёте на вход, а состояние дёшево так, как сгенерированные токены — нет.

Заглавные цифры вендора крупнее строки с ценой и заслуживают такой же маркировки. TypeSafe рекламирует «193.6x Faster, 444.6x Cheaper» со сноской, ограничивающей это «рабочими процессами для задач System One», и публикует под ней пример расчёта: TypeSafe AI за $0.000081 выполнил задачу за 0.114 с против LLM за $0.013880, выполнивших её за 8.566 с. Сам пост о запуске признаёт риск такой подачи — показатели 193.6x и 444.6x, как сказано, вероятно, находятся «на верхней границе реальных выигрышей» — и отмечает, что сравнительная демонстрация использовала «сильно упрощённый» запрос с читаемыми человеком ключами, выбранными вендором, чтобы «представить нашу модель в выгодном свете». Ни одна из этих цифр не была независимо воспроизведена, а собственная карточка бенчмарка вендора всё ещё помечена как ожидающая.

Что означает «calibrated», и что такое RLCD

TypeSafe сама называет свой метод обучения так: «обучение с подкреплением для калиброванных решений (RLCD)». RLCD — собственный термин TypeSafe, а не общий акроним из машинного обучения, существовавший до компании, и его цель оптимизации указана в сравнительной таблице из поста о запуске как «калиброванные решения: ответы с эпистемически честными вероятностями в задачах System One». Та же таблица противопоставляет его RLHF, который оптимизируется под человеческие предпочтения — тексты и ответы в чате, которые нравятся оценщикам, — и RLVR, который оптимизируется под результаты, которые можно проверить программно. RLCD оптимизирует третье: вероятность, приписываемую ответу как точному утверждению о собственной неопределённости модели.

На практике «калиброванная» — это утверждение об уверенности, а не гарантия правильности ответов. Калиброванная модель, которая выдаёт 0,8 на наборе вопросов, должна быть права примерно в 80% случаев по этому набору; при этом она всё ещё может ошибаться на любом отдельном вопросе. Это различие — честный способ прочитать строку с домашней страницы TypeSafe: «Ноль галлюцинаций — каждое решение Jev сопровождается оценкой уверенности, так что ваше программное обеспечение может действовать, когда уверенность высока, и эскалировать, когда она не высока». Это утверждение об оценке уверенности, а не доказательство отсутствия ошибок, и противовесом служат наши собственные данные: за семь дней, закончившихся 2026-09-30, наша карточка показывает уровень ошибок 0,49% на трафике Jev через OrcaRouter — цифра, которая ранее в том же окне составляла 0,57%, потому что она вычисляется по скользящим семи дням живого трафика плейграунда, а не по фиксированному тестовому набору. Оба факта должны стоять в одном абзаце: уверенность — это суть модели, и при этом модель всё ещё ошибается примерно в одном вызове из двухсот на нашем трафике.

История с калибровкой также объясняет такое поведение задержки, которое в противном случае выглядело бы как баг. В посте TypeSafe о запуске говорится: «Для вариантов с более высокой кардинальностью мы применяем двухэтапную систему: сначала независимое оценивание, а затем явный выбор, отсюда и периодические замедления». Выбор из 255 вариантов — это не одно прямое сравнение; поставщик сначала вычисляет оценки, а затем выбирает. Если вы видите, что запрос к большому набору меток выполняется заметно дольше, чем noul, то это задокументированный механизм, а не перегрузка.

Как вы это называете сегодня?

В OrcaRouter модель — это typesafe/jev-1.13, в каталоге она называется "TypeSafe: Jev 1.13", имеет context_length 65 536 токенов и ровно один поддерживаемый тип эндпоинта: systemone. Вы вызываете её через POST /v1/systemone со своим ключом OrcaRouter, отправляя поле model, поле state (строка, объект или массив) и карту questions, где каждая запись содержит type (noul, choice или score), свои instructions и свои criteria. Ответы представляют собой единый структурированный JSON-полезную нагрузку и не передаются потоково — режима потоковой передачи, который можно было бы включить, нет.

В самой карточке контракт сформулирован так: «текст на входе, структурированный JSON на выходе», а опубликованные лимиты — это те, на которые следует ориентироваться при проектировании: без потоковой передачи, до примерно 64K входных токенов суммарно по состоянию и вопросам, при этом запросы, превышающие этот лимит, отклоняются до попадания в модель. В записи каталога прейскурантная цена указана как $0.042 за миллион входных токенов, а ставка за генерацию — как ноль. Это числа поставщика, переданные без изменений, — пропорциональная форма нашего ценообразования: наценка 0% к прейскурантным ставкам провайдера.

Для этой модели ходят два бюджета токенов, и они не конфликтуют между собой, поэтому не смешивайте их. Цифра 65 536 — это context_length карточки, и в документации она описывается как примерно 64K входных данных суммарно по состоянию и вопросам. «Примерно 32 000 токенов», которые цитируют более ранние статьи OrcaRouter, — это только бюджет состояния: место, которое получает ваш материал до того, как вопросы возьмут свою долю. Если вы рассчитываете бюджет запроса, именно бюджет состояния ограничивает полезную нагрузку, которую вы формируете; совокупная цифра — это верхний предел для всего вызова.

Что Jev не может делать, сказано прямо

Он не умеет писать прозу, резюмировать, переводить или вести беседу. Это задумано, а не ограничение, за которое следует извиняться: в посте о запуске говорится, что Jev «отказывается от генерации строк», а на собственной странице TypeSafe, посвящённой jaggedness, «Генерация» указана как поименованный режим отказа, а рядом стоит инструкция «Используйте генеративную модель». Принудительная генерация медленна и плоха. Если вашему пайплайну нужна письменная сводка, Jev — неподходящий компонент, и никакое мастерство в составлении промптов этого не изменит.

Это не замена генеративной модели. Рабочий процесс, к которому относится Jev, включает две модели: генеративную, которая читает, пишет и рассуждает в тексте, и Jev, сидящий рядом с ней и выполняющий типизированные вызовы за миллисекунды. Это честная формулировка любого сравнения затрат на главной странице вендора — столбец «LLMs» не является вытесняемым конкурентом, это другая половина той же системы, и причина, по которой это сочетание интересно, в том, что половина, отвечающая за решения, теперь на том же ключе, что и генеративная половина, а не за отдельным контрактом.

И «калиброванный» не означает «правильный». Это означает, что число, привязанное к ответу, должно читаться как вероятность. 0,62 на noul — это модель сообщает вам, что она не уверена, а это полезная информация, которую уничтожило бы голое «да/нет», — и это не обещание, что «да» верно. Логика эскалации, построенная на уверенности, — это задуманный паттерн; считать ответ эталонной истиной — нет.

Честно читая цифры

Каждый показатель обслуживания в нашей карточке получен из нашего собственного трафика через playground OrcaRouter за скользящее семидневное окно, а не из бенчмарка вендора, и окно сместилось, пока писался этот материал, — относитесь к нему как к показанию, а не как к спецификации. За семь дней, завершившихся 2026-09-30: медианное время до первого токена — 151 мс, p95 — 247 мс, пропускная способность вывода — около 349 токенов в секунду, доля ошибок — 0,49 %, и 76,2 млн обслуженных токенов. Ежедневный p50 по окну составляет 175, 170, 163, 161, 170, 147 и 143 мс — плавно улучшающаяся линия. p95 за 09-28, равный 2 448 мс, — это настоящий однодневный выброс в этом ряду, и приводить его как норму было бы неправильно точно так же, как полностью опустить его было бы нечестно.

Ещё одна оговорка по показателю трафика: 349 выходных токенов в секунду звучит как пропускная способность генеративной модели, пока не вспомнишь, что Jev не производит сгенерированного текста. Счётчик измеряет то, что наш playground считает на стороне ответа для структурированной полезной нагрузки, и он полезен для выявления деградации между днями, а не для сравнения Jev с чат-моделью.

Это наши цифры. Цифры вендора — это 193.6x, 444.6x, разобранный пример с $0.000081 и сравнение 238x с Claude Fable 5.1 — все они принадлежат самой TypeSafe, ни один не был независимо воспроизведён, и все они, согласно их собственным сноскам, ограничены именно рабочими процессами задач System One. Единственное заявление о производительности, которое делает TypeSafe и которое вообще не является бенчмарком, но стоит больше, чем множители, — это структурное утверждение: поскольку ответы типизированы, в интеграции нет этапа парсинга и этапа проверки схемы, а это затрата, которая не отображается ни в одной таблице задержек.

Что открыто, а что нет

Проверено 2026-09-30: организация TypeSafe на GitHub опубликовала одиннадцать репозиториев. Ни один из них не содержит Jev. Те, что важны для разработчика, интегрирующего модель, распространяются под MIT или Apache-2.0: skills (MIT), system-one-adapter-python (MIT, описан как «Drop-in-замена TypeSafeClient на базе API LLM»), typesafe-sdk-js (MIT), typesafe-sdk-python (MIT), daggerverse (Apache-2.0), WorkflowEvals (Apache-2.0, с кодом рабочего процесса, опубликованным на evals.typesafe.ai), n8n-nodes-typesafe-ai (MIT), typesafe-ai.github.io и pulumi-clickhouse. Количество звёзд и даты push меняются, поэтому если вы читаете это позже, перепроверьте, а не доверяйте этому списку.

Три из одиннадцати — это форки не связанных проектов, и они ничего не доказывают о том, как работает Jev: форк vLLM, последний раз обновлённый в мае 2025 года, форк LLaDA от 2025 года — LLaDA — не связанная с этим языковая модель — и провайдер Pulumi для ClickHouse Cloud. Соблазнительно вывести архитектуру из списка форков. Не делайте этого: о дизайне Jev ничего не следует из этих трёх, и в частности Jev не является диффузионной моделью, как бы присутствие форка LLaDA к этому ни подталкивало.

Честный ответ в одну строку на вопрос «Jev — это открытый исходный код?» состоит в том, что инструментарий открыт, а модель — нет. Это обычная схема для размещённой модели передового уровня, и именно её следует предполагать, когда вы планируете что-либо вокруг Jev: API с опубликованной ценой, документированным контрактом и непубличным числом параметров.

Где поставщик говорит, что Jev ненадёжен

TypeSafe публикует собственную страницу неровностей для jev-1.13, последняя проверка — 2026-09-17, где указано, в каких местах модель даёт сбои. Она необычно откровенна, и с неё лучше всего начать раздел об ограничениях, потому что это собственный список вендора, а не конкурента:

• Буквальное прочтение — оно воспринимает формулировку буквально. Слова, задающие область действия, отрицания и подразумеваемые условия не выводятся; оно «отвечает на вопрос, который вы написали, а не на тот, который вы имели в виду». Решение поставщика — прописать точное условие и критерии для каждого варианта.

• Математика и числа — это не калькулятор, и он не умеет надёжно считать. Арифметику выполняйте в коде.

• Сравнение дат и времени — даты читаются как текст, а не как упорядоченные величины, поэтому порядок, пропуски и окна ненадёжны, а при смешанных форматах — ещё хуже.

• Косвенность — двойные отрицания и многошаговые рассуждения снижают точность. Сократите количество шагов и указывайте на соответствующее состояние.

• Большое состояние, полное нерелевантных деталей — не связанное с задачей содержимое действует как отвлекающий фактор, и точность падает по мере роста состояния. Сначала отфильтруйте.

• Состязательный контент — состояние не рассматривается как враждебное, поэтому внедрённые инструкции или вводящая в заблуждение подача могут сместить ответы.

• Противоречивые инструкции и критерии — когда они требуют разного, модель «может запутаться».

• Структурные инварианты здравого смысла — не гарантируется, что P(noul) и 1 − P(не noul) будут согласованы. Спрашивайте о каждом решении только в одном направлении и обеспечивайте выполнение тождеств в коде.

• Генерация — уже рассмотрено, а сам вендор советует использовать генеративную модель.

Два из них заслуживают особого внимания. Состязательный важен потому, что всё ценностное предложение Jev — это оценка недоверенного материала, а состояние, содержащее инструкции, может изменить ответ; если ваше состояние поступает от пользователей, это поверхность для prompt-injection той же формы, что и любая другая. Пункт о структурных инвариантах важен потому, что «калиброванная» модель приглашает вас выполнять арифметику над её вероятностями, а поставщик говорит вам не предполагать, что эта арифметика замыкается.

К чему обязывает пост о запуске, а к чему — нет

Почти каждое утверждение вендора, процитированное в этом материале, восходит к одной странице: собственному анонсу TypeSafe, опубликованному в разделе Company News и датированному 2026-09-15, подписанному основателем Диогу Алмейдой. Прочитать его напрямую стоит этих двух минут, потому что формулировка одной строки задаёт условия для всего последующего. «Наша первая публичная модель — Jev, доступная уже сегодня в режиме раннего доступа». Ранний доступ — это собственное описание вендором доступности на его собственной платформе, и это более узкое утверждение, чем кажется: оно обязывает TypeSafe предоставлять модель одобренным пользователям и ничего не говорит о том, кто ещё может её предоставлять. Именно этот пробел закрыло добавление в каталог от 2026-09-24, и поэтому карточка модели важнее поста для любого, кто оценивает Jev сегодня.

Та же страница столь же ясно говорит о своих собственных ограничениях — именно поэтому выше она цитируется, а не пересказывается. Она не публикует ни количество параметров, ни описание архитектуры, кроме «новой архитектуры модели», ни вычислительные затраты на обучение, ни репозиторий с весами и не называет ни даты, ни условий общей доступности. Эти пробелы и есть ограничения для планирования: с одной стороны — API с опубликованной ценой, с другой — стек, внутренности которого нельзя изучить. В посте также модель представлена достаточно честно, чтобы пост можно было использовать как спецификацию, — «вызов функции передового интеллекта: на входе — неструктурированное состояние, на выходе — типизированные вероятностные решения», — и это единственное предложение в нем, которое описывает интерфейс, а не амбиции.

Вопросы, которые вызывает этот интерфейс

Что происходит, когда набор вариантов выбора превышает 255 вариантов? Для него устанавливается потолок — 255 вариантов с метками — это предел для вопроса с выбором, и двухэтапный подход поставщика «сначала оценка, затем выбор» — это то, что он делает по мере роста количества вариантов, что также является документированной причиной периодических замедлений на больших наборах меток. Если ваша таксономия больше этого, ответ на уровне проектирования — разбить её на несколько вопросов и повторно объединить в коде; это тот же совет, который TypeSafe даёт для составных суждений.

Означает ли контекст в 65 536 токенов 65 536 токенов состояния? Нет. Заявленный бюджет — примерно 64K токенов в сумме для состояния и всех вопросов, а цифра «примерно 32 000 токенов», фигурирующая в более ранних публикациях, — это бюджет только состояния. Рассчитывайте свою полезную нагрузку исходя из показателя для состояния, а не из совокупного, и помните, что запросы, превышающие лимит, отклоняются ещё до того, как достигнут модели.

Что с этим делать

Jev 1.13 стоит взглянуть по одной конкретной причине, а не по общей. Если в вашем конвейере есть этап, на котором сейчас используется чат-модель, которую просят вернуть метку и которой доверяют вернуть её в правильной форме — маршрутизатор, оценщик, проверка политики, оценка по рубрике, применяемая к тысячам записей, — именно этот этап заменяет данная модель, по цене $0.042 за миллион входных токенов, при этом на стороне вывода ничего не тарифицируется. Если у вас есть этап, требующий письменного ответа, Jev — не тот инструмент, и сам его поставщик так говорит.

То, что изменилось за последнюю неделю, — не сама модель. А то, что для того, чтобы её попробовать, больше не нужно вступать в отношения со вторым вендором. Восемь дней назад оценка Jev означала отдельный аккаунт и отдельную интеграцию; сегодня это один идентификатор модели на ключе, который уже даёт доступ к более чем 200 моделям, при этом прайс-листовая цена вендора передаётся без изменений, а типизированные ответы приходят оттуда же, откуда и всё остальное. Для настолько необычной модели возможность протестировать её на собственных метках, не заключая новый контракт, — это большая часть решения.