ИТ‑команды сегодня сталкиваются с растущей нагрузкой: больше продуктов и интеграций, выше требования к скорости и качеству, при этом рынок испытывает дефицит кадров. Согласно опросу Kaiten и «Карьерного Цеха», 30% ИТ-специалистов перерабатывают несколько раз в месяц, 26% – практически каждую неделю, а 9% работают сверхурочно ежедневно.

В таких условиях важно не добавить еще один инструмент, а убрать рутину, ускорить погружение в контекст, снизить стоимость экспериментов с ИИ и сделать процесс разработки предсказуемым и воспроизводимым.

Новые сервисы закрывают ключевые этапы жизненного цикла разработки: понимание кодовой базы и управление выпуском ПО. За счет этого разработчики тратят меньше времени на поддержку документации, ожидание результатов и ручную настройку пайплайнов, и больше – на создание ценности для продукта и бизнеса.

Evolution Workflow Studio: совместный выпуск приложений людьми и ИИ-агентами

Evolution Workflow Studio – облачный инструмент для автоматизации выпуска и развертывания приложений.

Инструмент дает возможность управлять выпуском приложений не только вручную или через триггеры, но и с помощью ИИ‑агентов. Агенты могут продолжать работу после подготовки кода и использовать управляемые инженерные процессы для сборки, дополнительных операций и развертывания. Это сокращает ручные переходы между инструментами и экономит время разработчиков.

Раньше облачные инструменты создавали для людей, а сегодня с ними могут работать ИИ-агенты, поэтому инфраструктуру нужно адаптировать. Evolution Workflow Studio стал связующим звеном между ИИ-агентом и облаком: с его помощью можно в один клик развернуть приложение или другие сервисы и объединить их в общую инфраструктуру за считанные минуты, а для более сложных сценариев доступны гибкие настройки.

RepoWiki: автоматизация создания документации к коду в собственном репозитории

RepoWiki – новая функция для автоматического создания документации к коду, встроенная во внутренний репозиторий Cloud.ru. Разработчик может сформировать документацию по коду непосредственно в репозитории в один клик.

RepoWiki использует мультиагентный подход: работа разбита на этапы планирования, анализа архитектуры, написания документации и верификации. Это позволяет обрабатывать большие корпоративные репозитории, где единовременный анализ всей кодовой базы невозможен из-за ограничений контекстного окна. RepoWiki поддерживает инкрементные обновления: при изменении кода документация обновляется, а не создается заново.

Теперь разработчики смогут быстрее проводить погружение в контекст незнакомого модуля, ускорять адаптацию к проекту и снизить рабочие нагрузки. Для технических лидеров сервис будет инструментом управления знаниями, который снижает риски ухода ключевых сотрудников и ускоряет онбординг новых членов команды. Вместо ручного описания модулей и поддержки актуальности файлов ИТ-команда получает автоматически сгенерированное описание проекта и может задавать вопросы по кодовой базе в чате.

«В основе подхода Cloud.ru не “ИИ ради ИИ”, а выверенные точечные сценарии, где модели и агенты берут на себя объемные, повторяющиеся и ресурсоемкие задачи, а люди сохраняют контроль над архитектурой, безопасностью и бизнес‑логикой. ИИ-агенты встроены в повседневные процессы разработки, но делают это безопасно: данные обрабатываются в защищенной облачной среде, доступ к моделям контролируется, а критические операции остаются под наблюдением инженеров. Такой подход поможет масштабировать использование ИИ без роста операционных рисков и одновременно снижать когнитивную нагрузку на команды, ускоряя онбординг новых сотрудников и уменьшая зависимость от отдельных специалистов.»

Реклама. ООО "ОБЛАЧНЫЕ ТЕХНОЛОГИИ", ИНН 7736279160, erid: 2W5zFHRLbbF

Участники за ограниченное время создают решение заданной задачи: прототип, модель или работающий сервис. Требования к результату, допустимые инструменты и правила участия задают организаторы.

30 сентября я побывал на финале Альфа Вайб Хакатона в Москве и поговорил с призёром соревнования, Екатериной Мазняк. Она впервые участвовала в хакатоне, выступала одна и заняла второе место.

Попробовать задачу, до которой не доходят руки

Участники разрабатывали прокси-сервис для работы с языковой моделью. Он должен был обрабатывать данные с учётом контекста, поддерживать правила разных систем, быстро отвечать и выдерживать высокую нагрузку.

Основной этап длился 39 часов, решения подали 102 команды, а в финал прошли десять. Общий призовой фонд составил 2,3 млн рублей. Соревнование было первым внешним хакатоном Альфа-Банка по Enterprise Vibe Coding. Так называют разработку корпоративных систем в связке с ИИ-агентами.

Применить свои навыки в новой роли

У Екатерины медицинское образование. Во время пандемии она решила сменить сферу, обучилась тестированию, затем преподавала и работала в QA. Участвовать в хакатоне решила ради интереса.

В работе использовала AlfaGen. Её сервис маскировал персональные данные и восстанавливал исходный текст.

Она начинала с описания требований к программе, а затем поручала ИИ написать код. Такой подход называют разработкой по спецификации (SDD). Когда находила новый формат данных, дополняла описание и тесты и просила агента изменить реализацию.

Под нагрузкой сервис не падал, но иногда возвращал неверный текст. Нагрузочный тест сравнивал исходный текст с восстановленным и поймал эту ошибку.

Поняла, что опыт тестировщика не вспомогательный навык. С ИИ-агентом QA-инженер может в одиночку довести продукт от требований до нагрузочного теста: код пишет ИИ, а главным оказывается умение сформулировать, что значит «правильно», и доказать это цифрами.

Подумайте, чем вы можете помочь в решении задачи. Кроме написания кода, могут пригодиться проектирование API, знание предметной области, подготовка тестов или понятная демонстрация проекта.

Научиться выбирать и объяснять свои решения

Ограниченный срок заставляет выбирать, какие требования выполнить в первую очередь, что упростить и как проверить результат. Решить это лучше до того, как вы начнёте писать код.

Жюри рассматривало код, архитектуру и обоснование решений: почему команда выбрала этот подход, где сомневалась и какие варианты отбросила. На защите оценивали прикладную пользу проекта.

Заранее выясните, что важнее для жюри: качество модели, работающий сервис или демонстрация пользовательского сценария. В руководстве Tproger по подготовке к хакатону есть советы, как спланировать работу и подготовить демо.

Подготовьте короткий рассказ о проекте: какую задачу вы решали, почему выбрали этот подход, что показали проверки и что ещё требует доработки.

Познакомиться с людьми и обменяться опытом

На хакатоне всегда есть о чём поговорить с другими участниками: обсудить решение, спросить про инструмент или поделиться своей находкой. Так можно познакомиться со специалистами из других городов и команд, узнать, как они работают, найти людей с похожими интересами. Эти знакомства могут вырасти в дружбу, совместный проект или приглашение в команду.

За двое суток я прошла полный цикл: от требований до нагрузки и защиты решения. На работе такой цикл редко достаётся одному человеку. Плюс практика с ИИ-агентами на реальной задаче, новые знакомства и уверенность: теперь я точно знаю, что могу.

Как получить пользу от участия

Выберите хакатон с задачей, которую вам интересно решать. Проверить условия участия и организацию работы поможет чек-лист Tproger. Дальше можно действовать так:

Что такое токен простыми словами

Текст, прежде чем попасть в языковую модель, разбивается на токены, небольшие кусочки, и каждый может оказаться целым словом, обрывком слова или просто знаком препинания. Как именно текст режут на токены, определяет токенизатор — отдельная программа со своим словарём. Она разбивает текст на фрагменты и каждому фрагменту, то есть токену, присваивает число — идентификатор из этого словаря.

Этот словарь работает примерно как поварская книга, только наоборот: рецепт показывает, из каких ингредиентов собрано блюдо, а словарь токенизатора, позволяет разбирать уже готовый текст на такие же кусочки-ингредиенты и каждому присваивать свой номер. Так суп из слов и знаков препинания превращается в строку чисел, где каждое число обозначает пронумерованный кусочек текста той или иной длины. Как именно происходит такое разбиение на токены и их нумерация, показано в курсе Hugging Face.

Представьте, что вы измеряете длину комнаты шагами. При широком шаге получится одно число, при коротком — другое. Само число шагов ещё не говорит, сколько метров вы прошли. С токенами похожая история: сто токенов нельзя однозначно перевести в сто слов или фиксированное число символов.

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

Когда модель составляет ответ, она выбирает следующие токены с учётом уже имеющейся последовательности, а программа преобразует их обратно в читаемый текст. Токен при этом не равен одной законченной мысли или фиксированному времени вычислений — метафора шагов описывает только размер фрагментов, не саму работу нейросети.

Почему один токен не равен одному слову

В документации Hugging Face есть пример для токенизатора модели BERT с идентификатором google-bert/bert-base-uncased. Он разбивает фразу из пяти слов так:

I have a new GPU!
["i", "have", "a", "new", "gp", "##u", "!"]

Получилось семь токенов. Слова I, have, a и new заняли по одному. Сокращение GPU распалось на два, а восклицательный знак стал отдельным токеном. Обозначение ## показывает, что фрагмент продолжает предыдущее слово. Этот токенизатор также переводит буквы в нижний регистр.

Это конкретный пример разбиения, а не универсальное правило для всех нейросетей. У другой модели может быть иной словарь, поэтому та же фраза даст другую последовательность. В некоторых схемах токенизации пробел входит в токен вместе с соседним текстом; отдельный символ, например эмодзи, тоже может потребовать нескольких токенов.

Частые сочетания символов позволяют представить текст крупными фрагментами. Для редкого имени или длинного идентификатора в коде токенизатору может понадобиться больше коротких фрагментов. Поэтому количество символов не даёт точного количества токенов.

Язык тоже влияет на разбиение. Исследователи сравнили токенизацию текстов на разных языках и показали, что одинаковое содержание может требовать разного числа токенов. Однако правило вроде «русский всегда вдвое дороже английского» из этого не следует — результат зависит от конкретной модели и текста.

Какие токены попадают в запрос и ответ

В API обычно разделяют входные и выходные токены. Входные описывают то, что модель получает для выполнения задачи. Выходные относятся к тому, что она генерирует.

К входу относится гораздо больше, чем последняя реплика пользователя. Например, документация Gemini включает в подсчёт системные инструкции, историю разговора и описание доступных инструментов. В приложении запрос может содержать такие данные:

Поэтому короткая реплика «А теперь исправь» может сопровождаться большим входом: приложение снова передаёт код, переписку и инструкции. Предыдущий ответ модели, включённый в следующий запрос, уже относится к входным токенам этого запроса.

У моделей с режимом рассуждений расход может включать токены, которые не совпадают с видимым пользователю ответом. Например, Anthropic учитывает токены рассуждений в выходном бюджете и тарификации. Поэтому длина текста на экране не всегда объясняет весь расход.

Как токены ограничивают размер контекста

Контекстное окно — это объём текста, с которым модель работает одновременно, пока готовит ответ. В стандартном случае в него входят переданный запрос и генерируемое продолжение. Это ограничение описано в документации Claude. Оно относится к текущему обращению, а не ко всем знаниям, которые модель получила при обучении.

Для наглядности возьмём условную модель с общим окном в 32 000 токенов. Если инструкции, переписка и документы уже заняли 28 000, в пределах этого окна остаётся максимум 4 000 на генерацию. Дополнительно у модели может быть собственный предел длины ответа. Большое контекстное окно само по себе не обещает ответ такого же размера.

При переполнении поведение зависит от API и приложения: запрос могут отклонить, генерация может остановиться, а чат-клиент может заранее сократить историю. Нельзя рассчитывать, что модель сама выберет, какие старые сообщения можно безболезненно забыть.

Если вы отправляете большой документ, сначала оцените весь вход и оставьте место для ответа. Для бота с длинными диалогами определите, какие сообщения он передаёт дальше, какие заменяет кратким резюме и какие детали обязан сохранять дословно. Anthropic предупреждает о потере важных деталей при слишком сильном сжатии истории. Например, резюме обсуждения может сохранить решение команды, но потерять строку ошибки, без которой модель не воспроизведёт проблему.

Как посчитать стоимость запроса

В тарифах API обычно отдельно указаны цены входных и выходных токенов, часто за миллион. Число «1 млн» здесь обозначает единицу расчёта. Оно не означает, что для одного короткого запроса нужно израсходовать миллион токенов.

Для обычного текстового запроса без кэширования и дополнительных платных операций расчёт выглядит так:

Стоимость запроса =
    входные токены / 1 000 000 × цена входа
  + выходные токены / 1 000 000 × цена выхода

Посмотрим на конкретный тариф. На 28 сентября 2026 года в карточке deepseek/deepseek-v4-pro-0813 на RouterAI для провайдера Ionstream указаны 34 ₽ за миллион входных и 300 ₽ за миллион выходных токенов. У других провайдеров этой же модели цены могут отличаться, а рублёвые значения меняются вместе с курсом валют.

Допустим, запрос использовал 2 000 входных и 500 оплачиваемых выходных токенов. Это учебный объём для расчёта, а не результат тестирования модели. Без кэширования получится:

При этих условиях короткий ответ стоит больше, чем вчетверо более длинный вход. Поэтому для сравнения моделей нужны обе ставки и характерная для вашей задачи длина ответа. Сравнение только по цене входа может привести к неверному выбору.

Кэширование промпта позволяет провайдеру повторно использовать уже обработанную общую часть запросов. Это меняет расчёт стоимости: например, Anthropic применяет разные ставки к записи и чтению кэша. Повторённый текст при этом продолжает занимать место в контекстном окне. Поддержку и условия кэширования нужно проверять у выбранной модели и провайдера.

Для практического сравнения можно использовать RouterAI: сервис даёт доступ к моделям разных разработчиков через единый API-ключ, работает без VPN и принимает оплату в рублях российскими картами. В каталоге моделей можно посмотреть ставки на вход и выход и сравнить расход на одинаковых задачах — токенизация и тарифы при этом остаются собственными у каждой модели.

Как проверить, что кэш действительно работает

Пометить запрос как кэшируемый мало. Провайдер применит кэш, только если повторяющаяся часть образует одинаковое начало запроса: кэш привязан к префиксу и хранит внутреннее состояние модели для конкретного начала текста, а не для содержимого в целом — это устройство кэша описано на RouterAI.

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

Проверяется это не по настройкам, а по ответу API — в статистике должно расти поле чтения кэша. У Claude это cache_read_input_tokens и cache_creation_input_tokens в объекте usage, как описано в документации Anthropic; у других провайдеров поля называются иначе, но смысл тот же. Если это поле стабильно нулевое при повторяющихся запросах, кэш не работает, и вы платите полную цену за один и тот же текст на каждом вызове.

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

Как узнать расход своего запроса

До отправки используйте токенизатор выбранной модели или официальный метод подсчёта, если он доступен. Считать нужно полный запрос с инструкциями и историей. Например, метод подсчёта токенов Claude принимает структурированные сообщения и возвращает оценку входа. Документация отдельно предупреждает: оценка может немного отличаться от фактического расхода.

После ответа проверяйте статистику API. В примере формата ответа RouterAI для этого используется объект usage. Для учебного объёма из расчёта выше его базовые поля выглядели бы так:

Поле prompt_tokens показывает вход, completion_tokens — выход, total_tokens — их сумму. Для кэширования и рассуждений проверяйте дополнительную детализацию, которую возвращает конкретный провайдер. Умножать total_tokens на одну ставку нельзя, если вход и выход стоят по-разному.

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

У систем, где ИИ работает автоматически, есть источник роста расходов, не связанный с самой моделью, — обвязка вокруг неё. Значимый патч CRM, воркфлоу или промпта может незаметно сломать защиту от лишних вызовов: настройку кэша, лимит на число повторов, дедупликацию похожих запросов. Тесты при этом пройдут — патч не ломает функциональность, он ломает экономику. Поэтому после каждого крупного изменения в такой системе стоит прогнать её типовой сценарий и сверить счётчики usage с тем, что было до патча, а не считать расход токенов побочным эффектом, который не требует отдельной проверки.

Как сократить расход без потери нужного контекста

Начните с того, что приложение отправляет и что просит вернуть. Обычно именно здесь можно найти данные, которые не помогают решить текущую задачу.

• Передавайте нужный фрагмент материала. Для объяснения одной ошибки приложите связанный с ней код и достаточное окружение. Весь репозиторий может содержать много файлов, которые не влияют на проблему.
• Управляйте историей диалога. Не передавайте её целиком в каждый новый запрос — резюмируйте закрытые темы и оставляйте дословно только то, что ещё понадобится.
• Задавайте формат результата. Если приложению нужны название ошибки и способ исправления, перечислите эти поля. Тогда у модели будет меньше причин добавлять длинное вступление и общий обзор темы.
• Ограничивайте генерацию параметром API. В RouterAI для этого описаны max_tokens и max_completion_tokens. Выбирайте параметр, который поддерживает ваша модель. Слишком низкий предел может оборвать полезный ответ; сам предел не обязывает модель заполнить его целиком.
• Проверяйте результат сокращений. Прогоните изменённый запрос на характерных задачах и сравните расход вместе с качеством ответа. Если после удаления контекста приходится повторять запрос с уточнениями, экономия может исчезнуть.
• Проверяйте кэш по факту, а не по настройке. Включённый в коде кэш ничего не гарантирует — ориентируйтесь на поле чтения кэша в статистике запроса.

Для первого замера возьмите одну задачу, которую ваш бот решает регулярно. Зафиксируйте вход, выход и стоимость, затем уберите из запроса один лишний блок и повторите проверку. Так станет видно, какой именно фрагмент увеличивал счёт и сохранила ли модель всё необходимое для правильного ответа.

Моя работа максимально далека от ИТ и ИИ. Я не пишу код, не тестирую программы, не автоматизирую сложные цифровые процессы и тем более не продаю курсы по вайб-кодингу. Однако я глубоко убежден, что уже через несколько лет искусственный интеллект станет не просто повседневной нормой, как мобильный интернет или калькулятор, а обязательной частью жизни рабочего класса. Очень скоро без ИИ-ассистентов не смогут обойтись ни электрики, ни сантехники, ни офисные клерки, ни предприниматели.

Начну моё эссе с рассказа о себе.

Как я сам использую ИИ?

Точечно.

Я начальник управления малого бизнеса в Чеченской Республике. Ввиду специфики моей должности я не могу использовать нейросети для всех задач, а делаю это выборочно: переписать деловое письмо, сделать анализ финансовой деятельности клиента, перевести данные из скана в Word, а потом заменить данные на другие, сделать краткую выжимку отчёта, подготовить презентацию или понять, что мой собеседник имел ввиду. По поводу последнего: иногда задача, которую я должен выполнить, описана формальным языком, изобилует аббревиатурами и сложными терминами. Но попросить уточнить бывает неудобно и тогда спасает Gemini: расшифрует, объяснит, уточнит.

В работе мне часто требуется подготовить Google-таблицу, заполнить данными, вписать обозначения. Я умею это делать, но не так хорошо, как хотелось бы. Тогда я фотографирую таблицу, которая подходит под мои задачи (референс) и отправляю запрос. Нейросеть мне всё объясняет по шагам: куда зайти, что нажать, что добавить. Я спокоен.

Регулярно возникает задача сделать сводный файл (без клиентских данных, разумеется) из 5-6 разных таблиц по 5 республикам. Формулы — не моя сильная сторона, и вручную эта работа займет больше, чем я могу себе позволить. Но я загружаю файлы в Claude, описываю задачу вида «Объедини файлы, чтобы строки не слетали, чтобы столбцы соответствовали друг другу» и, вуаля, через 5 минут у меня есть единый файл.

Свежий пример, когда я использовал ИИ, — подготовка стратегии на 2027-2029 года. Когда её готовил, использовал нейросети, к примеру, задал вопрос о том, сколько юридических лиц в Республике Ингушетия и в Республике Чечня. Это можно было бы сделать зайдя на официальный сайт ФНС. Но ответ нейросети я получил почти мгновенно, по сравнению с тем, сколько бы времени потратил, изучая официальные документы. И ответ был достоверен на 100%.

Если говорить про конкретные модели, то я использую Claude. Он мне нравится тем, что подготовит Word-документ под любую задачу и отправит в готовом формате. Chat GPT с теми же задачами периодически не справляется. Иногда применяю Perplexity, для изображений в презентациях — Nano Banana 2, а из «быстрых» моделей — Google Gemini. Также пробовал внутреннюю платформу банка Альфа-Ген и создал два инструмента. Первый — скриптор, — формулирует скрипты продаж. Второй выдает экспертную оценку деятельности клиента по 115 ФЗ. Для меня это был полезный опыт, мне понравилось.

Но любимчиков, если можно так выразиться, у меня нет — если одна модель не справляется, то я переключаюсь на другую. Ведь это просто инструмент.

Задач, для которых я использую ИИ, в работе не много. Но, как правило, они трудоёмкие и, благодаря дарам технологического прогресса, я экономлю 3-4 рабочих дня в месяц.

Довольно часто на рабочих созвонах с руководством и коллегами-руководителями соседних регионов меня просят уделить время на рассказ о том, чем и как мы занимаемся, как продвигаем бизнес в регионе, и почему у нас такие хорошие показатели. Обобщать и громогласно заявлять, что дело только в ИИ-инструментах будет неправильно, ведь это комплекс действий, а большую и трудоёмкую работу нашего направления я не хочу обесценивать. Но, возможно, благодаря тому, что я экономлю несколько дней работы, у меня есть фора непосредственно в рабочих задачах, позволяющая мне быть на шаг впереди? Кто знает.

При этом я не могу похвастать, что мой опыт уникален, так как оглядываясь вокруг, вижу, что ИИ-инструменты — это привычная часть окружающего ландшафта:

• В подписках в одной из соцсети смотрю ролики преподавателя английского языка из Чечни. Часто вижу, как он работает в платной версии ЧатGPT.
• Диетологи и тренеры повсеместно имеют подписки на ИИ и активно используют. Буквально несколько дней назад я стал участником одного обсуждения: я, фитнес-тренер и ещё один человек стоим в зале и спорим о том, насколько часто можно есть баранину, если ты худеешь. Слева я слышу, что нельзя категорически, справа, что можно раз в неделю, а спортивный блогер, ролик которого мы в этот момент смотрим в качестве источника истины, утверждает, что можно и каждый день. Тогда мы спрашиваем у ИИ и получаем ответ, основанный на научных данных, что для диеты баранину можно есть не больше двух раз в неделю. Баранина является диетическим продуктом, но помешает похудеть за счёт некоторых нюансов (дословно не повторю ответ, да это и не нужно). Оказалось, что блогер был неправ.
• Проходя по улице слышу, как несколько незнакомых человек обсуждают, что Claude лучше ЧатGPT и как его оплатить (в текущей ситуации).
• Молодежь сплошь и рядом использует ИИ для поиска ответов, решения домашней работы, курсовых.
• Об ИИ говорят в Правительстве, в университетах, школах, в детсадах и на кухнях.

Именно поэтому я написал в начале, что использование ИИ в работе и жизни станет нормой. Это уже норма. Когда львиная доля рабочего класса будет повседневно использовать этот инструмент в работе — лишь вопрос времени.

Как я это вижу? К примеру, прямо в маску сварщика можно встроить камеру с компьютерным зрением. ИИ в режиме реального времени будет подсказывать какую величину тока задать и какой наклона электрода соблюдать. У электриков ИИ может быть интегрирован в отдельные устройства или даже в очки дополненной реальности. Мастер направляет взгляд на стену, а ИИ, в который уже загружены строительные чертежи, данные тепловизора и прочие данные, накладывает схему проводки на поверхность, а в процессе ассистент подсказывает, где проверить изоляцию. Если очки слишком футуристично (хотя это уже данность), то можно ИИ встроить в телефон. К примеру, у сантехников будет свой ИИ в телефоне: достаточно навести камеру на старый узел труб в подвале и спец-ИИ построит 3D-модель, найдет скрытые микротрещины и места коррозии, которые незаметны глазу.

Звучит фантастично? Но это уже частично реальность. Недавно узнал, что с 2021 по 2024 год российские компании ТЭК увеличили использование ИИ на 29%. Чат-ботов для приема обращений потребителей не будем рассматривать, — это уже норма, но и без этого интересно то, что ИИ уже выявляет скрытые дефекты оборудования, анализируя массивы данных с умных датчиков; фиксирует повреждения на изоляторах или провисшие провода; прогнозирует потребление электроэнергии предприятий, рассчитывая цифры по массивам данных о погоде, потребительских привычках и колебаниях спроса.

Это уже не фантастика.

То же самое для офисных работ. Я представляю это так, что на рабочем столе в телефоне и на ПК будет стоять определенное ПО с доступом к специализированной модели, за счет которой они будут решать свои повседневные задачи. Мобильный банкир, офис-менеджер, курьер, СТО и СЕО — у каждого будет свой ИИ.

Сейчас в ИТ есть свои рабочие инструменты: ПО для ревью кода, IDE, ПО для подготовки документации, диаграмм, тестов, деплоя, системы контроля версий, библиотеки и многое другое. На каждое действие свой инструмент, своя автоматизация. Если какое-то действие повторяется 2 раза — вы его автоматизируете. К ним добавился вайб-кодинг и десяток (или десятки?) моделей, заточенных на то, чтобы писать код, спецификации, тестировать и писать отчёты.

Так почему у каждой профессии не может быть своего ИИ? Ведь инструменты уже разделены по функциональности: код, видео, текст — для каждой задачи какой-то свой ИИ работает лучше. Осталось сделать совсем чуть-чуть.

Возможно, что это чуть-чуть сделает Банк? Глобально Альфа-Банк понимает, что мне, как сотруднику, нужно, а внутри уже есть платформа, где можно сделать любого агента. Для каждой нашей роли создадут отдельные матрицы ролей с доступом к специализированному искусственному интеллекту и завернут это всё в оболочку. И я думаю, что это будет интересно многим. Например, я недавно присутствовал на событии, где коллеги демонстрировали, как они создавали разные промпты под разные задачи. Там было 415 человек. И это лишь одно мероприятие из многих.

Многие, как и я, понимают, что…

Нет иного выбора, кроме как принять технологию

В 2025 году Сэм Альтман написал, что с текущей даты (в 2025) не родится человек, который будет умнее искусственного интеллекта. И в этом есть логика: все книги у нас оцифровываются и закладываются на сервера OpenAI, с каждым годом инструменты захватывают все новую область ИТ, создаются новые лекарства, публикуются решения математических задач, ранее считавшихся недоступными.

Человек, как существо, хочет сократить путь до цели, в чем бы это ни проявлялось. А инструмент, про который мы говорим, является помощником. И каждый будет пользоваться этой технологией. Кто-то из желания быть впереди, а кто-то, потому что будет вынужден конкурировать не только с окружающими, но даже и с другими странами.

Сейчас может показаться неочевидно, но я докажу тезис на примере Китая.

В Китае верят, что технологии — это хорошо, потому что они делают страну сильнее. Благодаря обязательной школьной программе маленькие жители Поднебесной знают, что правительство поздней династии Цин закрыло свои границы и пропустило промышленную революцию. Из-за этого некогда богатейшая империя и одна из величайших стран мира оказалась технически отсталой, была легко разгромлена, колонизирована и унижена более технологически развитыми европейцами и японцами, которые превосходили Китай в оружии и промышленности.

Про эту историческую ошибку обязательно рассказывают детям в школах с самого раннего возраста. Государство воспитывает новые поколения на примере этой национальной трагедии. Каждый китайский школьник с детства усваивает: «Если ты закрываешься от технологий и отстаешь в развитии — тебя уничтожат».

Развитие технологий — это вопрос выживания.

Китай выучил урок и то, на что у других стран уходили десятилетия, в Китае уместилось в поколение — к примеру, с 1991 по 2001 год региональный ВВП дельты Жемчужной реки вырос почти в восемь раз. Это всё случилось благодаря тому, что на юге Китая (рядом с Гонконгом и Макао) были созданы Особые экономические зоны (ОЭЗ) с налоговыми льготами. Туда хлынули инвестиции и за 10 лет с 1991 года ВВП региона вырос в 8 раз, население удвоилось, открылись десятки тысяч фабрик, а бывший аграрный край («земля рыбы и риса») превратился в главный промышленный узел планеты.

Особые экономические зоны создавались для индустриального рывка — привлечения иностранных инвестиций, строительства фабрик, логистики и физического производства товаров. Когда этот фундамент «мировой фабрики» был построен, он запустил колоссальный внутренний рынок и породил огромный спрос на ИТ-инфраструктуру. Вслед за этим были рождены ИТ-гиганты — Baidu, Alibaba, Tencent). Непосредственно в Особой экономической зоне была основана только одна компания. Остальные две появились в регионах, которые развивались параллельно благодаря общему экономическому буму в стране.

Они были основаны с 1998 по 2000 год, а к концу 2000 года число интернет-пользователей в Китае выросло с 3000 в начале 1995 года до 22,5 миллиона. В 2001 году Китай вступил во Всемирную торговую организацию. В стране начался бум урбанизации, число частных автомобилей выросло в 10 раз, и сформировался многомиллионный средний класс, начавший активно тратить деньги на путешествия, качественную еду и гаджеты.

Еще недавно в Китае варили чугун в уличных печах, а сейчас страна — технологический лидер. Так что в Китае ИИ воспринимается за благо, за новый технологический стероид, и внедряется очень активно. По мнению аналитиков, эта культура технооптимизма может и будет способствовать распространению и масштабному внедрению искусственного интеллекта, и в Китае скоро буквально все будут использовать ИИ. Ведь по данным отчёта Стэнфордского университета об индексе развития искусственного интеллекта за 2026 год, 85% китайских респондентов считают, что ИИ приносит больше пользы, чем вреда, а домохозяйки, пенсионеры, студенты и инженеры стоят в очереди, чтобы им установили на ПК OpenClaw (Clawdbot/Moltbot).

Поэтому Китай снова будет впереди планеты в технологическом плане.

Как я к этому пришёл?

Я отношу ИИ к той же категории изобретений, что электричество, интернет и индустриализация — к великим изобретениям, перевернувшим жизнь человечества с ног на голову.

Для меня ИИ — это инструмент такого порядка, который перевернет всю жизнь человечества, но мы пока это замечаем лишь отчасти.

Когда в первый раз я увидел такой инструмент, то он был не в лучшей своей форме. Как вы помните, это были сырые чат-боты, а генераторы видео могли создавать только странные смазанные видео с Уиллом Смитом, которые снятся при температуре 39. И я даже не мог придумать, а что у него спросить? Мой мозг ещё не понимал, что происходит, не осознавал, насколько этот инструмент серьезный. Поэтому я мог придумать только что-то вроде «Сколько тонн в одной ванной» или посмотреть как он решит какую-то математическую формулу — банальные вопросы.

Но аппетит приходит во время еды и в процессе я начал всё чаще и чаще обращаться к инструменту — как к какому-то допингу. «Погоди, а может чат знает?», «А как бы чат-бот повел себя в этой ситуации?» И в какой-то момент я осознаю, что на вопрос «Не вреден ли дождь для недавно залитого бетона», я не иду в поисковик и не звоню по знакомым. Я иду в ИИ. Как-то мне залили бетонный фундамент и через два часа пошел дождь, а строители ушли. Я мог бы спросить у одного, у второго, у третьего человека, опасно это или нет, но я уточняю у ассистента и получаю быстрый и развернутый ответ. Я спокоен.

Первая встреча с ИИ не создала в моем сердце культурного шока. Но раз за разом задумываясь это вызывает у меня взрыв мозга. Ведь ИИ очень коварный инструмент. Чем-то похож на автомобиль.

Когда первый раз видишь автомобиль, он не вызывает привыкания. Но вот ты начал интересоваться, потрогал, поездил, ты все чаще в поездках, открываешь новые функции, вроде кондиционера, и уже не хочется посещать общественные мероприятия в автобусах и троллейбусах. Однажды на выходных посетил соседний город как турист, потом соседнюю область, а дальше вся страна и соседние. Ты чаще засматриваешься на новые модели, выбираешь комплектации, покупаешь новый автомобиль: больше, мощнее, с круиз-контролем, автоматом и люком. Подписываешься на каналы с обзорами и Телеграм-группы автоподбора и однажды ты полностью осознаешь, что без автомобиля жизнь уже не та.

С ИИ также. Он очень коварен.

Когда в 2014-м я пришел в банковскую сферу, у меня был WhatsApp на телефоне. В том банке и в том офисе были коллеги и с WhatsApp, и с кнопочными телефонами. Но через полтора года ни один день не проходил без мессенджера и кнопочные телефоны закончились.

Недавно ко мне устраивался на работу человек, и он сказал: «У меня кнопочный телефон, я противник соцсетей, я не скачаю на телефоне ни одну соцсеть, имей это в виду». К сожалению, как бы он ни был хорош, мы не сможем с ним работать, потому что я банально не смогу с ним взаимодействовать. Без мессенджера я не могу принять человека на работу. Мне нужно, чтобы он утром в группе написал прогноз, днем принял задачи, скинул презентацию, а вечером отчитался по рабочему дню. С кнопочным телефоном это невозможно.

Выше я поделился изречением Альтмана, но сейчас я бы его дополнил так: с текущей даты (в 2025) не родится человек, который не будет знать, каково это жить без искусственного интеллекта. Уже сейчас подавляющая часть молодежи с ИИ на «Ты». К примеру, в Англии, согласно свежему опросу за 2026 год, в котором приняли участие более 4000 человек в возрасте от 11 до 24 лет, почти 90% молодых людей уже использовали ИИ, а половина чаще доверяют ИИ, чем человеку.

В США, по данным Common Sense Media (июнь 2026 года) 86% детей и подростков в возрасте от 9 до 17 лет регулярно используют ИИ или взаимодействуют с ним, а среди старшеклассников (16–17 лет) эта цифра уже 92%, причем 30% используют ИИ ежедневно.

В Европе, в среднем, по данным Eurostat, 60–64% молодежи активно используют генеративный ИИ. Для сравнения, среди взрослого населения этот показатель в два раза ниже.

В России данные противоречивы, но можно однозначно сказать, что больше половины молодежи от 12 до 24 лет использует ИИ регулярно.

В Тайване в июне этого года вышло исследование в Taipei Times, где сказано, что «92% детей в возрасте от шести до 15 лет используют искусственный интеллект». А по остальному Китаю уже были данные выше.

К чему здесь эти цифры? Я вижу, как на моих глазах происходят изменения, как меняются привычки людей, как повышается «диджитальность», как мы обрастаем инструментами и гаджетами. Оглядываясь вокруг, я не исключаю, что без минимального набора ИИ-приложений будет невозможно найти работу, как сейчас не найти работу без мессенджера.

Экономическая обстановка, трудовые обязанности на работе, быт — будут сами способствовать тому, что человек просто не сможет не использовать инструменты. Если 10 человек в твоем офисе работают с чатГПТ, ты не сможешь работать в команде.

Окружение решает. Есть тысячи историй, когда погружаясь в темную среду, люди скатывались на самое дно, погрязши в деяниях, о которых не стоит говорить. Какими бы ни были базовые настройки в начале, если все вокруг прикладываются к градусу, то ты не сможешь стоять в стороне. И есть тысячи историй, когда изменив свою среду, своё окружение, люди бросали алкоголь, табак, начинали заниматься спортом, худели, находили новую интересную работу и обретали новую жизнь.

Среда возьмет своё. Это так работает.

А когда молодежь, которая не мыслит жизнь без ИИ, сама станет начальниками, то пути назад уже не будет — установленный ИИ-ассистент на телефоне и ПК будет базовым требованием в вакансиях. И это произойдёт раньше, чем мы можем предположить.

Естественно, будет 1% населения, который, скажем так, принципиально не захочет пользоваться новой технологией. Мормоны тоже не пользуются благами цивилизации (хотя и среди них есть разные градации отрицания — кто-то ездит только на лошадях и каретах, а кто-то перемещается на поездах и ест современное мороженое, созданное на хладокомбинатах), но никому не мешают и спокойно живут на своих территориях. Но с остальным миром не взаимодействуют.

Если же не заходить так далеко с примерами, то мы знаем, что и сейчас есть люди, кто никогда не пользовался соцсетями и пользуется кнопочной Нокиа. Выбор каждого, но определенный и довольно широкий пул работ в этом случае просто закрыт — ты выпадешь из социума.

И вот, что ещё интересно.

Недавно появился глобальный доклад UNICEF Innocenti (июнь 2026). Не считая того, что в докладе поделились цифрами, которые показывают беспрецедентную скорость внедрения нейросетей в жизнь подрастающего поколения, эксперты ООН открыто заявили о формировании нового типа неравенства — AI Divide (ИИ-разрыв). Он заключается в том, что дети образованных и обеспеченных родителей используют ИИ как мощный инструмент для развития и буста карьеры. В это время дети из бедных семей или бедных стран используют его для развлечения или не имеют к нему доступа вообще. В будущем это создаст огромный разрыв в уровне квалификации на рынке труда.

А где мы хотим оказаться? На какой стороне? На стороне империи поздней династии Цин или на стороне технологичного мира 21-го века?

Чтобы оказаться на «той самой стороне», другого выбора, кроме как принять технологию, нет.

Выход — арендовать видеокарту в облаке. Разбираемся, чем такие облака отличаются друг от друга, сколько стоит час работы на мощной видеокарте и какие российские облака подойдут, если данные нельзя вывозить за границу. В конце — подсказка, что выбрать под вашу задачу.

• GPU-серверы: контроль над окружением для обучения, дообучения и инференса.
• Управляемый инференс: запуск модели с меньшим объёмом работ по развёртыванию инфраструктуры.
• Инструменты ML-разработки: ноутбуки и трекинг экспериментов для командной работы.
• Условия эксплуатации: доступность ускорителей, стоимость всей конфигурации, сеть и требования к данным.

Как выбирать облако под свою модель

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

Начните с видеопамяти: место нужно не только весам модели, но и рабочим данным, включая KV-кеш — память для хранения контекста уже обработанного текста при генерации ответа. Дообучение требует отдельного расчёта памяти под выбранный метод. Для нескольких GPU проверяйте соединение между картами и узлами: наличие восьми ускорителей само по себе ничего не говорит о скорости распределённого обучения.

Сравнивайте полную стоимость: GPU, CPU, RAM, диски, хранение датасетов, трафик и простаивающие ресурсы. Для сервиса с постоянными запросами дополнительно нужны мониторинг, резервирование и понятные условия масштабирования. Российское расположение дата-центра само по себе не закрывает требования 152-ФЗ: до загрузки персональных данных проверьте документы на конкретную услугу и распределение обязанностей между вами и провайдером.

1. immers.cloud — видеокарта на час, а не на год

Допустим, вы хотите запустить открытую нейросеть — Qwen или DeepSeek — или дообучить её на своих данных. Домашней видеокарты вам точно не хватит, но можно у immers.cloud арендовать железо: берёте сервер с нужной видеокартой, работаете сколько надо и платите только за это время — с точностью до секунды.

Что это и кому подойдёт

immers.cloud — российское облако, которое сдаёт в аренду серверы с видеокартами NVIDIA. Сервер создаётся сам, через сайт или API: заявок и ожидания нет, обычно всё готово через несколько минут после регистрации и оплаты.

Кроме серверов у облака есть каталог готовых нейросетей Immers Foundation Models. По словам провайдера, в нём больше 200 открытых моделей — это крупнейший такой каталог в России. Для каждой указано, сколько видеопамяти ей нужно. Видеопамять — это рабочий стол нейросети: если модель на нём не помещается, она просто не запустится. Поэтому подсказка из каталога экономит часы проб и ошибок.

Два примера от провайдера:

• Команда «КС Авто» вынесла круглосуточную модерацию контента на три облачные RTX 4090 с Ollama: потоки изолированы по видеокартам, система работает стабильно, а на старте это обошлось дешевле команды из 15 модераторов.
• В IBS собрали песочницу для экспериментов с ИИ на GPUStack и vLLM: 11 серверов на A100, RTX 3090 и RTX 4090 обслуживают 14 моделей, и новую гипотезу проверяют за часы.

Облако рассчитано на тех, кто не боится командной строки: подключаться к серверу по SSH и настраивать окружение придётся самому. Мастера «в один клик» для всего ML-процесса здесь нет.

Какие видеокарты есть

Всего 13 моделей: H200, H100 NVL, H100, A100, V100, A10, A2, T4, RTX 5090, 4090, 3090, 3080 и 2080 Ti. В один сервер ставят до восьми карт, соединённых NVLink — быстрой шиной, через которую карты обмениваются данными, чтобы большая модель могла работать сразу на нескольких. InfiniBand для связи между серверами — по запросу.

Серверы стоят в дата-центре уровня Tier III в Москве, и всё оборудование там погружено в диэлектрическую жидкость — это называется иммерсионным охлаждением. Жидкость забирает тепло лучше воздуха, поэтому видеокарты не перегреваются и не сбрасывают частоту даже при круглосуточной нагрузке.

Как запустить модель

Есть три пути. Первый — публичный эндпоинт. Эндпоинт — это адрес, на который ваша программа отправляет вопрос и получает ответ модели. Проверить модель можно в чате на сайте или по API, ничего не разворачивая. На момент публикации это бесплатно, провайдер готовит переход на оплату за токены.

Второй — частный эндпоинт: модель разворачивается на арендованном сервере через vLLM. При создании можно указать несколько серверов — на каждом поднимется своя копия модели, а балансировщик раскидает между ними запросы.

Третий — обычный сервер: больше ста готовых образов в маркетплейсе, включая ComfyUI для генерации картинок. Управлять серверами можно через OpenStack API и Terraform.

Дообучать модели тоже можно, но своими скриптами на арендованном сервере: готового инструмента для этого нет. Данные хранят в S3, на момент публикации оно бесплатное.

Сколько стоит

Оплата посекундная, минимальный платёж — 100 ₽. Самый простой сервер с T4 стоит 20,34 ₽ в час, сервер с H200 — 423,04 ₽ в час. За предоплату на 30 или 60 дней дают скидку: на H200 — 10 и 15%, на T4 — 15 и 25%. Месяц H200 с предоплатой обойдётся в 274 129,80 ₽ вместо примерно 304 600 ₽.

Для новых пользователей есть тестовый период на 30 дней. Юрлица работают по оферте или договору через ЭДО, закрывающие документы приходят 5 числа каждого месяца. НДС провайдер не платит — он освобождён по статье 145.1 НК РФ.

Ограничения

• Трекинга экспериментов, версионирования моделей и датасетов, интеграций с MLflow и Kubeflow нет — полный MLOps-процесс придётся собирать самому.
• Одну модель на 400B+ параметров не получится разнести по нескольким серверам из коробки: потолок — восемь видеокарт в одной машине.
• По умолчанию у нового аккаунта лимит: четыре сервера, 16 vCPU, 128 ГБ памяти и 1600 ГБ хранилища. Расширяют через поддержку.
• В S3 нет версионирования, а скорость около 50 МБ/с и заметно плавает.
• Юрлицам на общей системе налогообложения НДС к вычету принять не получится.

Поддержка и документы

Поддержка работает круглосуточно: чат на сайте, Telegram, Max, почта и личный менеджер. Заявленное время ответа — не больше пяти минут. Инструкции собраны в FAQ на сайте и на YouTube-канале. У провайдера есть сертификат ГОСТ Р ИСО/МЭК 27001-2021 по защите информации, а за время простоя он обещает компенсацию в полном объёме.

Сайт: immers.cloud

2. Selectel — гибкие GPU-конфигурации

Selectel предлагает GPU как выделенное PCI-устройство внутри виртуальной машины. Можно подобрать CPU, RAM и диски под конкретную задачу, а рядом разместить хранилище, базу данных и другие компоненты приложения.

Кейсы клиентов и кому подойдёт

В кейсе RobotMIA описана инфраструктура для голосовых роботов с облачными серверами, GPU и объектным хранилищем. Подобный набор подойдёт команде, которая разворачивает речевые модели или компьютерное зрение вместе с прикладным API. Ещё один сценарий — обучение на GPU с последующим переносом модели в контейнерный продакшен.

Что можно развернуть

На GPU-ВМ можно использовать TensorFlow, PyTorch и другие ML-фреймворки, устанавливать собственное ПО и загружать образ системы. Доступен Kubernetes с GPU для обучения и инференса. Такой вариант удобен, если команда уже поставляет приложения в контейнерах и хочет встроить модели в тот же процесс разработки.

Инфраструктура и экосистема

На странице продукта перечислены T4, A2, A30, A100, RTX 4090, RTX 6000 Ada и другие карты. Доступность зависит от пула. Управлять ресурсами можно через панель, API и Terraform; рядом доступны S3, IAM, балансировщики и резервное копирование дисков. Selectel заявляет соответствие серверов требованиям 152-ФЗ до УЗ-1: состав услуги и документы следует сопоставить с требованиями конкретной информационной системы.

Отзывы и репутация

Публичный кейс RobotMIA позволяет оценить применение инфраструктуры в работающем сервисе. Указанные в нём показатели относятся к конкретной архитектуре и не служат обещанием задержки для любой модели. Агрегированная пользовательская оценка на странице GPU-продукта не приведена.

Поддержка и каналы связи

Для подбора конфигурации на странице указаны sales@selectel.ru и телефон 8 800 555-06-75. Это каналы предварительной консультации; порядок обращения по техническим инцидентам и условия реакции лучше согласовать до запуска. Есть русскоязычная документация по созданию GPU-сервера, оплате, API и Terraform.

Тарифы, ограничения и условия

Оплата — по потреблению, стоимость выбранной конфигурации уточняется в калькуляторе на сайте. Для проектов аккаунта указаны 3 ТБ бесплатного внешнего трафика; дополнительный трафик — 0,90 ₽/ГБ. Услугой могут пользоваться физические и юридические лица: доступны пополнение картой и выставление счёта.

При выборе региона сначала проверьте наличие нужной GPU в конкретном пуле. Возможность отключить ускоритель помогает сокращать расходы между задачами, но оставшиеся ресурсы нужно учитывать отдельно. Аренда GPU-ВМ даёт инфраструктуру для ML; настройку окружения, запуск заданий и эксплуатацию модели должна организовать команда.

Официальный сайт: Selectel — облачные серверы с GPU.

3. Cloud.ru — управляемый инференс

Cloud.ru предлагает Evolution ML Inference для развёртывания моделей на GPU, в том числе из пользовательских Docker-образов. Это вариант для команды, которой нужно обслуживать запросы к готовой модели с автоматизацией развёртывания и масштабирования.

Кейсы клиентов и кому подойдёт

Разработчик может запустить модель из Hugging Face для текстового помощника; команда генеративной графики — развернуть обработку изображений; ML-инженер — передать собственное окружение в Docker. Это сценарии использования продукта, а не названные клиентские внедрения: на странице ML Inference конкретные заказчики не перечислены.

Что можно развернуть

Поддерживаются vLLM, TGI, Ollama, Diffusers и Transformers, а также языковые, трансформерные и диффузионные модели. Помимо Hugging Face и маркетплейса, предусмотрен запуск с пользовательским Docker-образом. Сервис описывает динамическое автомасштабирование при изменении числа запросов.

Инфраструктура и экосистема

Для ML Inference указаны V100 и H100, а также совместное использование GPU несколькими инференсами — Shared GPU. В экосистеме Evolution есть объектное хранилище, Kubernetes, реестр артефактов, мониторинг и логирование. Cloud.ru сообщает о дата-центрах в России; расположение ресурсов конкретного сервиса и доступную сетевую схему нужно проверить при проектировании.

Отзывы и репутация

На странице ML Inference нет агрегированной пользовательской оценки. При выборе сервиса полезнее проверить совместимость собственного образа, время запуска экземпляра и поведение под всплесками запросов. Известность провайдера не определяет эти характеристики для конкретной модели.

Поддержка и каналы связи

Стандартная техподдержка работает бесплатно круглосуточно. На странице поддержки перечислены личный кабинет, телефон 8 800 444-24-99, support@cloud.ru и Telegram. Для проектов с дополнительными требованиями есть премиальный тариф по запросу.

Тарифы, ограничения и условия

Стоимость уточняется на сайте для выбранной конфигурации. При расчёте бюджета учитывайте число одновременно работающих экземпляров и условия Shared GPU: экономия на разделяемом ускорителе должна соответствовать требованиям к задержке. Общие бонусы облака не стоит считать бесплатными GPU-часами без проверки условий конкретного предложения.

Существенное ограничение для закрытых данных: Private Endpoint на странице ML Inference помечен «скоро будет доступен». Если доступ без публичного интернета обязателен, подтвердите готовность функции до выбора сервиса. ML Inference предназначен для исполнения моделей; обучение и дообучение требуют отдельного решения и расчёта ресурсов.

Официальный сайт: Cloud.ru — Evolution ML Inference.

4. VK Cloud — инструменты ML-разработки

VK Cloud предлагает GPU-ВМ и Cloud ML Platform с преднастроенными JupyterHub и MLflow. Это сочетание вычислительных ресурсов, среды для ноутбуков и инструментов работы с экспериментами.

Кейсы клиентов и кому подойдёт

Команда дата-сайентистов может использовать платформу для совместной разработки и сравнения экспериментов. Для прикладных сервисов провайдер отдельно описывает инференс небольших языковых моделей, видеоаналитику и получение эмбеддингов для RAG-поиска. На странице GPU эти сценарии приведены без привязки к конкретным клиентам.

Что можно развернуть

GPU можно использовать для обучения и инференса на виртуальных машинах с Linux или Windows. В Cloud ML Platform доступны преднастроенные JupyterHub и MLflow; GPU-конфигурация подключается к среде разработки. Наличие этих инструментов уменьшает объём начальной настройки, но производственный API и процесс доставки модели всё равно нужно спроектировать.

Инфраструктура и экосистема

Среди ускорителей перечислены L4, L40S, A30, A100 и V100. Для небольших нагрузок заявлена аренда доли карты через vGPU — от 1/24 до целого ускорителя. Доступные профили и объём видеопамяти необходимо уточнять под модель. Провайдер указывает российские ЦОД уровня Tier III и аттестацию виртуальных серверов по 152-ФЗ до УЗ-1. Рядом доступны объектное хранилище и управляемые базы данных.

Отзывы и репутация

Агрегированный пользовательский рейтинг на странице Cloud GPU не указан. Для оценки платформы имеет смысл провести небольшой командный эксперимент: проверить доступ к ноутбукам, запись метрик в MLflow и воспроизводимость запуска. Это покажет, насколько готовая среда соответствует процессам вашей команды.

Поддержка и каналы связи

Технические вопросы можно направлять через портал поддержки. При подключении Cloud GPU через заявку назначается менеджер для расчёта конфигурации и коммерческого предложения. Также доступна русскоязычная документация по GPU.

Тарифы, ограничения и условия

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

vGPU имеет смысл, когда задача не использует всю карту. Доля ускорителя ограничивает доступные ресурсы, поэтому нельзя выбирать её только по числу параметров модели: важны точность весов, длина контекста и параллельные запросы. Заявленный SLA 99,95% относится к доступности виртуальных машин и не означает такую же гарантию скорости ответов вашей модели.

Официальный сайт: VK Cloud — Cloud GPU.

5. Timeweb Cloud — облако и выделенные

Timeweb Cloud предлагает облачные и выделенные серверы с NVIDIA GPU. Провайдера можно рассмотреть для собственного ML-окружения и проектов, которым требуется отдельно подобрать физическую конфигурацию.

Кейсы клиентов и кому подойдёт

В каталоге историй на странице GPU есть проекты AI-компаний и голосовых роботов. Например, опубликована история миграции AI-сервиса и клиентских проектов. Для команды разработки практический сценарий — разместить модель рядом с бэкендом, S3 и базой данных. Для длительных вычислений можно отдельно обсудить выделенный сервер.

Что можно развернуть

На сервер разрешено устанавливать собственное ПО; доступны SSH, KVM-консоль и приложения из маркетплейса. Провайдер относит к GPU-сценариям обучение нейросетей, распознавание речи и изображений, рекомендательные системы и чат-боты. Стек обучения, зависимости и сервер инференса можно собрать под свою модель.

Инфраструктура и экосистема

В линейке перечислены T4, RTX 3090, RTX 4090 и карты серии A. Обычно провайдер предлагает от одной до четырёх GPU на сервер, большее количество обсуждается отдельно. В облаке есть Kubernetes, S3, базы данных и балансировщики. Наличие Kubernetes как соседнего продукта не следует автоматически считать подтверждением поддержки выбранной GPU-конфигурации в кластере.

Отзывы и репутация

Опубликованные истории позволяют увидеть работу облака с AI-сервисами и прикладной инфраструктурой. Их результаты относятся к отдельным проектам: кейс миграции сам по себе не подтверждает скорость обучения на GPU. Агрегированная пользовательская оценка на странице продукта не приведена.

Поддержка и каналы связи

Поддержка заявлена в режиме 24/7/365. На странице доступны чат, Telegram, форма обращения по электронной почте и телефон 8 800 700-32-92. Подбор нестандартной конфигурации и изменение выделенного сервера обсуждаются с командой провайдера.

Тарифы, ограничения и условия

Для облачных серверов указано почасовое списание, хотя тариф формируется за месяц. Стоимость GPU-конфигурации уточняется на сайте или через заявку. H100 и H200 находятся в разделе предзаказа: для него указан минимальный аванс от 5000 ₽. Это не цена месяца аренды и не подтверждение немедленной выдачи ускорителя.

У Timeweb Cloud есть российские и зарубежные площадки. Если данные должны оставаться в РФ, зафиксируйте российскую локацию и наличие нужной GPU именно в ней. Для выделенного сервера согласуйте срок подготовки и изменения конфигурации; обещание быстрого запуска облачной ВМ нельзя переносить на индивидуальную поставку оборудования.

Официальный сайт: Timeweb Cloud — серверы с GPU.

Сравнение по ключевым критериям

• Самостоятельное окружение: immers.cloud — GPU-серверы и каталог моделей; Selectel — GPU-ВМ и Kubernetes с GPU; Timeweb Cloud — облачные и выделенные серверы с установкой собственного ПО.
• Готовые инструменты: Cloud.ru — управляемый инференс с поддержкой Hugging Face, Docker и автомасштабирования; VK Cloud — Cloud ML Platform с JupyterHub и MLflow; immers.cloud — публичные и частные эндпоинты.
• Оплата: immers.cloud заявляет посекундный учёт, Selectel — оплату по потреблению, Timeweb Cloud — почасовые списания за облачные серверы. У VK Cloud минимальная аренда GPU-ВМ составляет час. Стоимость Cloud.ru нужно рассчитать для выбранной конфигурации инференса.
• Доступность: у Selectel состав GPU зависит от пула; VK Cloud предлагает подключение через заявку; H100 и H200 у Timeweb Cloud указаны как предзаказ. Наличие модели ускорителя в каталоге не гарантирует свободную конфигурацию на нужную дату.
• Ограничения: в immers.cloud потребуется самостоятельная настройка ML-процесса; у Cloud.ru Private Endpoint для ML Inference пока обозначен как будущая функция. Для Timeweb Cloud отдельно выбирайте российскую локацию, если этого требуют условия обработки данных.

Что выбрать под вашу задачу

Для проверки открытой модели начните с каталога immers.cloud, а для управляемого исполнения с масштабированием изучите Cloud.ru. Если важны командные ноутбуки и трекинг экспериментов, рассмотрите VK Cloud. Для собственного контейнерного стека с GPU подойдёт к рассмотрению Selectel; для выбора между облачной ВМ и отдельным физическим сервером — Timeweb Cloud.

Перед длительной арендой проведите короткий тест на своих данных. Зафиксируйте используемую видеопамять, время обучения или задержку инференса, пропускную способность и итоговый расход средств. Эти показатели помогут выбрать конфигурацию точнее, чем сравнение названий GPU или стоимости одного часа.

Для агентов в API подешевел кэшированный вход: $0,10 за миллион токенов, вдвое меньше, чем у GPT-6 Sol. Кроме модели, OpenAI обновила инструменты: Codex работает в облаке с общими окружениями, Codex CLI принимает голосовые команды, Agents API научился управлять компьютером, а плагины ChatGPT встраиваются в боковую панель и реагируют на события во внешних сервисах. Запись трансляции выложена на YouTube.

• GPT-6.1 Sol: $2, $0,10 и $10 за миллион входных, кэшированных и выходных токенов; в ChatGPT Work и Codex — на Plus, Pro, Business, Enterprise и Edu, в обычном чате пока нет.
• По замерам OpenAI, на DeepSWE 1.1 GPT-6.1 Sol решает 75,2% задач при $0,65 за задачу, Astra — 74,1% при $4,43.
• Ultrafast ускоряет генерацию до 8 раз в Codex и до 6 раз в API; в подписке он есть только на Pro 500 за $500 в месяц и на подходящих тарифах Enterprise и Edu.
• Codex в облаке доступен с тарифа Plus, обновлённый Codex CLI и Code Review — на всех тарифах.
• Agents API получил computer use, а MCP Events запускает автоматизации плагинов по вебхукам из внешних сервисов.

GPT-6.1 Sol стоит в пять раз меньше Astra

GPT-6.1 Sol — обновление GPT-6 Sol, которую OpenAI выпустила в API 22 сентября. Стандартные цены у новой модели в пять раз ниже, чем у GPT-6 Astra. GPT-6.1 Sol уже работает в ChatGPT Work и Codex на Plus, Pro, Business, Enterprise и Edu со стандартной скоростью, а режим Fast, по документации, доступен там, где позволяют тариф, клиент, настройки рабочего пространства и раскатка; в обычном чате ChatGPT её пока нет.

Что показывают бенчмарки OpenAI

Результаты моделей OpenAI ниже — замеры самой компании, независимых подтверждений нет; результаты конкурентов она взяла из их публичных отчётов. На графиках по горизонтали — стоимость одной задачи в долларах, по вертикали — результат в процентах, точки на линии — уровни рассуждения от low до max. Чем точка левее и выше, тем выгоднее модель.

На DeepSWE 1.1, где модели решают длинные задачи в реальных кодовых базах, лучший результат GPT-6.1 Sol — 75,2% на уровне high при $0,65 за задачу. У Astra максимум 74,1% на xhigh при $4,43, у GPT-6 Sol — 68,8% на max при $2,74. На max GPT-6.1 Sol набирает меньше, чем на high, так что предельный уровень рассуждения здесь не нужен.

AutomationBench 1.0.6 проверяет сквозные бизнес-процессы с 47 инструментами. На уровне medium GPT-6.1 Sol на 2,2 п. п. выше Opus 5.5 примерно за треть цены, но на max впереди другие: Opus 5.5 с резервными моделями — 42,5% при $1,44, Astra — 41,4% при $1,73, GPT-6.1 Sol — 36,1% при $0,30. Цену Fable 5.1 ($2,45 за задачу) OpenAI в сноске называет заниженной: в неё не вошли вызовы резервной модели, которые понадобились примерно в 40% задач.

На OSWorld 2.0, где агент работает с обычными программами (частичная оценка на offline-наборе версии v2026.08.08), GPT-6.1 Sol на max набирает 71,4% при $1,27, Astra — 73,5% при $9,44, GPT-6 Sol — 64,4% при $3,37. Разница с Astra — 2,1 п. п. при цене примерно в 7 раз ниже.

На Terminal-Bench Science 0.1 (анализ данных, симуляции, доказательство теорем в терминале) GPT-6.1 Sol получает 57,0% при $5,47 за задачу, больше чем вдвое выше GPT-6 Sol. Лидирует Astra с 68,1% при $23,80, и OpenAI сама советует брать её для самых трудных научных задач.

На GDP.pdf, где нужно отвечать на вопросы по сложным PDF, GPT-6.1 Sol на max сравнялась с Astra — по 31,0% — при цене $0,42 против $2,08. Доля ответов с фактической ошибкой на уровне low снизилась с 11,4% до 7,7%, но замер сделан на специально трудных диалогах, нетипичных для обычной работы.

Ultrafast ускоряет генерацию токенов до 8 раз, но в подписке только на Pro 500

Ultrafast — платный уровень скорости: по данным OpenAI, в Codex это до 300 токенов в секунду, до 8 раз быстрее обычного режима, в API — до 6 раз быстрее. Широко он доступен только для GPT-6 Astra, для GPT-5.6 Sol в API есть превью. В API режим включается параметром service_tier, лимиты — от 500 тыс. до 5 млн токенов в минуту в зависимости от уровня аккаунта, региональные эндпоинты вроде европейского не поддерживаются, цены вынесены в отдельную таблицу. В Codex, по документации, Ultrafast расходует включённый в подписку лимит в 8 раз быстрее обычного режима.

Подписка Pro теперь бывает трёх видов: Pro 100 за $100, Pro 200 за $200 и Pro 500 за $500 в месяц, последний с Ultrafast и лимитом в 25 раз выше, чем у Plus. Pro 200 снова открыт для новых подписчиков, но с сокращённым лимитом. Подписчики, попавшие под условия сохранения, держат прежний лимит до 29 октября 2026 года. Ultrafast это не даёт, и покупка кредитов на Pro 100 или Pro 200 его тоже не открывает.

Codex получил облачные окружения, а CLI начал слушать голос

Codex в облаке запускает задачи на удалённой машине, а ставить и проверять их можно с компьютера, телефона или из браузера. Вы выбираете репозитории GitHub, Codex сам ставит зависимости и инструменты и прогоняет проверки, а опубликованное окружение с настройками сети и секретами команда может выбирать для своих задач. Каждая задача работает в своём пространстве, даже когда ноутбук спит. Тарифы — от Plus.

В Codex CLI задачи можно ставить и направлять голосом (голосовые диалоги появились ещё в версии 0.155.0), а новый экран /agents показывает сразу несколько делегированных задач. OpenAI также улучшила возобновление сессий и работу с git worktree. Доступно на всех тарифах, обновление ставится той же командой, что и сам CLI:

Code Review в десктопном приложении ChatGPT показывает сводку и диффы и позволяет спросить Codex о проблемах до комментария в пулл-реквесте GitHub или мерж-реквесте GitLab; в автоматическом режиме Codex делает первый проход в облаке сам. Функция есть на всех тарифах.

Codex Security Cloud сканирует репозитории GitHub по запросу или расписанию, следит за новыми коммитами, сам отсеивает дубли и готовит исправления, которые можно оформить черновым пулл-реквестом. В него входит доступ к моделям программы Daybreak Blue без отдельной заявки. Тарифы — Pro, Business, Enterprise и Edu.

Какие API OpenAI дала для собственных агентов

Agents API получил computer use: агент на нём может сам работать с программами. Туда же перенесли возможности Codex — несколько агентов в одной задаче, поиск инструментов, сжатие контекста, а инфраструктуру держит OpenAI. Песочницу для команд и файлов может дать OpenAI или ваш провайдер. В Codex и ChatGPT Work функция доступна на Pro 500 и Enterprise. По словам OpenAI, отдельной платы за сам Agents API нет: оплачиваются токены и инструменты.

Decisions API сводит работу модели Luna к ответам на заданные вопросы с фиксированными вариантами: так можно классифицировать контент, маршрутизировать запросы или выбирать следующий шаг агента. Пока это ограниченное превью. Bedrock Managed Agents, сделанные вместе с Amazon, запускают агентов OpenAI целиком внутри AWS.

Sign in with ChatGPT даёт тратить лимит подписки Plus или Pro в 16 сторонних сервисах, среди них Devin, Notion, Vercel и T3, с отдельным потолком для каждого.

Для компаний OpenAI собрала набор Private Intelligence: Private Safety Processing вместе с нулевым хранением данных позволяет проводить автоматические проверки безопасности без доступа сотрудников OpenAI к содержимому запросов, а превью Private Inference на конфиденциальных вычислениях обещано осенью.

Плагины встраиваются в интерфейс ChatGPT и реагируют на события

Plugin extensions открывают сторонним разработчикам платформу, на которой OpenAI делает функции ChatGPT: плагин получает пункт в боковой панели, панель рядом с диалогом, свой просмотрщик для форматов файлов, формы и упоминания в поле ввода. Точки входа объявляются в метаданных MCP-сервера ключом openai/ui, SDK есть для TypeScript и Python. Canva, Figma и Adobe уже используют расширения.

Для авторов плагинов появились Plugin Creator и обновлённая подача в каталог с более понятной обратной связью, а сами плагины можно подключать к Sites на тарифах Business, Enterprise, Healthcare и Edu.

MCP Events — поддержка предложенной спецификации событий MCP. ChatGPT подписывается на события сервера и выполняет инструкцию пользователя: например, на каждый баг-репорт в канале #product-feedback открывает черновой пулл-реквест. Серверу нужны протокол MCP версии 2026-07-28, методы events/list, events/subscribe и events/unsubscribe и доставка вебхуками с подписью Standard Webhooks, не больше 256 КиБ на событие. Опрос и стриминг не поддерживаются, события могут прийти не по порядку, поэтому инструменты записи должны быть идемпотентными.

Dots — агенты на GPT-6 Astra, которые работают круглосуточно

Dots — постоянно работающие агенты на GPT-6 Astra со своим облачным компьютером и браузером; через плагины они подключаются к более чем 4000 приложений и доступны в ChatGPT, Slack и Teams. OpenAI приводит сценарий для разработчика: агент следит за отзывами клиентов, сам делает мелкие исправления с тестами и приносит готовые пулл-реквесты. В фоне он работает только с инструментами на чтение. Первый dot входит в Pro и Business Premium без доплаты, раскатка идёт в поддерживаемых странах; у Enterprise, Edu и Healthcare это бета, которую включает администратор.

Что OpenAI добавила в ChatGPT для командной работы

• ChatGPT Space — общее пространство команды, ChatGPT и агента dot; Pro, Business и Enterprise, создавать и править можно в десктопном приложении и вебе, на телефоне пока только искать, читать и делиться.
• Pages — документы, которые вместе правят люди и агенты; Pro, Business и Enterprise.
• Совместные слайды с экспортом в PowerPoint и Google Slides — в ближайшие недели для Pro, Business и Enterprise.
• Команды и общие задачи, которые запускаются по расписанию или по событию, например новому письму; Business и Enterprise.
• @ChatGPT в Slack и Microsoft Teams, коллегам не нужна своя лицензия; Business и Enterprise.
• Плагин Meetings пишет заметки со встреч, аудио удаляется после подготовки заметок; бета на macOS для Pro и Business.
• Профили, где можно делиться своими Sites и плагинами; Business и Enterprise.
• OpenAI Marketplace: подходящие корпоративные клиенты могут подать заявку и направить часть действующего обязательства перед OpenAI на одобренный софт 32 партнёров, от Adobe и Figma до Salesforce и CrowdStrike.

Что ещё не вышло и что можно сделать сегодня

GPT-6.1 Sol Ultrafast обещан в ближайшие дни, широкий доступ к Decisions API — тоже, совместные слайды — в ближайшие недели, превью Private Inference — осенью. Точных дат OpenAI не назвала.

• В API достаточно заменить имя модели на gpt-6.1-sol; в Codex CLI модель меняется командой /model, режим Fast включается командой /fast.
• 14 октября 2026 года GPT-5.5 уйдёт из ChatGPT, ChatGPT Work и Codex на всех тарифах; в API она останется.
• Подписчикам Pro 200 стоит проверить почту: письмо о сохранённом до 29 октября лимите получат только те, кого коснулось изменение.

Источники: OpenAI: DevDay 2026 Recap, OpenAI: Introducing GPT-6.1 Sol, OpenAI: Introducing dots, OpenAI Help Center: About ChatGPT Pro tiers, OpenAI API: Ultrafast mode, ChatGPT Learn: Speed, ChatGPT Learn: Codex Cloud, ChatGPT Learn: Codex CLI, ChatGPT Learn: Code review, ChatGPT Learn: Codex Security Cloud setup, OpenAI: Introducing the Agents API, OpenAI Plugins: Extensions, OpenAI Plugins: MCP Events, OpenAI API: Private Safety Processing, Трансляция OpenAI DevDay 2026

Изображение на обложке: Кадр трансляции: OpenAI

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

Дальше всё развивается предсказуемо. Раз разобрать поток руками невозможно, на разбор ставят языковую модель — ту же технологию, которая этот поток и создала. AI пишет код, AI ищет в нём уязвимости, AI решает, какие из находок настоящие. И остаётся вопрос: как понять, что модель не ошиблась, если проверять её ответ, вообще-то, тоже некому.

Эту проблематику подробно разбирали на OFFZONE — конференции по практической кибербезопасности, которая прошла в Москве 20–21 августа. Среди тем докладов — применение ИИ для поиска уязвимостей и анализа результатов, автоматизация задач специалистов и новые риски, которые возникают вместе с этими возможностями. Два выступления особенно точно продолжили разговор о том, что происходит, когда в цепочку поиска и проверки уязвимостей всё активнее включается AI. Мы попросили их авторов подробнее прокомментировать эту тему.

Дмитрий Абрамов занимается уязвимостями, которые приносит генеративный код: что именно ломается, когда код пишет агент. Юрий Туманов отвечает за вторую половину задачи — за разбор находок. Он строит на локальных языковых моделях триаж сработок SAST: статический анализатор просматривает код и выдаёт список подозрительных мест (это и есть сработки), а триаж — разбор этого списка на настоящие уязвимости и ложные срабатывания.

Каждый из них говорил про свою часть работы. Но в двух местах они, не сговариваясь, сказали почти одно и то же — об этом в конце.

Находок стало больше. Но не только из-за уязвимостей

Начну с оговорки, без которой дальше легко скатиться в панические настроения.

Да, поток находок вырос в несколько раз. Но объяснять это только дырявым машинным кодом неправильно, и Дмитрий сразу это проговаривает:

«Рост находок в несколько раз больше. Но я бы это связал, в первую очередь, с ростом количества строк кода из-за скорости написания кода, перестройки паттернов сканеров и периода внедрения новых сканеров».

То есть часть роста — это не новая опасность, а новая видимость. Строк стало больше, потому что их стали быстрее писать. Правила сканеров перестроили. Подключили инструменты, которые раньше в эти места не смотрели.

Но команде, которая разбирает эту очередь, от такого объяснения не легче: откуда бы ни взялся рост, вручную столько находок всё равно не обработать. И дело не только в количестве — изменилось ещё и то, как эти находки приходят.

Три механизма, из-за которых дефекты идут пачками

Это, по словам Дмитрия, главное практическое отличие генеративного кода. Раньше уязвимость была разовым событием: кто-то один раз ошибся в одном месте. Теперь ошибка тиражируется.

Первый механизм — шаблонный. Агент подобрал способ решения и применяет его везде, где видит похожую задачу:

«Агент применяет один шаблон ко всем похожим местам — если шаблон дефектный, дефект тиражируется».

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

Третий механизм Дмитрий Абрамов называет самым коварным:

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

Практический вывод отсюда простой. Чинить находки по одной бессмысленно. Если вы видите два десятка однотипных срабатываний, у них почти наверняка один источник: шаблон, правило или пример, который уже лежит в репозитории. Разбираться нужно с источником, а не с каждой строчкой в отчёте.

Что ушло, что пришло

Набор дефектов заметно изменился. Меньше стало синтаксических ошибок и простых логических багов. Отдельная история — SQL-инъекции: их стало «заметно меньше просто потому, что модель почти всегда тянет ORM». Не из соображений безопасности, а потому что так написано в большинстве примеров, на которых модель училась.

Вместо них выросли пути эскалации привилегий, архитектурные дефекты, SSRF (когда сервер можно заставить сходить по адресу, который выбрал злоумышленник), отсутствие CSRF-защиты и security-заголовков. Плюс, как формулирует Дмитрий, «отсутствие понимания архитектуры приложения» — код, который сам по себе корректен, но не учитывает, как устроена система вокруг.

Причину он называет одну:

«Но все эти ошибки чаще всего проскакивают из-за недостаточности контекста, передаваемого агенту».

Часть проблем лечится буквально этим. Заголовки и CSRF в его команде почти исчезли после того, как добавили то, что они назвали «ИБ-контекстом». Модель не отказывалась делать безопасно — ей просто не сказали, что от неё этого ждут.

А вот ролевая модель и бизнес-логика контекстом не лечатся. Здесь нужны ручные проверки или специфичные автотесты, а значит, снова человеческое время.

Кстати, он поправил саму постановку вопроса про слепые зоны:

«Слепыми называть неправильно, скорее было бы правильно — невнимательные».

Разница есть. Слепая зона — то, чего инструмент не видит в принципе. Невнимательность — то, что исправляется правильно поставленной задачей.

Ошибки не в коде, а в поведении агента

Есть категория проблем, которая не попадёт ни в один SAST, потому что это вообще не про код.

«Лишний вызов инструмента, преждевременное завершение задачи, „починил“ тест вместо кода, сфабрикованный отчёт о прогоне — как у Replit. Это не свойство кода, это свойство процесса, и статические анализаторы к нему не приспособлены по определению».

Эта мысль пригодится дальше. Модель, которая уверенно рапортует об успехе, — проблема не только на стороне написания кода, но и на стороне его проверки.

Разбирать некому. Ставим на разбор модель

Масштаб задачи у Юрия Туманова выглядит так: в агрегаторе, куда стекаются сработки всех анализаторов, накоплено больше миллиона записей. Решение одного аппсека — специалиста по безопасности приложений — по одной сработке стоит около пятнадцати рублей рабочего времени. Дальше можно умножать.

Напрашивается очевидное: спросить у модели, настоящая это уязвимость или ложное срабатывание. Спросить действительно можно.

«Спросить можно, и ответ придёт мгновенно — складный, развёрнутый, уверенный».

У него в докладе есть слайд, который так и называется: «Складно ≠ доказано».

Почему прямой вопрос не работает

Причин три.

Уверенность модели ничего не значит. Модель на семь миллиардов параметров — класс «умной автодополнялки» — на прямой вопрос подтверждает почти половину сработок и выдаёт целые серии с уверенностью 1.0.

«Само-оценка модели без внешней калибровки театральна, опираться на неё нельзя».

Формулировка вопроса определяет ответ. Куда модель натаскали при обучении, туда она и копает. Универсальная рамка «найди источник и сток» — то есть место, где данные попадают в приложение, и место, где они используются в опасной операции, — хорошо работает на цепочечных дефектах. И не работает там, где никакой цепочки нет: захардкоженный пароль или слабый алгоритм шифрования видно по одной строке.

«Универсальная рамка „найди источник и сток“ на дефектах-„свойствах“ хоронит реальное: на одном моём замере неудачная постановка вопроса похоронила 140 реальных сработок из 363».

У прямого вопроса нет метрик. Без размеченного эталона — набора сработок, по которым заранее известны правильные ответы, — неизвестно ни какая доля подтверждений оказалась правдой, ни какую долю реальных дефектов модель вообще поймала. Остаётся верить ей на слово.

Здесь стоит остановиться. У Дмитрия дефект проскакивает, потому что агенту недодали контекста. У Юрия модель хоронит реальную сработку, потому что ей задали не тот вопрос и не показали нужный кусок кода. В обоих случаях дело не в модели.

Модель предполагает, правила решают

Главное, что стоит понять про систему Юрия: последнее слово в ней принадлежит не модели. Порядок такой — модель предполагает, улики подтверждают, правила проверяют. Сам по себе вердикт модели не закрывает ничего.

Второе — сработки разделены на два сорта, и доказываются они по-разному.

Уязвимость-свойство. Опасен сам факт в коде: пароль в исходниках, слабый хеш, слишком открытые права. Вопрос ровно один — настоящий секрет или заглушка. Никакого пути данных здесь нет и быть не должно. Таких сработок в потоке подавляющее большинство, около 93%.

Для них выстроена лестница проверок, и модель на ней — лишь одна из ступеней. Сначала работает алгоритмика без всякой LLM: ключ в формате боевого AWS — сразу подтверждаем, файл сгенерированный или из SBOM — сразу ложное срабатывание. Это снимает больше половины шума и не стоит ни одного обращения к модели. Дальше вопрос уходит модели, но задаётся по сути факта. Потом больше сотни детерминированных правил проверяют её ответ и могут вердикт поправить. Потом пороги по классам: слабый ответ превращается в Unknown. Последняя ступень — человек. Отдельным правилом запрещена сама формулировка «не вижу пути атаки» как причина закрытия: именно на ней система и теряла те самые 140 сработок из 363.

Уязвимость-путь. Здесь опасен маршрут данных: SQL-инъекция, XSS, обход каталогов. Вопрос другой — дошли ли данные атакующего до опасного вызова и была ли по дороге защита. Вот для этого типа и сделан evidence gate.

Evidence gate: перечисли факты — вердикт выведется сам

Идея в том, чтобы не спрашивать у модели вердикт вообще. Сначала она обязана заполнить таблицу фактов по жёсткой схеме: найти настоящий sink — строку, где реально выполняется опасный вызов (сканер её часто теряет); перечислить каждую переменную запроса — откуда пришла, какой строкой, была ли по дороге защита; выписать список незащищённых переменных.

И только потом вердикт вычисляется из этой таблицы механически. Список не пуст — уязвимость подтверждена. Пуст, и происхождение всех переменных известно — ложное срабатывание. Улики повреждены — Unknown, пусть смотрит человек. Переопределять этот результат собственной интуицией модели прямо запрещено.

Держится всё на двух подпорках. Первая — порядок полей в ответе: сначала дословные цитаты из кода, потом вывод. Схема зафиксирована на уровне формата, пропустить шаг физически нельзя. Одна только перестановка полей подняла долю верно закрытых ложных срабатываний больше чем вдвое.

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

«Придумать вывод легко, придумать проверяемую улику сложно. <…> Фактам — да, поэзии — ни-ни».

Unknown в этой схеме — не сбой, а штатный ответ и часть защиты. Система обязана его выдать, если не определён источник или сток трассы — цепочки, по которой анализатор проследил путь данных через код; если виден только фрагмент без окружающего кода; если непонятно, тест это или бой; если не видно значение переменной. На главном замере через Unknown человеку ушло 370 сработок, и реальных уязвимостей среди них не оказалось ни одной. То есть механизм отработал ровно так, как задумывался.

И снова всё упирается в контекст. Чаще всего система отвечает «недостаточно данных» по одной причине: трасса слишком короткая. Модель видит место, где переменная попадает в опасный вызов, но не видит, откуда эта переменная пришла и проверяли ли её по дороге. Лечится это не увеличением окна и не моделью побольше, а доставкой недостающего кода. Юрий пробовал 72B через внутренний портал и получил обратный результат:

«Дисциплина важнее размера».

Решение, какому классу дефектов доверить автозакрытие, принимают не на глаз, а по результатам замера. Для каждого класса отдельно берут около сотни сработок, по которым уже есть решения живых аппсеков, и сравнивают: что по этим же сработкам сказала модель и что сказали люди. Совпало — класс допускают до автомата, нет — он продолжает ходить к человеку.

Дальше система работает на реальном потоке. Там она закрывает чуть больше половины очереди, и ни одной пропущенной уязвимости за ней пока не зафиксировали. Расплата за такую осторожность — около двухсот перестраховок: сработок, по которым система могла бы вынести вердикт сама, но на всякий случай передала их человеку.

Почему локально

Приватность здесь не аргумент в споре, а входное условие: код, трассы и содержимое агрегатора за периметр не выходят. Облачный вариант отпал сразу.

Но у локального стенда есть и собственные плюсы, главный из них — воспроизводимость. Фиксированные веса и квантизация — сжатие модели до размера, который помещается в видеокарту, — дают повторяемые вердикты, а на этом держится еженедельная калибровка.

«Облачная модель обновляется без спроса, и вчерашний замер сегодня уже ни о чём».

Со стоимостью тоже всё сходится: одна игровая RTX 4080 разбирает около восьми тысяч сработок в сутки за электричество.

История про токен

Самая показательная часть доклада— не про метрики.

«Боевой GitLab-токен, модель с уверенностью 1.0 обозвала его „placeholder in test configuration“ — заглушкой в тестовом конфиге, — поверила пути файла и похоронила. Реальный секрет, закрытый автоматом».

Доверие команды после такого падает мгновенно:

«Тысяча правильных вердиктов проходит незамеченной, одну галлюцинацию запоминают все и надолго».

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

«Доверие к автомату устроено как доверие к коллеге: ошибаться можно, прятать ошибки нельзя. Система, которая сама показывает промахи и после каждого меняется, доверие возвращает. Система, которая уверенно бормочет „всё хорошо“, теряет его навсегда».

Где проходит граница

Обоим спикерам был задан один и тот же вопрос: что бы вы не стали автоматизировать в ближайший год, даже если технически уже можно? Ответы стоит прочитать подряд.

Дмитрий Абрамов:

«У меня довольно чёткая граница, и она проходит не по сложности задачи, а по обратимости последствий и по возможности проверить результат. Не стал бы автоматизировать применение фиксов без человека. Черновик патча — отлично, автомерж в прод — нет, особенно в авторизации и криптографии».

Дальше в его списке — агент в промышленной среде, автоматическое закрытие тасок и автоматический перевод сработки в статус ложной. Последнее он оставляет как мнение модели, а не как решение.

Юрий Туманов отвечает про свою часть работы, но приходит к тому же. Автомат работает там, где улика видна прямо по артефакту, а полноту можно проверить канарейками. Цепочечные классы — SQL-инъекции, XSS, path traversal, всё, где нужно доказать путь данных через приложение, — идут к человеку: именно там небольшие модели выдают уверенные галлюцинации, а уверенный неверный вердикт обходится дороже, чем честный ответ «недостаточно данных». Необратимые действия без человека — ротация и отзыв секретов, блокировки, автопатчи с автомержем — тоже нет. И отдельно:

«Выбор допустимого риска и разметка эталона — решение людей с числами на столе. Эталон размечают люди: отдай его модели — и система начнёт сверяться сама с собой, по кругу».

Дмитрий и Юрий занимаются разными вещами. Один смотрит, как AI пишет код, второй — как AI этот код проверяет. Но границу автоматизации оба провели в одном месте, и правило у них получилось одинаковое: автоматизировать можно то, что потом можно проверить. Всё остальное — необратимые действия и всё, что зависит от контекста, которого не видно, — модель готовит, фильтрует и предлагает, но решает человек.

Совпало и кое-что конкретное. Оба назвали одно и то же действие, которое автоматизировать нельзя: перевод сработки в статус ложной без человека. Хотя со стороны именно оно выглядит самым безобидным — подумаешь, закрыли лишнюю строчку в отчёте.

Логика тут простая. Если система ошиблась в другую сторону и отдала человеку лишнюю сработку, это стоит нескольких минут его времени, и ошибку заметят. Если она посчитала ложной настоящую уязвимость, не заметит никто — пока эту уязвимость не найдёт кто-то другой.

Для программиста, который уже работает с агентами, это готовая замена самодельным файлам с инструкциями и длинным описаниям задачи в чате. Вместо «сделай мне функцию экспорта» агент получает конституцию проекта, спеку с пользовательскими историями, технический план и список задач в репозитории, и каждый шаг можно прочитать и поправить до того, как появится код. За год к базовой цепочке добавились команда сверки кода со спекой, расширения для багфикса и оценки идей, пресеты под стандарты команды и бандлы под роли. Spec Kit при этом не единственный репозиторий такого рода в топе GitHub: за ту же неделю звёзды собирали ещё десять проектов про агентов, от скиллов и надстроек над Claude Code и Codex до локального инференса и управления Blender; они разобраны во второй части.

• Spec Kit 1.0.0 вышел 21 августа 2026 года, текущий релиз 1.0.6 от 10 сентября; между ними шесть патч-релизов.
• Ставится через uv или с PyPI, командой specify init подключается к проекту под любой из более чем 30 агентов.
• Цепочка из шести слэш-команд: constitution, specify, plan, tasks, implement, converge; последняя сверяет код со спекой и дописывает недостающие задачи.
• Расширение bug ведёт исправление по шагам «оценить, починить, проверить», assess разбирает идею до решения «делать» или «не делать».
• Мейнтейнер пишет, что 1.0 больше не обещает стабильности API: ломающие изменения агент теперь переносит сам.
• Среди набравших звёзды за неделю: ponytail (135 тысяч, режет объём кода агента на 54% в замере автора), ECC (256 тысяч), skills (259 тысяч), humanizer (46 тысяч), archify (57 тысяч), HyperFrames, MiniMind, Magnitude, SGLang и blender-mcp.

Что такое Spec Kit и как он работает?

Spec Kit это утилита specify на Python плюс набор markdown-шаблонов и скриптов, которые она раскладывает в проект. После specify init в каталоге агента (например, .claude/ или .github/) появляются слэш-команды или скиллы с префиксом speckit, а в .specify/ лежат шаблоны документов. Дальше вся работа идёт внутри привычного агента.

Базовая цепочка описана в README репозитория и состоит из шести шагов. /speckit.constitution один раз на проект фиксирует принципы: стек, стиль, что запрещено. /speckit.specify превращает описание задачи в спеку с требованиями и пользовательскими историями, /speckit.plan пишет технический план под выбранный стек, /speckit.tasks режет план на задачи, /speckit.implement их выполняет. Замыкает цикл /speckit.converge: команда сравнивает кодовую базу со спекой, планом и задачами и дописывает в список то, что ещё не сделано. Шаги implement и converge повторяются, пока converge не сообщит, что всё сошлось.

Есть три необязательные команды. /speckit.clarify вытаскивает недосказанное из спеки вопросами, её рекомендуют запускать до плана. /speckit.analyze ищет расхождения между спекой, планом и задачами после tasks и до implement. /speckit.checklist генерирует чек-листы качества требований, в документации их называют «юнит-тестами для английского языка». Команда /speckit.taskstoissues, которая раскладывает задачи в GitHub Issues, в релизе 1.0.5 помечена как уходящая из ядра в отдельное расширение github-issues; пока она работает.

Что изменилось к версии 1.0?

Год назад Spec Kit был набором шаблонов под несколько команд и несколько агентов. К 1.0 вокруг ядра выросла система настройки из четырёх слоёв. Внизу ядро с встроенными командами и шаблонами, выше расширения, которые добавляют новые команды, ещё выше пресеты, которые переписывают шаблоны ядра и расширений, а на самом верху локальные правки конкретного проекта в .specify/templates/overrides/. Шаблоны разрешаются во время выполнения сверху вниз, побеждает первое совпадение.

Два расширения идут в комплекте и включаются по желанию. specify extension add bug добавляет цепочку из трёх команд для исправления ошибок: assess проверяет диагноз по отчёту, fix чинит именно найденную причину, test подтверждает, что исходный симптом исчез. Авторы объясняют это тем, что агент, который прыгает от баг-репорта сразу к патчу, часто чинит не то. Расширение assess работает ещё до спеки: intake, research, define, shape, decide, на выходе документированное решение «делать», «нужны уточнения» или «не делать». Идею с решением «делать» можно передать в /speckit.specify.

Пресеты ставятся командой specify preset add и меняют форму, а не набор возможностей: например, требуют в спеке трассируемость под регуляторику, добавляют обязательный этап проверки безопасности в план, переставляют задачи так, чтобы тесты шли первыми, или переводят весь процесс на другой язык. Бандлы собирают расширения, пресеты, шаги и рабочие процессы в один версионированный набор под роль: продакт-менеджер, аналитик, исследователь безопасности, разработчик. Ставится бандл одной командой specify bundle install, каталог бандлов у проекта свой, поверх пользовательского и встроенного. В релиз-нотах 1.0.x рядом с исправлениями регулярно идут обновления расширений сообщества, например Jira Mirror в 1.0.2, и правки в загрузчике бандлов.

Список агентов вырос до более чем 30. Для части из них, включая Claude Code, Codex CLI, Copilot и Devin, команды ставятся как скиллы, а не как файлы промптов, и вызываются как /speckit-specify или $speckit-specify, в зависимости от агента. Для остальных остаётся режим слэш-команд; переключатель --integration-options="--skills" есть у тех, кто поддерживает оба.

Почему 1.0 больше ничего не обещает?

Ведущий мейнтейнер проекта в записи к годовщине прямо говорит, что единица в номере версии здесь только число. Раньше мажорная версия была страховкой от стоимости изменений: ломающее изменение означало ручной обход всех мест вызова по гайду миграции, и семантическое версионирование превращало эту стоимость в сигнал. Теперь, по его словам, адаптация к ломающему изменению это одно предложение агенту, который правит места вызова быстрее, чем автор успевает описать их в changelog. Поэтому 1.0.0 у Spec Kit значит «хорошее место, чтобы начать», а не обещание замороженной формы. Это заявление проекта о себе, и для команд, которые встраивают Spec Kit в CI и внутренние инструменты, оно означает, что пинить версию всё равно придётся: за три недели после 1.0.0 вышло шесть патч-релизов.

Как установить и с чего начать?

В README рекомендуют менеджер uv, альтернатива pipx. Установка идёт с привязкой к тегу релиза, тег с ведущей буквой v, либо из PyPI, где пакет specify-cli обновлён до 1.0.6. Проверить, не вышла ли новая версия, можно командой specify self check.

Ключ --integration принимает имя агента из списка интеграций, например copilot, claude, codex, cursor-agent или gemini; полный перечень выдаёт specify integration list. Дальше запускается сам агент в каталоге проекта, и цепочка начинается с /speckit.constitution.

Кому это не нужно?

Spec Kit не единственный инструмент такого рода. Kiro от AWS делает то же самое внутри собственной IDE на базе VS Code, у Tessl это CLI и MCP-сервер к разным ассистентам, а сам фреймворк на момент разбора был в закрытой бете; в разборе трёх подходов на сайте Мартина Фаулера Spec Kit выделяют как самый агентонезависимый: это markdown и скрипты в репозитории, которые легко править. Обратная сторона та же: спека, план и задачи это документы, которые кто-то должен читать, и для правки в одну функцию цепочка из шести команд избыточна. Авторы и сами пишут в README, что не каждое изменение проходит полный цикл: небольшие исправления идут обычным путём через issue, pull request, ревью и тесты.

Какие ещё репозитории про ИИ-агентов набирали звёзды на этой неделе?

Подборку из десяти репозиториев, которые «за неделю разом собрали звёзды», опубликовал 10 сентября японский аккаунт So AInsight; прирост за неделю там не приведён, поэтому ниже суммарное число звёзд на 11 сентября по данным GitHub. Половина списка про то же, что и Spec Kit: как заставить агента работать по процессу, а не по настроению; остальное про инференс, обучение и управление другими программами.

1. skills, 259 тысяч звёзд. Скиллы Мэтта Покока, автора Total TypeScript, из его рабочего каталога .agents: небольшие, составные, под любую модель. В README автор прямо противопоставляет их Spec Kit, GSD и BMAD: те, по его словам, забирают процесс себе и делают ошибки в нём трудноразрешимыми.
2. ECC, 256 тысяч. Надстройка над Claude Code, Codex, OpenCode и Cursor с циклом «план, тест, реализация, ревью из свежего контекста, проверка, память, улучшение». Репозиторий под MIT, у автора есть платная версия ECC Pro как GitHub App для приватных репозиториев от $19 за место в месяц.
3. ponytail, 135 тысяч. Скилл, который заставляет агента думать «как самый ленивый сеньор»: перед кодом пройти лестницу из семи вопросов, от «нужно ли это вообще» до «есть ли это в стандартной библиотеке». Автор замерил на Claude Code и репозитории full-stack-fastapi-template по 12 тикетам: минус 54% строк, минус 22% токенов, минус 20% стоимости против агента без скилла; ранние цифры «на 80–94% меньше кода» он сам признал завышенными из-за некорректной базы.
4. archify, 57 тысяч. Скилл для Cursor, Claude Code, Codex CLI и OpenCode: агент описывает систему типизированным JSON, Node.js-компилятор превращает его в самодостаточный HTML с интерактивной схемой архитектуры, последовательности или потока данных, экспорт в PNG, SVG и WebM. Умеет сравнивать два снимка архитектуры до и после изменения.
5. humanizer, 46 тысяч. Скилл на чистом markdown, который переписывает текст агента так, чтобы в нём не было характерных следов машинного письма, без изменения смысла; ставится через npx skills add blader/humanizer или как плагин Claude Code.
6. HyperFrames, 49 тысяч. Проект HeyGen: пишешь HTML, получаешь видео. Рассчитан на агентов, которым нужно генерировать ролики с диаграммами и озвучкой без съёмки; TypeScript, Apache 2.0, Node 22 и новее.
7. MiniMind, 61 тысяча. Учебный проект: обучить языковую модель на 64 млн параметров с нуля на чистом PyTorch. Заявленные «2 часа» и «3 юаня» это оценка автора для одного прохода предобучения и дообучения минимальной версии на одной RTX 3090 и аренда GPU на это время; в репозитории полная цепочка от предобучения до DPO, GRPO и агентного RL, плюс версии с картинками и диффузией.
8. Magnitude, 4 тысячи. Локальный движок инференса: профилирует машину (Mac, NVIDIA, AMD или только CPU), подбирает подходящие модели, скачивает, настраивает и запускает их. Единственный проект списка с числом звёзд в тысячах, а не десятках тысяч.
9. SGLang, 36 тысяч. Зрелый фреймворк раздачи больших языковых и мультимодальных моделей под нагрузкой, существует с января 2024 года; в список попал, судя по всему, из-за очередного всплеска интереса, а не как новинка.
10. blender-mcp, 28 тысяч. MCP-сервер и аддон, через которые любая модель управляет Blender: создание сцен, моделирование и расстановка объектов по текстовому запросу. Сторонний проект, к Blender Foundation отношения не имеет, о чём README предупреждает отдельно.

Общий знаменатель списка тот же, что у Spec Kit 1.0: скиллы и надстройки, которые фиксируют процесс работы агента в репозитории, стали отдельной категорией инструментов, и у неё уже есть внутренняя полемика. Spec Kit и ECC предлагают полный цикл, skills и ponytail дают отдельные небольшие правила, которые сочетаются с чем угодно. Что выбирать, зависит от размера задачи: для мелких правок цепочка из шести команд избыточна, для новой функции с несколькими файлами спека и план окупаются тем, что их можно прочитать до кода.

Что смотреть дальше у Spec Kit: вынос /speckit.taskstoissues в расширение github-issues и следующие патч-релизы: между 1.0.1 и 1.0.6 паузы были от нескольких часов до десяти дней. Раздел экспериментальных целей из README никуда не делся, сроков по 1.1 или 2.0 GitHub не называет.

Источники: GitHub: репозиторий github/spec-kit, Релиз Spec Kit v1.0.0, Релиз Spec Kit v1.0.6, Manorrock: Spec Kit Turns One — and Ships 1.0.0, Документация: поддерживаемые агенты, Martin Fowler: Understanding Spec-Driven Development: Kiro, Spec-Kit, and Tessl, So AInsight в X: десять ИИ-инструментов, собравших звёзды на GitHub за неделю, GitHub: mattpocock/skills, GitHub: affaan-m/ECC, GitHub: DietrichGebert/ponytail, GitHub: tt-a1i/archify, GitHub: blader/humanizer, GitHub: heygen-com/hyperframes, GitHub: jingyaogong/minimind, GitHub: magnitudedev/magnitude, GitHub: sgl-project/sglang, GitHub: ahujasid/blender-mcp

Изображение на обложке: Логотип: GitHub

Главный вывод недели: цена за миллион токенов больше не говорит, во что обойдётся задача. Astra стоит за токен в 2,5 раза дороже GPT-5.6 Sol, но по замеру Artificial Analysis в агентном кодинге тратит на задачу втрое меньше токенов и в итоге выходит примерно в ту же сумму; на общих задачах экономия токенов всего 10%. Fable 5.1 сохранила цены Fable 5, но чтение кэша подешевело в 4 раза, и Anthropic оценивает экономию для агентных задач до 45%. Поэтому в этом обзоре у каждой модели рядом с ценой за токен стоит цена за задачу, если её кто-то мерил. Августовские релизы разобраны в прошлом обзоре, здесь они не повторяются.

• Claude Fable 5.1 и Mythos 5.1 — одна модель с разными ограничителями. Цена $10/$50 за миллион токенов, чтение кэша $0,25 вместо $1. По оценке Anthropic это минус около 25% к счёту на типичных задачах и до 45% на агентных.
• GPT-6 Astra стоит те же $10/$50. На Terminal-Bench 4.0 по замеру OpenAI она набирает 57,9% против 55,8% у Fable 5.1 при цене задачи на 63% ниже. В индексе Artificial Analysis v4.3 обе модели делят первое место с 53 баллами, но задача у Astra стоит $3,26 против $7,63 у Fable 5.1.
• Уровень рассуждений стал главным рычагом цены: у Fable 5.1 шаг с xhigh до max даёт полбалла на Humanity's Last Exam за 46% цены сверху, у Astra уровень max удваивает стоимость на коде без прироста точности.
• Дешёвый сегмент: Gemini 3.8 Flash $0,75/$3,75 до конца года, Muse Spark 1.3 $1,25/$4,25 и $0,55 за задачу индекса, Mercury 2.5 $0,20/$0,75 при заявленных 1107 токенах в секунду, DeepSeek V4 Flash $0,22/$0,66 в непиковые часы.
• MAI-Transcribe-2 стоит $0,10 за час аудио до конца года при WER 5,2% на FLEURS по замеру Microsoft. GPT-Transcribe от OpenAI стоит $0,27 за час.
• Автономность пока не продаётся: в эксперименте Bottleneck Labs семь моделей за 72 часа и $300 каждая заработали $0 и отправили 2797 писем.

Чем Fable 5.1 отличается от Astra, если цена у них одинаковая?

Разница в том, за что вы платите: Fable 5.1 берёт качеством на широком наборе задач и дешёвым кэшем, Astra экономит токены в агентном коде. Anthropic выпустила Claude Fable 5.1 и Claude Mythos 5.1 как одну модель с разными уровнями ограничителей: Fable доступна всем, Mythos только через программы проверенного доступа для кибербезопасности и биологии. В API модель называется claude-fable-5-1, есть на Amazon Web Services, Google Cloud и Microsoft Azure. Цены прежние, $10 и $50 за миллион токенов, но чтение кэша подешевело на 75%, до $0,25 за миллион. Anthropic посчитала по четырём неделям реального использования в августе, что типичная нагрузка станет дешевле примерно на 25%, а агентная, где кэш составляет большую часть счёта, до 45%. Это оценка вендора.

По бенчмаркам самой Anthropic модель обошла Opus 5 и GPT-5.6 Sol, а на низком и среднем усилии даёт результат Fable 5 дешевле. У кибер-фильтров на 60% меньше ложных срабатываний: искать уязвимости в коде теперь можно, разработка эксплойтов запрещена. В Claude Code по умолчанию уровень high.

We're moving our Opus 5 traffic in Devin to Claude Fable 5.1 on launch day. It matched or edged out Fable 5 in our testing at a lower cost per task, and with the new cache read pricing a Fable-class model is finally economical for the workloads we'd kept on Opus, starting with code review.

OpenAI начала раскатку GPT-6 Astra 3 сентября: сначала ограниченному кругу организаций, затем всем на Plus, Pro, Business и Enterprise, в API под именем gpt-6-astra, а также в Microsoft Azure и Amazon Bedrock. Стандартная цена $10 за миллион входных и $50 за миллион выходных токенов, быстрый режим даёт до 2 раз больше скорости за двойную цену. По замеру OpenAI на Terminal-Bench 4.0 Astra набирает 57,9% против 55,8% у Fable 5.1 и 37,3% у Sol, при этом задача по оценке OpenAI обходится на 63% дешевле, чем у Fable 5.1, и на 9% дешевле, чем у Sol. На Humanity's Last Exam и в общем индексе Artificial Analysis она ниже Fable 5.1 и Opus 5. Подробный разбор цен, бенчмарков и кибер-ограничений Astra есть в отдельной новости.

Независимая лаборатория Artificial Analysis разобрала Astra и увидела две разные истории. В Coding Agent Index Astra в Codex набирает 67 баллов, столько же, сколько Opus 5 и Fable 5 в Claude Code, при цене задачи меньше половины от Fable 5. Лидер индекса Fable 5.1 в Claude Code с 70 баллами. Экономия идёт от токенов: Astra тратит на задачу треть от Sol на уровне max и пятую часть от Opus 5 на xhigh. В общем индексе интеллекта картина хуже: токенов уходит всего на 10% меньше, чем у Sol, при том же балле, поэтому после подорожания в 2,5 раза задача стоит на 75% дороже. Галлюцинаций на AA-Omniscience вдвое меньше: 51% против 92% у Sol.

In the Artificial Analysis Coding Agent Index, GPT-6 Astra equals Fable 5 at less than half the cost, driven by significant token efficiency gains. In the Artificial Analysis Intelligence Index, GPT-6 Astra is more token efficient than its predecessor for similar performance, but this is offset by the price increase.

7 сентября Artificial Analysis обновила индекс до версии 4.3: Terminal-Bench поднят до 4.0, банковский Tau3-Banking заменён на AutomationBench от Zapier. По данным сайта лаборатории, Fable 5.1 и Astra на уровне max делят первое место с 53 баллами, Opus 5 набирает 51, Muse Spark 1.3 48, GLM-5.3 45, Grok 4.6 и Kimi K3 по 44, Gemini 3.8 Flash 41. Цена задачи индекса при этом $7,63 у Fable 5.1, $3,26 у Astra, $5,86 у Opus 5, $1,60 у Muse Spark 1.3 и $1,24 у Gemini 3.8 Flash.

Какой уровень рассуждений ставить, чтобы не переплатить?

Короткий ответ: у обеих флагманских моделей верхняя ступень почти не добавляет качества, а цену поднимает заметно, поэтому начинать стоит с low или medium и подниматься по результатам своей оценки. У Fable 5.1 пять уровней, по умолчанию high. Anthropic в разборе экономии приводит две цифры: на Humanity's Last Exam шаг с xhigh до max прибавляет около половины балла за 46% цены сверху, а на CursorBench 3.2 Fable 5.1 на low повторяет результат Fable 5 на high втрое дешевле. Команды Claude Code, которые ищут экономию сами (/claude-api prompt-audit, hillclimb, cost-optimize), мы разбирали отдельно.

Уровень задаётся параметром output_config.effort, пример из документации Anthropic (в примере модель Opus 5, для Fable 5.1 подставьте claude-fable-5-1). Документация отдельно отмечает, что Fable 5.1 умеет менять effort посреди диалога без сброса кэша промптов.

У Astra уровни задаются через reasoning.effort в Responses API. По документации OpenAI значение none для GPT-6 Astra не поддерживается и возвращает HTTP 400, а вызов функций работает только в Responses API, не в Chat Completions.

Однозначного оптимума у Astra нет. По опыту редакции Tproger на общих вопросах уровень выше high не окупается: цена растёт, точность нет. В коде по Coding Agent Index разумно выглядят low, medium и xhigh, а max удваивает стоимость без надёжного прироста. Рабочая схема: low по умолчанию, для сложных подзадач агент вызывает модель на более высоком уровне. Astra цепляется за формулировки, неточный промпт меняет результат сильнее, чем у прежних моделей; чеклист чистки инструкций под неё есть в отдельной статье.

Что взять, если бюджет считается в центах?

Четыре модели закрывают этот сегмент по-разному: Gemini 3.8 Flash сильнее всех в агентном коде, Muse Spark 1.3 дешевле всех за задачу на уровне Sol, Mercury 2.5 быстрее всех, DeepSeek V4.1 Flash пока бета. Google выпустила Gemini 3.8 Flash 3 сентября по вводной цене $0,75 за миллион входных и $3,75 за миллион выходных токенов; с 1 января 2027 года будет $1,50 и $7,50. Контекст миллион токенов, на OpenRouter у Flex-провайдеров вдвое дешевле. По замеру Google на DeepSWE v1.1, где модель сама доводит инженерную задачу до конца, 3.8 Flash обходит большинство более крупных моделей, на HLE-Verified набирает 54,9%. Google предупреждает: токенов на сложной задаче уйдёт больше, особенно на высоком уровне усилия, и советует понижать уровень или оставаться на 3.7 Flash.

These performance gains stem from a core design choice: 3.8 Flash works harder. On complex tasks, it exhibits greater diligence — executing extra reasoning steps, and calling tools iteratively. At times, the model might use more tokens to maximize performance, especially at higher effort levels.

Уровень рассуждений у Gemini задаётся параметром thinking_level, у 3.8 Flash доступны low, medium и high, по умолчанию medium. Пример из документации Gemini API:

Muse Spark 1.3 от лаборатории суперинтеллекта Александра Вана вышла 2 сентября в Muse Code и в API. Цены не менялись: $1,25 за миллион входных и $4,25 за миллион выходных токенов, попадание в кэш $0,15. По замеру Artificial Analysis открытая всем версия xhigh набрала 61 балл индекса v4.2, вровень с GPT-5.6 Sol и Grok 4.6, при цене $0,55 за задачу индекса против $0,95 у Sol и $0,94 у Grok. Рост почти весь в агентных задачах: банковский Tau3-Bench вырос с 35% до 47%. Просели длинный контекст и AA-Omniscience, где модель чаще отказывается отвечать. Входных токенов на задачу стало больше, поэтому цена задачи выросла с $0,40 у версии 1.2.

Inception выпустила Mercury 2.5, диффузионную модель, которая пишет текст блоками параллельно. Заявлено 1107 токенов в секунду на обычных NVIDIA GPU, контекст 260 тыс. токенов, уровень GPT-5.6 Luna на низком усилии и Claude Haiku 4.5. Цена $0,20 за миллион входных и $0,75 за миллион выходных токенов, на старте скидка 80% до $0,04 и $0,15, новым аккаунтам дают 100 млн токенов; модель есть в API Inception, на OpenRouter и Baseten. Независимых замеров Mercury 2.5 пока нет, все цифры вендора. Из кейсов в анонсе: Augment Code перевела на Mercury сжатие контекста, сжатие ускорилось со 150 секунд до 27 при снижении цены на 90%.

After we switched to Mercury, our P99 response time dropped from several minutes to just one second, and our P50 dropped from 0.4 seconds to under 0.2 — significantly faster than any other provider we've seen, and that's including reasoning.

DeepSeek 8 сентября открыла бету V4.1 Flash на два дня: модель deepseek-v4.1-flash-expires-on-0910 живёт в API до 10 сентября с лимитом 20 параллельных запросов. Цена как у V4 Flash: по прайс-листу $0,22 за миллион входных токенов при промахе кэша, $0,007 при попадании и $0,66 за миллион выходных в непиковые часы; в пиковые вдвое дороже, $0,44 и $1,32. Официальных бенчмарков нет. Тестеры намерили 400–500 токенов в секунду, а китайский XSCT Bench поставил V4.1 Flash выше V4 Flash, Gemini 3.8 Flash и Qwen3.8 Flash почти везде.

Qwen 2 сентября обновила закрытую Qwen3.8-Max до снапшота 0902: те же 2,4 трлн параметров, миллион контекста, режим размышлений, дообучение на кодинг и совместную агентную работу. По словам Qwen, прирост в основном в коде и агентных правках репозиториев, до Opus 5 в терминале ещё далеко. Цена в QwenCloud $2 за миллион входных и $6 за миллион выходных токенов, чтение кэша $0,17.

Что нового в картинках и распознавании речи?

Две картиночные модели без бенчмарков и одна речевая с рекордом на FLEURS. OpenAI выпустила ChatGPT Images 2.5: в API две модели, GPT-Image-2.5 Flare по умолчанию с вдвое меньшей задержкой, чем у GPT-Image-2, и Sunburst для точных правок. Цена у обеих $8 за миллион входных токенов картинки, $30 за выходные и $5 за текст на входе. Бенчмарков в анонсе нет, только примеры.

Microsoft AI выпустила MAI-Image-2.6-Flash и вывела MAI-Image-2.6 из закрытого превью в Microsoft Foundry. По заявлению Microsoft, Flash рисует в 2,8 раза быстрее GPT-Image-2-Medium при сопоставимом качестве; старшая модель на Arena вторая в генерации и редактировании, у Artificial Analysis вторая в генерации и первая в редактировании.

MAI-Transcribe-2 Microsoft выпустила 3 сентября: 60 языков с автоопределением, разделение говорящих, таймкоды на каждое слово, режимы verbatim и clean, подсказка терминов. По замеру Microsoft модель первая на мультиязычном FLEURS со средним WER 5,2%, у Artificial Analysis вторая по точности. Цена $0,10 за час аудио как акция до конца года, GPT-Transcribe от OpenAI стоит $0,27 за час. На OpenRouter модель лежит под именем microsoft/mai-transcribe-2, ещё есть в Microsoft Foundry и MAI Playground.

Какую модель брать под какую задачу в сентябре 2026 года?

Ниже сводка по задачам с ценами на 9 сентября. Все цены из прайс-листов вендоров, цены задач из замеров Artificial Analysis и вендоров, как указано.

• Агентный кодинг в большой кодовой базе. GPT-6 Astra на low или medium: 67 баллов Coding Agent Index при цене задачи меньше половины от Fable 5 (Artificial Analysis). Если важен максимум качества, Fable 5.1 в Claude Code с 70 баллами, но задача почти вдвое дороже.
• Массовые дешёвые задачи с агентами. Gemini 3.8 Flash на low: $0,75/$3,75 до конца года, $1,24 за задачу индекса v4.3. Muse Spark 1.3 на xhigh, если нужен уровень Sol за $0,55 за задачу (AA, v4.2).
• Голосовые агенты и всё, где важна задержка. Mercury 2.5: $0,20/$0,75, заявленные 1107 токенов в секунду и медиана ответа около 170 мс у OpenCall. Независимых замеров нет, проверяйте на своём трафике: новым аккаунтам дают 100 млн токенов.
• Сжатие контекста и маршрутизация внутри агента. Mercury 2.5 по кейсу Augment Code или DeepSeek V4 Flash за $0,22/$0,66 в непиковые часы.
• Транскрибация. MAI-Transcribe-2 за $0,10 в час до конца года против $0,27 у GPT-Transcribe.
• Картинки. GPT-Image-2.5 Flare для скорости, Sunburst для правок, $8/$30 за миллион токенов картинки.
• Длинный контекст. Qwen3.8-Max-0902 или Gemini 3.8 Flash с миллионом токенов; у Astra и Muse Spark 1.3 длинный контекст по замерам Artificial Analysis просел.

Порядок действий, чтобы перейти на новые модели без сюрпризов в счёте:

1. Замените идентификатор модели: claude-fable-5-1 в Claude API, gpt-6-astra в Responses API, gemini-3.8-flash в Gemini API. У Astra уберите reasoning.effort: none, иначе получите HTTP 400.
2. Поставьте низкий уровень усилия (output_config.effort: low, reasoning.effort: low, thinking_level: low) и прогоните свою оценку; поднимайте уровень только там, где балл растёт.
3. Проверьте долю попаданий в кэш: у Fable 5.1 чтение кэша стоит $0,25, и смена effort посреди диалога кэш не сбрасывает, у остальных моделей сброс возможен.
4. Для агентов с инструментами на Astra заложите обработку остановки: внешний мониторинг OpenAI может прервать задачу, и через API диалог не возобновить.
5. Сравнивайте цену задачи вместо цены токена: считайте токены на задачу из поля usage в ответе API и умножайте на прайс.

Почему автономный агент на новых моделях всё ещё нельзя оставлять без присмотра?

Потому что фильтры вендоров останавливают работу, а сами модели делают лишнее. OpenAI признаёт, что Astra достигла критического уровня в кибербезопасности по её Preparedness Framework: в тестах модель сама нашла и использовала две уязвимости нулевого дня. Поэтому на вызовы с инструментами в Codex, ChatGPT и Responses API включён внешний мониторинг.

Extra safety checks can sometimes slow, pause, or stop legitimate work, including defensive cybersecurity. If a task is paused in ChatGPT or Codex, you may be asked to review the action before continuing. In the API, the task will stop.

Вторая причина показана в эксперименте Bottleneck Labs, которая дала семи моделям по $300, Mac mini, почту, Stripe и 72 часа с промптом «заработай как можно больше денег». Итог по всем семи: 2797 писем, 11 живых посетителей, выручка $0, около $2800 на токены. Qwen 3.8 открыла сервис аудита GitHub-репозиториев, упёрлась в лимиты почты и выставила через Stripe 50 счетов незнакомым людям за незаказанную работу на $12 350, сочтя это допустимым шагом продаж. Это один эксперимент одной компании, но подтверждение человеком на платёжных действиях он делает обязательным.

Попробовать можно без денег: Inception даёт 100 млн токенов Mercury 2.5 новым аккаунтам, а Z.ai до 20 сентября держит ночной Global Build с бесплатной GLM-5.3-Flash для подписчиков Coding Plan. Цену решённой задачи у GLM-5.3, Sol и других мы считали отдельно. Следующая проверка — когда OpenAI закончит раскатку Astra и Artificial Analysis добавит в индекс v4.3 Mercury 2.5 и DeepSeek V4.1 Flash.

Источники: Anthropic: Introducing Claude Fable 5.1 and Claude Mythos 5.1, Claude Platform Docs: Effort, Claude Blog: Reducing cost and improving performance with Claude Platform, OpenAI: Introducing GPT-6 Astra, OpenAI Docs: Reasoning models, OpenAI: Introducing ChatGPT Images 2.5, Artificial Analysis: разбор GPT-6 Astra, Artificial Analysis: замер Muse Spark 1.3, Artificial Analysis: Intelligence Index v4.3, Artificial Analysis: главная страница индекса, Google: Gemini 3.8 Flash and 3.8 Flash Cyber, Gemini API Docs: Thinking, Inception: Introducing Mercury 2.5, QwenCloud: Qwen3.8-Max-0902, Alibaba Qwen: анонс Qwen3.8-Max-0902, DeepSeek API Docs: Pricing, IT之家: бета DeepSeek V4.1 Flash, Microsoft AI: MAI-Transcribe-2, Microsoft AI: MAI-Image-2.6, Bottleneck Labs: Benchmarking 7 autonomous businesses

Этот обзор продолжает августовский разбор открытых моделей. В сентябре главный сдвиг в том, что для каждого объёма памяти, от часов до двух серверных узлов, есть свежая модель, а независимый замер Quesma показал: 4-битный квант Qwen3.8-27B в 17 ГБ на трёх бенчмарках неотличим от полной версии в 55 ГБ. У каждой модели ниже три вещи: для каких задач, какие цифры и чей замер, как запустить.

• Nex-N2.5-Max: 1,6 трлн параметров, MoE, контекст 262 тыс. токенов, Apache 2.0. По таблице самой Nex-AGI на AutomationBench 50,2 против 50,3 у Opus 5, на SWE-Bench Pro 65,7 против 79,2. Запуск: два узла по восемь H200.
• K2 Horizon от MBZUAI: шесть моделей 0,9–375 млрд параметров, Apache 2.0, обещаны чекпоинты, данные, код и логи обучения. Модель 36B-A4B с 4 млрд активных на Terminal-Bench 2.1 набирает 58,6 против 53,9 у Nemotron 3 Ultra на 550 млрд (замер IFM).
• MiniCPM5-2B: 2,5 млрд параметров, индекс Artificial Analysis v4.2 равен 15, столько же у Qwen3.5 9B вчетверо большего размера. Тратит 19 тыс. токенов на задачу индекса против 56 тыс. у Ling 3.0 Tiny.
• Quesma потратила $3000 на GPU и не нашла измеримой разницы между BF16 в 55 ГБ и Q4_K_M в 17 ГБ у Qwen3.8-27B на GPQA Diamond, IFBench и Terminal-Bench 2.1. 1-битные кванты отвечают на уровне случайного угадывания.
• GLM-5.3-Flash в llama.cpp стала быстрее до 3,3 раза на длинном контексте после доработки Unsloth; на 65 тыс. токенов скорость выросла с 20,7 до 49,0 токенов в секунду ещё без MTP. Требования прежние: 100 ГБ для 1-битного кванта, 128 ГБ для 3-битного.
• llama.cpp 0.4.0 добавила ленивое чтение тензоров --lazy-mode, потолок памяти квантизатора и разреженное flash attention для DeepSeek-V4, GLM и Qwen3.8-Flash-Next.

Что вышло крупного и кому это по силам запустить?

Три больших релиза недели: Nex-N2.5 на 1,6 трлн параметров, семейство K2 Horizon и обновление Hy4, которое до открытых весов не дошло. Дома реально запускается только младшая K2 Horizon и, с натяжкой, Nex-N2.5-mini на двух H100.

Nex-AGI выложила Nex-N2.5, следующее поколение агентных моделей после июньской Nex-N2, в трёх размерах: mini, Pro и Max. Max это текстовая MoE-модель на 1,6 трлн параметров, первый у компании пост-трейнинг триллионного масштаба. Все три под Apache 2.0, контекст 262 144 токена. По таблице в карточке модели, замер вендора, Max сильна в агентных задачах: AutomationBench 50,2 против 50,3 у Claude Opus 5, BrowseComp 92,6 против 90,8 у Opus 5. В коде отстаёт: SWE-Bench Pro 65,7 против 79,2 у Opus 5. Чужие цифры Nex-AGI берёт из отчётов вендоров, так что таблица сравнивает разные харнесы.

Vision is therefore no longer merely an input modality; it has become a critical interface through which an agent perceives its environment, verifies outcomes, and moves a task forward.

Порог входа высокий. В репозитории Max запускается через форк SGLang в Docker на двух узлах по восемь H200, Pro на восьми H100, mini на двух H100. Mini и Pro есть на OpenRouter под именами nex-agi/nex-n2.5-mini и nex-agi/nex-n2.5-pro. Веса Pro в карточке только анонсированы, считать её открытой рано.

Институт фундаментальных моделей MBZUAI (IFM) 3 сентября выпустил K2 Horizon, шесть моделей под Apache 2.0: 375B-A23B для серверов, плотная 32B и разреженная 36B-A4B для рабочих станций, 7B и 3.7B для телефонов, 0.9B для часов и очков. Каждая обучена примерно на 20 трлн токенов. Главное обещание IFM: открыть для каждой модели весь путь, от промежуточных чекпоинтов и данных или рецептов их сборки до кода, конфигов и логов обучения вплоть до агентного пост-трейна.

A final checkpoint shows what a model can do. Horizon's complete training record helps reveal how it learned to do it.

Самая интересная из шести для локального железа это K2-Horizon-MoVA-36B-A4B: 36 млрд параметров, около 4 млрд активных на токен, контекст 524 288 токенов. Разреженность применена не только к полносвязным слоям, как в обычном MoE, но и к вниманию: механизм MoVA (Mixture-of-Value Attention) маршрутизирует экспертов внутри multi-head attention. По таблице IFM, где базовые значения взяты у Artificial Analysis, на τ³-Banking она набирает 26,8 против 14,2 у Nemotron 3 Ultra на 550 млрд, на Terminal-Bench 2.1 58,6 против 53,9, а отстаёт на Humanity's Last Exam и на длинном контексте AA-LCR. Запуск из README:

Про Hy4 от Tencent важно не перепутать. Компания 7 сентября сообщила, что подкрутила preview-версию: модель думала дольше нужного. Цифр нет, обновление уже работает в сервисах Tencent вроде WorkBuddy, а веса на Hugging Face не менялись с 28 августа.

Что поместится на одну видеокарту или в ноутбук?

Четыре свежие модели (Granite 4.2 8B вышла 31 августа) рассчитаны на 4–24 ГБ памяти: MiniCPM5-2B для агентов на ноутбуке, Spark-X2.5-4B для длинного контекста, младшие K2 Horizon для телефонов и Granite 4.2 8B для дешёвых массовых запросов. Ни одна не заменит большую модель в знаниях, и это видно по бенчмаркам.

OpenBMB выложила MiniCPM5-2B, плотную модель на 2,5 млрд параметров под Apache 2.0, контекст 131 тыс. токенов, с вызовом инструментов и рассуждениями. По независимому замеру Artificial Analysis она набирает 15 баллов индекса v4.2, лучший результат среди открытых моделей до 4 млрд: на 4 балла выше Granite 4.2 3B и вровень с Qwen3.5 9B вчетверо большего размера. Сильная сторона агентные задачи: GDPval-AA v2 831 против 718 у Ling 3.0 Tiny, τ³-Banking 21%. Слабые места знания и терминал: Terminal-Bench 2.1 9% против 29% у Qwen3.5 9B. Зато токенов на задачу индекса уходит 19 тыс. против 56 тыс. у Ling 3.0 Tiny, а для ноутбука это и есть скорость ответа.

As a dense model, its size advantage is in memory footprint rather than active-parameter compute.

Под капотом, по README, три стадии пост-трейна: SFT на 400 млрд токенов, RL по доменам и дистилляция 16 экспертных RL-моделей, из них 5 агентных, обратно в одну модель. Запуск через vLLM по README:

Spark-X2.5-4B решает другую задачу: агент со сверхдлинным контекстом на слабом железе. Модель на 4 млрд параметров держит 1 млн токенов, потому что на каждый слой с полным вниманием приходится три со скользящим окном, и кэш растёт медленнее. Обучена примерно на 20 трлн токенов на кластерах Huawei Ascend, поддерживает больше 200 языков, лицензия Apache 2.0. По таблице в карточке модели (замер вендора) на τ³-bench она набирает 30,4 против 9,3 у Qwen3.5-9B, на остальных тестах идёт вровень с моделями своего размера. Есть версия на 1,7 млрд. Из README, запуск в vLLM через официальный образ:

Младшие K2 Horizon 0.9B, 3.7B и 7B IFM называет лучшими в своих классах; у 0.9B, по данным блога, больше 48 баллов на AIME 2026. При этом IFM оговаривает: задачи с долгим исследованием, как в Terminal-Bench, малым моделям по-прежнему трудны. Веса, а для большинства и FP8 с GGUF, лежат в коллекции на Hugging Face.

Granite 4.2 8B от IBM, плотная модель с рассуждениями и контекстом 131 072 токена под Apache 2.0, стоит на OpenRouter $0,06 за млн входных и $0,25 за млн выходных токенов. Индекс Artificial Analysis v4.3 всего 12,4 при 17,6 у Haiku 4.5, агентные задачи слабое место: это модель под дешёвые массовые запросы вроде классификации, для агентов её не хватит.

Сколько памяти реально нужно локальной модели?

Для Qwen3.8-27B ответ измерен: 17 ГБ. Piotr Migdał из Quesma прогнал кванты от Unsloth через GPQA Diamond, IFBench и Terminal-Bench 2.1 на арендованных GPU Modal, потратил около $3000 и не нашёл измеримой разницы между полной BF16-версией в 54,7 ГБ и 4-битным Q4_K_M в 17 ГБ ни на одном из трёх тестов.

Цифры такие. На GPQA Diamond при уровне рассуждений xhigh BF16 даёт 89,9%, Q4_K_M 90,4%, 2-битный UD-Q2_K_XL 85,4%, доверительные интервалы перекрываются. На IFBench 81,7% против 81,0% и 80,0%. На Terminal-Bench 2.1 из 89 задач BF16 и Q4_K_M решили по 63, UD-Q2_K_XL 57.

In short, if you go with a 4-bit quantization Q4_K_M (17GB), you won't notice a difference on these benchmarks.

На практике Quesma держала KV-кэш в F16, около 2,3 ГБ на 32 тыс. токенов, и Q4_K_M влезает в 24 ГБ карты вроде RTX 4090 вместе с контекстом примерно на 64 тыс. токенов. 2-битный UD-Q2_K_XL на 10,7 ГБ по инструкциям и знаниям почти не отстаёт, а в агентном кодинге проседает и на тех же решённых задачах пишет в медиане на 27% больше токенов. 1-битный UD-IQ1_S на GPQA при xhigh даёт 10,4% и в 64% случаев возвращает пустой ответ: думает до исчерпания бюджета. Уровень рассуждений xhigh стоит включать только там, где он измеримо помогает: на GPQA да, на IFBench нет.

Ещё сильнее ужалась лаборатория DASLab австрийского института ISTA. Её кванты GSQ-RCO той же Qwen3.8-27B неравномерные: точность каждого тензора подбирается градиентным поиском под заданный размер файла. Сборка на 3,5 бита весит 11,8 ГБ вместо 53,8 ГБ в BF16 и, по замеру самой лаборатории, повторяет базовую модель на AIME25 (100,00) и LiveCodeBench v6 (85,71), уступая 0,51 балла на GPQA-Diamond. Это обычные GGUF, работают в llama.cpp, Ollama и LM Studio:

Для тех, у кого памяти много, а модель большая, новость недели это скорость GLM-5.3-Flash. Unsloth 4 сентября дописала свой pull request в llama.cpp: ускорила декодирование и добавила MTP, предсказание нескольких токенов за шаг. Кванты те же, докачивать ничего не нужно. На одной B200 с квантом UD-IQ1_S генерация на контексте 65 536 токенов выросла с 20,66 до 48,99 токена в секунду ещё без MTP, на коротких промптах прирост до 1,6 раза. С MTP лучший вариант два черновых токена: на 4096 токенах 86,5 против 58,6 без MTP.

However we should stop at around n=2 as more draft tokens makes inference slower.

Требования не изменились: 1-битный квант в 100 ГБ памяти, 3-битный в 128 ГБ, как у Mac Studio или DGX Spark. По таблице Unsloth, 1-битный UD-IQ1_S в 93 ГБ сохраняет 71% совпадений top-1 токена с BF16 в 642 ГБ, 3-битный 82%. С учётом результата Quesma по 1-битным квантам Qwen3.8 к 1-битной GLM стоит относиться осторожно: совпадение токенов и решение задач это разные метрики.

Наконец, llama.cpp 0.4.0, очередной сводный релиз, которые проект теперь собирает из ежедневных билдов раз в несколько недель. Что важно локальщику:

• Новые архитектуры: Qwen3.8-Flash-Next (пока без оптимизаций), Nemotron-3-Puzzle 75B с 9 млрд активных, DSpark для Nemotron 3.5.
• Разреженное flash attention для DeepSeek-V4, GLM и Qwen3.8-Flash-Next; ggml обновлён до 0.23.0.
• Ленивое чтение тензоров --lazy-mode: большие тензоры читаются по мере надобности, а пик памяти при загрузке убран.
• Потолок рабочей памяти квантизатора: раньше один большой тензор мог съесть всю оперативку.
• Сервер: лимит контекста на слот, видео на вход через --video-*, медиа через data:-ссылки, preserve_reasoning по умолчанию.

Что нового не только для текста?

Картинки, речь, вождение, временные ряды и видео. Под Apache 2.0 или MIT четыре модели из шести: TimesFM 3.0 только для некоммерческого использования, а у VDN-H3 своя лицензия MiniMax.

LLaDA-Image. Ant Group выложила модель на 6 млрд параметров, которая одним чекпоинтом и генерирует картинки, и редактирует их по инструкции; и языковой бэкбон, и картиночная часть диффузионные. Базовая версия работает за 50 шагов, Turbo за 4. На Qwen-Image-Bench 53,53 в английском, по данным авторов лучший результат среди открытых. Веса под Apache 2.0, есть FP8 и демо Turbo; код проверен на Python 3.11, PyTorch 2.8 и Diffusers 0.39.0.

Ling-3.0-flash-VL. Та же Ant Group показала зрячую версию Ling-3.0-flash (MoE, 5,5 млрд активных из 124) с таблицей против Qwen3.8-27B и Gemini 3.5 Flash-Lite: впереди по распознаванию документов и агентным задачам с картинками, отстаёт в математике по картинкам. Веса выложены на Hugging Face 8 сентября под MIT, есть FP8-версия.

VibeVoice-ASR-Streaming. Microsoft Research открыла потоковое распознавание речи, которое сразу пишет, кто что сказал, без отдельного этапа диаризации. Десять языков, русский в списке. По отчёту авторов, 7B-версия по доле ошибок в среднем лучше Gemini 3.5 Transcribe Live, ElevenLabs Scribe v2 Realtime и потоковых моделей OpenAI на четырёх наборах записей встреч и мультиязычном MLC-Challenge, хотя на двух Gemini впереди. Версии 1,5B и 7B под MIT, код на GitHub; список терминов, чтобы модель их не коверкала, передаётся флагом --context_info.

Qwen-Drive-1.0. Qwen вместе с Хуачжунским университетом выложила модель для беспилотного вождения на базе Qwen3.5-4B: VLM отвечает на вопросы о сцене, два внешних модуля дают 3D-восприятие и траекторию. На NAVSIM v1.1 планировщик после RL даёт 90,7 PDMS (замер авторов). Apache 2.0, VLM весит 9,1 ГБ, нужна карта от 24 ГБ.

TimesFM 3.0. Модель Google для прогноза временных рядов научилась прогнозировать несколько связанных рядов сразу и, по данным авторов, держит первое место на fev-bench и GIFT-Eval. Ставится через pip install timesfm[torch], но веса выпущены под некоммерческой лицензией.

VDN-H3. Ускоренная версия MiniMax-H3 для генерации видео со звуком: к сети добавили линейную ветку внимания по кадрам и два LoRA-адаптера. По словам авторов, ролик на 14,4 секунды генерируется за 11 секунд на восьми B200. Лицензия своя, MiniMax H3 Community License, перед коммерческим использованием её стоит прочитать. Лицензия своя, MiniMax H3 Community License, перед коммерческим использованием её стоит прочитать.

Что для какой задачи брать в сентябре 2026?

Короткий ответ: выбирать стоит по задаче и объёму памяти, размер в названии вторичен. Пары «задача, модель, почему» по цифрам выше; цены и требования проверены 9 сентября 2026.

• Агент на слабом железе: MiniCPM5-2B. Лучший индекс Artificial Analysis до 4 млрд, 19 тыс. токенов на задачу, есть GGUF и MLX, Apache 2.0.
• Агент с огромным контекстом на одной карте: Spark-X2.5-4B. 1 млн токенов при 4 млрд параметров, τ³-bench 30,4 против 9,3 у Qwen3.5-9B по замеру вендора.
• Локальный кодинг на 24 ГБ: Qwen3.8-27B в кванте Q4_K_M от Unsloth (17 ГБ) или GSQ-RCO IQ3_S от ISTA (11,8 ГБ). Сравнения двух между собой на Terminal-Bench никто не публиковал.
• Терминальный агент на рабочей станции: K2-Horizon-MoVA-36B-A4B. 4 млрд активных, Terminal-Bench 2.1 58,6 по замеру IFM, контекст 524 тыс.
• Кодинг на 128 ГБ памяти: GLM-5.3-Flash в 3-битном кванте Unsloth, теперь до 3,3 раза быстрее на длинном контексте. Про цену решённой задачи в API есть отдельный разбор.
• Распознавание встреч с указанием, кто говорил: VibeVoice-ASR-Streaming-7B. Стриминг, диаризация внутри, русский в списке, MIT.
• Картинки и правка по инструкции: LLaDA-Image-Turbo, 4 шага, есть FP8, Apache 2.0.
• Прогноз временных рядов: TimesFM 3.0, только для исследований из-за некоммерческой лицензии.
• Дешёвые массовые запросы через API: Granite 4.2 8B, $0,06 и $0,25 за млн токенов на OpenRouter; для агентов её не хватит.

Правило из замера Quesma, которое по опыту редакции Tproger подтверждается: берите самую большую модель, которая помещается в память вместе с нужным контекстом, и не бойтесь 4-битных квантов. 1-битные для задач с рассуждениями не годятся.

Что происходит вокруг и чего ждать дальше?

Вокруг релизов три события задают контекст, и все три об одном: открытые веса стали коммерческой стратегией.

Vals AI 31 августа опубликовала полные результаты GLM-5.3: в Vals Index модель вторая среди открытых с 57,0 балла после Kimi K3 и 13-я из 50 в общем зачёте при 18-м месте у GLM-5.2. Это объясняет, почему GLM-5.3 и GLM-5.3-Flash держатся в топе загрузок Hugging Face вторую неделю.

Mistral 8 сентября объявила, что подняла €3 млрд при оценке больше €21 млрд; по словам компании, это крупнейший акционерный раунд в истории европейских технологических компаний. Раунд ведёт Samsung Electronics, ставка прежняя: открытые веса плюс своя инфраструктура. Новых моделей в анонсе нет.

DeepSeek открыла бету V4.1 Flash: модель deepseek-v4.1-flash-expires-on-0910 живёт в API до 10 сентября, веса не выложены, официальных бенчмарков нет, так что в обзор она не попадает; о закрытых моделях речь в разборе за август. Что проверить дальше: выйдут ли веса Nex-N2.5-Pro, доедет ли доработка Unsloth в основной llama.cpp и обновит ли Tencent веса Hy4.

Источники: Карточка Nex-N2.5-Max на Hugging Face, Репозиторий Nex-N2.5 на GitHub: команды запуска, IFM: Introducing K2 Horizon, Карточка K2-Horizon-MoVA-36B-A4B, Коллекция K2 Horizon на Hugging Face, Artificial Analysis: OpenBMB releases MiniCPM5-2B, Карточка MiniCPM5-2B на Hugging Face, Репозиторий MiniCPM на GitHub, Карточка Spark-X2.5-4B на Hugging Face, Quesma: Benchmarking Qwen3.8 27B quantizations, ISTA-DASLab: Qwen3.8-27B GSQ-RCO GGUF, Unsloth: GLM-5.3-Flash, how to run locally, Релиз llama.cpp v0.4.0, LLaDA-Image на GitHub, Карточка VibeVoice-ASR-Streaming-7B, Qwen-Drive-1.0 на GitHub, TimesFM на GitHub, Granite 4.2 8B на OpenRouter, Mistral: раунд на €3 млрд, Vals AI: результаты GLM-5.3

Для разработчика это значит, что аудит расходов теперь можно запустить одной командой прямо в рабочей директории проекта, а не выискивать промахи кэша по логам. Цифры в статье приводит сама Anthropic, поэтому ниже они даются с оговорками авторов.

• Кэш промптов ломают таймстампы в системном промпте, перетасованные описания инструментов и смена effort посреди диалога. Менять effort без сброса кэша умеют отдельные модели, в том числе Opus 5 и Fable 5.1.
• Команда prompt-audit вычищает из промптов «проверь дважды», «будь максимально тщательным», обязательные scratchpad и противоречивые правила. На саппорт-бенчмарке при переезде с Opus 4.8 на Opus 5 это дало минус 14,6% к стоимости и плюс 5,3 пункта точности.
• На CursorBench 3.2 Fable 5.1 на низком усилии повторяет результат Fable 5 на высоком за треть цены. У Fable 5.1 на Humanity's Last Exam шаг с xhigh до max прибавляет полбалла за 46% цены сверху.
• Команда cost-optimize на четырёх открытых бенчмарках с Sonnet 5 срезала 52–73% стоимости при качестве в пределах шума.
• Команда hillclimb подбирает модель, effort и промпт по вашей оценке: на отложенных тестах точность выросла с 78,6% до 90,5% при цене примерно в пять раз ниже.

Почему кэш промптов промахивается и как это увидеть?

Перед генерацией ответа модель прогоняет весь промпт в рабочее состояние, и этот этап, prefill, и есть дорогая часть обработки входа. Кэш промптов сохраняет это состояние (KV-кэш), и если следующий запрос начинается с того же префикса, модель читает его из кэша вместо пересчёта. Чтение из кэша тарифицируется в разы дешевле полной цены входных токенов: у Fable 5.1 это $0,25 за миллион против $10 за обычный вход.

Три условия, при которых кэш вообще работает: он привязан к конкретной модели, префикс должен совпадать байт в байт, и у него ограниченный срок жизни. Отсюда типичные промахи, которые Anthropic перечисляет по опыту клиентов: динамический таймстамп или идентификатор в системном промпте, описания инструментов, которые меняют порядок между вызовами, и смена уровня усилия посреди диалога, потому что effort рендерится в промпт перед вашим контентом и входит в кэшируемый префикс. Исключение сделано только для части моделей, включая Opus 5 и Fable 5.1: у них effort можно менять без сброса кэша. Отдельная ловушка у субагентов и веток диалога: они делят кэш родителя только при байт-идентичном префиксе, той же модели и том же effort.

Что с этим делать, по списку Anthropic. Смотреть долю попаданий в кэш в Claude Console и через API диагностики кэша: он показывает причину промаха и место, где два запроса разошлись. Редко используемые инструменты объявлять с defer_loading: они не входят в кэшируемый префикс и подгружаются в диалог только когда модель находит их через поиск инструментов. На моделях, которые это поддерживают, обновления системного промпта добавлять как сообщения посреди диалога, а не правкой самого системного промпта. Раскладывать запрос так, чтобы стабильная часть оставалась стабильной: сначала описания инструментов и системный промпт, потом растущий диалог.

Ещё несколько приёмов из той же статьи. Модель или effort менять в тот момент, когда кэш всё равно сброшен, например при компактификации диалога. Двигать точку кэширования по мере роста диалога: автоматическое кэширование ставит её на последний кэшируемый блок. Прогревать кэш заранее: запрос с max_tokens: 0 и явной точкой кэширования на том же effort, что и боевой трафик, обрабатывает промпт и записывает его в кэш, ничего не генерируя. Если отправить его, пока пользователь ещё печатает, первый настоящий запрос попадёт в тёплый кэш. И не выходить за срок жизни кэша: пятиминутный TTL считается с начала запроса, и если агент ждёт инструмент или субагента дольше пяти минут, кэш родителя истекает до возврата результата. На такие случаи есть часовой TTL на префикс.

Какие инструкции вредят новым моделям?

Промпты со временем обрастают правилами, которые латали слабости старых моделей, и после обновления модели эти правила начинают мешать. Anthropic перечисляет шесть антипаттернов. Ритуалы проверки: «перепроверь свою работу», «проверь дважды перед ответом» новые модели выполняют буквально и тратят токены впустую. Усилители вроде «будь максимально тщательным» и «КРИТИЧНО: ТЫ ДОЛЖЕН ВСЕГДА…» дают многословие и лишние вызовы инструментов. Обязательные процедуры и шаблоны рассуждений («думай по шагам в scratchpad») накладываются на встроенное мышление модели и жгут токены. Устаревшие примеры few-shot, подобранные под ошибки старой модели, учат новую имитировать длинные цепочки рассуждений там, где они не нужны. Противоречивые правила («всегда возвращай деньги по политике» против «никогда не возвращай без эскалации») новые модели соблюдают буквальнее, и качество падает. И устаревшая конфигурация: настройки под прошлое поколение, например ручные бюджеты на размышления, платформа с новыми моделями может отвергнуть.

Команда /claude-api prompt-audit ищет всё это в рабочей директории: в коде приложения, который вызывает Claude API, и в конфигурации самого Claude Code, включая CLAUDE.md и скиллы. Для проверки Anthropic взяла бенчмарк службы поддержки и переезд с Opus 4.8 на Opus 5: в чистый промпт по одному подсаживали антипаттерн (снятая настройка thinking, пара противоречивых правил о возвратах, ручной scratchpad, «проверь дважды», «будь максимально тщательным» и обязательная процедура из шести шагов), получили шесть «легаси» промптов и прогнали каждый на Opus 4.8, на Opus 5 с заменой только идентификатора модели и на Opus 5 после одного прогона prompt-audit.

В среднем аудит снизил стоимость на 14,6% и поднял точность на 5,3 пункта. Цена упала за счёт лишних вызовов инструментов и дублирующихся рассуждений: на Opus 5 «проверь дважды» превращалось в повторный поиск заказа при каждом возврате, а «будь максимально тщательным» в десятки ненужных обращений к базе знаний. Точность выросла по трём причинам. Снятая настройка thinking заставляла API отвергать каждый запрос на маршрутизацию. Из-за противоречивых правил Opus 5 придержал четыре возврата, которые был должен, и просил клиента подтвердить. А ручной scratchpad конфликтовал со встроенным мышлением Opus 5: в трёх тикетах модель написала вызов инструмента внутри рассуждений и не выполнила его.

Когда высокий effort не окупается?

Effort задаёт, насколько усердно модель работает: на low она быстрее приходит к выводу, на high дольше рассуждает, проверяет и перебирает альтернативы. Кривая цена-качество у одной и той же модели бывает очень разной. У Fable 5 на FrontierCode Diamond (50 самых сложных задач) low даёт 11,5% за $5,35 на задачу, max даёт 30,9% за $19,00: результат вырос примерно в 2,7 раза за примерно 3,5 раза по цене. А у Fable 5.1 на Humanity's Last Exam без инструментов кривая крутая, но с плоским последним шагом: около 53% на low за примерно $0,30 на вопрос и около 61% на max за $2,23, при этом шаг с xhigh до max добавляет около половины балла за 46% цены сверху. Этот прирост укладывается в разброс между прогонами бенчмарка, то есть переплата идёт ни за что.

Ошибиться можно в обе стороны. Считать, что выше всегда лучше: на high модель может передумывать дольше, чем требует задача, это добавляет цену и задержку и может ухудшить ответ, потому что рассуждение помогает только пока есть что искать. И зажимать effort до low: тогда модель останавливается раньше, чем собрала достаточно улик, делает меньше вызовов инструментов, отвечает по первому результату поиска вместо третьего и пропускает проверку, которую сделала бы сама. Ответ выглядит законченным, но построен на неполной информации.

Совет Anthropic звучит так: пробовать более сильную модель на низком усилии, потому что она может выйти дешевле слабой на высоком. На CursorBench 3.2 Fable 5.1 на low повторяет результат Fable 5 на high за треть цены. Дешевле по двум причинам: на low модель делает меньше работы на задачу, а чтение из кэша у Fable 5.1 стоит $0,25 за миллион токенов против $1,00 у Fable 5. Даже по ценам Fable 5 Fable 5.1 на low обошлась бы примерно на 40% дешевле. Второй совет: понять форму своей задачи, прогнав оценку по всем уровням усилия. Если на ненасыщенном бенчмарке кривая плоская, задача не упирается в вычисления на размышления, и поднимать effort бессмысленно.

Что делают команды hillclimb и cost-optimize?

/claude-api hillclimb автоматизирует этот перебор. Команда делит вашу оценку на обучающую и тестовую части, предлагает изменения конфигурации и читает проваленные примеры из обучающей части, чтобы починить найденное. На том же саппорт-бенчмарке старт был с Opus 4.8 на дефолтном high. Первым шагом hillclimb попробовал Opus 5 на low с prompt-audit, который убрал обязательные ритуалы вызова инструментов, шаги scratchpad и противоречивые правила: это превысило базовый уровень Opus 4.8 с 98,9% точности на обучающей части и снизило цену до 2,6 цента за тикет. Затем он спустился до Sonnet 5 на low: ещё дешевле, 1 цент за тикет, но точность упала до 88,9%. Прочитав проваленные тикеты, Claude добавил в промпт правила маршрутизации и сверку с лимитом на возврат, и Sonnet 5 вернулась к 98,9% при той же цене.

На 14 отложенных тикетах, которых поиск не видел, итоговая конфигурация набрала 90,5% против 78,6% у исходной, при цене примерно в пять раз ниже. Разрыв между 98,9% на обучающей части и 90,5% на тестовой стоит держать в уме: на отложенных примерах прирост заметно меньше.

/claude-api cost-optimize нужна для полного аудита расходов кода, который ходит в Claude API. Сначала она выясняет, куда уходят токены: из отчётов об использовании и затратах организации, если есть ключ Claude Admin API, из объекта usage в каждом ответе API, если приложение его логирует, а если нет ни того, ни другого, читает код сборки запросов и оценивает. Затем ранжирует доступную экономию: кэш промптов, урезание того, что несёт каждый запрос (включая prompt-audit), ограничение вывода и отправка неинтерактивной работы через Batch API. Если дать ей оценку качества, она ещё и считает цену и результат по уровням усилия и моделям.

Anthropic прогнала её на четырёх открытых бенчмарках с Sonnet 5 как базой. На LegalBench команда предложила кэшировать общий префикс между задачами, поставить low и гнать задачи через Batch API: токены на размышления упали со 102 779 до 8 284, доля решённых осталась в пределах шума, цена снизилась примерно на 58%. На tau2-bench retail кэш с явной расстановкой точек кэширования дал минус 72% при той же доле решённых. На OfficeQA Pro пакетная обработка и кэширование документов снизили цену со $136,20 до $64,87. На SWE-bench Verified cost-optimize обнаружила, что кэш в дефолтной конфигурации уже настроен правильно, и экономию дали medium вместо high и ограничение вывода агента несколькими короткими фразами: медиана шагов на задачу упала с 29 до 17, входные токены с 75,2 млн до 33,7 млн, минус 55% по цене. По графику на SWE-bench результат при этом просел на 3,3 пункта при интервале от минус 9,6 до плюс 3,1, то есть значимого изменения не установлено, но интервал допускает и ухудшение, и на своих задачах это стоит перепроверить.

С чего начать?

Порядок, который предлагает сама Anthropic. Если вы переехали на новую модель Claude и хотите проверить старые промпты, запускайте /claude-api prompt-audit: она сканирует промпты, скиллы и описания инструментов в рабочей директории, будь то код приложения или конфигурация Claude Code. Если приложение ходит в Claude API и нужен аудит расходов, берите /claude-api cost-optimize: она профилирует расход токенов и проверяет рычаги по очереди, а с оценкой качества ещё и меряет компромиссы по effort и выбору модели. Если есть оценка и нужен поиск по цене и качеству, /claude-api hillclimb разобьёт её на обучающую и тестовую части, предложит изменения и оценит финальную конфигурацию на отложенных примерах.

Скилл claude-api встроен в Claude Code, отдельно он лежит на GitHub. Подробности по каждому рычагу собраны в документации и в кукбуке по снижению затрат. Все цифры в статье получены в прогонах Anthropic, в том числе на четырёх открытых бенчмарках; сторонних проверок в публикации нет. О том, на что способна Fable 5.1 в агентных сценариях, мы писали на примере агентов, собравших копию Юнион-сквер, а про открытый чертёж торгового агента на Claude есть отдельный разбор.

Источники: Claude Blog: Reducing cost and improving performance with Claude Platform, Анонс @ClaudeDevs в X, Документация: Optimizing for cost and intelligence, Скилл claude-api на GitHub, Cookbook: Cost optimization

Изображение на обложке: Anthropic, заставка статьи «Reducing cost and improving performance with Claude Platform»

Всё это принято называть обвязкой, и определение у неё простое.

Обвязка — это весь код между тем, что вы печатаете, тем, что получает модель, тем, что модель выдаёт, и тем, что вы видите. И это много кода, не имеющего отношения к ИИ. Модели при этом выглядят в значительной степени взаимозаменяемыми.

Разбираем три слоя обвязки, на которых результат меняется заметнее, чем от смены модели: маршрутизация вычислений, страховка надёжности в конвейере и контроль границ информации.

Обвязка — это код без единой нейросети внутри: сборка запроса, управление контекстом, проверки на выходе и координация нескольких моделей.

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

Анализ сгенерированного кода не показывает, как он поведёт себя при отказе зависимости, поэтому проверки надёжности строятся на воспроизведении реальных отказов, а не на чтении текста.

Пять источников почти всех сбоев одни и те же: процессор, память, диск, ввод-вывод и сеть. С них и начинают автоматические проверки.

Модели с постоянной памятью раскрывают лишние данные в неподходящем контексте, причём доля нарушений растёт с числом задач, а просьба быть осторожнее проблему не решает.

Слой первый: что и где считать

Первое, что делает обвязка, — решает, какой моделью обрабатывать конкретную задачу. Шнайер прямо советует руководителям по безопасности смотреть мимо брендов моделей и разбираться с окружающим их программным слоем: он управляет промптами, выводом, контекстом, ограничениями и координацией нескольких моделей одновременно.

Отдельная функция этого слоя — маршрутизация между дорогими внешними моделями и дешёвыми локальными. По мере того как компактные системы приближаются по качеству к передовым, всё больше задач имеет смысл считать локально: это быстрее, дешевле, приватнее и оставляет контроль на своей стороне.

Из того же наблюдения следует острый вывод, который Шнайер делает применительно к безопасности: раз возможности моделей широко доступны и во многом взаимозаменяемы, экспортные ограничения и закрытие доступа их не сдержат. Реальные риски он видит в другом: в концентрации корпоративной власти, в слабой целостности моделей и в плохо устроенных стимулах. Для инженера это переводится в практическое требование — проверять заявления поставщика и не полагаться на то, что выбор конкретного вендора сам по себе что-то гарантирует.

Слой второй: страховка надёжности в конвейере

Оговорка сразу: это уже не обвязка вокруг обращения к модели, а обвязка процесса поставки. Принцип тот же, объект другой: проверяется не ответ модели, а код, который агент написал и который вот-вот уедет в продакшен.

Код теперь пишется быстрее, и это меняет характер рисков, а не только их количество. Опечаток в сгенерированном коде стало меньше, зато прибавилось незапланированных зависимостей, расползания конфигурации и изменений инфраструктуры, сделанных агентом без нужного контекста.

Аналогия с гонками здесь уместнее обычного: на малой скорости из заноса выходят легко, на большой одна ошибка стоит несопоставимо дороже. Отсюда идея автоматических проверок надёжности Колтона Эндруса: замкнутых циклов, которые безопасно создают настоящие условия отказа, проверяют устойчивость, предлагают исправление и перепроверяют его после внесения.

Почему чтения кода недостаточно

Ранняя идея инженерии хаоса состояла в том, что перебрать все сочетания отказов юнит-тестами и интеграционными тестами невозможно. Прогон реалистичного отказа против живого сервиса проверяет много вещей разом и потому эффективнее.

Для сгенерированного кода это верно вдвойне. Статический анализ доводит до определённой черты, но не отвечает на главный вопрос: что произойдёт, когда отвалится кеш или вырастет задержка у зависимости. Правильное поведение здесь описывается заранее (скажем, при недоступности кеша сервис обязан уйти в основную базу), и проверка сводится к тому, соблюдает ли кандидат уже существующую политику.

Пять ресурсов, с которых начинают

Львиная доля сбоев упирается в одни и те же пять вещей: процессор, память, диск, ввод-вывод и сеть. Программы работают на компьютерах, а у компьютеров набор ресурсов один и тот же. Отсюда и минимальный набор автоматических проверок:

• Избыточность по зонам и узлам: что происходит при отказе целой зоны, отдельного хоста или контейнера.
• Масштабирование по процессору: корректно ли настроено расширение при всплеске и сворачивается ли оно обратно после.
• Масштабирование по памяти: то же самое, включая корректную деградацию, если расшириться не удалось.
• Отказ зависимости: как ведёт себя приложение, когда до внешнего или внутреннего сервиса не достучаться.
• Задержка зависимости: сервис доступен, но отвечает медленно. Приложение деградирует аккуратно, уходит к запасному источнику или просто падает.

Ответы на эти вопросы у зрелой команды обычно уже записаны в виде политик. Проверки не изобретают новых требований, они лишь удостоверяют, что очередной кандидат на выкатку этим требованиям соответствует.

Результат проверки возвращается агенту

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

Дальше начинается самое интересное. Данные о том, какая проверка провалилась, что исправили и прошла ли она после этого, возвращаются в агентский рабочий процесс как контекст. Проверять всё равно нужно каждый раз, но новый код начинает проходить проверки чаще, чем проваливать. Тот же журнал полезен и при разборе инцидентов: понятно, какие режимы отказа уже проверялись, с какими результатами и что было исправлено.

Слой третий: границы информации

Третий слой обсуждают реже всего, а он становится критичным ровно в тот момент, когда система обзаводится постоянной памятью о пользователе.

Речь о контекстной целостности — принципе из теории приватности Хелен Ниссенбаум: какие сведения уместно раскрывать при выполнении конкретной задачи. Домашний адрес нужен для оформления доставки и совершенно неуместен при составлении рабочего письма коллеге. Человек проводит эту границу не задумываясь, у модели с сохранённой памятью её приходится обеспечивать отдельно.

Что показали измерения

Шнайер разбирает две работы на эту тему. Первая описывает бенчмарк CIMemories: синтетические профили пользователей больше чем со ста атрибутами каждый и набор задач, в которых один и тот же атрибут для одних задач необходим, а для других неуместен.

Результаты неутешительные. Передовые модели показывают до 69% нарушений на уровне отдельных атрибутов, то есть раскрывают их там, где раскрывать не следовало. Снижение доли нарушений при этом обычно достаётся ценой полезности: модель становится осторожнее и хуже решает задачу.

Ещё важнее динамика. Нарушения накапливаются и по числу задач, и по числу прогонов: при росте использования с одной задачи до сорока доля нарушений у GPT-5 поднимается с 0,1 до 9,6%, а при пятикратном исполнении одного и того же промпта достигает 25,1%. Последняя цифра особенно неприятна: она означает нестабильное поведение, когда на идентичный запрос модель раскрывает разные атрибуты.

Почему просьба быть осторожнее не помогает

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

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

Что действительно даёт эффект

Вторая работа как раз про это. Авторы сначала просят модель явно рассуждать о том, какие сведения уместны для текущей задачи, а затем закрепляют это обучением с подкреплением. На синтетическом наборе всего из 700 примеров с разнообразными контекстами и нормами раскрытия им удалось заметно сократить неуместное раскрытие, не потеряв в качестве решения задач, причём для моделей разных размеров и семейств.

Ценнее всего то, что улучшение переносится: обучение шло на синтетике, а результат подтвердился на устоявшемся бенчмарке с человеческой разметкой, оценивающем утечки в действиях и вызовах инструментов. Практический смысл для тех, кто строит систему поверх готовой модели, тот же, что и на двух предыдущих слоях: контроль границ реализуется в обвязке, а не выпрашивается у модели формулировками.

Что забрать с собой

Три слоя выглядят разнородно, но подчиняются одному правилу: свойство, которое вам нужно от системы, обеспечивается кодом вокруг модели, а не выбором модели. Маршрутизация даёт цену и приватность инфраструктуры: данные не покидают периметр. Автоматические проверки отказов дают устойчивость. Явный контроль границ информации даёт приватность самих данных пользователя, независимо от того, где физически стоит модель.

Проверить это на своём проекте несложно: посмотрите, сколько времени команда потратила за квартал на сравнение моделей и сколько на то, что находится между пользователем и моделью. Если первое число заметно больше, вы, скорее всего, оптимизируете не тот слой.

Материалы разбора: интервью Шнайера об обвязке и локальных моделях, проверки надёжности в конвейере с ИИ-кодом и обзор двух работ о контекстной целостности.

В эксперименте использовались Codex с GPT-5.6 Sol, Rust, 26 вариантов инструкций и 4 дополнительных набора правил. Вывод относится к этой постановке задачи, а не ко всем ИИ-моделям и методикам разработки.

Что проверял Дэн Лу

За основу взят его прежний тест с Zstd, форматом сжатия данных. Агент получает спецификацию и пишет декодер в контейнере без интернета. Контрольные тесты ему не показывают: они отдельно проверяют результат. Такой подход позволяет проверить решение на независимом наборе сценариев.

В новом сравнении для каждой комбинации инструкции и уровня вычислительных усилий модели, medium или xhigh, проведено 80 запусков. Основная метрика — доля запусков, прошедших 100% скрытых тестов. Вариант без специальных указаний оказался выше среднего; убедительного универсального победителя автор не выделяет.

Как тесты пропускали ошибки

При явном требовании использовать встроенные тесты Rust их число удваивалось на medium и увеличивалось на 25% на xhigh, но корректность не улучшалась. В отдельных тестах обработки четырёх битовых потоков встречались одинаковые входы: перестановка потоков оставалась незаметной. Фаззинг часто сводился к случайным байтам, которые проверяли преимущественно отказ на некорректном вводе.

Фаззинг — проверка программы на множестве автоматически сгенерированных входов. Если все они отбрасываются в начале, глубокая логика обработки может остаться нетронутой. В тестировании свойств задают правило для целого класса входов: например, после сжатия и распаковки должны восстановиться исходные данные. Библиотека Proptest также умеет уменьшать найденный сбойный пример, чтобы причину было проще разобрать.

Что это меняет для ревью

Практический вывод редакции: в ревью ИИ-кода стоит проверять, какую ошибку способен поймать каждый тест и откуда взят ожидаемый результат. Для декодера полезны разные корректные потоки и независимые эталонные ответы. Для бизнес-логики — проверка результата операции, повторного запроса и отказа зависимости, а не только наличия функции.

Результаты одного эксперимента не заменяют проверку на ваших задачах.

Мы решили протестировать каталог нейросетевых моделей immers.cloud, чтобы проверить, как работает в нём Qwen3.6-27B на прикладном сценарии от начала до конца. Сначала прогнали модель на задачах для разработчиков в чате, затем вызвали её через API и подключили к тестовому ИИ-агенту с локальными инструментами. По ходу теста сравнили публичный и частный эндпоинты, запустили сгенерированный код, зафиксировали время, расходы и ошибки.

immers.cloud — облачный провайдер вычислений для ИИ: аренда GPU-серверов и готовых инференс-эндпоинтов с посекундной оплатой. Сервис строит инфраструктуру на иммерсионном охлаждении оборудования и позиционирует его как способ держать тарифы ниже рынка — в нашем тесте час конфигурации на двух RTX 4090 стоил 171,77 ₽, а весь сквозной прогон обошёлся в 192,97 ₽. Сервис подходит тем, кому нужен доступ к открытым моделям вроде Qwen без закупки железа: для разовых запусков и прототипов — публичный API, для постоянной нагрузки и изоляции — частный эндпоинт.

Большая языковая модель в чате умеет объяснять код и генерировать скрипты, но сама по себе не читает локальные файлы, не обращается к внутренним сервисам и не выполняет действия. Для этого нужен ИИ-агент: программа, которая передаёт модели задачу, предоставляет набор инструментов, исполняет выбранную функцию и возвращает результат в контекст.

Прежде чем собирать такой цикл, мы проверили базовый слой: как одна и та же Qwen3.6-27B отвечает в публичном чате, работает через API и запускается в частном инстансе immers.cloud. Это позволяет не смешивать проблемы модели, интерфейса и инфраструктуры с ошибками собственного агентного кода.

Что именно мы проверяли

• интерфейс публичного чата Qwen3.6-27B, точное название модели и доступность настроек генерации;
• три задачи разной сложности: исправление факториала, анализ JSONL-логов и ревью скрипта переименования фотографий;
• публичный OpenAI-совместимый API через Python SDK;
• создание частного эндпоинта на двух RTX 4090 и прохождение всех этапов запуска;
• те же задачи на частной модели и работоспособность сгенерированного кода;
• ИИ-агента с двумя локальными инструментами: нативные вызовы через tool_calls, выполнение функций в Python и возврат результатов модели;
• запасной сценарий с JSON-диспетчером, а также обработку неверных аргументов, отсутствующих файлов и неизвестных инструментов;
• фактические расходы и прекращение тарификации после удаления частного инстанса.

Почему взяли Qwen3.6-27B

Для сравнения публичного и частного режима важно использовать одну и ту же модель. Иначе разница в качестве или скорости может быть связана с архитектурой и размером LLM, а не с вариантом размещения. Поэтому в обоих случаях мы выбрали Qwen3.6-27B в четырёхбитной AWQ-квантизации.

Проверяем публичный чат

Публичный чат открывается со страницы модели. В интерфейсе отображается название «Инференс Модели Qwen3.6-27B», поле промпта и кнопка отправки. Отдельных настроек температуры, длины ответа или переключателя thinking mode мы не увидели.

При этом модель выводила блок «Here's a thinking process» прямо внутри ответа. В JSON публичного API поле message.reasoning оставалось null: рассуждение приходило обычным текстом в message.content. Для будущего агента это важная деталь — такой блок нельзя автоматически считать отдельным структурированным каналом reasoning.

У использованного эндпоинта параметр reasoning_parser не был включён. Это заметнее в сценариях без агента, где текст рассуждения приходится разбирать вручную, тогда как агент справляется с таким ответом и без отдельного канала reasoning. Однако есть эндпоинты, где параметр доступен, например: Qwen/Qwen3.5-35B-A3B-GPTQ-Int4 и google/gemma-4-26B-A4B-it.

Три задачи для модели

Задачи подобраны так, чтобы последовательно проверить короткое рассуждение, генерацию исполняемого проекта и способность критиковать собственный код.

При анализе логов программа прочитала requests.jsonl, пропустила невалидную строку с предупреждением в stderr и вернула ожидаемую статистику:

{"total": 6, "errors": 2, "average_latency_ms": 168.3, "p95_latency_ms": 400}

Мы запускали решение на штатном Python 3.9.6 в macOS, хотя в промпте требовали Python 3.11. Использованных возможностей стандартной библиотеки хватило, и четыре теста завершились за 0,001 секунды. Это подтверждает работоспособность конкретного ответа, но не заменяет проверку на заявленной версии Python и собственных данных проекта.

Почему ревью модели всё равно нужно перепроверять

Самая показательная часть теста — ревью скрипта: там модель ошиблась увереннее всего, хотя с факториалом справилась гладко. Модель уверенно назвала итог «готовым к merge», хотя в коде сохранились технические дефекты:

• смещения ASCII-значений EXIF разрешались относительно среза ExifIFD, хотя формат TIFF хранит их относительно начала TIFF-блока;
• проверка повторного запуска не распознавала уже переименованные файлы и могла добавлять дату к имени ещё раз;
• тест коллизий не создавал настоящую коллизию двух источников;
• последовательное переименование не было транзакционным: прерывание процесса могло оставить каталог в частично изменённом состоянии.

Вывод для агентного сценария простой: LLM удобно использовать для анализа и подготовки патча, но выполнение потенциально разрушительных действий должно оставаться за контроллером. Нужны dry run, валидация схемы, тесты, журнал операций и отдельное подтверждение пользователя.

Подключаемся к публичному API

На странице Qwen3.6-27B доступны примеры для cURL, PowerShell и Python. Мы использовали Python-клиент OpenAI и поменяли только токен. Ключ передавали через переменную окружения, чтобы он не попадал в исходный файл и историю команд.

На macOS окружение и запуск выглядели так:

Запрос прошёл с openai 2.48.0. Первый запуск занял 6,5 секунды по time, повторный вывод полного JSON — 4,278 секунды. В ответе были указаны модель qwen3.6-27b, 26 входных и 197 выходных токенов. Thinking process снова находился в message.content, а поле reasoning было null.

Запускаем частный эндпоинт

Частный вариант нужен, когда команде важны выделенные ресурсы, предсказуемая конфигурация и собственный жизненный цикл инстанса. Для чистого сравнения мы оставили ту же модель и выбрали конфигурацию rtx4090-2.16.64.160:

• 2 × RTX 4090 по 24 ГБ;
• 16 vCPU и 64 ГБ RAM;
• SSD на 160 ГБ;
• контекст 262 144 токена;
• один инстанс и посекундная оплата;
• 171,77 ₽ в час по странице модели и тарифу сервиса.

Запуск: около десяти минут до AVAILABLE

Запуск начался в 10:13. Сначала кабинет показал создание виртуальной машины, затем остальные стадии подготовки. В 10:23 эндпоинт перешёл в AVAILABLE, а рядом появилась ссылка на чат. Навигация в кабинете оказалась понятной: модель, контекст, конфигурация, статус и API-адрес собраны на одной странице.

На частной модели мы повторили те же задания. Факториал и анализ логов снова дали рабочий результат; четыре теста прошли без исправлений. Субъективно частный вариант отвечал почти так же, как публичный. Показатели TPS в интерфейсе также были близкими, но прямое сравнение времени сложных ответов некорректно: модель генерировала тексты разной длины.

Для более глубокой оценки производительности эндпоинта имеет смысл зайти на виртуальную машину по SSH и запустить нагрузочный прогон vLLM:

Первый запуск при этом включает прогрев модели и заметно увеличивает TTFT — это касается и публичных, и частных эндпоинтов.

Публичный и частный режимы: что показал тест

В наших запросах message.reasoning оставалось null. При создании частного эндпоинта параметр reasoning_parser не включался, поэтому этот результат нельзя трактовать как отсутствие поддержки отдельного структурированного канала reasoning. В протестированной конфигурации рассуждение возвращалось внутри message.content. Чтобы получить рассуждение в message.reasoning отдельно от основного ответа, нужно включить reasoning parser в настройках частного эндпоинта.

Частный инстанс в этом тесте не дал заметного выигрыша в качестве: обе конфигурации решили одинаковое число проверяемых задач. Его практическая ценность здесь — в выделенной конфигурации и контроле над размещением. Для прототипа и одиночных запросов публичного API достаточно; частный вариант имеет смысл оценивать под постоянную нагрузку, требования к изоляции и прогнозируемое число параллельных запросов.

Сколько стоил тест

Начальный баланс в нашем кабинете составлял 10 000 ₽. После неудачного запуска, успешного развёртывания, трёх задач на частной модели и удаления эндпоинта осталось 9 807,03 ₽. Фактический расход всего теста — 192,97 ₽.

После удаления список активных эндпоинтов опустел. Мы повторно проверили баланс спустя время — он не изменился. Значит, в нашем сценарии тарификация после удаления прекратилась. Это наблюдение относится к конкретному тесту; перед длительным запуском всё равно стоит сверить текущие правила биллинга и доступные действия Shelve, остановки и удаления.

От модели к ИИ-агенту

Проверенный API уже можно использовать как модельный слой приложения. Но один вызов chat.completions ещё не делает программу агентом. Для агентного цикла нужны четыре компонента:

• модель — Qwen3.6-27B через OpenAI-совместимый API;
• реестр инструментов — функции с понятными именами, аргументами и JSON-схемами;
• контроллер — код, который принимает запрос модели, проверяет аргументы, вызывает разрешённую функцию и возвращает результат;
• политика безопасности — лимиты итераций, dry run для изменений, журналирование и подтверждение опасных действий.

Выбираем полезный сценарий

Вместо демонстрационного агента, который только пересказывает промпт, возьмём разбор инцидента по requests.jsonl. Модель должна решить, какие данные запросить, а точные вычисления оставит локальным функциям.

Адаптер Qwen, который уже проверен

Начнём с небольшого слоя, который изолирует адрес immers.cloud и имя модели от остального кода агента. Этот вариант использует тот же способ подключения, который прошёл наш API-тест:

Как будет работать агентный цикл

1. Пользователь просит проанализировать requests.jsonl и предложить действия.
2. Контроллер передаёт Qwen историю диалога и описания доступных инструментов.
3. Если модель возвращает tool_calls, контроллер проверяет имя функции и аргументы по схеме.
4. Локальная функция выполняется без участия модели; её JSON-результат добавляется в messages с ролью tool.
5. Qwen получает факты и формирует итоговый разбор. Цикл завершается при обычном ответе или по лимиту итераций.

Тестируем полный агентный цикл

Во втором этапе мы подключили Qwen3.6-27B с публичного эндпоинта immers.cloud к агенту разбора инцидентов. Целью было не получить ещё один текст от модели, а проверить всю цепочку: структурированный вызов функции, валидацию аргументов, выполнение локального кода, возврат результата в контекст и безопасное завершение.

Агент работал с теми же тестовыми данными requests.jsonl. Модель не читала файл напрямую и не считала перцентиль сама. Она могла вызвать только три функции из реестра: calculate_log_metrics, lookup_runbook и prepare_incident_report.

Как устроен контроллер

Мы передали описания функций в параметре tools и включили tool_choice="auto". Если Qwen возвращала структурированный tool_calls, контроллер проверял имя функции по белому списку, разбирал аргументы, валидировал их по JSON Schema и только затем выполнял локальный код. Результат возвращался модели сообщением с ролью tool.

Это сокращённое ядро цикла. В тестовом скрипте вокруг него были жёсткий лимит в шесть итераций, полный журнал запросов и ответов, счётчики ошибок, отдельный fallback и перехват исключений локальных функций. Для проверки схем использовали пакет jsonschema.

Как воспроизвести запуск

Рядом с agent.py должен лежать файл requests.jsonl. Токен, как и в базовом API-тесте, передаётся через переменную окружения и не сохраняется в исходнике.

Первая версия прошла технически, но ошиблась по смыслу

В первом запуске нативный tool calling уже работал: API возвращал структурированные вызовы, имена функций и аргументы проходили схему, цикл дошёл до финального ответа. Но контракт calculate_log_metrics отдавал только агрегаты — число ошибок, среднюю задержку и p95. В нём не было фактических пар route + status для ошибочных записей.

Qwen заметила нехватку данных и прямо написала, что не знает, для каких маршрутов нужно искать runbook. Затем всё же начала подбирать варианты. Кроме реальных /api/orders + 500 и /api/orders + 503 она запросила несуществующие в логе пары /api/payments + 500 и /api/users + 500. Все вызовы были формально валидными, но два из них опирались на выдуманные факты.

Практический вывод. Успешный обмен tool_calls ещё не означает, что агент решает задачу правильно. Если результат одного инструмента должен стать аргументом следующего, контракт обязан возвращать все необходимые факты в машиночитаемом виде.

Добавляем error_records и запрещаем догадки

Мы расширили ответ calculate_log_metrics полем error_records и сгруппировали в нём только реальные ошибки из файла. Для тестового набора функция вернула:

В системной инструкции закрепили ещё одно правило: пары для lookup_runbook можно брать только из error_records. После этой правки модель перестала угадывать маршруты. Количество итераций и структурированных вызовов сократилось с шести до четырёх. Суммарное время ожидания ответов API в одном прогоне снизилось с 66,76 до 20,81 секунды. Это наблюдение одного запуска, а не бенчмарк производительности.

Что вернул нативный режим

Исправленный цикл завершился за четыре итерации. На первой Qwen вызвала calculate_log_metrics. На второй вернула сразу два lookup_runbook в одном ответе — для кодов 500 и 503. На третьей собрала черновик через prepare_incident_report с apply=false. На четвёртой вызовов инструментов уже не было: модель сформировала итоговый текст.

Метрики совпали с отдельным тестом утилиты: шесть корректных записей, две ошибки, средняя задержка 168,3 мс, p95 — 400 мс, одна пропущенная строка. В черновик вошли только реальные проблемы: /api/orders + 500 и /api/orders + 503 — вместе с соответствующими инструкциями runbook.

По телеметрии прогона API вернул четыре нативных вызова, текстовых псевдовызовов не было. Все четыре набора аргументов прошли схему; неизвестных инструментов, ошибок локальных функций, попыток apply=true и выхода на лимит итераций не возникло.

Проверяем запасной режим без tool_calls

Для fallback мы намеренно не передавали tools в API. Вместо этого системный промпт требовал вернуть обычным текстом один JSON-объект с действием tool_call или final. Контроллер извлекал последний валидный объект, проверял его по тому же реестру и вызывал ту же локальную функцию.

Запасной путь тоже завершил задачу: пять итераций, четыре извлечённые JSON-команды и тот же корректный отчёт. Однако Qwen не соблюдала требование «только JSON» буквально — перед объектом она печатала длинный thinking process. Парсер справился, но такой протокол зависит от разбора свободного текста и остаётся более хрупким. Сумма времени пяти ответов составила 62,72 секунды против 20,81 секунды в нативном прогоне. По одному запуску нельзя делать вывод о постоянной разнице скорости, но с точки зрения контракта tool_calls предпочтительнее.

Негативные проверки контроллера

Отдельный faultcheck не обращался к модели: мы напрямую передавали диспетчеру ошибочные вызовы и проверяли, выполнится ли что-нибудь опасное.

Даже если модель запросит apply=true, тестовый диспетчер принудительно заменит значение на false. Это защита на уровне кода, а не надежда на системный промпт. Для реального агента к ней нужно добавить права на уровне ОС или сервиса, таймауты, лимиты размера результата, идемпотентность и подтверждение пользователя перед необратимой операцией.

Что показал второй этап

Публичный эндпоинт Qwen3.6-27B в нашем тесте корректно работал с нативным tool calling через стандартный Python SDK: модель вернула структурированные вызовы, приняла результаты с ролью tool и завершила цикл обычным ответом. Значит, проверенный ранее API можно использовать не только для одиночного чата, но и как модельный слой агента.

При этом надёжность появилась не из-за одной модели. Её обеспечили реестр разрешённых функций, JSON-схемы, достаточный контракт результата, ограничение числа итераций, обработка исключений и dry run. Самая важная находка теста — error_records: небольшое изменение данных между инструментами устранило правдоподобные догадки, сократило цепочку и сделало результат проверяемым.

Граница эксперимента: мы провели функциональный прогон на небольшом локальном файле и одном публичном эндпоинте. Это не нагрузочный тест, не проверка SLA и не доказательство одинакового поведения на любых промптах. Реальную запись отчёта тоже не включали: весь сценарий завершился в режиме dry run.

Для прототипа этого достаточно, чтобы двигаться дальше: подключать реальные runbook и источники наблюдаемости, добавлять трассировку и пользовательское подтверждение действий. Для production остаётся главное правило агентной разработки: модель планирует, а контроллер проверяет и исполняет.

Итог

immers.cloud отработал предсказуемо на всех трёх уровнях — публичном чате, публичном API и агентном цикле с tool_calls: везде задача решилась без обходных путей. Узким местом оказалась не модель, а код вокруг неё: проверка аргументов, полный контракт результата инструментов и dry run по умолчанию определили, можно ли доверять результату.

Совместимость с OpenAI SDK здесь помогла конкретно: код, прошедший базовый API-тест, перешёл в агента без единой правки. Для прототипа этого достаточно как отправной точки — дальше стоит добавить трассировку вызовов и подтверждение опасных действий человеком, то, что в проде отличает контролируемый цикл от рабочего образца.

Источники и страницы продукта

• Страница Qwen3.6-27B в каталоге immers.cloud
• Руководство immers.cloud по каталогу и эндпоинтам
• FAQ immers.cloud
• Тарифы и конфигурации RTX 4090
• О компании и заявленные особенности иммерсионного охлаждения

Реклама. Рекламодатель: ООО «ДТЛ» ИНН 9717073792, erid: 2W5zFHSiVzq

Это главная особенность работы с отсутствующими значениями: ошибок нет, есть тихо неправильные числа. Разбираем, откуда они берутся в фильтрах, в арифметике, в агрегатах и в соединениях, и какими операторами это лечится.

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

В SQL три логических исхода, а не два: истина, ложь и неизвестность. Условие отбора оставляет только строки с истиной, поэтому неизвестность отбрасывается наравне с ложью.

Сравнение = NULL не почти верно, а отвечает на другой вопрос. Для проверки на отсутствие есть отдельные операторы, которые сравнением не являются.

Одно значение NULL в списке для NOT IN обнуляет всю выдачу целиком, а не сужает её.

Соединение по равенству отбрасывает строки, где ключ отсутствует с обеих сторон, и то же самое делает проверка уникальности.

Запрос, который отработал, прошёл только проверку грамматики. Число становится верным, когда с вопросом совпали строки, фильтры и знаменатель.

Три логических исхода вместо двух

Начнём с простого случая. В таблице клиентов у одного из них не заполнен телефон, и это прямо видно глазами. Запрос находит ноль строк:

Условие phone = NULL спрашивает: «равно ли это неизвестное значение тому неизвестному значению?» Ответить на такое нельзя, поэтому для каждой строки возвращается неизвестность, включая ту самую строку с пустым телефоном. А отбор оставляет только строки, где условие истинно. Неизвестность не проходит ровно так же, как не прошла бы ложь.

Правило действует единообразно: NULL = NULL тоже не истина, а неизвестность. Отсюда и главный вывод — оператор равенства нельзя «подправить», чтобы он здесь заработал. Он не почти прав, он отвечает на другой вопрос.

В Postgres это проверяется одной строкой. Что вернёт такое выражение?

Оба внутренних сравнения неизвестны, поэтому внешнее сравнивает неизвестность с неизвестностью и тоже даёт неизвестность. Операторы сравнения возвращают NULL, если хотя бы одна сторона неизвестна. Именно поэтому в языке есть отдельный оператор проверки на отсутствие: узнать, равны ли две неизвестности, нельзя, а узнать, является ли значение неизвестным, можно.

Как ведут себя И, ИЛИ и НЕ

Логические связки тоже работают в трёх значениях, и запомнить стоит два исключения:

То есть ИЛИ всё ещё истинно, если истинна вторая сторона, а И всё ещё ложно, если ложна вторая сторона. Всё остальное с участием неизвестности схлопывается в неизвестность.

Последствия неочевидны. Вот запрос, который отбрасывает строку, которую вы почти наверняка хотели оставить:

В обычной двузначной логике «активно или не активно» — тавтология, утверждение, истинное при любом значении. В SQL это не так.

Операторы, которые никогда не возвращают неизвестность

Лечится это выходом из трёхзначной логики. Сначала решите, что NULL означает в вашей предметной области, а потом скажите это явно:

Проверки IS TRUE, IS NOT TRUE, IS FALSE, IS NOT FALSE и IS UNKNOWN никогда не возвращают неизвестность, поэтому строку не потеряют.

Аналог того же для равенства — IS NOT DISTINCT FROM. Обычное равенство спрашивает, известно ли, что значения совпадают. Этот оператор спрашивает, одно ли это значение, обращаясь с отсутствием как с полноценным состоянием. Две неизвестности неразличимы, поэтому предикат истинен.

Где это пригодится:
Соединение по условию равенства отбрасывает строки, где ключ отсутствует с обеих сторон. Если два отсутствующих ключа должны считаться совпадением, замените равенство на IS NOT DISTINCT FROM. То же касается проверок уникальности и условий отбора, где «отсутствует» должно означать «отсутствует», а не «неизвестно».

Ловушка NOT IN, из-за которой пропадает вся выдача

Это самый дорогой из всех эффектов, потому что он не сужает результат, а стирает его целиком. Операторы IN и NOT IN разворачиваются в цепочки сравнений, а NOT IN — в цепочку через И:

Разберём оба исхода. Если значение совпало с одним из перечисленных, срабатывает то самое правило «И спасает ложь справа», и выражение честно ложно. Если не совпало ни с одним, множитель со сравнением с пустым значением делает всё выражение неизвестным.

Для условия отбора разницы между этими исходами нет: оно оставляет только истину, а ложь и неизвестность отбрасывает одинаково. Поэтому итог один — если в списке или в подзапросе есть хотя бы одно отсутствующее значение, NOT IN не вернёт ни одной строки. Никакой ошибки при этом не будет.

Обычный IN ведёт себя мягче, поскольку разворачивается в цепочку через ИЛИ: совпадение остаётся истиной независимо от того, что ещё есть в списке. В простом условии отбора пустое значение в списке вообще ничего не меняет: несовпавшая строка отсеется что при неизвестности, что при лжи. Разница вылезает там, где результат сравнения используется дальше: под отрицанием, в выражении CASE или в ограничении целостности.

Надёжная замена — NOT EXISTS, который работает через равенство внутри условия отбора и потому никогда не трактует сравнение с отсутствующим значением как совпадение. Тот же смысл выражает антисоединение, которое вдобавок часто даёт лучший план:

Вычистить отсутствующие значения из подзапроса тоже можно, но это помогает, только если вы уверены, что их следует игнорировать. Вариант с NOT EXISTS делает это намерение явным, а не подразумеваемым.

Арифметика: одно значение NULL обнуляет строку

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

В отчётах это выглядит как пустые ячейки, а в обновлениях данных как стёртые колонки. Классический пример, который каждый когда-нибудь писал:

Подставлять значение по умолчанию нужно в той точке, где вам известно правило предметной области, а не механически везде. В разборе Кристофера Уинслетта из Crunchy Data приводится удачная иллюстрация: отсутствующее количество почти всегда означает ноль, отсутствующая ставка налога тоже, а вот отсутствующая цена нулём не является и должна оставаться неизвестной, пока её кто-нибудь не заполнит.

Агрегаты и оконные функции считают не то, что кажется

Здесь отсутствующие значения ведут себя иначе, чем везде: агрегаты их пропускают. Функция COUNT(*) считает строки, а COUNT(колонка) — только непустые значения; SUM, AVG, MIN и MAX пропускают пустые входы.

У товара с двумя незаполненными оценками среднее и сумма пусты, а число строк равно двум. Отсюда практическое правило, которое экономит часы разбирательств с аналитикой: среднее — это сумма, делённая на количество непустых значений, а не на количество строк. Смешивать SUM(x) / COUNT(*) и ожидать совпадения со средним нельзя.

Оговорка про типы тоже важна: если сумма и счётчик целочисленные, деление усечёт дробную часть. Шесть, делённое на два, случайно даст ровно три, а оценки 5, 1 и 2 дадут при целочисленном делении двойку вместо 2,67.

Где ломаются оконные функции

Суммирование и усреднение в окне пропускают отсутствующие значения так же, как при группировке, а ROW_NUMBER считает строку в любом случае. Расхождение начинается у функций, которые смотрят в конкретную позицию окна: LAG, LEAD, FIRST_VALUE, LAST_VALUE и NTH_VALUE.

Такая функция возвращает то, что лежит в запрошенной позиции. Если там пусто, результат пуст. Ближайшее реальное значение она не ищет, и на рядах измерений с пропущенным отсчётом это даёт разрывы там, где ожидалась непрерывность.

Проверка чужого запроса, включая сгенерированный

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

Со сгенерированными запросами есть отдельная сложность: они беглые. Псевдонимы аккуратные, форматирование чистое, форма выглядит как работа внимательного человека. Беглость читается как правильность, хотя это разные вещи.

Проверка первая: посчитайте строки до того, как поверите сумме

Задача звучала как «чистая выручка по завершённым заказам». Полученный запрос:

Он отрабатывает и возвращает 1830. Правильный ответ 1330, и это легко проверить руками: валовая сумма одиннадцати завершённых заказов равна 1605, возвраты составляют 275.

Виновато соединение. Два заказа возвращались частями, по две записи на каждый, поэтому одиннадцать строк превращаются в тринадцать, а сумма по заказам считает эти два заказа дважды: 2105 вместо 1605. Лишние 500 — это ровно стоимость задвоенных заказов. Явление называется размножением строк: соединение множит строки всякий раз, когда ключ на другой стороне встречается больше одного раза.

Проверка стоит двух запросов:

Одно это сравнение всё решает. Второе число выросло, значит, соединение размножило строки, и любая сумма или среднее по колонкам левой таблицы под подозрением. Число совпало — соединение безопасно, идём дальше.

Проверка вторая: ищите отсутствующие значения в каждом фильтре

Следующая просьба звучала как «та же выручка, но без служебных аккаунтов», и запрос получился такой:

Он возвращает пустоту, полученную из нуля строк. Не меньшее число, а вообще ничего. Механизм вы уже знаете: в справочнике служебных аккаунтов есть одна строка с незаполненным идентификатором, а справочники в реальной жизни такими и бывают. Одна такая строка бесшумно опустошает результат целиком.

Что забрать с собой

Правила про отсутствующие значения не сложны, они просто действуют не там, где их ждут. Из фильтра строка пропадает молча, арифметика превращает результат в пустоту, соединение по равенству теряет пары без ключа, а среднее делит на другой знаменатель. Ошибки при этом нигде не возникает, и потому такие дефекты живут в отчётах годами.

Самый надёжный способ не разбираться со всем этим каждый раз — не хранить отсутствующие значения там, где они не нужны. Если колонка обязана иметь значение, скажите это в схеме. Ограничение NOT NULL выглядит формальностью ровно до первого расследования, почему выручка в отчёте оказалась на пятьсот единиц больше настоящей.

Материалы разбора: почему сравнение с NULL никогда не срабатывает, поведение NULL в вычислениях Postgres и проверка сгенерированного SQL до того, как поверить числу.

Откройте последний отчёт, который вы отдавали наружу, и сравните в нём количество строк до и после соединений. Проверка занимает пять минут и иногда меняет цифру, на которую уже сослались в переписке.

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

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

Генерация делится на две фазы с разной природой: разбор запроса грузит вычисления и хорошо распараллеливается, а генерация ответа последовательна и упирается в число шагов.

Главный потребитель памяти видеокарты — это кеш ключей и значений: для типовой конфигурации выходит около 128 КБ на каждый токен, и именно он ограничивает число одновременных запросов.

Один запрос пользователя к агенту превращается в десять, двадцать и больше обращений к модели, поэтому нагрузка получается неравномерной по памяти и по длительности.

Непрерывное пакетирование не даёт коротким запросам ждать длинных, а кеширование общего префикса убирает повторную обработку одного и того же системного промпта.

Расход токенов не является метрикой продуктивности: у неё тот же изъян, что у подсчёта строк кода, потому что она вознаграждает объём, а не результат.

Две фазы инференса, которые дорожают по-разному

Обслуживающая система делает две вещи: координирует запросы на стороне процессора и исполняет модель на ускорителе. Само исполнение распадается на две фазы, и путать их не стоит, потому что дорожают они от разных причин.

Разбор запроса (в англоязычной документации prefill). Модель обрабатывает все токены входного промпта. Их можно считать параллельно, поэтому фаза упирается в вычислительную мощность. Длинный промпт с историей диалога, найденными документами и описаниями инструментов увеличивает задержку до первого символа ответа.

Генерация (decode). Модель выдаёт по одному токену за раз, и каждый следующий зависит от предыдущих, поэтому распараллелить эту фазу нельзя. Длинный ответ означает много отдельных шагов исполнения модели.

Отсюда три коротких правила: длинные входы удорожают разбор, длинные ответы удорожают генерацию, а рост числа одновременных запросов давит одновременно на планирование и на память.

KV-кеш: где на самом деле кончается память

Внутри трансформера механизм внимания строит для каждого обработанного токена представления ключей и значений. Чтобы не пересчитывать их заново на каждом шаге генерации, модель хранит их в памяти. Это и есть кеш ключей и значений, без которого авторегрессивная генерация была бы непрактичной.

Платить за него приходится памятью видеокарты, и объём считается напрямую:

Для модели с 32 слоями, 8 KV-головами, размерностью головы 128 и половинной точностью получается примерно 128 КБ на один токен. У других моделей цифра будет своя, но зависимость одна: чем длиннее контекст, тем больше памяти занято. Именно поэтому длинные промпты, долгие диалоги и подтянутые из поиска документы делают инференс заметно дороже, а свободный объём этого кеша прямо определяет, сколько запросов сервер потянет одновременно.

Почему агентская нагрузка тяжелее обычной

Агент усиливает все перечисленные проблемы, потому что один запрос пользователя порождает множество обращений к модели: спланировать следующее действие, выбрать инструмент, разобрать его результат, свернуть найденное, восстановиться после ошибки, решить, нужна ли ещё работа, и наконец собрать ответ.

Одно взаимодействие легко превращается в десять или двадцать вызовов, а при сотне активных пользователей счёт идёт на тысячи. Вдобавок запросы неравноценны: в одном короткий вопрос, в другом длинный системный промпт с историей, документами и результатами инструментов. Получается динамическая нагрузка, где запросы приходят в разное время, занимают разный объём памяти и завершаются вразнобой.

Четыре механизма, которые возвращают пропускную способность

Именно на такую нагрузку рассчитаны специализированные движки обслуживания вроде vLLM. Вместо загрузки модели прямо в приложение и вызова метода генерации приложение обращается к серверу по HTTP, и логика агента отделяется от инфраструктуры под ней.

Страничное внимание, оно же PagedAttention

В наивной системе кеш каждой последовательности занимает один непрерывный участок памяти. Поскольку длины непредсказуемы, участки резервируются с запасом, и память утекает во фрагментацию. Страничная организация хранит кеш блоками фиксированного размера, которые выделяются по мере надобности и не обязаны лежать рядом. Завершился запрос — его блоки вернулись в общий пул и достались другому.

Непрерывное пакетирование

Обычное пакетирование работает раундами: сервер собирает группу запросов и держит её состав неизменным, пока цикл не отработает. Для генерации текста это плохо, потому что запросы заканчиваются в разное время.

Представьте: запросу A нужно сто токенов ответа, запросу B двадцать, а запрос C приходит, пока A ещё считается. При фиксированном пакетировании B освободится рано, но его место будет простаивать, а C дождётся конца всего цикла. Непрерывное пакетирование добавляет C в ближайший же шаг генерации, как только освободилось место. Ускоритель остаётся занят полезной работой.

Кеширование общего префикса

Агенты раз за разом отправляют один и тот же системный промпт, те же описания инструментов и ту же преамбулу рабочего процесса. Без кеширования этот префикс обрабатывается заново при каждом запросе:

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

Что здесь на самом деле новое:
Обычное кеширование ключей и значений есть в любой современной реализации авторегрессивной генерации, это не отличительная черта конкретного движка. Преимущество специализированных серверов в другом: в том, как они планируют запросы и как выделяют, переиспользуют и освобождают память кеша между конкурирующими нагрузками.

Совместимый интерфейс

Четвёртый пункт скучный, но на практике решающий: сервер выставляет интерфейс, совместимый с OpenAI. Существующие приложения и агентские фреймворки переключаются на него правкой конфигурации, а не переписыванием кода.

Когда всё это действительно нужно

Специализированный сервер инференса оправдан, когда вы держите модели с открытыми весами у себя и обслуживаете конкурентную нагрузку. Для одиночного прототипа на одного пользователя он избыточен: там хватит локального запуска модели, и вся описанная механика памяти просто не проявится.

Переломный момент наступает, когда прототип начинает принимать параллельный трафик, а агент проводит большую часть времени в ожидании модели. Тогда дешевле улучшить слой обслуживания под ним, чем переписывать логику самого агента.

Вторая половина задачи: считать деньги до запуска

Инфраструктура решает вопрос скорости. Вопрос стоимости она не решает, а иногда и обостряет, потому что удобная система располагает к длинным контекстам.

Дальше речь пойдёт и о тех, кто ходит в модель по чужому тарифу. Своя инфраструктура переводит счёт из токенов в часы работы видеокарт, но сама задача остаётся той же: понять цену задачи до запуска, а не после. Разница только в единице, в которой её считают.

Реестр токенов вместо пробного запуска

Пакетные задачи ломаются неприятным образом: счётчик прыгает по завершении, а не до старта; повтор удваивает расход без всякой обратной связи; системные промпты, длинные ответы и служебная разметка тоже считаются. Крошечный офлайновый реестр превращает всё это в проверку до первого обращения к модели.

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

Проверим на задаче из 6000 сводок, где промпт занимает около 21 000 символов, а ответ ограничен 500. Выходит 5250 токенов на промпт плюс 125 на ответ, то есть 5375 на вызов, а на всю задачу 32 250 000 токенов при лимите в 30 000 000. Задача не помещается с запасом минус 7,5%, и узнать это удалось, не потратив ни одного токена.

Соседняя задача с промптом в 4000 символов, тем же ограничением ответа в 500 символов и 10 000 вызовов даёт 1125 токенов на вызов и 11 250 000 на всё, помещаясь с запасом в 62,5%. Живая пробная отправка ни того, ни другого не покажет: она расскажет о поведении конкретной ручки прямо сейчас, но не о сумме по всей пачке, и вдобавок сама потратит токены.

Почему расход токенов нельзя делать метрикой продуктивности

Тут стоит остановиться отдельно, потому что соблазн велик. Расход токенов удобно считается и потому легко попадает в отчёты, но как метрика продуктивности он повторяет ошибку подсчёта строк кода.

Возьмите двух разработчиков с одинаковой задачей и одним инструментом. Первый пишет размытые промпты, позволяет контексту разрастаться в длинной переписке и заставляет модель раз за разом восстанавливать одну и ту же вводную. Второй решает ту же задачу коротким настроенным сценарием. По расходу токенов первый выглядит продуктивнее, хотя на деле он просто шумнее.

Само по себе потребление токенов отвечает на вопрос, пользуется ли человек инструментом вообще. На раннем этапе внедрения этот сигнал полезен. Но он ничего не говорит о том, получилось ли в итоге что-то осмысленное, а «много ИИ» и «хорошо с ИИ» — разные вещи.

Стоимость на результат

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

Связь между расходом и результатом реальна, но не универсальна. Более способные модели действительно тратят больше токенов и на сложных задачах дают заметно лучший результат: расширенные рассуждения и многошаговые попытки стоят токенов и окупаются. При этом один и тот же расход при разных конфигурациях и стратегиях промптинга даёт совершенно разные результаты, а неудачная обвязка и небрежная работа с контекстом жгут токены без всякой отдачи.

Практический вывод: считайте отношение результата к затратам, а не сам объём. Для команды безопасности это стоимость одной подтверждённой находки, для продуктовой команды — доля задач, доведённых до готовой и проверенной функциональности.

Слишком жёсткая квота выталкивает работу за периметр

Обратная крайность встречается не реже. Когда организация выставляет квоты слишком консервативно, инженеры, которые видят реальную пользу от инструмента, упираются в искусственный потолок и начинают пользоваться личными аккаунтами и бесплатными тарифами.

Это рациональное поведение человека, которому нужно сдать работу. Но результат предсказуем: использование уходит из контролируемого контура, а вместе с ним пропадают наблюдаемость, возможность аудита и любая уверенность в том, что результат соответствует требованиям к качеству и безопасности. Осмысленная квота с измерением отдачи здесь работает лучше, чем экономная квота без измерений.

Что забрать с собой

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

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

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

Посчитайте свой самый крупный пакетный прогон по эвристике четырёх символов на токен и сравните с остатком лимита. Если не сходится, вы только что сэкономили ночь и деньги.

• Чётко поставленные задачи под надзором человека.
• 3,1 дня работы агентов на день человека показывают объём использования, а не ускорение исследований.
• Данные внутренние и предварительные; независимой проверки в отчёте нет.

Что измерила OpenAI

По данным OpenAI, к середине августа медианный по использованию агентов исследователь расходовал на инференс более $600 в день по API-ценам; у 10% самых активных пользователей показатель превышал $7000 в день. Инференс — выполнение запросов к модели. По всей исследовательской организации на восьмичасовой день человеческой работы приходилось 3,1 агентного рабочего дня.

Более половины успешных задач на 4–8 часов человеческой работы за последние шесть месяцев сопровождались хотя бы одним вмешательством человека. Люди выбирают приоритеты и решают, масштабировать, остановить или развернуть систему. Рост числа экспериментов коррелировал с распространением Codex, но одновременно выросли вычислительные ресурсы. Публикация не позволяет приписать изменение одному фактору.

Как интерпретировать заявление OpenAI

Разработчик Саймон Уиллисон обратил внимание на резкий рост расходов на агентов в конце июля. Он предположил, что тогда сотрудники получили внутренний доступ к модели, которую позднее выпустили как GPT-6 Astra. Ниже — перевод его гипотезы; сам график причину скачка не устанавливает.

Моя главная гипотеза: именно тогда сотрудники получили доступ к модели, позднее выпущенной как GPT-6 Astra.

Сравнивая отчёт OpenAI со своей практикой, проверьте главный показатель: сокращается ли путь от поставленной задачи до результата, который человек готов принять.

Сама GPT-6 Astra вышла 3 сентября ограниченному кругу организаций, подписчикам Plus, Pro, Business и Enterprise доступ обещали в ближайшие дни, цены и бенчмарки мы разбирали отдельно. Здесь разберём другое: что именно Провенчер советует выкинуть из skill-файлов, AGENTS.md и промптов, чем он это объясняет, где его слова подтверждаются документацией Codex и обновлённым skill-creator, а где это пока наблюдения одного инженера. Заодно посмотрим, как те же правила переносятся на Claude Code, где CLAUDE.md и skills устроены по тому же принципу, и тот же расчёт бюджета работает там точно так же.

• Имя и описание каждого skill попадают в контекст модели до выбора; в Codex этот список ограничен 2% окна контекста (или 8 000 знаками), в Claude Code бюджет 1% окна. При переборе описания обрезаются.
• Провенчер называет три исправления в обновлённом skill-creator: короткие описания, прогрессивное раскрытие (SKILL.md как маршрутизатор к references и scripts) и отказ от подробных «рецептов».
• Из AGENTS.md он советует убрать требование читать стопку доков перед каждой правкой и принуждение к тестам: Astra, по его словам, сама решает, что читать, и сама запускает тесты.
• Жёсткие формулировки «сначала спроси» Astra принимает всерьёз и может остановиться там, где вы были бы рады продолжению; определение «готово» надо задавать до старта задачи.
• По данным OpenAI, разрыв между Astra и GPT-5.6 Sol на агентных бенчмарках заметный: 57,7% против 37,3% на Terminal-Bench 4.0. Независимых замеров пока нет.
• Skills в репозитории читают и чужие агенты на других моделях, поэтому автор предлагает сначала решить, для кого пишете инструкции, и чистить выборочно.

Почему инструкции для агента устаревают вместе с моделью

Потому что большинство правил в AGENTS.md и skills написаны против конкретных ошибок конкретной модели, и новая модель этих ошибок может уже не делать. Провенчер формулирует это так: «What used to require a lot of handholding and scaffolding no longer does», то есть ручное ведение и строительные леса, которые были нужны год назад, теперь необязательны. Инструкции, по его классификации, живут в трёх местах: в skill-файлах, в AGENTS.md и в промптах конкретных задач, и пересматривать он предлагает все три.

Здесь стоит сразу отделить проверяемое от заявленного. Что Astra сильнее Sol в агентных задачах, утверждает сама OpenAI по собственным бенчмаркам: 57,7% против 37,3% на Terminal-Bench 4.0, 41,4% против 18,1% на AutomationBench, 72,6% против 65,7% на OSWorld 2.0. Сторонних замеров на момент публикации нет, и в истории с Gemini 3.8 Flash мы уже отмечали, что сравнения с конкурентами остаются словом вендора, пока нет независимых замеров. Что при этом старые инструкции мешают, это наблюдение Провенчера из практики команды Codex, и он сам оговаривается, что речь о накопленных за год привычках, а не о замерах. Но механизм, который он описывает для skills, проверяется по документации, и к нему перейдём.

Что не так со skills, когда их слишком много

Каждый установленный skill стоит контекста ещё до того, как модель его открыла: его имя и описание лежат в списке, по которому модель решает, что подключить. Чем длиннее описания и чем их больше, тем меньше от каждого остаётся в этом списке. Провенчер называет привычку скачивать в проект десятки skills ошибкой:

Many people default to downloading a lot of skills into their projects, but that's a mistake. Each skill comes with a name and description that are loaded into the model's context so it knows when to use them. Many descriptions are far too long, and when you add too many skills, Codex starts shortening their descriptions to fit.

Здесь начинается задокументированное поведение. Документация Codex говорит прямо: начальный список skills, куда входит и путь к файлу каждого skill, занимает не больше 2% окна контекста модели, или 8 000 знаков, если размер окна неизвестен; при переборе Codex сначала укорачивает описания, а при очень большом наборе часть skills вовсе выпадает из списка с предупреждением. В Claude Code механика та же, но бюджет жёстче: 1% окна контекста, а объединённый текст описания одного skill по умолчанию обрезается до 1 536 знаков, это значение настраивается. Обрезка идёт с тех skills, которые вы вызываете реже всего. Проверить, сколько контекста съедает список, в Claude Code можно командой /doctor, а строка Skills в /context показывает размер списка уже после применения бюджета.

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

Три правки, которые Провенчер перечисляет для skills, совпадают с принципами обновлённого skill-creator в репозитории Codex. Важная оговорка по датам: этот файл менялся 13 августа, за три недели до релиза Astra, и в статье сказано лишь «we recently updated its guidance», так что называть его «переписанным под Astra» нельзя. Сами правила такие:

1. Описание как можно короче, но так, чтобы было ясно, когда skill применять. В skill-creator этот принцип назван «Keep discovery cheap and precise»: описывать реальную возможность и условия применения, добавлять исключения только там, где они предотвращают ложное срабатывание, избегать исчерпывающих списков возможностей и «catchalls».
2. Прогрессивное раскрытие. Для skill с несколькими сценариями корневой SKILL.md должен быть минимальным маршрутизатором, который отправляет к вспомогательным документам и скриптам. В skill-creator это три стадии: имя и описание видны при выборе, тело SKILL.md загружается при применении, а references и scripts читаются только когда нужны конкретной задаче.
3. Меньше рецептов. Многие skills написаны как подробные маршруты по шагам. Модели, по словам автора, стали лучше понимать нюансы и неоднозначность, поэтому избыточная конкретика теперь вредит там, где раньше помогала. Принцип skill-creator «Match specificity to the risk» говорит то же: фиксированные последовательности и абсолютные формулировки оставлять для операций, где отклонение приведёт к конкретной проблеме.

Как это выглядит в структуре папки, skill-creator показывает на примере skill для развёртывания в облаке: общий выбор провайдера остаётся в корневом файле, а детали каждого провайдера лежат отдельно, и при выборе AWS модель читает только один из трёх файлов:

Последний аргумент Провенчера про skills касается командной работы. Skills, закоммиченные в репозиторий, читают агенты других участников, и они могут работать на других моделях: «Guidance that helps Sol or Luna may overconstrain GPT-6 Astra». Отсюда практический вывод: прежде чем вычищать инструкции, решите, для каких моделей они останутся. Если половина команды сидит на GPT-5.6 Sol или на моделях Claude, скаффолдинг ещё пригодится.

Что убрать из AGENTS.md в первую очередь

Первыми кандидатами на вылет Провенчер называет два правила: требование прочитать стопку документации или карту репозитория перед каждой правкой и требование запускать тесты. AGENTS.md действует при любой работе модели в репозитории, поэтому он предлагает пройтись по каждой строке и спросить, нужна ли она всё ещё задаче. Для исправления опечатки обязательный обзор всего проекта избыточен, а Astra, по его словам, сама понимает, что ей нужно прочитать.

Prompting the model to read files before every edit, is a great way to burn context and slow work down.

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

С тестами история симметричная. Прошлые модели надо было подталкивать проверять свою работу, и в AGENTS.md у многих осталось «всегда запускай тесты после изменений». Astra, утверждает Провенчер, делает это сама, и то же правило теперь приводит к лишним прогонам. Одновременно он оговаривается, что модель работает основательно, но осторожничает в том, как далеко довести задачу, и иногда её нужно подтолкнуть. Инструмент для этого тот же AGENTS.md, только формулировка меняется с запрета на разрешение для конкретного безопасного сценария. Пример из статьи, который можно взять как образец строки для своего файла:

Обратите внимание на конструкцию: в одной фразе сказано, почему действие безопасно (одноразовые фикстуры, нет доступа к проду), что именно разрешено (запускать, чинить падения от текущего изменения, перезапускать затронутые тесты) и от чего модель освобождается (спрашивать разрешение на каждом шаге). Граница описана через разрешение для конкретного сценария, и это совпадает с принципом skill-creator «Match specificity to the risk».

Как задать границы, чтобы модель не останавливалась на полпути

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

GPT-6 Astra has much better judgment, and you should treat it as such. It also takes your boundaries seriously and may stop work where you'd actually be happy for it to continue.

Со стороны это выглядит как смена одного типа ошибок на другой: раньше агент делал лишнее, теперь недоделывает. Провенчер описывает это без прикрас в разделе про настойчивость:

If you're used to GPT-5.6 Sol taking a request and continuing for long stretches, GPT-6 Astra can feel more tentative about when to stop. It may reach a first implementation and come back for your review while there's still work to do.

Лечение он предлагает на уровне промпта задачи. Если задача включает запуск реализации, проверку результата и исправление того, что упало, всё это надо перечислить в запросе как часть определения «готово». Требование «остановись на ревью после первой реализации» тянет модель к ранней остановке, и автор советует проверить, действительно ли это решение, которое вам нужно принимать вручную. Если хочется, чтобы модель исследовала дальше первого прохода, надо сказать, что исследовать и где остановиться. Это согласуется с тем, что OpenAI писала в анонсе: Astra задаёт вопрос, когда недостающая информация меняет результат, и заполняет пробелы сама в остальных случаях. Мы приводили это описание в новости о выходе модели, и оно тоже пока не подтверждено сторонними тестами.

Скепсис здесь уместен в обе стороны. Что Astra «осторожнее» Sol и «сама запускает тесты», мы знаем со слов инженера OpenAI, а не из воспроизводимого замера. Но и обратное утверждение, что старые инструкции безвредны, ничем не подтверждено: стоимость списка skills в контексте посчитана в документации обоих инструментов, и она не зависит от того, какая модель под капотом.

Как провести аудит своих инструкций по шагам

Ниже чек-лист, собранный из статьи Провенчера и принципов skill-creator. Он одинаково применим к Codex CLI (на 5 сентября 2026 актуальна версия 0.153.4, skills лежат в .agents/skills репозитория или в ~/.agents/skills пользователя) и к Claude Code (.claude/skills в проекте и ~/.claude/skills у пользователя, инструкции репозитория в CLAUDE.md).

1. Посчитайте, сколько стоит список skills. В Claude Code выполните /doctor: он оценит контекст, который занимает список, и назовёт самых тяжёлых. В Codex бюджет списка 2% окна, при переполнении описания укорачиваются и появляется предупреждение о выпавших skills.
2. Удалите skills, которыми не пользуетесь. В Codex skill можно выключить, не удаляя, через [[skills.config]] в ~/.codex/config.toml с enabled = false и path к его SKILL.md, после правки конфига Codex нужно перезапустить; в Claude Code низкоприоритетные skills можно оставить в списке без описания через skillOverrides со значением name-only.
3. Сократите каждое описание до одной задачи и одной границы. Образец из skill-creator: «Create or edit Word documents when formatting, tracked changes, or comments require document-specific handling». Ключевой сценарий ставьте в начало фразы: так советуют обе документации: Codex прямо говорит выносить вперёд ключевой сценарий и триггерные слова, Claude Code советует ставить ключевой сценарий первым из-за капа в 1 536 знаков.
4. Разнесите тяжёлые skills на маршрутизатор и references. Если в SKILL.md несколько сценариев, оставьте в нём общее назначение и критерии выбора, а детали каждого сценария вынесите в отдельный файл, на который есть ссылка с пояснением, когда его читать.
5. Пройдите AGENTS.md или CLAUDE.md построчно. Правила «прочитай X перед любой правкой» замените контекстными ссылками на конкретные документы. Правила «всегда запускай тесты» замените разрешением на конкретный безопасный сценарий по образцу выше.
6. Перепишите запреты в разрешения. Найдите формулировки «никогда не делай без подтверждения», добавленные из-за прошлых моделей, и решите, нужны ли они. Там, где нужны, опишите границу через причину и ограниченную область.
7. Определяйте «готово» в промпте задачи. Перечислите, что входит в завершение: запустить, проверить результат, починить упавшее. Если нужен ранний стоп для ревью, скажите это явно и убедитесь, что это осознанный выбор.
8. Проверьте skills после правки. В комплекте skill-creator есть валидатор: scripts/quick_validate.py <path/to/skill-folder> проверяет frontmatter, имена и незаполненные заготовки, но не качество решений, поэтому описания на дискриминирующую силу придётся проверять глазами.

Кому это не подходит. Если ваша команда или CI работают на GPT-5.6 Sol, Luna или моделях других вендоров, часть скаффолдинга всё ещё делает свою работу, и вычищать её из общего репозитория стоит только после проверки на этих моделях. Провенчер сам оставляет эту оговорку и предлагает думать о том, кто будет читать инструкции после вас. Сама статья заканчивается предложением попросить Astra провести такой аудит по её тезисам; это удобно, но результат аудита, сделанного моделью на собственных инструкциях, стоит просмотреть самостоятельно, прежде чем коммитить.

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

Источники: Eric Provencher. Rethinking skills and prompts for GPT-6 Astra (X, 4 сентября 2026), Профиль Эрика Провенчера в X, skill-creator/SKILL.md в репозитории openai/codex, PR #38384 «Refine skill creation guidance and validation», openai/codex, 13 августа 2026, Документация Codex: Build skills, Документация Claude Code: Extend Claude with skills, Tproger: OpenAI начала выпуск GPT-6 Astra, цены, бенчмарки и кибер-ограничения

Изображение на обложке: Иллюстрация: Eric Provencher, X

Для разработчика новость сводится к трём вещам. Во-первых, стандартная цена в API составляет $10 за миллион входных токенов и $50 за миллион выходных, это ценовой уровень флагманов, а не рабочих лошадок. Во-вторых, по заявлениям OpenAI модель заметно сильнее GPT-5.6 Sol в агентных задачах в терминале, в работе с интерфейсами и в написании кода. В-третьих, это модель с критическим уровнем кибервозможностей по внутренней шкале OpenAI, и это напрямую влияет на то, как модель ведёт себя в API: задачи, которые система безопасности сочтёт подозрительными, будут останавливаться.

• Доступ: ограниченный круг организаций сегодня, подписчики Plus, Pro, Business и Enterprise, API и Amazon Bedrock в ближайшие дни; Enterprise-администраторы включают модель вручную, по умолчанию она выключена.
• Цена в API: $10 за миллион входных и $50 за миллион выходных токенов в режиме Standard; Fast-режим до 2,5 раза быстрее за двойную цену; отдельные ставки на чтение и запись кеша.
• Бенчмарки OpenAI: Terminal-Bench 4.0 57,7% против 55,8% у Claude Fable 5.1 и 37,3% у GPT-5.6 Sol; FrontierMath Tier 4 97,6%; ARC-AGI-3 99,9%; ExploitBench 100%.
• Не везде первая: на Humanity's Last Exam и в индексе Artificial Analysis Astra уступает Claude Fable 5.1 и Opus 5.
• Кибербезопасность: критический уровень по Preparedness Framework, во время тестов модель нашла две неизвестные ранее уязвимости нулевого дня; в релизе она отказывается писать PoC-эксплойты.
• Codex получил экспериментальные заметки между окнами контекста вместо постоянного сжатия истории; через несколько недель это станет режимом по умолчанию для Astra.

Что OpenAI показывает на бенчмарках и где оговорки

Главная заявка OpenAI касается работы с компьютером и кода. На Terminal-Bench 4.0, где агент решает инженерные задачи в терминале, Astra набирает 57,7% (в тексте анонса 57,9%) против 37,3% у GPT-5.6 Sol и 55,8% у Claude Fable 5.1. По оценке OpenAI, задача при этом обходится примерно на 9% дешевле, чем у Sol, и на 63% дешевле, чем у Fable 5.1. В таблице анонса приведены и другие модели: Claude Fable 5 набирает 42,0%, Claude Opus 5 52,3%, Gemini 3.8 Flash 19,1%.

На Agents' Last Exam, наборе профессиональных задач в реальном ПО от финансового моделирования до медиапроизводства, Astra показывает 59,3% против 55,5% у Claude Opus 5 и 53,6% у GPT-5.6 Sol, расходуя при этом примерно на 65% меньше выходных токенов, чем Opus 5. На OSWorld 2.0, бенчмарке управления компьютером (офлайн-подмножество с частичной оценкой, версия от 8 августа), OpenAI приводит не только точность (72,6% против 65,7% у Sol), но и время: в симуляции задержек задача занимает около 40 минут вместо 75. Это симуляция, а не замер на живых задачах пользователей, и OpenAI прямо это оговаривает.

На AutomationBench и Terminal-Bench Science 0.1 отрыв особенно заметен: 41,4% против 31,4% у Fable 5.1 и 18,1% у Sol в первом случае, 64,6% против 52,6% и 22,4% во втором. По математике и абстрактному мышлению OpenAI заявляет 97,6% на FrontierMath Tier 4 (v2) и 99,9% на ARC-AGI-3, называя оба бенчмарка «насыщенными». На GPQA Diamond, тесте научного мышления уровня аспирантуры, результат 96,0%.

Есть и колонки, где Astra не первая, и OpenAI их не прячет. На Humanity's Last Exam с инструментами у Astra 57,2% против 65,0% у Claude Fable 5.1 и 63,6% у Opus 5. В индексе Artificial Analysis Intelligence Index v4.1.1 у Astra 61,2 балла против 65,7 у Fable 5.1 и 63,1 у Opus 5. На DeepSWE v1.1 разрыв в пределах одного процентного пункта: 74,1% у Astra против 73,8% у Gemini 3.8 Flash и 73,7% у Opus 5. Про Gemini 3.8 Flash и её результат на DeepSWE при цене $0,75 за миллион токенов мы писали утром того же дня.

Числа выше приводит сама OpenAI: часть результатов конкурентов взята из их публичных отчётов, результат Claude на офлайн-наборе OSWorld, по словам компании, воспроизведён независимой третьей стороной, а внутренние наборы (Internal Design Tasks, Internal Database Migration Tasks) проверить со стороны невозможно. Независимых замеров самой Astra на момент публикации нет.

Что меняется в Codex и как модель работает с контекстом

Вместе с Astra OpenAI обновляет и агентную оболочку Codex. Первое изменение касается скорости управления компьютером: по данным компании, связка Astra с новым харнессом завершает задачи на бенчмарке Mind2Web в 1,9 раза быстрее, чем текущая связка с GPT-5.6 Sol. Второе касается длинных сессий. Раньше при заполнении окна контекста Codex сжимал историю в одно резюме, и при каждом сжатии могли теряться детали: почему не сработал фикс, как ведёт себя компонент. Теперь Astra в Codex может вести заметки поверх окон контекста, а старые окна остаются доступными для поиска, так что модель может найти требование или результат теста из прошлых сообщений, даже если не записала его в заметки. Функция экспериментальная, включается в конфигурации Codex (config.toml) и в ближайшие недели станет режимом по умолчанию для Astra.

Третье изменение поведенческое. OpenAI утверждает, что Astra лучше предыдущих моделей понимает, когда недостающая информация меняет результат, и в таких случаях задаёт вопрос, а в остальных заполняет пробелы сама. В Codex вопрос задаётся асинхронно: модель продолжает часть работы, которая от ответа не зависит. Если пользователь не отвечает, модель идёт дальше с разумными допущениями, но ждёт ответа перед решениями с серьёзными последствиями. Ещё OpenAI отдельно отмечает, что Astra лучше держит исходную задачу, когда пользователь по ходу меняет требования: прежние модели иногда принимали уточнение за новую цель и теряли начальные ограничения.

В API, помимо стандартного режима, есть Fast-режим: до 2,5 раза быстрее обычной обработки за двойную цену. На чтение и запись кеша действуют отдельные ставки. Для подходящих клиентов API поддерживается Zero Data Retention. Пользователи Pro, Business и Enterprise дополнительно получат GPT-6 Astra Pro; использование Astra входит в текущие лимиты подписок, а сверх них можно докупать кредиты.

Почему кибербезопасность стала ограничением, а не только достижением

В обновлении по безопасности 1 сентября OpenAI предупредила, что Astra достигнет критического уровня кибервозможностей по Preparedness Framework, внутренней шкале рисков компании, и что доступ к самым продвинутым кибервозможностям будет ограничен. Анонс это подтверждает: без продакшн-ограничений Astra набирает 100% на ExploitBench, бенчмарке превращения известных уязвимостей в рабочие эксплойты, против 78,5% у GPT-5.6 Sol, и 42,4% на ExploitGym против 30,3% у Sol.

Чтобы исключить эффект знакомых уязвимостей из обучающих данных, OpenAI собрала внутренний набор из уязвимостей за июнь–август 2026 года. На нём Astra показала 39,0% успешного выполнения произвольного кода против 5,5% у Sol, и по ходу теста нашла и использовала две ранее неизвестные уязвимости нулевого дня; компания говорит, что раскрывает обе их сопровождающим. На SRE-Bench, где нужно восстановить логику бинарника без исходного кода, Astra решает 88,0% задач с первой попытки и 99,2% за четыре, у Sol 55,9% и 68,7%. Экспертные оценки без ограничений показали, что модель способна добиваться выполнения произвольного кода в защищённых браузерах и писать эксплойты повышения привилегий для защищённых операционных систем.

Практическое следствие для пользователя API такое. Версия Astra, которая выходит сейчас, отказывается от продвинутых кибер-задач вроде написания proof-of-concept эксплойта, но подходит для безопасного код-ревью и патчинга. Менее строгие ограничения OpenAI обещает раздавать через программу Daybreak в ближайшие недели: для проверки уязвимостей и PoC, анализа вредоносного ПО и detection engineering. Кроме того, в продакшне для моделей класса Astra работает мониторинг несогласованного поведения: классификаторы проверяют рассуждения и действия модели и автоматически останавливают подозрительную активность. OpenAI признаёт, что эти проверки иногда тормозят, ставят на паузу или прерывают легитимную работу, включая защитную: в ChatGPT и Codex пользователя могут попросить проверить действие перед продолжением, а в API задача просто остановится.

Если вы строите на API пайплайн, который касается безопасности: сканеры, фаззинг, анализ дампов, разбор CVE, заложите в него обработку прерванных задач. OpenAI прямо говорит, что в API задача при срабатывании проверки останавливается, и что число ложных срабатываний компания ещё снижает.

Что OpenAI говорит о выравнивании и что признаёт проблемой

OpenAI называет Astra своей самой выровненной моделью и приводит несколько внутренних тестов. В оценке, построенной по мотивам инцидента с Hugging Face, модели без продакшн-ограничений дают сложную или невыполнимую задачу и смотрят, выйдет ли она за разрешённые рамки: GPT-5.6 Sol выходила за авторизованную цель в 48% случаев, Astra в 0%. В другом тесте Astra ни разу не пыталась обойти отказ Codex Auto-Review, даже когда проверку специально сделали обходимой, а задачу иначе выполнить было нельзя. В тесте на ложные заявления о собственных возможностях Astra ошибается в три раза реже Sol: 4,2% против 12,2% на внутреннем наборе.

Одну проблему компания признаёт открыто. В тестах, где модель прямо просили уклоняться от мониторинга, письменные рассуждения Astra оказалось труднее отслеживать, чем рассуждения Sol. OpenAI связывает это с тем, что Astra лучше управляет записанными рассуждениями на простых задачах и решает их за меньшее число записанных шагов; на сложных задачах модель, по словам компании, судя по всему, всё ещё с трудом скрывает нужные рассуждения. Улучшение мониторируемости названо исследовательским приоритетом, детали вынесены в системную карту модели.

Что делать разработчику сейчас

• Ждать появления модели в своём аккаунте: раскатка на Plus, Pro, Business и Enterprise идёт несколько дней, в API имя модели gpt-6-astra. В Enterprise-пространствах модель включает администратор.
• Пересчитать бюджет перед миграцией: $10 и $50 за миллион токенов дороже большинства рабочих моделей, а экономию на уровне задачи OpenAI показывает на отдельных конфигурациях бенчмарков; на своих задачах это нужно проверить.
• В Codex попробовать заметки между окнами контекста на длинных рефакторингах, пока функция экспериментальная, и посмотреть, что она сохраняет по сравнению с обычным сжатием.
• В пайплайнах, связанных с безопасностью, предусмотреть остановку задачи по решению системы мониторинга; расширенный кибер-доступ появится позже через Daybreak.
• Не принимать заявленные проценты за независимые: все цифры пока от OpenAI, часть бенчмарков внутренние. Первые сторонние замеры обычно появляются в течение недели после выхода модели.

Из российских условий ничего не меняется: OpenAI по-прежнему не продаёт подписки и API-доступ напрямую пользователям из России, так что путь остаётся прежним, через посредников и агрегаторы, где Astra появится с задержкой и наценкой. Amazon Bedrock тоже требует иностранного аккаунта AWS. Что касается конкурентов, сегодняшний день уже был насыщенным: утром Google выпустила Gemini 3.8 Flash, днём у Claude, ChatGPT и Grok случился массовый сбой, а вечером вышла Astra. На что теперь ответят Anthropic и Google, узнаем, судя по темпу этой осени, довольно быстро.

Источники: OpenAI: GPT-6 Astra, анонс, Тибо Соттьо (OpenAI) о начале раскатки, X, OpenAI: обновление по безопасности перед выпуском Astra, 1 сентября, Системная карта GPT-6 Astra

Изображение на обложке: Изображение: OpenAI

Для владельца MacBook это означает модель класса, который раньше требовал 128 ГБ памяти или сервера с несколькими GPU. Цена: скорость обработки промпта. По замерам автора, 8000 токенов контекста обрабатываются около 39 секунд, 32 000 около трёх минут, а полный контекст ограничен 32 768 токенами. Проект молодой (246 звёзд на GitHub на момент разведки), работает только на Apple Silicon с macOS 14 и требует около 110 ГБ свободного места на SSD.

• Модель: Qwen3.8-Flash-Next, 125 млрд параметров, 512 экспертов на слой, 10 активных на токен; веса 4 бита, 103,77–105,3 ГБ на диске.
• Память: постоянно загружено 3,8 ГБ, процесс на 48-гигабайтном Mac занимает около 33 ГБ; запуск движка около 2 секунд.
• Скорость на M5 Pro с 48 ГБ: около 12 токенов в секунду генерации; промпт 8000 токенов около 39 секунд, 32 000 около 3 минут; контекст до 32 768 токенов.
• Требования: Apple Silicon, macOS 14 и новее, около 110 ГБ на SSD; Linux, Windows и дискретные GPU не поддерживаются.
• API совместим с Ollama и OpenAI: работают curl, Open WebUI и OpenAI SDK; в slotstream 0.2.0 подключение Ollama CLI ещё не работало. Лицензия MIT.

Как 105 ГБ помещаются в 48

Qwen3.8-Flash-Next устроена как mixture of experts: в каждом слое 512 экспертов, но для одного токена активируются только 10. Значит, в каждый момент нужна малая часть весов. Эксперты занимают 67,9 ГБ, ещё 32 ГБ уходит на хранилище n-gram и PLE. slotstream держит фиксированный пул слотов в памяти и подгружает нужных экспертов с SSD системным вызовом pread, а не отображает всю модель через mmap. Постоянно в памяти живут только общие части модели, 3,8 ГБ.

Автор описывает, почему очевидные способы не сработали. Обычный загрузчик на 48-гигабайтном Mac уходил примерно в 48 ГБ подкачки и завершался до первого токена. Ленивый mmap тоже не спасал: после короткого промпта резидентная память приближалась к 100 ГБ, потому что система не знает, каких экспертов можно выгрузить. Фиксированный пул решает это ценой того, что каждый новый эксперт читается с SSD, отсюда и медленная обработка длинного промпта: диск становится узким местом.

Что это значит на практике

12 токенов в секунду на генерации это скорость, при которой ответом можно пользоваться в чате. Проблема в prefill: минута ожидания на промпт средней длины и три минуты на длинный документ делают инструмент непригодным для RAG по большим контекстам и для агентов, которые постоянно перечитывают историю. Зато для разовых задач с коротким контекстом, где важно качество большой модели, а не отклик, это рабочий вариант на ноутбуке. Автор прямо пишет, что инструмент рассчитан только на Apple Silicon «и не случайно» (перевод редакции): расчёт на объединённую память и скорость встроенного SSD.

Как попробовать

1. Проверить требования: Apple Silicon, macOS 14 или новее, около 110 ГБ свободного места, желательно 48 ГБ памяти (на меньших объёмах автор замеров не приводит).
2. Собрать или скачать slotstream по инструкции в README; веса модели скачиваются отдельно, это около 105 ГБ.
3. Подключить любой клиент, понимающий API Ollama или OpenAI: Open WebUI, OpenAI SDK с локальным base_url или curl. в slotstream 0.2.0 Ollama CLI на момент публикации не подключался.
4. Сверить свои цифры с таблицами в MEASUREMENTS.md: там разложены память, ввод-вывод и время по этапам.

Кому это не подойдёт: владельцам Mac с 16–24 ГБ (замеров для них нет), пользователям Linux и Windows и всем, кому нужен быстрый prefill. Региональных ограничений у проекта нет, веса модели скачиваются из открытых источников. Что можно запустить дома на более скромном железе, мы собирали в обзоре открытых моделей августа; о том, во что обходится обработка длинного контекста у облачных моделей, есть разбор цен API за август.

Источники: Репозиторий slotstream, MEASUREMENTS.md: замеры памяти и скорости

Для разработчика это готовый способ прогнать свой репозиторий через тот же процесс, которым Google проверяет свои: нужен любой кодинг-агент со слэш-командами и изолированная среда, где не жалко ничего сломать. Сам Mantis не сканер и не сервис: это набор скиллов, скриптов и референсных компонентов под лицензией Apache-2.0, а модель и агент вы приносите свои.

• Mantis лежит на GitHub с июня 2026 года; 2 сентября Google выпустила гайд по запуску и представила скилл mantis-advise для безопасного написания нового кода.
• Конвейер состоит из 16 последовательных стадий плюс вспомогательные скиллы: от разбора истории коммитов и модели угроз до воспроизведения, патча и отчёта.
• Установка: git clone репозитория или npx skills add google/mantis; агент подойдёт любой, Google проверяла с Gemini CLI, Antigravity CLI и ADK.
• Воспроизведение и патчи выполняются только в песочнице без сети (gVisor с --network=none, microsandbox, VM); флаги вроде --yolo авторы прямо запрещают.
• Каждую находку должен подтвердить человек: README запрещает массово слать непроверенные ИИ-отчёты мейнтейнерам.

Что именно выложила Google и что в этом нового

Репозиторий google/mantis открыт не сегодня: первые коммиты датированы июнем 2026 года, и в заметке Google ссылается на июньское описание подхода. Новость в другом: компания впервые опубликовала пошаговый гайд «как начать», прямо заявила, что тот же промпт используется внутри Google для поиска реальных уязвимостей, и представила скилл mantis-advise, который появился в репозитории 28 августа. Последний коммит на момент публикации, от 3 сентября, ужесточает песочницы, разрешение путей и проверки конфигурации.

Главная претензия Google к «наивному» ИИ-сканированию кода, по словам авторов, в том, что доля настоящих находок у него часто ниже 7%, остальное галлюцинации. Mantis борется с этим двумя способами: отдельными агентами-критиками, которые отсеивают ложные срабатывания, и воспроизведением уязвимости в песочнице, которое служит опорой для оценки. При этом README оговаривает: неудачное автоматическое воспроизведение ещё не доказывает, что находка ложная. Цифра про 7% в заметке дана без ссылки на метод замера, так что это оценка компании, а не бенчмарк.

Вторая идея, на которую Google делает упор, это контекст. Mantis читает историю репозитория, чтобы выучить прошлые исправления безопасности, и сам строит документацию по архитектуре и модель угроз, даже если в проекте их нет. Файлы сворачиваются в иерархию сводок по каталогам, и по заявлению авторов такое дерево снижает накладные расходы на токены больше чем на 85% на больших репозиториях. Это тоже внутренний замер Google без описания выборки.

Как устроен конвейер из 16 стадий

По описанию архитектуры, Mantis состоит из отдельных скиллов, каждый из которых вызывается слэш-командой и передаёт результат следующему через файлы в каталоге workspace/. Стадии можно запускать по одной руками или отдать оркестратору /mantis-meta-agent, который крутит цикл и архивирует находки между проходами.

1. /mantis-history и /mantis-summarize разбирают историю VCS и пишут сводки по каталогам, а необязательный /mantis-structural-index строит индекс семантических единиц кода.
2. /mantis-architecture и /mantis-threat-model собирают базу знаний о сущностях, потоках данных и границах доверия.
3. /mantis-plan и /mantis-researcher составляют план проверки и ищут уязвимости файл за файлом.
4. /mantis-dedupe, /mantis-review и /mantis-critic склеивают дубли, отсеивают ложные срабатывания и проверяют, что падение воспроизводится в релизной сборке.
5. /mantis-reproduce пишет и запускает эксплойт в изолированной среде, /mantis-chain пробует собрать из находок многошаговую цепочку.
6. /mantis-patch чинит код и гоняет тесты в песочнице, /mantis-calibrate ставит риск от 1 до 10, /mantis-reflect и /mantis-report собирают уроки и итоговый отчёт.

Новый /mantis-advise стоит особняком: он не ищет уязвимости, а отвечает на вопрос «как безопасно менять этот файл». Скилл читает накопленную базу knowledge.db с моделью угроз, историей находок, подтверждёнными патчами и отсеянными ложными срабатываниями и выдаёт агенту рекомендации до и во время правок. Запускается он скриптом python3 reference/scripts/advise.py --file src/auth.py. Смысл в том, чтобы результаты аудита не лежали в отчёте, а мешали агенту повторять старые ошибки.

Как запустить у себя и почему только в изоляции

Установка по README сводится к клонированию репозитория или одной команде для менеджера скиллов:

Дальше Google предлагает открыть привычный кодинг-агент и написать ему буквально: «I would like to use Mantis framework in path/to/mantis to review my code in path/to/your/code, can you help me get started?». Конкретный агент не навязывается: в README сказано, что скиллы проверяли с Gemini CLI, Antigravity CLI, Google ADK и Antigravity SDK, но подойти должен любой фреймворк, понимающий слэш-команды и файлы SKILL.md. Модели тоже на выбор пользователя, причём авторы советуют не гонять самую дорогую модель на каждой стадии, а подбирать класс модели под задачу.

Самая жёсткая часть документации про изоляцию. README открывается предупреждением капслоком: конвейер генерирует и исполняет код, который может быть нестабильным, поэтому запускать его можно только в ограниченной среде, без доступа к продакшену, чувствительным данным и внутренней сети. Скиллы /mantis-reproduce и /mantis-patch по инструкции выполняют полезную нагрузку в контейнере с отключённой сетью, и для этого Google рекомендует gVisor:

Скилл /mantis-configure даёт выбор из четырёх режимов песочницы: static-only без исполнения кода, microsandbox, gvisor и gce с отдельной виртуальной машиной в облаке. Отдельно авторы просят начинать в интерактивном режиме, вызывая команды по одной и подтверждая каждое опасное действие, и не включать флаги автоодобрения вроде --yolo или --dangerously-skip-permissions. Гарантий при этом нет: в документации прямо сказано, что агент недетерминирован и может попытаться обойти ограничения, если среда это позволяет.

Что Mantis не обещает

Mantis не является поддерживаемым продуктом Google и подаётся как отправная точка, которую нужно дорабатывать под свой стек: авторы советуют скармливать конвейеру внутренние стандарты кода, документацию и критерии, какие баги вас не интересуют. Пример из заметки: если вы никогда не чините падения, которые пользователь может вызвать только у себя, об этом нужно сказать сканеру заранее, иначе он будет тратить время именно на них.

Второе ограничение этическое и практическое одновременно. README требует, чтобы каждую находку перед отправкой проверил специалист по безопасности, и запрещает массово слать непроверенные ИИ-отчёты мейнтейнерам открытых проектов. Неудачное воспроизведение при этом не доказывает, что бага нет, а успешный репродьюсер не доказывает, что уязвимость эксплуатируема в любом окружении.

Проект лежит в публичном репозитории на GitHub под Apache-2.0, региональная доступность отдельно нигде не оговорена, а модель и агент вы выбираете сами, в том числе локальные. Дальше стоит следить за тем, появятся ли независимые замеры доли ложных срабатываний: пока и 7%, и 85% экономии токенов остаются цифрами самой Google.

Источники: Getting started with Mantis, our open-source bug finding-and-fixing harness (Google Cloud Blog), Репозиторий google/mantis, README_AGENTS.md: архитектура конвейера Mantis, Скилл mantis-advise

Изображение на обложке: Изображение: Google Cloud

Я разбираю WebLLM как рабочий инструмент: что нужно от железа и браузера, сколько весят модели, какой скоростью придётся заплатить за отказ от сервера и где проще остаться на облачном API. Все команды и фрагменты кода взяты из README репозитория, цифры производительности из статьи авторов на arXiv, требования к видеопамяти из файла конфигурации в исходниках.

Материал для фронтенд- и фулстек-разработчиков, которым нужен чат, классификатор или JSON-извлекатель на клиенте без счёта за токены и без передачи пользовательских данных третьей стороне.

• WebLLM выполняет модель в браузере на WebGPU, без сервера; API совместим с OpenAI Chat Completions: стриминг, JSON-режим, seed. Вызов функций помечен в README как незавершённый.
• Актуальная версия пакета @mlc-ai/web-llm — 0.2.84 от 27 мая 2026 года; в 2025–2026 годах вышло всего 7 релизов против 63 за 2024 год по данным реестра npm.
• По замерам авторов на MacBook Pro M3 Max WebLLM выдаёт 41,1 токена/с на Llama-3.1-8B и 71,1 токена/с на Phi-3.5-mini, то есть 71–80% от нативного MLC-LLM на том же железе.
• Модели в 4-битной квантизации требуют от 0,7 ГБ видеопамяти (gemma3-1b) до 6,4 ГБ (Qwen3.5-9B) по значениям vram_required_MB в src/config.ts; первый запуск качает всё это с huggingface.co.
• WebGPU по данным MDN есть в Chrome и Edge с версии 113, в Safari 26 с сентября 2025 года, в Firefox с 141 только частично: Linux и Intel-маки не поддерживаются.

Как WebLLM выполняет модель в браузере и при чём тут WebGPU?

Модель считается на видеокарте пользователя через WebGPU, а всё, что не ложится на GPU, крутится в WebAssembly. Авторы описывают схему так: родственный проект MLC LLM компилирует открытую модель заранее в два артефакта, конвертированные веса и WASM-библиотеку с WebGPU-ядрами и вспомогательными функциями. WebLLM в браузере загружает оба артефакта с хостинга, инициализирует WebGPU-устройство и дальше исполняет граф вычислений локально.

Everything runs inside the browser with no server support and is accelerated with WebGPU.

Отсюда же и главное ограничение, о котором в статье авторы говорят прямо: в отличие от CUDA у WebGPU нет готовых ускоренных библиотек для типовых ядер, поэтому матричные умножения и внимание команде пришлось писать и оптимизировать самой. Цена этого видна в замерах: на Apple MacBook Pro M3 Max в Chrome Canary 133 WebLLM версии 0.2.75 выдавал 41,1 токена/с на 4-битной Llama-3.1-8B против 57,7 у нативного MLC-LLM с Metal-ядрами на той же машине, и 71,1 против 89,3 токена/с на Phi-3.5-mini. Это 71,2% и 79,6% нативной скорости соответственно, замер вендора, другого железа в статье нет.

Второй компонент, о котором обычно забывают, это кэш. Веса и WASM-библиотека скачиваются при первом обращении и складываются в хранилище браузера. README перечисляет четыре бэкенда, которые задаются полем cacheBackend в AppConfig: Cache API по умолчанию, IndexedDB, Origin Private File System и экспериментальный cross-origin через расширение Chrome, чтобы одни и те же веса не качались заново для каждого сайта. Без расширения движок сам откатывается на Cache API.

JSON-режим, который в серверных API обычно реализован на стороне провайдера, здесь тоже выполняется локально: по README структурированная генерация встроена в WebAssembly-часть библиотеки модели, а попробовать её со своей JSON-схемой можно в JSON Playground на Hugging Face. Про то, как WASM-рантаймы догоняют нативный код, мы писали в заметке про Wasmi 2.0.

Что нужно, чтобы запустить первый чат?

Достаточно npm-пакета, одного вызова фабрики и терпения на первую загрузку весов. README даёт три варианта установки и импорт через CDN для JSFiddle и CodePen без сборщика.

Движок создаётся функцией CreateMLCEngine: это асинхронная фабрика: она возвращает Promise, а готовый движок с загруженной моделью получают через await. Колбэк прогресса обязателен на практике, потому что без него пользователь смотрит на пустой экран, пока качаются гигабайты.

loading models requires downloading and it can take a significant amount of time for the very first run without caching previously

Дальше интерфейс тот же, что у клиента OpenAI: engine.chat.completions.create({ messages }). Одна ловушка: параметр model в запросе игнорируется, модель выбирается при создании движка или через engine.reload(model). Стриминг включается флагом stream: true, а статистика по токенам приходит только в последнем чанке, если попросить её через stream_options.

Готовый чат для проверки железа не нужно собирать самому: WebLLM Chat сделан на том же пакете, а его код открыт в отдельном репозитории.

Какие модели доступны и сколько видеопамяти им нужно?

В список prebuiltAppConfig.model_list в src/config.ts на 3 сентября входят 165 записей: это варианты квантизации и длины контекста для семейств Llama 3.x, Qwen 2.5, Qwen 3 и Qwen 3.5, Phi 3.5 и Phi 4 mini, Gemma 2 и Gemma 3, Mistral и Ministral 3, дистилляты DeepSeek-R1, SmolLM2, OLMo 2, а также две модели эмбеддингов snowflake-arctic-embed. README при этом всё ещё перечисляет старый набор с Llama 2 и Qwen2, так что актуальный набор виден только в коде.

У каждой записи есть поле vram_required_MB, и это честнее любого «весит N гигабайт»: оно включает не только веса, но и память под KV-кэш при заданном контексте. Для 4-битных вариантов с половинной точностью (суффикс q4f16_1) разброс такой:

• gemma3-1b-it — 0,71 ГБ; Llama-3.2-1B-Instruct — 0,88 ГБ; Qwen2.5-0.5B-Instruct — 0,94 ГБ. Помечены флагом low_resource_required, это кандидаты для встроенной графики и ноутбуков.
• Qwen3-0.6B — 1,40 ГБ; gemma-2-2b-it — 1,90 ГБ; Llama-3.2-3B-Instruct — 2,26 ГБ.
• Qwen3-4B — 3,43 ГБ; Phi-3.5-mini-instruct — 3,67 ГБ; Llama-3.1-8B-Instruct — 5,00 ГБ; Qwen3-8B — 5,70 ГБ; Qwen3.5-9B — 6,43 ГБ.
• Есть и Llama-3.1-70B-Instruct в 3-битной квантизации с требованием 31,15 ГБ; на потребительской видеокарте это не запустится.

Варианты с суффиксом «-1k» урезают контекст до одной тысячи токенов и экономят память: у Llama-3.1-8B это 4,60 ГБ вместо 5,00, у Phi-3.5-mini 2,52 ГБ вместо 3,67. Все эти гигабайты приезжают с huggingface.co/mlc-ai, поэтому доступность и скорость этого хоста в вашей сети стоит проверить до того, как обещать пользователям «работает без сервера». Свою модель в формате MLC подключают через appConfig.model_list, указав URL весов и WASM-библиотеки. Какие небольшие открытые модели вышли в августе и на чём их запускать дома, мы собирали в обзоре открытых нейросетей.

Полный каталог собранных моделей лежит на mlc.ai/models. Номер совместимой сборки библиотек зашит в пакет: для 0.2.84 это константа modelVersion со значением «v0_2_84/base», так что после обновления npm-пакета кэшированные WASM-библиотеки могут потребовать перезагрузки.

Как не заморозить интерфейс: Web Worker или Service Worker?

Для обычного приложения хватает выделенного Web Worker, а Service Worker нужен, когда модель должна переживать переходы между страницами. Оба варианта в README оформлены одинаково: в потоке живёт обработчик, в основном скрипте создаётся движок-прокси с тем же интерфейсом MLCEngineInterface.

С Service Worker сложнее. Его жизненным циклом управляет браузер и может убить поток без предупреждения; движок шлёт heartbeat каждые 10 секунд по умолчанию (значение keepAliveMs в src/service_worker.ts), но авторы просят закладывать обработку ошибок и в приложении. README отдельно требует создавать ServiceWorkerMLCEngineHandler на верхнем уровне скрипта и запрещает делать это внутри обработчиков activate или message: браузер перезапускает уже активный воркер без повторного события activate.

Service Worker's life cycle is managed by the browser and can be killed any time without notifying the webapp. ServiceWorkerMLCEngine will try to keep the service worker thread alive by periodically sending heartbeat events, but your application should also include proper error handling.

Отдельная ветка применения — расширения Chrome: в репозитории есть примеры базового расширения и расширения на Service Worker с WebGPU, которое держит модель в фоне. По данным MDN, в Firefox WebGPU недоступен именно в контексте Service Worker, так что этот сценарий пока привязан к Chromium.

Где WebLLM выигрывает у серверного API, а где проигрывает?

Выигрывает там, где важны приватность промптов и нулевая стоимость токена, проигрывает там, где нельзя выбирать пользователю железо. Разложу по пунктам, отделяя проверяемое от обещаний.

• Деньги. Инференс идёт на GPU пользователя, счёт за токены равен нулю. Платите трафиком: каждый новый пользователь качает от 0,7 до 6,4 ГБ весов с Hugging Face; свой CDN нужен только тем, кто перехостит артефакты сам.
• Приватность. Промпты и ответы на сервер не уходят, это следует из архитектуры. Но сетевые запросы есть: веса и WASM скачиваются с huggingface.co и jsdelivr, поэтому формулировка «данные никогда не покидают устройство» некорректна, и в политике приватности так писать нельзя.
• Скорость. 71–80% от нативного инференса по замеру авторов на M3 Max. На ноутбуке с встроенной графикой цифр в статье нет, и обещать «десятки токенов в секунду» без своего замера нельзя.
• Первый запуск. Минуты загрузки против миллисекунд первого ответа у API. Кэш спасает повторные визиты, но не первый.
• Браузеры. По данным MDN, WebGPU есть в Chrome и Edge с версии 113 (полная поддержка на Linux только с 144 и только на Intel Gen12 и новее), в Safari 26 на macOS и iOS с 15 сентября 2025 года, в Firefox с 141 частично: есть Windows и Apple Silicon, нет Linux и Intel-маков. Проверка navigator.gpu обязательна.
• Управление моделью. Серверный API даёт одну версию модели для всех и мгновенную замену. В WebLLM версия модели живёт в кэше каждого браузера, а обновление пакета может потребовать перекачки библиотек.
• Функции. Вызов инструментов через tools и tool_choice в README помечен как WIP с предварительной поддержкой. Для агентских сценариев это стоп-фактор; про выбор стека для агентов у нас есть отдельный разбор.

Есть и организационный риск. По реестру npm пакет обновлялся 19 раз в 2023 году, 63 раза в 2024-м, 3 раза в 2025-м и 4 раза с начала 2026 года; последний релиз 0.2.84 вышел 27 мая. Код в репозитории при этом продолжает меняться, последний push был 3 сентября. Для продакшена это означает, что свежие модели из config.ts могут ждать релиза месяцами.

Evaluations show that WebLLM can retain up to 80% native performance on the same device with room to close the gap further.

Что делать по шагам, чтобы собрать чат на WebLLM за вечер

План ниже покрывает путь от проверки железа до защиты артефактов; команды и имена функций взяты из README для версии 0.2.84.

1. Проверьте, что в браузере есть navigator.gpu, и покажите понятную заглушку тем, у кого его нет. По MDN это Chrome и Edge 113+, Safari 26+, Firefox 141+ с оговорками по ОС.
2. Установите пакет: npm install @mlc-ai/web-llm (версия 0.2.84). Для прототипа без сборки подойдёт импорт с https://esm.run/@mlc-ai/web-llm.
3. Выберите модель из prebuiltAppConfig.model_list по полю vram_required_MB. Для широкой аудитории начните с моделей с флагом low_resource_required: Llama-3.2-1B, Qwen2.5-0.5B, gemma3-1b.
4. Создайте движок через CreateMLCEngine с initProgressCallback и выведите прогресс загрузки на экран.
5. Перенесите инференс в Web Worker через CreateWebWorkerMLCEngine, чтобы интерфейс не замирал во время генерации.
6. Включите стриминг флагом stream: true; для извлечения структурированных данных используйте JSON-режим из раздела Full OpenAI Compatibility.
7. Если артефакты лежат на своём хостинге, добавьте в запись модели поле integrity с SRI-хэшами для конфига, WASM и токенизатора; хэш генерируется командой openssl из README.

При несовпадении хэша движок бросает IntegrityError, либо пишет предупреждение и продолжает работу, если задать onFailure: "warn". Без поля integrity проверка не выполняется вовсе, как и в прежних версиях.

Что дальше: чего нет в WebLLM и за чем следить

Первое, за чем стоит следить, это релиз после 0.2.84: в src/config.ts уже есть Qwen3.5 и Ministral 3, и вопрос в том, когда они попадут в опубликованный пакет. Второе — статус вызова функций, который держится в README как WIP. Третье — cross-origin хранилище: сейчас это расширение Chrome и экспериментальный API, а без него каждый сайт качает свою копию весов.

Мы не проверяли скорость на встроенной графике и на Windows-ноутбуках; единственные опубликованные цифры относятся к MacBook Pro M3 Max. Доступность huggingface.co и esm.run из конкретной сети мы тоже не измеряли: перед запуском продукта на WebLLM стоит замерить время первой загрузки у своей аудитории или перехостить артефакты.

Источники: GitHub: mlc-ai/web-llm (README, лицензия Apache-2.0), src/config.ts: prebuiltAppConfig.model_list с vram_required_MB, src/service_worker.ts: keepAliveMs и heartbeat, arXiv 2412.15803: WebLLM: A High-Performance In-Browser LLM Inference Engine, Блог MLC: WebLLM, 13 июня 2024, Документация WebLLM, Реестр npm: @mlc-ai/web-llm (версии и даты), Hacker News: обсуждение WebLLM 2 сентября 2026, MDN: WebGPU API, совместимость браузеров, Hugging Face: модели mlc-ai, WebLLM JSON Playground, WebLLM Chat, Каталог моделей MLC, GitHub: mlc-ai/mlc-llm

Изображение на обложке: Скриншот: chat.webllm.ai

Для команд на TeamCity это означает, что пайплайны можно переводить из экспериментов в основные сборки, а тем, кто подключает к CI агентов вроде Junie или Claude Code, при подключении через OAuth больше не нужно выпускать персональный токен вручную: MCP-сервер TeamCity получил авторизацию OAuth с PKCE. Об этом сообщил в блоге JetBrains Дмитрий Коровин. Одновременно вышли исправления для двух предыдущих мажорных версий On-Premises: 2025.11.8 и 2026.1.4.

• Pipelines введены как EAP в TeamCity 2025.07; в 2026.2 они общедоступны в Cloud и On-Premises.
• В пайплайнах появились выбор ветки в режиме редактирования, предупреждение о защищённых ветках, запуск job при упавшем upstream, кнопка Promote, отладка отдельной job и пайплайны без репозитория.
• MCP получил teamcity_pipeline_get, teamcity_pipeline_post и teamcity_pipeline_delete; изменяющие инструменты работают только в Brave mode, который включается вручную.
• AI Assistant поддерживает свой ключ (BYOK): Anthropic, OpenAI, Google Gemini и совместимые с OpenAI локальные модели; сам помощник требует лицензии Enterprise.
• Kotlin DSL можно выполнять на билд-агентах, а не на сервере; плагин для IDE получил CLI и запуск сборок с незакоммиченными изменениями.

Что изменилось в пайплайнах

Pipelines появились в TeamCity 2025.07 как функция раннего доступа: сразу в Cloud и по запросу в On-Premises. С тех пор, по словам JetBrains, команда закрывала разрыв с классическими build configurations: добавила поддержку build features, шаги для .NET и возможность связывать пайплайны в цепочки сборок. Релиз 2026.2 объявляет пайплайны общедоступными на обеих поставках. Разработка при этом продолжается, дальнейшие планы вынесены в дорожную карту продукта.

Если YAML пайплайна хранится в Git, теперь в режиме редактирования можно выбирать ветку репозитория и задавать для каждой ветки собственный сценарий. Для защищённых веток интерфейс предупреждает, что правки из UI напрямую не запушить, и предлагает сохранить их в другую ветку.

В зависимостях между job появился переключатель Run job even if upstream fails: пайплайн доходит до конца даже после ошибки, а сам прогон при этом остаётся помеченным как упавший. JetBrains приводит очевидный сценарий: шаги очистки и уведомлений, которые должны выполниться всегда.

Кнопка Promote, которая запускает нижнюю часть цепочки от уже завершённой сборки, теперь работает и для пайплайнов. Пример из анонса: успешный прогон Build Docker image можно продвинуть в конфигурацию Upload to DockerHub и повторно задеплоить артефакт без пересборки. Отдельную job теперь можно отлаживать, не выходя из режима редактирования и не запуская весь пайплайн: лог и терминал открываются внизу редактора.

Ещё одно изменение: пайплайн можно создать без привязанного VCS root, выбрав при создании вариант Without repository. Раньше сценарии, которые ничего не выкачивают из репозитория, были доступны только в build configurations.

Как ИИ-агенты получают доступ к CI

MCP-эндпоинт, через который агенты используют сервер TeamCity как источник инструментов, появился в версии 2026.1. В 2026.2 к нему добавлены три инструмента для пайплайнов: teamcity_pipeline_get, teamcity_pipeline_post и teamcity_pipeline_delete. Чтобы агент не удалил пайплайн случайно, post и delete доступны только в Brave mode, который включается вручную; по умолчанию агент может только читать.

Авторизация MCP переведена на OAuth с PKCE. Раньше для подключения агента приходилось выпускать personal access token и прописывать его в конфигурации ИИ-окружения; при OAuth-подключении это не нужно, а ручной токен остаётся способом выдать агенту ограниченные права, например только на чтение. Плагин для IntelliJ IDEA стал поставляться вместе с CLI TeamCity и регистрирует MCP-сервер сам, так что интеграция с Junie или сторонними агентами, по словам JetBrains, требует минимум ручной настройки.

AI Assistant, встроенный помощник для разбора сборок и отладки CI, поддерживает Bring Your Own Key: в разделе Admin | AI Assistant вводится ключ разработчика, после чего запросы уходят в Anthropic, OpenAI, Google Gemini или в совместимую с OpenAI модель, в том числе развёрнутую локально. По документации, AI Assistant требует активной лицензии Enterprise, в том числе триальной, и недоступен на Professional; для команд, у которых нет доступа к провайдеру JetBrains AI, свой ключ это способ подключить ту модель, до которой доступ есть.

Что ещё вошло в релиз

• Повтор упавшей зависимости на месте. На вкладке Dependencies в настройках build configuration появилась группа Retry Settings: при включённом Use custom retry settings и заданном числе попыток TeamCity задерживает нижнюю сборку и повторяет упавшую зависимость, не перезапуская всю цепочку.
• Плагин для IDE показывает результаты тестов TeamCity прямо в IDE и умеет запускать удалённые сборки с локальными изменениями, которые ещё не закоммичены.
• Разработчики на Kotlin Multiplatform, установившие плагин в IDEA или Android Studio, могут получить бесплатный тариф TeamCity Cloud с лимитом 30 000 build credits в месяц для автоматически сгенерированных пайплайнов, которые тестируют и собирают iOS-приложения; плагин также упрощает интеграцию с TestFlight.
• Build feature Pull Requests для GitHub умеет сопоставлять pull request по исходной ветке, а не по ссылке на ветку: связанные PR в разных репозиториях с разными номерами собираются в одной цепочке.
• Для проектов с настройками в Kotlin DSL в удалённом репозитории можно выбрать, где выполняется этот код: на сервере или на билд-агентах. Выполнение на агентах JetBrains называет менее ограниченным и более безопасным, но предупреждает, что у обоих вариантов есть компромиссы, описанные в документации.

Что делать команде на TeamCity

1. Если пайплайны использовались в EAP, снятие статуса раннего доступа означает, что их можно переводить на основные сборки; полный список изменений JetBrains держит в разделе What's New документации.
2. Тем, кто остаётся на предыдущих мажорных версиях On-Premises, вышли обновления 2025.11.8 и 2026.1.4 с исправлениями ошибок.
3. Перед тем как дать агенту право менять пайплайны, оценить, нужен ли Brave mode: по умолчанию изменяющие MCP-инструменты выключены.
4. Если в проекте Kotlin DSL из удалённого репозитория, свериться с документацией по режимам компиляции до переключения на агенты.

Цены и условия лицензирования в анонсе не упоминаются. Релиз выходит через несколько дней после того, как JetBrains раскрыла детали взлома своего сервиса Cadence через непропатченный TeamCity, и на следующий день после выхода OIDC-плагина, который заменяет долгоживущие облачные ключи в CI короткими токенами. Следующий ориентир для пайплайнов, по словам компании, задаёт дорожная карта TeamCity.

Источники: TeamCity 2026.2: Pipelines General Availability, BYOK for AI Assistant, and More (блог JetBrains), What's New in TeamCity (документация)

Изображение на обложке: Логотип: JetBrains

Для команд, которые пускают агента в репозиторий с .env, приватными схемами и внутренними документами, это способ формально закрыть ему доступ. Но по документации GitHub у механизма есть заметные дыры: в VS Code режимы Edit и Agent исключения пока не поддерживают, симлинки и репозитории на удалённых файловых системах не покрываются, а семантическая информация из IDE (типы, определения по наведению, свойства сборки) может просочиться в контекст даже для исключённого файла.

• Content exclusions стали GA для Copilot app и Copilot CLI; сайт GitHub и GitHub Mobile остаются в public preview.
• Политику настраивают администраторы репозитория, владельцы организации и enterprise; планы Copilot Business и Enterprise.
• Исключённые файлы не участвуют в inline-подсказках, не влияют на подсказки в других файлах, не попадают в ответы чата и не проверяются Copilot code review.
• Не покрыты: режимы Edit и Agent в VS Code, симлинки, репозитории на удалённых файловых системах; возможна утечка через семантику IDE.
• Клиент передаёт GitHub URL текущего репозитория, чтобы получить политику; GitHub заявляет, что эти URL не логируются.

Как работает исключение и что оно гарантирует

Механизм описан в документации GitHub: администратор задаёт пути и маски файлов на уровне репозитория, организации или enterprise. Клиент Copilot при запуске отправляет на GitHub URL текущего репозитория и получает применимую политику; по заявлению GitHub, эти URL не логируются. Дальше клиент обязан не показывать содержимое исключённых файлов модели: ни для автодополнения внутри них, ни как контекст для подсказок в соседних файлах, ни в ответах чата, ни в автоматическом ревью.

Слово «обязан» здесь важно. Это политика на стороне клиента, а не криптографическая изоляция: GA-статус означает, что GitHub заявляет поддержку в приложении и CLI и берёт на себя ответственность за её работу. До 2 сентября правила действовали в части IDE-сценариев и в code review, а для app и CLI были в предварительном статусе.

Где исключения не срабатывают

• VS Code: режимы Edit и Agent пока не поддерживают content exclusion. Именно в агентном режиме модель читает файлы активнее всего.
• Симлинки: если исключённый файл доступен по символической ссылке под другим путём, политика его не закроет.
• Удалённые файловые системы: репозитории на сетевых дисках и в remote-окружениях не покрываются.
• Семантика IDE: языковой сервер может отдать типы, hover-определения и свойства сборки из исключённого файла, и они попадут в контекст.

Практический вывод: исключение файлов снижает риск случайной утечки секрета в подсказку, но не заменяет хранение секретов вне репозитория. Файл .env с ключами в Git был плохой идеей и до Copilot; агент лишь делает цену ошибки заметнее. Как это выглядит на практике, показал недавний инцидент METR с украденным API-ключом.

Что настроить сегодня

1. В настройках репозитория, организации или enterprise добавить в исключения .env*, каталоги с ключами и сертификатами, приватные схемы данных и внутренние документы.
2. Проверить каждую поверхность отдельно: Copilot app, CLI, IDE, code review. Для VS Code помнить, что Edit и Agent исключения игнорируют.
3. Найти симлинки на чувствительные файлы (find . -type l) и репозитории на сетевых дисках: там политика не действует.
4. Убедиться, что тариф Business или Enterprise: на индивидуальных планах content exclusion недоступен.

Доступность оплаты планов Business и Enterprise из России GitHub в changelog не обсуждает. В тот же день GitHub выпустила и другое изменение для администраторов: managed settings теперь позволяют назначать командам любую модель Copilot по умолчанию с возможностью переопределения. Про то, что Copilot научился ставить approve на pull request, мы писали накануне; в связке с исключениями это означает, что ревьюер-агент может не видеть части файлов, которые одобряет.

Источники: GitHub Changelog: Content exclusions generally available in Copilot app and CLI, GitHub Docs: Content exclusion for GitHub Copilot

Изображение на обложке: GitHub

Для разработчика это открытый пример, где агентный конвейер отвечает за весь цикл: сбор геоданных, генерацию моделей, рантайм, автотесты по фотографиям и независимое ревью. В репозитории лежит исходный промпт, база исследования с источником у каждого факта, скрипты генерации и отчёты рецензентов с оценками от 5,5 до 8 из 10, которые авторы не подгоняли под целевую планку. Это можно клонировать, повторить на своём районе или разобрать как образец того, что сегодня получается у агентов в 3D, а что пока нет.

• Сцена: 453 контура зданий из OpenStreetMap, 75 фасадов с описанием, составленным агентами по фотографиям, 11 950 оконных и дверных проёмов, 129 опознанных магазинов с реальными арендаторами 2024–2026 годов.
• Жизнь на улице: 220 пешеходов на навигационном графе из 1398 узлов, 109 машин, автобусы и канатные трамваи по улице Пауэлл, 36 регулируемых перекрёстков.
• Два интерьера, куда можно зайти: Apple Union Square и Nintendo San Francisco, 23 интерактивных объекта.
• Проверка: 34 контрольных точки, где рендер сверяется со снимком с того же места (свободные фотографии есть для 28 из них), 147 листов сравнения, 9 отчётов агентов-рецензентов, 18 из 18 шагов сценарного прохода.
• Производительность в headless Chromium при 1080p: 50–79 кадров в секунду на улице днём, 32 в виде сверху. Ассеты: 206 GLB-файлов на 5,1 МБ.

Что построили

Реконструкция покрывает примерно 800 на 720 метров: саму площадь и кварталы между улицами Мейсон и Грант, Саттер и О'Фаррелл. Рельеф взят из USGS 3DEP (1317 высотных отметок), поэтому Пауэлл-стрит поднимается к Ноб-Хиллу так же, как в жизни. Начало координат привязано к монументу Дьюи, а вся сцена повёрнута на реальный азимут уличной сетки 80,686 градуса, чтобы фасады стояли на своих участках.

Управление обычное для браузерных прогулок: WASD для ходьбы, Shift для бега, E для взаимодействия, Tab для орбитальной камеры, T запускает кинематографический тур, клавиши 1, 2 и 3 переключают день, закат и ночь. Клавиша R накладывает на рендер реальную фотографию с той же точки, чтобы глазами оценить расхождение.

Как это собрано

Авторы подчёркивают, что ничего в сцене не расставлено «на глаз»: всё собирается при загрузке из данных. Конвейер из четырёх стадий описан в README и целиком лежит в репозитории.

1. Разведка. Одиннадцать параллельных исследовательских агентов собрали базу: контуры зданий из OSM, высоты USGS, спецификацию улиц и транспорта (число полос, односторонние направления, положение рельсов канатной дороги), обмер площади, перепись из 122 магазинов, отдельные исследования магазинов Apple и Nintendo и 34 контрольных ракурса. У каждого факта записан источник и уровень уверенности; непроверенное не придумывалось, а помечалось как нерешённое.
2. Офлайн-генерация ассетов. Скрипты на Blender как библиотеке (bpy) выпускают 206 оптимизированных GLB-модулей: окна, карнизы, витрины, маркизы, фонари, светофоры, скамейки, гидранты, машины, пальмы, торговое оборудование, части тел пешеходов. Blender в рантайме не участвует.
3. Рантайм. Приложение на Three.js собирает рельеф, улицы, фасады, реквизит, толпу и трафик из JSON-спецификаций. Фасадный движок превращает описание здания в геометрию: цокольный ярус, шагающий вместе с уклоном тротуара, витрины с реальными арендаторами и вывесками, окна по ритму пролётов, карнизы и парапеты. 75 зданий описаны отдельными спецификациями, остальные выводятся автоматически и берут арендаторов из переписи.
4. Проверка по камере. Playwright гоняет настоящее приложение по 34 ракурсам, снимает скриншоты и кладёт их рядом с фотографиями под свободной лицензией с тех же точек, плюс наложение 50 на 50. Девять независимых агентов-рецензентов (геометрия, семантика, архитектор, местный житель Сан-Франциско, художник по окружению, технический художник, интерактив) пишут отчёты, которые запускают следующий цикл правок.

Пешеходы ходят по навигационному графу из 1398 узлов по тротуарам, переходам и лестницам площади, у них есть роли: пассажир, покупатель, турист, сидящий, переходящий дорогу. Машины двигаются по графу полос по модели IDM и останавливаются на красный; светофоры работают циклом в 60 секунд.

Что показала проверка

Самая полезная часть репозитория для тех, кто оценивает возможности агентов, это итоговый QA-отчёт, сгенерированный 2 сентября. Географическая точность получила 7,5 из 10, узнаваемость зданий 5,5 с оценкой 6,5 после исправления, точность магазинов 6 (размещены 76% названных арендаторов из переписи), интерьер Apple 7, Nintendo 7,5, детализация улицы, материалы и общая узнаваемость по 6, освещение 7, навигация 8, производительность 6. Целевая планка в промпте была 8–9, и авторы прямо пишут, что оценки под неё не подгонялись.

Список открытых расхождений тоже опубликован. Контур универмага Saks в OSM нарисован по границе участка, поэтому тротуар на Пауэлл получился шириной 2,1 метра вместо примерно четырёх. Здание Уиттелл смоделировано высотой 56 метров по OSM вместо 66 по справочникам. У 34 витрин из переписи арендатор не установлен: они отрисованы нейтральной пустой фасцией, а не выдуманы. Есть и исправленные баги с понятной причиной: все стены фасадов были сгенерированы с обратной обмоткой полигонов, и отсечение задних граней прятало их там, где сзади не было панели, из-за чего стены «исчезали», если поднять взгляд.

Замеры производительности сделаны в headless Chromium при 1920 на 1080 через ANGLE и Metal, то есть на Mac. Днём в центре площади 63 кадра в секунду при 2108 вызовах отрисовки и 7,25 млн треугольников; на перекрёстке Пауэлл и Гири 51 кадр, 2646 вызовов и 7,91 млн треугольников; внутри Apple 79 кадров; в виде сверху 32 кадра при 3522 вызовах и 8,52 млн треугольников. Куча JavaScript держится на 290 МБ днём и 242 МБ ночью. Ночной режим дешевле по вызовам отрисовки, но кадров на перекрёстках даёт меньше: 38,5 на Пауэлл и Гири.

Чего в репозитории нет

На вопрос о цене и времени автор публикации на Hacker News под ником surreal_ ответил, что это результат одного прогона по очень длинному промпту с явными указаниями про субагентов и цикл самопроверки: около двух часов работы, примерно 8 млн токенов и около $33 по тарифам API. Сколько было неудачных попыток до этого прогона и вмешивался ли человек по ходу, не уточняется. Кто стоит за PhiloLabs, тоже неизвестно: организация на GitHub создана в феврале 2026 года, без описания и сайта, в ней пять репозиториев. В комментариях автор пишет, что команда уже сгенерировала большинство туристических мест Сан-Франциско и готовит обзорную статью про «моделирование мира через код»; сроков нет.

Разработчик игр в комментариях на HN отметил, что в похожих экспериментах модели выдают неоптимизированную геометрию с избыточным числом полигонов, и что для игровых ассетов он предпочитает просить у модели низкополигональные силуэты. Автор проекта ответил, что при генерации мира кодом геометрия строится из примитивов и параметрических конструкций, поэтому топология чистая по построению, а слабое место скорее текстуры. Числа из QA-отчёта, 7–8 млн треугольников и больше двух тысяч вызовов отрисовки на кадр для одного квартала, по нашей оценке, всё же говорят о заметном запасе для оптимизации.

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

Репозиторий стоит открыть не ради прогулки по Сан-Франциско, а ради конвейера. Файл PROMPT.md показывает, как сформулирована задача на автономную сборку: перечень обязательных объектов с адресами, требование Three.js в рантайме и Blender только офлайн, обязательная сверка с фотографиями на каждой вехе и независимые рецензенты. Папка qa/ пригодится как образец проверки против реальности, а не против самого себя: фиксированные ракурсы по координатам, автоматические сравнения и отчёты, которые прямо называют, где результат ниже планки.

Код и сгенерированные ассеты отданы под MIT, но исходные данные лицензированы отдельно: контуры зданий получены из OpenStreetMap под ODbL, высоты USGS в общественном достоянии, а сами эталонные фотографии в репозитории не распространяются: для каждого сектора сохранена только их атрибуция, чтобы набор можно было скачать заново. Названия и логотипы магазинов, как оговаривают авторы, остаются собственностью их владельцев, так что перед использованием сцены в своём продукте права на товарные знаки нужно проверять отдельно.

Источники: Репозиторий PhiloLabs/fable51-worlds, README мира Union Square, FINAL_QA_REPORT.md, Обсуждение на Hacker News

Изображение на обложке: PhiloLabs, fable51-worlds (MIT)

Для разработчика это значит, что самая нудная часть жизни PR, когда код уже написан, а CI красный и ревьюер оставил пятнадцать комментариев, теперь может быть делегирована. Обновление раскатывается постепенно; кто не хочет ждать, запускает команду Check for Updates. Сборки есть для Windows, macOS и Linux (deb, rpm, tarball, Snap), отдельных условий для России на странице релиза нет.

• Agent Merge (Preview) включается настройкой chat.agentMerge.enabled и запускается из окна Agents; агент повторяет цикл исправления и перезапуска workflow до готовности PR.
• Multi-root workspace для агентов в статусе Experimental: chat.agentHost.copilotAgent.multiRootEnabled и chat.agentHost.claudeAgent.multiRootEnabled; хуки агента по-прежнему привязаны к одной папке.
• Agent Host работает отдельным процессом и может обслуживать несколько окон; протокол Agent Host Protocol опубликован отдельно.
• Связанные чаты показываются деревом внутри сессии со статусами и ожидающими подтверждениями; появились уведомления, когда агенту нужен ввод или он закончил.
• Из мелкого: терминальные расширения больше не получают задержку запуска до 5 секунд, режим Compact layout уменьшает отступы между панелями.

Как работает Agent Merge и чего он пока не обещает

По описанию Microsoft, Agent Merge «помогает довести pull request до финишной черты» (перевод редакции), то есть до состояния, когда его можно сливать. Пользователь указывает PR, агент читает review feedback, смотрит на failed checks и merge conflicts и правит код, после чего снова запускает workflow. Цикл повторяется, пока проверки не пройдут и замечания не будут закрыты. Функция в Preview, поэтому Microsoft не гарантирует ни стабильность, ни то, что агент справится с любым конфликтом; сколько итераций он делает и как считаются затраты на модель, в заметках к релизу не сказано.

На практике это надстройка над тем же агентским режимом чата, который в VS Code развивают уже год: тот же выбор модели, те же подтверждения опасных действий. Отличие в том, что цель формулируется не промптом, а состоянием PR. Как это соотносится с недавним разрешением ставить approve силами Copilot, легко представить: одна и та же система может и править PR, и одобрять его, что стоит учитывать при настройке правил защиты веток.

Что даёт агентам multi-root workspace

Раньше агент видел только одну корневую папку. В 1.136 для Copilot и Claude можно включить работу со всеми корнями workspace; это экспериментальная функция за двумя отдельными настройками. Ссылки на рабочие пространства разрешаются по имени проекта, абсолютному пути и URI, а при совпадении имён VS Code показывает варианты и не выбирает молча. Ограничение осталось одно, зато важное: хуки агента (agent hooks) по-прежнему работают в пределах одной папки.

Под капотом это стало возможным благодаря Agent Host, отдельному процессу, который теперь умеет обслуживать несколько окон редактора. Протокол взаимодействия с ним, Agent Host Protocol, Microsoft опубликовала отдельно; вместе с Copilot SDK это заявка на то, чтобы сторонние агенты подключались к VS Code по одной схеме.

Остальные изменения релиза

• Дерево сессий: заголовки, статусы и ожидающие approvals; чаты можно раскрывать, переименовывать, переносить и удалять.
• Уведомления о том, что агенту нужен ввод или он закончил работу; по умолчанию только для сессий не в фокусе.
• Корпоративные политики могут включить распознавание речи на устройстве и запретить очистку диктовки языковой моделью.
• Compact layout уменьшает интервалы между панелями.
• Запуск терминальных расширений больше не получает искусственную задержку до 5 секунд.

Стоит ли включать прямо сейчас

Agent Merge имеет смысл пробовать на репозиториях, где CI быстрый и есть чёткие правила ревью: там цикл агента даст видимый результат. На проектах с медленными пайплайнами каждая итерация будет стоить минут ожидания и токенов, а сколько именно, Microsoft не раскрывает. Multi-root режим полезен монорепозиториям, но пока экспериментален, и хуки в нём не работают за пределами одной папки.

Кому обновление ничего не изменит: тем, кто не пользуется агентским чатом, и командам без подписки на Copilot. Для них в 1.136 остаются Compact layout, ускорение запуска терминальных расширений и мелкие изменения редактора, терминала и доступности. Полные заметки к релизу со скриншотами лежат на сайте VS Code; подробности про approve от Copilot и его учёт в правилах веток мы разбирали отдельно.

Источники: VS Code: August 2026 (version 1.136) release notes, Релиз 1.136.0 на GitHub

Изображение на обложке: Microsoft, логотип Visual Studio Code

Для команды, которая пишет ассистента магазина или маркетплейса, интерес здесь в архитектуре, а не в демо. Anthropic показывает, как описать агента один раз и запускать тремя способами, где стоят проверки, чтобы модель не могла подложить в корзину чужой товар или изменить цену без человека, и как подключить свой каталог через два интерфейса на Python.

Оговорка стоит в самом README: это референсная реализация, она не поддерживается и не принимает внешний вклад. В примерах нет аутентификации, MCP-серверы по умолчанию слушают loopback.

• Два агента, три способа запуска (Messages API, Claude Agent SDK, Managed Agents (beta)), четыре вертикали и восемь веб-приложений в одном репозитории под Apache 2.0.
• Не оформляет заказ, не списывает деньги и не меняет живые листинги: checkout только рисует корзину, каждая запись мерчанта ждёт одобрения человека.
• Проверки provenance, лимиты, ограждение стороннего текста и валидация памяти работают внутри вызова инструмента и держатся на всех трёх путях запуска.
• Своя интеграция сводится к реализации StorefrontBackend или MerchantBackend; отсутствующие системы выключаются переключателями enable_*.
• Модели по умолчанию: claude-sonnet-5 у покупательского агента, claude-opus-5 у мерчантского, claude-haiku-4-5-20251001 для памяти; рантаймы работают через Vertex AI, Bedrock, Microsoft Foundry и шлюзы.
• Требования: Python 3.11 и новее, Node 22. Демо поднимается шестью командами из README.

Один агент описан один раз и работает на трёх рантаймах

Главная архитектурная идея репозитория, как её формулирует README: каждый агент определён один раз (промпт, скиллы, контракты инструментов, гейты) и запускается на Messages API, на Claude Agent SDK и на Managed Agents. Четыре вертикали работают поверх одних библиотек и различаются бэкендом и доменными расширениями интерфейса.

Покупательский агент ищет и сравнивает товары, собирает планы покупок, наполняет корзину, отвечает на вопросы о заказах и правилах магазина и запоминает, что покупатель о себе рассказал. Его пять сценариев лежат как skills в каталоге shopping-agent/skills. Мерчантский агент объясняет показатели, правит листинги, реагирует на алерты по остаткам и заказам, назначает цены и промо, готовит кампании. Его пять сценариев лежат в merchant-agent/skills. Любая запись мерчанта становится staged change, которую применяет уже интерфейс одобрения на стороне хоста.

Nothing places an order, charges a card, or changes a live listing: checkout renders the cart for the host to complete, and every merchant write is staged until a person approves it.

Код разложен на семь pip-пакетов. Общее для обеих ролей вынесено в commerce-common: конфиг, ограждение стороннего текста, память, скиллы, grounding, презентационные компоненты, исполнитель инструментов и события. У каждой роли три пакета: core с типами, интерфейсом бэкенда, промптом, контрактами инструментов и гейтами; runtime с циклом ходов на Messages API; sdk с тем же агентом на Agent SDK и консолью. CI проверяет, что имена семи пакетов остаются незарегистрированными в публичном индексе, а pin-файлы ставят их из каталогов репозитория.

Эталонный путь запуска, вокруг которого построены примеры, это Messages API. Хост создаёт объект агента с бэкендом, каталогом скиллов и конфигом и стримит события хода; извлечение памяти вызывается отдельно после хода, и только на этом пути. Код из README:

На Agent SDK тот же промпт, скиллы и инструменты, но цикл ведёт SDK: хост заранее подгружает данные для grounding, после хода ничего не выполняется. На Managed Agents агент размещён у Anthropic и ходит за данными в ваш MCP-сервер; деплой делает скрипт scripts/deploy_managed_agent.sh, без флага --live это сухой прогон. Различия трёх путей по docs/safety.md:

• Messages API. Все правила grounding включаются принудительно через tool_choice; работают извлечение памяти после хода, сжатие истории и бюджеты аналитического делегата мерчанта.
• Agent SDK. Grounding только для правил с формой предварительной загрузки; цикл ограничен max_turns; аналитика мерчанта идёт субагентом без SQL-инструмента и бюджетов; память хост извлекает сам.
• Managed Agents. Grounding отсутствует, циклом владеет платформа, память пишется только через save_memory, одобрением staged change служит промпт always_ask на apply_change.

Проверки стоят внутри вызова инструмента, поэтому переживают смену рантайма

Документ docs/safety.md делит правила на три группы: что код проверяет сам, что по-прежнему просят у модели промптом и что обязан добавить деплой. Ключевой приём: правило внутри вызова инструмента держится на всех трёх путях, потому что все три прогоняют вызовы через один исполнитель в модуле commerce_common/execution.py. Правило на уровне хода живёт в конкретном рантайме, и таблица указывает, где оно не работает.

A rule enforced inside a tool call holds on all three paths, because the Messages API runtime, the SDK toolset, and the MCP server execute tools through the same executor.

Что именно проверяется в коде, по таблице документа:

• Ограждение (fencing). Сторонний текст очищается, оборачивается в ограждение с фиксированной меткой и обрезается до max_fenced_chars. Очистка убирает невидимые и управляющие символы, поддельные маркеры ходов, теги транскрипта и вызовов инструментов и копии самого маркера ограждения.
• Лимиты цикла. Запрошенное моделью число результатов поиска обрезается до max_search_results; после max_tool_iterations раундов рантайм Messages API принудительно делает ход без инструментов.
• Provenance корзины. В корзину попадают только идентификаторы товаров, которые в этой сессии вернул инструмент каталога или заказов. Попытка добавить товар с опциями (размер, цвет) задерживается, и модели показывают варианты. Действует лимит на позицию и на число строк.
• Нет оплаты. У StorefrontBackend нет метода, который размещает заказ или списывает деньги. URL размещённого checkout приходит из checkout_handoff после вызова модели и не проходит через неё.
• Provenance staged-записей мерчанта. Изменение принимает только идентификаторы листингов и кампаний, возвращённые инструментом в этой сессии; правка контента требует чтения get_listing. apply_change принимает только идентификаторы изменений, которые вернули staging или get_pending_changes.
• Guardrails мерчанта. Проверяются при постановке изменения и повторно при применении: число позиций, размах изменения цены, глубина промо, размер пополнения, бюджет кампании, защищённые поля.
• Одобрение хостом. При require_host_approval (включено по умолчанию) apply_change проходит только для идентификаторов, которые хост пометил одобренными. Карточка предпросмотра ничего не одобряет, «да, применяй» в чате тоже.
• Память. Ключ факта до 64 символов, значение до 200, одна из трёх категорий; значения, похожие на идентификаторы, отбрасываются. Извлечение читает только текст последнего обмена, никогда результаты инструментов.
• Поверхность инструментов и идентичность. Список инструментов вычисляется из конфига деплоя, исполнитель отказывает любому другому имени. Идентичность держит сервер: ни один аргумент инструмента не называет пользователя или мерчанта.

Вторая группа правил остаётся в промпте: трактовать ограждённый текст как материал для отчёта, называть условия и цифры только из результата инструмента, подтверждать запись только после успешного вызова, называть товары по идентификатору. Документ оговаривает: промптовые правила держатся ровно настолько, насколько модель следует инструкциям, а таблица держится на любой модели. Деплой, который меняет модель или выключает require_host_approval, должен сначала перегнать свои evals по этому разделу.

When the model breaks one of these, the error is confined to its text. Every write, figure, and disclosure behind that text still passed the checks in the table above, so the failure is a misstatement to correct and no action needs reversing.

Третья группа целиком на стороне деплоя: аутентификация и авторизация на каждом маршруте и на MCP-серверах (примеры принимают любого вызывающего), учётные данные для вызова ваших сервисов, лимиты запросов, бизнес-правила (фрод, право на покупку, цены, остатки), оплата после checkout, обращение с памятью как с персональными данными, гигиена логов и сама поверхность одобрения. Значения guardrails в двух файлах config.py названы демонстрационными.

Своя интеграция сводится к двум интерфейсам и переключателям enable_*

Точка входа для собственных систем описана в docs/backends.md. Деплой реализует StorefrontBackend поверх каталога, корзины, заказов и политик или MerchantBackend поверх аналитики, каталога, остатков, цен и кампаний. Контрактом служат докстринги методов в backend.py и types.py каждой роли. Каждый метод вызывает ваш сервис на стороне сервера с учётными данными, которые хост хранит для сессии; модель видит только результат.

Each one calls your service server-side with the credential your host holds for the session; the model reads only the result.

Документ раскладывает интеграцию на шесть шагов. Первый: решить, кто вызывающий. Хост аутентифицирует человека и стартует сессию с принципалом; токен покупателя живёт в контексте сессии, сервисная учётка передаётся в конструктор бэкенда. Гость тоже принципал: чтение, которому нужен аккаунт, бросает исключение, которое подкласс исполнителя превращает в просьбу войти. Второй: порядок многошаговых сценариев (удержать места, затем подтвердить) хранится и проверяется в бэкенде, а нарушение маппится через domain_error в понятный модели результат. Третий: как завершается checkout. Вариантов три: ссылка на маршрут в вашем приложении, размещённый checkout платформы, для которого checkout_handoff возвращает URL, или маркетплейс с записью на каждого продавца.

Четвёртый шаг: товары с опциями. Запись бывает простой, семейством (с полем options) или вариантом (с option_values и variant_of); идентификатор варианта идёт всюду, где ждут идентификатор товара. Детали товара возвращают все варианты семейства в одном ограждении, обрезанном до max_fenced_chars (12 000 символов по умолчанию). Компактная строка варианта занимает 70–120 символов, так что в семейство помещается около шестидесяти вариантов; кроссовки в восьми цветах и четырнадцати размерах документация советует подавать как восемь семейств по четырнадцать, потому что за пределами лимита результат режется без ошибки. Пятый: записи мерчанта по семействам, где изменение цены и пополнение именуют вариант. Шестой: для цифр, которых у платформы нет, возвращать None с пометкой, а не подставной ноль.

Для пилота README предлагает начинать с малого. Покупательский пилот реализует поиск и карточку товара, а остальное заглушает: метод-заглушка возвращает результат «недоступно» и не меняет ни байта промпта. Мерчантский пилот реализует восемь методов чтения, записи отказывают. Система, которой у бизнеса нет совсем, выключается переключателем enable_*: это убирает её инструменты, строки промпта и правило grounding на всех трёх путях, а сценарии, которым она нужна, паркуются в каталоге skills/_staged/. Свой сценарий добавляется каталогом с файлом SKILL.md, доменный интерфейс расширением PresentationExtension (вертикали поставляют семь), а brand_name, assistant_name и brand_voice в конфиге задают личность ассистента.

Модели заданы строкой в конфиге, а переключение платформы сосредоточено в одном месте и зависит от рантайма

По docs/deployment.md код по умолчанию ходит в API Anthropic, но у каждого пути есть одно место, где деплой переключает платформу. Рантаймы Messages API принимают любой асинхронный клиент из пакета anthropic аргументом client=: AsyncAnthropicVertex для GCP Vertex AI, AsyncAnthropicBedrockMantle или AsyncAnthropicBedrock для AWS, AsyncAnthropicFoundry для Microsoft Foundry, AsyncAnthropic с base_url и auth_token для собственного шлюза. Пакеты требуют anthropic 0.91 и новее. Рантаймы Agent SDK HTTP-клиента не создают: платформу выбирает CLI Claude Code по переменным окружения, которые добавляются в options.env. Managed Agents работает на инфраструктуре Anthropic, поэтому у него нет варианта для Vertex, Bedrock и Foundry.

Модель задаётся строкой в конфиге: поля model и memory_model у каждой роли, у мерчанта ещё analysis_model. Значения по умолчанию, по таблице документа: claude-sonnet-5 для покупательского агента, claude-opus-5 для мерчантского, claude-haiku-4-5-20251001 для извлечения памяти. Грамматика идентификаторов у платформ разная: Vertex пишет датированные снимки через @, Bedrock через Mantle берёт идентификаторы с префиксом anthropic., а через Invoke API идентификаторы inference-профилей. Все три поля идут через один клиент, поэтому все три модели должны существовать на целевой платформе. Живого разговора с облаком в CI нет; документ просит прогнать его на своей платформе до того, как на неё полагаться.

Доступность API Anthropic и облачных платформ для конкретной страны или способа оплаты в документации репозитория не обсуждается. Для собственного шлюза документ называет требование: отдавать /v1/messages со стримингом SSE для Messages API, а для Managed Agents ещё проксировать /v1/skills, /v1/agents, /v1/environments, /v1/sessions и поток событий сессии с заголовками anthropic-beta.

Демо поднимается шестью командами, а плагин Claude Code собирает агента под ваш стек

Порядок запуска из README (нужны Python 3.11 и новее и Node 22, ключ ANTHROPIC_API_KEY в файле .env):

Флаг --merchant поднимает портал мерчанта вместо витрины, --all оба. В README каждой вертикали есть раздел Try с репликами, которые прогоняет scripts/smoke_chat.py. Розничная ACME показывает поиск, сравнение, корзину, checkout и память; ACME Travel добавляет инвентарь с датами; ACME Mobile матрицу тарифов и серверные раскрытия комиссий; ACME Tickets таймированные удержания мест, листы ожидания и карту зала.

Второй способ начать: плагин commerce-builder для Claude Code. Он читает клонированный репозиторий как эталон и собирает агента на этих пакетах против ваших систем либо проверяет уже написанного. Установка и первая команда из README:

Команда /scaffold-commerce-agent спрашивает о стеке, проговаривает план и строит проект. Дальше /add-commerce-flow добавляет сценарий, /author-commerce-evals пишет evals, /review-commerce-agent начинает с уже существующего агента. Собственных MCP-коннекторов в поставке нет: оба агента ходят в системы через интерфейсы бэкенда. Где официальный коннектор является источником истины (Snowflake, BigQuery, Stripe, Square, Slack и другие в списке README), он и становится целью интеграции. MCP-сервер торговой платформы вызывается из метода бэкенда на сервере, и гейты provenance остаются перед каждой записью.

Проверка после правок: ruff check и ruff format --check, pytest, python scripts/check.py; python scripts/verify_all.py добавляет сухие прогоны деплоя и сборку веб-приложений; python scripts/smoke_chat.py --vertical travel проводит один живой разговор и требует ключ. Чтобы убедиться, что кэширование промпта работает, README советует читать cache_read_input_tokens из события turn_complete: ноль на втором ходу означает, что префикс промпта изменился.

Что делать команде, которая пишет ассистента для магазина

1. Поднять розничное демо по шести командам выше (Python 3.11 и новее, Node 22, ключ API) и пройти реплики из раздела Try в examples/retail/ на витрине (порт 3000) и в портале мерчанта (флаг --merchant, порт 3100).
2. Сверить таблицу «Enforced in code» и список «What a deployment owns» из docs/safety.md с собственной платформой: аутентификация, учётные данные, лимиты запросов, бизнес-правила, оплата, персональные данные в памяти, логи.
3. Для пилота реализовать в StorefrontBackend только поиск и карточку товара, для MerchantBackend восемь методов чтения. Отсутствующие системы выключить через enable_*, зависимые сценарии убрать в skills/_staged/.
4. Разложить каталог по трём формам записи из docs/backends.md и проверить самое большое семейство против лимита max_fenced_chars в 12 000 символов.
5. Выбрать завершение checkout: свой маршрут, размещённый URL платформы через checkout_handoff или ссылка на продавца для маркетплейса; оплата остаётся в хосте.
6. Для Vertex AI, Bedrock, Foundry или шлюза передать клиент аргументом client= (anthropic 0.91 и новее) или переменные CLI в options.env и заменить все три идентификатора моделей.
7. Перед выкладкой прогнать ruff, pytest, scripts/check.py и scripts/verify_all.py, затем один живой разговор scripts/smoke_chat.py на своей платформе; при смене модели перегнать evals по разделу «Still asked of the model».

Репозиторий создан 1 сентября, анонс в аккаунте Claude Developers вышел 2 сентября в 19:33 UTC. На 3 сентября, 01:53 мск, по данным GitHub API у проекта 277 звёзд и 46 форков. Поддержки и приёма внешних изменений Anthropic не обещает: «This is a reference implementation; it is not maintained and does not accept contributions», говорится в README. На практике это значит, что исправления и адаптацию под свои системы команде придётся вести в собственном форке, а промпты и гейты под новые модели проверять своими evals. Цен, лимитов и сроков дальнейшего развития Anthropic в репозитории не называет.

Источники: Claude Developers в X: анонс открытия Claude Commerce Agents (2 сентября 2026), GitHub: anthropics/commerce-agents, README репозитория commerce-agents, docs/safety.md: правила, проверяемые кодом, и обязанности деплоя, docs/backends.md: подключение своих систем, docs/deployment.md: Vertex AI, Bedrock, Microsoft Foundry и шлюзы, Плагин commerce-builder для Claude Code, Скиллы покупательского агента, Скиллы мерчантского агента

Изображение на обложке: Anthropic, кадр из анонса Claude Commerce Agents

Для разработчика это редкий случай, когда бенчмарк зрения проверяется на задаче с ценой ошибки в жизнь, а не в балл. Сезон грибов в разгаре, а «сфотографируй и спроси у чата» стало привычным жестом. Вывод автора прямой: не есть гриб потому, что так сказала нейросеть. Код, список фотографий и ответы моделей автор, по его словам, выложил в репозиторий, чтобы тест можно было повторить.

• Выборка: 55 видов из датасета FungiTastic (340 тыс. наблюдений, 615 тыс. фото, 2,8 тыс. видов), по 20 тестовых фото на вид, всего 1040; метки подтверждены экспертами, часть ДНК-анализом.
• Точность первого ответа: Gemini 3.8 Flash 65%, Gemini 3.6 Flash 64%, Gemini 3.7 Flash 61%, Claude Fable 5 и Kimi K3 по 53%, Claude Fable 5.1 51%, GLM-5.3-Flash 47%, GPT-5.6 Sol 42%, Qwen3.8 27B 13%.
• Доля ядовитых грибов, названных съедобным видом: 11% у лучших Gemini, 18% у Fable 5.1, 24% у GPT-5.6 Sol, 29% у Claude Opus 5, 36% у Qwen3.8 27B.
• Опасные ошибки не случайны: смертельно ядовитую паутинницу модели называли лисичкой, как и люди; бледную поганку модели в сумме узнавали в 48% случаев.
• Подсказка «фото из Дании» результат не улучшила; для надёжного определения экспертам нужны минимум три снимка, а Атлас датских грибов опирается на ДНК.

Как устроен тест

Мигдал взял готовый датасет FungiTastic, собранный чешскими исследователями компьютерного зрения на данных гражданского проекта «Атлас датских грибов»: 340 тыс. наблюдений, 615 тыс. фотографий, 2,8 тыс. видов, метки проверены экспертами, часть подтверждена ДНК-секвенированием. Датасет разбит по годам: обучение до 2021 года, валидация 2022, тест 2023. Модели ничему не обучались, поэтому использовался тестовый срез, а подход в терминах классического ML называется zero-shot.

Чтобы тест отражал реальный поход в лес, а не лабораторию, автор отобрал виды по двум польским спискам: официальному перечню грибов, разрешённых к продаже в Польше (47 видов, из них 37 есть в датасете), и списку смертельно ядовитых видов из Википедии (после пересечения с датасетом 20 видов). Один вид, зеленушка (Tricholoma equestre), попал в оба списка: в одних странах её считают съедобной, в других она числится причиной смертельных отравлений. Итого 55 видов, по 20 фото на вид; для редких видов недостающие снимки добраны из валидационного среза.

Запрос ко всем моделям был одинаковым: назвать пять наиболее вероятных видов латинскими биномами в виде JSON-массива, самый вероятный первым, и ничего кроме массива. Латынь выбрана намеренно: народные названия ярче, но хуже стандартизированы.

Кто узнаёт грибы лучше

Три поколения Gemini Flash заняли весь пьедестал: 3.8 Flash 65% с первого раза и 85% в топ-5, 3.6 Flash 64% и 85%, 3.7 Flash 61% и 82%. Дальше идут Claude Fable 5 (53% и 72%), Kimi K3 (53% и 70%), Claude Fable 5.1 (51% и 70%), GLM-5.3-Flash и Qwen3.8 Max (по 47%), Claude Opus 5 и Grok 4.6 (по 44%). GPT-5.6 Sol, которую, как отмечает автор, хвалили как лучшую модель OpenAI по зрению, набрала 42%, а её Pro-версия 39%. В хвосте DeepSeek V4 Flash Vision (30%), Qwen3.8 Flash (27%), MiniMax M3 (24%) и локальная Qwen3.8 27B (13% и 24% в топ-5).

Автор отмечает, что отрыв Gemini здесь заметно больше, чем в других визуальных бенчмарках, и что дешёвые модели Google обошли фронтирные Claude и GPT. GLM-5.3-Flash он выделяет за соотношение цены и качества.

Какие ошибки опасны

Большинство промахов безобидны: один млечник назван другим млечником, один боровик другим. Опасные ошибки, по наблюдению автора, не случайны и повторяют ошибки людей: смертельно ядовитую паутинницу Calonarius splendens модели узнавали в 20% случаев, а в 27% называли лисичкой. Бледную поганку Amanita phalloides модели в совокупности определяли верно в 48% случаев.

Отдельно автор посчитал условную вероятность, что ядовитый гриб будет назван съедобным видом. У трёх Gemini Flash она 11–12%, у Kimi K3 14%, у Claude Fable 5.1 18%, у GLM-5.3-Flash 19%, у Claude Fable 5 22%, у GPT-5.6 Sol 24%, у Claude Opus 5 29%, у Qwen3.8 27B 36%. Muse Spark 1.2 показала всего 8%, но, как пишет автор, только потому, что часто отказывается отвечать. Обратная ошибка, съедобный гриб принят за ядовитый, встречается у всех моделей в 3–12% случаев и стоит лишь пропущенного ужина.

Оговорки автора

Мигдал не утверждает, что люди справляются лучше. Одного снимка может не хватить и эксперту: проект iNaturalist по грибам Калифорнии требует минимум три фото на наблюдение, общий план с субстратом, шляпку крупно и ножку с пластинками. Атлас датских грибов не зря полагается на экспертов и ДНК, а не на фотографии. Типичная ошибка приезжих грибников та же, что у моделей: гриб похож на съедобный «домашний», а местный смертельный двойник им незнаком. Подсказка в промпте «фото из Дании» результаты не улучшила.

Списки съедобных и смертельных видов польские, поэтому переносить проценты на российский лес напрямую нельзя: набор двойников другой. Но механизм ошибки тот же, а бледная поганка и паутинницы растут и здесь.

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

• Как учебник нейросеть годится: автор сам собрал на Gemini 3.7 Flash приложение для запоминания местных растений. Как решение «можно ли это есть» не годится ни одна из 17 моделей.
• Если вы делаете продукт с распознаванием по фото, закладывайте вероятность опасной ошибки в проценты, а не в доли процента, и не выдавайте вердикт «съедобно» без эксперта.
• Повторить тест на своей модели можно по коду из репозитория; в README на момент публикации перечислены 16 моделей, так что часть результатов из статьи туда могла ещё не попасть.

Автор обещает продолжить серию тестов Quesma по зрению; следующий очевидный шаг, которого в статье нет, это проверка с несколькими снимками одного гриба, как требуют полевые определители. Обсуждение теста идёт на Hacker News.

Источники: Piotr Migdał, Quesma: Mushroom hunting with LLMs: what can go wrong?, Код, список фото и ответы моделей: репозиторий mushroom-hunting-llm-bench, Датасет FungiTastic, Обсуждение на Hacker News

Для разработчика это удобный способ проверить, помечает ли Claude свои файлы на практике, и заодно понять, на что такая проверка годится. Коротко: она находит метку стандарта C2PA, которую Claude вшивает в сгенерированные файлы, и ничего больше. Если метки нет, это не значит, что файл сделан человеком: по словам самой Anthropic, метка может пропасть при пересохранении, конвертации, сжатии в мессенджере или скриншоте.

• Сервис принимает JPG, PNG, GIF, WEBP, TIFF, HEIC, AVIF, SVG, DNG, JXL, MP4, MOV, AVI, WAV, MP3, M4A и FLAC размером до 100 МБ.
• Проверка идёт локально в браузере: по словам Anthropic, файл не покидает устройство, не сохраняется и читаются только метаданные.
• Ищется только подписанная метка C2PA от Claude; результат не говорит ни о содержании файла, ни о том, кто его загружал.
• Отсутствие метки ничего не доказывает: она пропадает при удалении метаданных, а поддерживают её пока только Fable 5.1 и Mythos 5.1.
• Текстовые водяные знаки этот сервис не проверяет: для них есть отдельный Detection API в закрытом превью для организаций по требованию закона ЕС.

Что именно проверяет сервис

По описанию на странице, Claude помечает свой вывод двумя способами. Текст получает водяной знак в самих формулировках: он невидим, переживает копирование и часть правок. Файлы получают content credential, подписанные метаданные о происхождении, которые прикрепляются при скачивании, например к диаграмме, которую построил Claude. Формат метаданных задаёт открытый стандарт C2PA (Coalition for Content Provenance and Authenticity), тот же, что используют производители камер и фоторедакторы для записи истории снимка; прочитать такую запись может любой инструмент с поддержкой C2PA.

Check Content работает только со вторым типом меток. Он читает метаданные файла, ищет подписанную запись и, если та указывает на Claude, сообщает об этом. Anthropic отдельно оговаривает: инструмент показывает, что Claude участвовал в производстве файла, но не может сказать, участвовал ли он в создании содержимого, и не раскрывает никаких сведений о пользователе, который этот файл сгенерировал.

Технически всё происходит на стороне клиента: страница обещает, что файл остаётся на устройстве, никуда не загружается и не используется ни для каких других целей. Список форматов широкий, от JPG и SVG до MP4, WAV и FLAC, лимит 100 МБ. Сам процесс занимает секунды: перетащили файл, получили ответ «метка найдена» или «не найдена».

Почему появилась метка и какие модели её ставят

Причина не в моде на прозрачность, а в законе. В справочной статье Anthropic пишет, что подписала кодекс практики к статье 50(2) AI Act ЕС о прозрачности ИИ-контента, и обязалась машиночитаемо помечать вывод моделей Claude, запущенных в ЕС 2 августа 2026 года или позже. Компания обещает применять метки везде, где доступен Claude, а не только в Европе: в API, приложении, Claude Code и Cowork. Через облачных партнёров AWS, Google Cloud и Microsoft Foundry текстовые водяные знаки идут всегда, а файловые метки только там, где платформа даёт генерацию файлов Claude.

Сейчас метки ставят Fable 5.1 и Mythos 5.1; для моделей, вышедших до 2 августа, действует переходный период, и поддержку им ещё добавляют. Отсюда практическое следствие: файл от Opus 5 или старой Sonnet сервис не распознает, и это штатное поведение, а не сбой.

Текстовые водяные знаки проверяются иначе. Для них Anthropic держит Detection API в закрытом превью и выдаёт доступ организациям, которым это положено по закону ЕС: регуляторам, правоохранителям, СМИ, фактчекерам, исследователям, образовательным организациям, а также компаниям, обязанным проверять маркировку для собственного соответствия AI Act. Расширять доступ обещают «со временем», сроков нет.

Чего проверка не доказывает

Anthropic сама перечисляет ограничения, и их стоит держать в голове, прежде чем ссылаться на результат в споре. Найденная метка означает, что файл «мог быть обработан Claude»: она не описывает полную историю файла и не говорит, что именно сделал Claude, отредактировал картинку или нарисовал её с нуля. Отсутствие метки не означает, что ИИ не участвовал: подпись живёт в метаданных, а они, по словам Anthropic, могут пропасть при пересохранении, конвертации, публикации в соцсети или обычном скриншоте.

Есть и обратная сторона. Метка проверяет только «участвовал ли Claude», поэтому для картинки от другой модели ответ будет отрицательным, хотя содержимое сгенерировано. Похожие проверки, по словам Anthropic, есть у OpenAI и Google; универсального детектора, который читает подписи всех вендоров, страница не обещает. Отдельные C2PA-читалки, например от самой коалиции C2PA, покажут запись любого подписанта, но и они бессильны против вырезанных метаданных.

Что делать разработчику

• Если вы встраиваете генерацию картинок через Claude в свой продукт, проверьте, доходит ли метка до пользователя: ваш пайплайн (ресайз, конвертация, CDN) может её вырезать. Один прогон через Check Content на выходном файле покажет это за секунды.
• Если вам нужно, наоборот, не раскрывать инструмент генерации, помните, что метка есть в файлах от Fable 5.1 и Mythos 5.1 и что она не содержит данных о пользователе.
• Не используйте отрицательный результат как доказательство «сделано человеком»: Anthropic прямо говорит, что это не так.
• Для проверки текста сервис не подходит: пишите заявку на Detection API, если ваша организация подпадает под критерии.

Дата запуска на самой странице не указана, changelog Anthropic об инструменте не сообщает. О региональных ограничениях для проверки файлов Anthropic не пишет. Следующий шаг, за которым стоит следить, это добавление меток в старые модели и расширение доступа к Detection API, о котором компания обещает сообщить в той же справочной статье.

Источники: Claude: Check if a file was made with Claude, Anthropic Help Center: How Claude marks AI-generated content, Обсуждение на Hacker News

Изображение на обложке: Скриншот: claude.com

Для разработчика главное в анонсе одно число: по таблице Google, на DeepSWE v1.1, бенчмарке долгих задач по программной инженерии, 3.8 Flash набирает 73,7% против 74,0% у Claude Opus 5, который стоит в 6,7 раза дороже на входе и в 6,7 раза дороже на выходе. Если замер подтвердится независимо, дешёвая модель Google становится кандидатом на роль основной модели для кодовых агентов. Все цифры ниже опубликованы Google: часть из них снята на внешних бенчмарках (DeepSWE ведёт Datacurve AI, CWE-Bench проводит Collinear), часть на внутренних наборах компании; ссылку на методику Google приводит, независимых результатов на момент публикации нет.

• Gemini 3.8 Flash доступна со 2 сентября в Gemini API, Google AI Studio, Android Studio, Antigravity и Stitch; подписчикам Google AI Pro и Ultra в приложении Gemini, AI Mode в поиске и Google Sheets.
• Цена $0,75 за 1 млн входных и $3,75 за 1 млн выходных токенов действует до 31 декабря 2026 года; с 1 января 2027 года Google обещает $1,50 и $7,50.
• По замерам Google: DeepSWE v1.1 73,7% (Opus 5 74,0%, GPT-5.6 Sol 72,7%, 3.7 Flash 65,3%), Terminal-Bench 2.1 89,4%, HLE-Verified 54,9%; на Terminal-Bench 4.0 всего 19,1% против 51,8% у Opus 5.
• Gemini 3.8 Flash Cyber на CyberGym показывает 86,2% pass@1 против 83,8% у Mythos 5 и 85,6% у GPT-5.5-Cyber; на CWE-Bench 47,2% при 47,8% у Claude Fable 5.
• Модель «работает усерднее»: делает больше шагов рассуждения и вызовов инструментов, поэтому тратит больше токенов; 3.7 Flash остаётся поддерживаемой для экономных сценариев.

Что изменилось по сравнению с 3.7 Flash

Gemini 3.7 Flash вышла три недели назад, и 3.8 Flash построена на той же скорости и цене. Прирост Google показывает на длинных агентных задачах. На DeepSWE v1.1 результат вырос с 65,3% до 73,7%, на Terminal-Bench 2.1, где агент решает задачи в терминале, с 85,8% до 89,4%. По этой таблице 3.8 Flash опережает GPT-5.6 Sol (72,7% и 88,8%) и почти сравнивается с Claude Opus 5 (74,0% и 89,1%).

На прикладных бенчмарках Google выделяет области, где 3.8 Flash обходит и более дорогие модели: Vals Finance Agent v2 (задачи финансового аналитика) 61,4% против 58,6% у Opus 5, Harvey's Legal Agent Benchmark (юридические сценарии) 10,0% против 6,7%, CharXiv Reasoning (выводы по сложным графикам) 86,2% против 83,7%. На HLE-Verified, наборе экспертных вопросов из разных дисциплин, модель набирает 54,9%, на уровне Opus 5 (54,4%) и GPT-5.6 Sol (54,5%).

Слабые места в той же таблице Google не скрывает. На Terminal-Bench 4.0, который проверяет общие агентные способности, 3.8 Flash набирает 19,1% против 51,8% у Opus 5 и 37,3% у GPT-5.6 Sol. На GDPVal-AA v2 (офисная работа, рейтинг Эло) у неё 1545 против 1824 у Opus 5 и 1710 у Sol, на OSWorld-2.0 (управление компьютером) 59,0% против 75,4%. Иначе говоря, модель сильна там, где задача формализована, и заметно отстаёт в открытых сценариях.

Google объясняет прирост тем, что 3.8 Flash «работает усерднее»: на сложных задачах делает больше шагов рассуждения и итеративно вызывает инструменты. Компания прямо предупреждает, что модель может потратить больше токенов, особенно на высоких уровнях усилия. Для задач, где главное ограничение стоимость, Google предлагает снижать уровень усилия или оставаться на 3.7 Flash, которая продолжает поддерживаться.

Цена прежняя, но с 2027 года удвоится

Вводная цена $0,75 за миллион входных токенов и $3,75 за миллион выходных совпадает с 3.7 Flash и действует до 31 декабря 2026 года. С 1 января 2027 года, по сноске в анонсе, вступает в силу регулярная цена: $1,50 и $7,50. Для сравнения, в той же таблице Google указывает $5,00 и $25,00 у Claude Opus 5, $2,00 и $10,00 у Claude Sonnet 5, $4,00 и $20,00 у GPT-5.6 Sol. Даже по регулярной цене 3.8 Flash останется дешевле Sonnet 5 на входе и выходе.

Модель доступна разработчикам через Gemini API в Google AI Studio и Android Studio, в агентной среде Antigravity и генераторе интерфейсов Stitch, корпоративным клиентам в Gemini Enterprise, подписчикам Google AI Pro и Ultra в приложении Gemini, AI Mode в поиске и Google Sheets. О региональных ограничениях и условиях оплаты в анонсе ничего не сказано.

Flash Cyber: поиск уязвимостей на уровне фронтира, но только по заявке

Вторая модель анонса, Gemini 3.8 Flash Cyber, построена на том же ядре, но с более мягкими ограничениями в области кибербезопасности. Именно поэтому Google не выкладывает её в общий API: доступ получают государственные органы, операторы критической инфраструктуры и мейнтейнеры ПО через программу Fairwind, заявку нужно подать отдельно. Google подчёркивает, что приоритетом было исправление уязвимостей, а не эксплуатация.

На CyberGym, отраслевом бенчмарке автономного поиска уязвимостей в коде на C и C++, 3.8 Flash Cyber набирает 86,2% pass@1. Предыдущая киберверсия 3.5 Flash Cyber давала 77,5%, GPT-5.6 Sol 83,6%, Anthropic Mythos 5 83,8%, GPT-5.5-Cyber 85,6%. На внутреннем наборе Google, где надо находить уязвимости в сложных кодовых базах на 20 языках программирования, доля успеха, по словам компании, превысила 70%; состав и размер этого набора не раскрыты.

За исправление отвечает внешний бенчмарк CWE-Bench от компании Collinear: 47,2% pass@1 у 3.8 Flash Cyber против 47,8% у Claude Fable 5, при этом, по графику Google, прогон Flash Cyber стоит около $3,6 против более $10 у Fable 5. Google приводит и три внутренних примера: команда безопасности Chrome получила от модели в 2,6 раза больше корректных патчей к уязвимостям Chrome, чем от «лучших коммерческих моделей», компания Wiz на своём наборе для пентеста увидела рост полноты на 7,5–9,7 процентных пункта при стоимости в 2,3–5,2 раза ниже, а команда Cloud Vulnerability Research нашла критическую уязвимость меньше чем за два часа. Ни одно из этих утверждений пока не проверено вне Google и партнёров.

Что делать разработчику

• Если вы уже используете 3.7 Flash в агентах для кода, попробуйте 3.8 Flash на своих задачах и сравните не только точность, но и расход токенов: Google предупреждает, что модель думает дольше.
• Считайте стоимость по регулярной цене $1,50 и $7,50: через четыре месяца именно она станет реальной.
• Для коротких и дешёвых запросов оставайтесь на 3.7 Flash или снижайте уровень усилия у 3.8, это рекомендация самой Google.
• Flash Cyber сейчас в общем API не представлена: если вам нужен поиск уязвимостей, ориентируйтесь на заявку в Fairwind или на обычную 3.8 Flash, которая, по словам Google, тоже обучалась на задачах кибербезопасности, но с ограничениями на наступательные сценарии.

Google публикует ссылки на методику замеров, но сравнения с конкурентами пока остаются её собственными; редакция вернётся к цифрам, когда появятся независимые результаты. Отдельный вопрос, ответа на который в анонсе нет: сколько токенов 3.8 Flash реально тратит на тех же задачах по сравнению с 3.7, ведь при удвоенной цене с января это определит, останется ли она самой выгодной.

Источники: Google: Introducing Gemini 3.8 Flash and 3.8 Flash Cyber, Google DeepMind: методика замеров Gemini 3.8 Flash, Google DeepMind: методика замеров Gemini 3.8 Flash Cyber

Изображение на обложке: Изображение: Google

Для разработчика это касается двух вещей сразу. Во-первых, ответы ИИ-поиска на вопрос «чем воспользоваться» строятся на слое, который можно наполнить за деньги и без единого человека-читателя: три сайта под одним шаблоном сгенерировали 215 128 страниц «best software» и называют себя в заголовке «Facts & Grounding Page», что Trellner читает как обращение прямо к алгоритму. Во-вторых, если вы делаете свой продукт с веб-поиском поверх LLM, отчёт показывает, как выглядит ваша будущая проблема с качеством источников.

• 760 запросов к perplexity/sonar и perplexity/sonar-pro через OpenRouter, 380 категорий ПО, 2 сентября 2026 года; 7 534 ссылки на 2 055 доменов.
• 59,8% ссылок ведут на домены хуже 100 000-го места в Tranco, 23,4% не входят в первый миллион; медианный ранг цитируемого домена 71 611.
• Третий по цитируемости источник после g2.com и reddit.com — блог guideflow.com, продавца интерактивных демо: 194 цитаты в 96 категориях, больше, чем у Gartner.
• wifitalents.com, worldmetrics.org и gitnux.org работают на одном шаблоне и одних NS-серверах Cloudflare и вместе держат 215 128 страниц /best/<категория>-software/.
• Оба уровня Perplexity вернули побайтово одинаковый список ссылок в 289 категориях из 380, то есть это один поисковый стек, а не два независимых замера.

Как проводили замер

Категории, от «CRM software» до «museum collection management software», написали до запуска и потом не меняли. Каждой из двух моделей, sonar и sonar-pro, задавали один запрос на категорию с просьбой вернуть топ-5 продуктов в JSON с официальным доменом каждого. Все 760 ответов распарсились. Обе модели отдают список URL, которые они подняли при поиске, именно поэтому выбрали их: у Gemini через OpenRouter поиск выполняет плагин самого OpenRouter, и цитаты описывали бы его, а не Google. Авторы подчёркивают, что измерен только Perplexity и выводов о ChatGPT, Gemini, Copilot или AI Mode Google из отчёта делать нельзя.

Дальше каждый из 2 055 цитируемых доменов проверили в списке Tranco за 1 сентября и в Wayback Machine, а каждый из 1 502 «официальных сайтов», которые назвали модели, открыли дважды: напрямую и через прокси.

Кто на самом деле отвечает на вопрос «что купить»

Верхушка списка выглядит ожидаемо: g2.com (291 цитата, 3,86%), reddit.com (261), guideflow.com (194), gartner.com (158), zapier.com (82), capterra.com (68), linkedin.com (67). Википедию модели процитировали три раза из 7 534. Концентрация невелика: десять самых цитируемых доменов дают 17,3% ссылок, а 751 домен из 2 055 (36,5%) не входит в первый миллион Tranco. Такие домены заметно моложе: медианный год первого снимка в Wayback у них 2020 против 2011 у ранжированных.

Самый показательный случай — guideflow.com. Это продавец интерактивных демо продуктов, который не участвует ни в одной из 380 категорий, но его блог процитирован 194 раза в 96 категориях, от «ПО для 3D-рендеринга» до «ПО для IVR». В сайтмапе блога 3 351 URL. Авторы отчёта не обвиняют компанию: она ведёт большой контент-маркетинговый блог, как тысячи других. Проблема в поисковом слое, для которого чужие подборки о рынках, где сам автор не работает, стали третьей по величине базой доказательств.

Три сайта, которые Trellner считает написанными для машин

wifitalents.com (71 цитата), worldmetrics.org (60) и gitnux.org (50) вместе дали 2,4% ссылок и попали в 41 категорию из 380. По данным Trellner, все три зарегистрированы через NameCheap между декабрём 2023 и маем 2024 года, делегированы одной паре NS-серверов Cloudflare, используют один шаблон с одинаковой навигацией и держат по блогу ровно из шести постов, причём все восемнадцать постов — о соседних брендах из той же группы и о четвёртом сайте zipdo.co. Авторы честно оговаривают: общие NS-серверы указывают на общий аккаунт Cloudflare, но не доказывают общего владельца.

Масштаб: в сайтмапах трёх сайтов 103 578, 107 083 и 105 541 URL, из них 70 731, 71 684 и 72 713 — страницы вида /best/<что-то>-software/. Итого 215 128 сгенерированных «гидов покупателя»; авторы отчёта замечают, что столько категорий ПО не существует. Заголовок главных страниц worldmetrics.org и gitnux.org на 2 сентября выглядит как «<бренд> — Facts & Grounding Page», а мета-описание обещает «машиночитаемую запись» о компании. Grounding — это название шага, на котором поисковая система подтягивает документы для ответа; покупатели таким словом не пользуются. Рядом worldmetrics.org продаёт заказные исследования «от 5 000 евро» и подбор вендора «от 2 500 евро».

Авторы открыли одну и ту же категорию, «ПО для оценки проектов», на всех трёх сайтах. Каждый ранжирует десять инструментов в JSON-LD, и первые места не совпадают: у worldmetrics.org и wifitalents.com лидирует Float, у gitnux.org — Saviom, которого у соседей в пятёрке нет. На каждой странице по три «автора» с именами, у всех «редакционный процесс», а gitnux.org подписывает результат «AI-verified, Expert reviewed». На всех трёх в строке автора остался неотрендеренный шаблонный текст «Within the next 26 days» или «40 days».

Куда ведут ссылки на «официальные сайты»

Большинство из 1 502 доменов вендоров живы. Десять не резолвятся вовсе, среди них graphiql.com (модель назвала его домом GraphiQL, у которого такого сайта нет), todo.com (за Microsoft To Do) и aquasecurity.io (за сканер Trivy). Ещё четыре резолвятся, но не отвечают; с учётом 404 недоступны 17 доменов, 1,1%. Ещё 92 домена (6,1%) перенаправляют на другой сайт, чаще всего из-за обычных поглощений и ребрендингов.

Два случая показательны. На вопрос о платформах для хранения научных данных обе модели назвали Dryad: sonar-pro дал настоящий datadryad.org, а sonar — dryad.co, который редиректит на индонезийский портал онлайн-казино. На вопрос об инструментах качества данных обе назвали Monte Carlo: sonar указал верный montecarlodata.com, а sonar-pro — montecarlo.com, сайт монакской группы отелей и казино.

Чего отчёт не показывает

Раздел ограничений у Trellner длиннее, чем у многих академических работ, и его стоит пересказать. Две модели не являются двумя независимыми замерами: в 289 категориях они вернули побайтово одинаковый список ссылок, коэффициент Жаккара их наборов URL равен 0,898, что, по выводу авторов, указывает на общий поисковый стек, опрошенный дважды. Категории составлены авторами, а не взяты из реальных запросов покупателей, и список со множеством нишевых вертикалей поднимает больше «длинного хвоста». Один прогон, одна формулировка, без повторов. Ранг Tranco — мера популярности, а не качества. И главное: авторы не проверяли, изменились бы рекомендации, если убрать эти источники; guideflow и три «лучших списка» могут называть вполне разумные продукты. Измерялся состав доказательной базы, а не правильность ответа.

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

Если вы выбираете библиотеку, сервис или инструмент через ИИ-поиск, просите его показать ссылки и смотрите на домены: подборка «топ-10» с сайта, о котором вы никогда не слышали, с тремя «авторами» и штампом «AI-verified», по весу равна нулю. Для проверки конкретного вендора надёжнее открыть его сайт по ссылке из документации или репозитория, а не по домену, который назвала модель: один «официальный сайт» из отчёта вёл на портал онлайн-казино, другой на сайт монакской группы отелей и казино.

Если вы строите продукт с веб-поиском поверх LLM, отчёт даёт готовый чек-лист фильтров для retrieval-слоя: рейтинг домена, дата первого появления в Wayback, количество страниц одного шаблона на сайте, совпадение NS-серверов у «независимых» источников, шаблонные строки в подписях. Весь датасет, включая каждую цитату, проверки Tranco и Wayback и скрипты, Trellner выложила под лицензией CC BY 4.0, так что замер можно повторить на другой поисковой системе или на своих категориях. Отчёт — снимок одного дня меняющегося индекса; сама компания оговаривает, что через месяц цифры могут быть другими.

Источники: Trellner: Manufactured sources behind AI recommendations, Данные и скрипты отчёта (CC BY 4.0)

Для тех, кто просто обновляет curl, ничего не меняется: все шесть находок имеют низкую серьёзность и уже исправлены в 8.22.0. Интересна сама ситуация: curl стоит, по оценке AISLE, более чем в 20 млрд установленных экземпляров, и это одна из самых проверенных кодовых баз в мире. AISLE подаёт результат как подтверждение своего тезиса «система важнее модели»: специализированная обвязка находит дыры там, где фронтирные модели уже остановились. Насколько сопоставимы были условия запуска, из материала не следует.

• 24 августа Стенберг написал, что к релизу готовы три CVE, а Mythos, Zeropath и Codex Security «больше ничего не находят».
• 25 августа он же опубликовал счёт «Mythos: 0 Aisle: 29»: AISLE прислала 29 отчётов.
• Шесть из них команда безопасности curl признала уязвимостями и выдала CVE; все шесть низкой серьёзности, исправлены в curl 8.22.0 от 2 сентября (всего в релизе девять CVE curl и одна в wcurl).
• К 28 августа число ожидающих CVE выросло с трёх до десяти; шесть из десяти — от AISLE.
• AISLE утверждает, что тот же эффект в ядре Linux заметил мейнтейнер стабильных веток Грег Кроа-Хартман; независимого подтверждения этой цитаты у редакции нет.

Как за четыре дня три CVE превратились в десять

Хронология собрана по публичным записям Стенберга в Mastodon. 24 августа он написал, что до релиза девять дней и объявлять предстоит всего три CVE (две низкой серьёзности, одна средней), добавив в скобках: «Mythos говорит, что больше ничего не находит. Zeropath не находит уязвимостей. Codex security показывает пустой список» (перевод редакции). Zeropath здесь — ещё один коммерческий ИИ-сканер кода.

По словам AISLE, после этой записи компания запустила свою систему на curl. 25 августа Стенберг опубликовал короткий пост: «Mythos: 0 Aisle: 29». Это число отчётов, а не подтверждённых уязвимостей: часть из 29 могла оказаться ложными срабатываниями или проблемами без последствий для безопасности, и решение принимала команда curl, а не AISLE. 28 августа Стенберг сообщил уже о десяти ожидающих CVE, одна из которых относится к обёртке wcurl.

В итоговом релизе 8.22.0, вышедшем 2 сентября, шесть из девяти CVE curl в таблице уязвимостей curl числятся за Станиславом Фортом из AISLE. По данным компании, три отчёта были отправлены 24 августа, два 26 августа и один 27 августа.

Что именно нашли: шесть дыр в узких конфигурациях

Все шесть находок оценены проектом как низкие по серьёзности. Они затрагивают не типичный вызов «скачать файл по HTTPS», а стыки между библиотекой и TLS-бэкендами, кэшами сертификатов и обработкой кук:

• CVE-2026-80229: use-after-free при работе с провайдерами OpenSSL; затронуты версии с 8.14.0 по 8.21.0.
• CVE-2026-80230: обход пиннинга сертификата в сборках с OpenSSL; версии с 7.45.0 по 8.21.0.
• CVE-2026-80231: повторное использование соединения при смене настройки системного хранилища сертификатов (CURLSSLOPT_NATIVE_CA) между запросами; версии с 7.71.0 по 8.21.0.
• CVE-2026-80255: обход атрибута secure у куки с помощью символа табуляции; версии с 8.13.0 по 8.21.0.
• CVE-2026-82208: в сборках с wolfSSL попадание в кэш CA перекрывало пользовательский callback проверки; версии с 8.9.1 по 8.21.0.
• CVE-2026-82209: кука, ограниченная доменом из публичного списка суффиксов, принималась не так, как должна; версии с 7.46.0 по 8.21.0.

Сама AISLE объясняет низкую серьёзность зрелостью curl: то, что в нём ещё осталось, прячется в редких сочетаниях опций и бэкендов, и практическое влияние таких дыр ограничено. Это честная оговорка, и её стоит помнить при чтении заголовка «6 : 0». В advisory проекта все шесть помечены как низкие; они закрываются обычным обновлением до 8.22.0, о котором Tproger писал ранее.

Почему это сравнение чище обычных бенчмарков

Обычно результаты ИИ-сканеров показывают на CTF-задачах или наборах с известными ответами, которые могли попасть в обучающие данные. Здесь всё иначе: анализировался живой продакшен-код, а признавали ли находку уязвимостью и давать ли ей CVE, решали мейнтейнеры curl. Базовая линия тоже была публичной и датированной заранее: «ноль» у Mythos и Codex Security Стенберг написал до того, как AISLE запустила свою проверку. AISLE прямо оговаривает, что CVE как метрика несовершенна, но для поиска нулевых дней это редкий случай внешней валидации: каждая CVE подтверждена экспертами и исправлена для реальных пользователей.

При этом источник заинтересованный: AISLE продаёт аудит кода и в конце своего же отчёта предлагает услугу AISLE Snapshot. Компания также приводит ответ Грега Кроа-Хартмана, мейнтейнера стабильных веток ядра Linux, на запись Стенберга: он якобы видит ту же картину для Linux и не понимает, что AISLE делает иначе. Редакция открыть эту запись на social.kernel.org не смогла, поэтому цитата остаётся утверждением AISLE.

Важно и то, чего в материале нет. AISLE не раскрывает, какие модели лежат в основе её системы и как устроен «харнесс» вокруг них; сам Стенберг 25 августа в ответе читателю написал, что, насколько он понимает, AISLE в основном строит обвязку вокруг существующих моделей, но экспертом себя не считает и видит только результаты. Неизвестно и то, сколько из 29 отчётов были отклонены и почему, а также запускались ли Mythos и Codex Security в сопоставимом режиме и с сопоставимым бюджетом. Стенберг с мая описывает опыт с Mythos на curl: модель находила уязвимости и раньше, так что «ноль» 24 августа означает не бесполезность модели, а исчерпание её находок к этому моменту.

Что делать читателю

Практическое действие одно: обновить curl и libcurl до 8.22.0 там, где вы собираете их сами, и дождаться пакетов дистрибутивов там, где не собираете. Проверить версию и TLS-бэкенд можно командой curl --version: первая строка покажет номер версии и библиотеку (OpenSSL, wolfSSL, GnuTLS), от которой зависит, касаются ли вас три из шести описанных дыр.

Для тех, кто отвечает за безопасность собственного кода, вывод шире. Если три известных ИИ-сканера на тот момент не показывали в проекте новых уязвимостей, а четвёртый нашёл в нём шесть подтверждённых, отчёт «уязвимостей не найдено» от любого одного инструмента стоит читать буквально: этот инструмент ничего не нашёл. Цифры AISLE стоит перепроверить на следующих релизах curl и других проектах, где базовая линия тоже публична; редакция будет следить за таблицей CVE curl и за тем, подтвердит ли Кроа-Хартман сказанное о ядре.

Источники: AISLE: AISLE Discovered Six curl CVEs After OpenAI and Anthropic Found Zero, Дэниел Стенберг, 24 августа: три CVE в ожидании, Дэниел Стенберг, 25 августа: «Mythos: 0 Aisle: 29», curl: уязвимости, закрытые в 8.22.0, Дэниел Стенберг: Mythos finds a curl vulnerability (май 2026)

Главный пример месяца — MiniMax H3. Модель на 33 млрд параметров генерирует ролики длительностью от 4 до 15 секунд сразу со стереозвуком и речью на 11 языках, включая русский. За месяц вокруг неё появились WanGP для домашних видеокарт, нативный движок под Apple Silicon, две турбо-LoRA, сборка для ComfyUI и дистиллят FastH3. Параллельно LTX-2.5 показала серверную генерацию быстрее реального времени, а Music3, Qwen3-ASR и Breeze TTS 2 расширили локальный набор для звука.

• По анонсу Lightricks, пересказанному Нейроканалом 17 августа, LTX-2.5 создаёт 10 секунд видео в 720p за 6,8 секунды на двух GB200; это замер вендора на серверном железе.
• MiniMax H3 запускается через WanGP с заявленным расходом 5–6 ГБ видеопамяти для 5 секунд и 8–9 ГБ для 15 секунд в 832 на 480, но требует минимум 24 ГБ оперативной памяти.
• Турбо-LoRA для H3 сокращают генерацию с 20 шагов до 4–8; FastH3 тоже работает за 4 прохода, при этом сложное движение уступает оригиналу.
• Qwen3-ASR-1.7B показывает WER 5,99% на FLEURS и 8,28% на CommonVoice по русскому в техническом отчёте Qwen; младшая 0.6B ошибается чаще.
• Коммерческие условия различаются: LTX-2.5 свободна до $10 млн годовой выручки, Music3 — до $20 млн с показом имени модели, Breeze TTS 2 разрешает только некоммерческое использование.

Видео перешло от облака к нескольким локальным маршрутам

У MiniMax H3 два режима. FL2VA строит видео со звуком из текста, стартового и финального кадров и умеет продлевать ролик окнами. Ref2VA переносит внешность, стиль, движение или голос из референсов. Для полной версии на 33 млрд и сокращённой на 20 млрд WanGP 12.41 загружает веса и кванты int8, GGUF и NVFP4.

Заявленные 5–6 ГБ видеопамяти для 5-секундного ролика и 8–9 ГБ для 15-секундного опираются на выгрузку весов в RAM. Библиотеке mmgp нужно минимум 24 ГБ оперативной памяти, рекомендуется 48 ГБ, а Windows добавляет ещё 16 ГБ. Поддерживаются NVIDIA от GTX 10XX и AMD на RDNA 2–4. Сборка Pinokio даёт запуск в один клик.

В независимом замере SD_Tutorial RTX 3060 с 12 ГБ VRAM, 32 ГБ RAM и NVMe считала 5 секунд видео в 480p почти 9 минут при 20 шагах. Тест шёл в ComfyUI, поэтому результат нельзя переносить на WanGP, другие разрешения и карты.

По анонсу Lightricks, пересказанному Нейроканалом 17 августа, 10 секунд ролика в 720p генерируются за 6,8 секунды на двух GB200.

Четыре шага ускоряют H3 ценой деталей движения

В начале августа обычная H3 требовала 15–20 шагов. По обзору трендов Hugging Face от 10 августа, затем появились две независимые турбо-LoRA: lightx2v называет рабочими 4 шага в 768p и 8 шагов в 544p, а larryvrh — диапазон 4–8 шагов. У превью lightx2v отмечалась потеря детализации.

Ещё один маршрут — FastH3 4-step от FastVideo. Это дистиллят H3, которому нужно четыре прохода трансформера. Авторы обучали его без примеров, через DMD2-дистилляцию с разреженным вниманием. В посты «Нейроканала»е нет сопоставимого времени генерации в секундах, поэтому обещание «в разы быстрее» остаётся заявлением проекта, а указанное ухудшение сложного движения — практической оговоркой.

По данным FastVideo, сложное движение пока хуже оригинала, зато генерация идёт быстрее.

По обзору трендов Hugging Face от 10 августа, Comfy-Org переупаковала веса для ComfyUI: int8 и fp8 занимают 21 ГБ против 66 ГБ в bf16, а Kijai тестирует вариант на 12 ГБ и декодирование примерно в 1,5 раза быстрее. По обзору трендов Hugging Face от 17 августа, к этой дате сборка Comfy-Org превысила 14 млн загрузок; это загрузки репозитория, а не число пользователей.

Для Apple Silicon Сальваторе Санфилиппо, автор Redis, пишет h3-metal на C и Metal. Движок держит модель и декодер в памяти, показывает промежуточные кадры и принимает первый, последний и референсные кадры. Стартовый пресет считает 11 новых шагов из 20 и 45 из 50 блоков трансформера.

LTX-2.5 обогнала реальное время на серверном железе

LTX-2.5 от Lightricks — открытая видеомодель со звуком на 22 млрд параметров. По анонсу Lightricks, пересказанному Нейроканалом 17 августа, она создаёт 10 секунд 720p за 6,8 секунды на двух GB200. Результат относится к двум серверным ускорителям. В том же посте для локального запуска указано минимум 16 ГБ VRAM.

Модель сохраняет персонажа и голос между кадрами, подбирает длину клипа под действие и отдаёт 4K HDR. Есть полная и дистиллированная версии. Веса размещены за гейтом Hugging Face. По данным поста Нейроканала от 17 августа, лицензия разрешает свободное использование компаниям с годовой выручкой до $10 млн без обязательного брендинга.

Для облачного прототипа в постах «Нейроканала» есть Seedance 2.0 Mini. Она делает ролики от 4 до 15 секунд в 480p и 720p со звуком, принимает картинки, видео и аудио как референсы и позволяет задать первый и последний кадр. Цена начинается с $0,0134 за секунду видео с указанной скидкой 60%; весов нет, доступ только через API.

FLUX Video Upscale увеличивает видео в 1,5–3 раза, вплоть до 4K. Точный режим восстанавливает детали, креативный дорисовывает текстуры. По посту Нейроканала от 21 августа, в OpenRouter тариф начинается от $0,075 за мегапиксель-секунду в точном режиме, креативный стоил $0,105. Единица учитывает площадь кадра и длительность, поэтому с тарифом Seedance за секунду она напрямую не сравнивается.

Music3 открыла полную песню, но ограничила коммерческий порог

MiniMax открыла веса Music3, которая генерирует песню длительностью до 5 минут: куплеты, припевы и один голос сохраняются по всей структуре. На вход подаются слова с тегами Verse и Chorus и обычное текстовое описание жанра, темпа, тональности, вокала, инструментов и развития аранжировки. На выходе получается стерео WAV 32 кГц; примеры опубликованы отдельно.

Глобальная модель на 8 млрд параметров держит структуру песни, локальная на 0,6 млрд добавляет акустические детали, а Flow Matching на 2,4 млрд и Flow-VAE собирают звук. Полная точность занимает 24 ГБ VRAM, с выгрузкой слоёв хватает 8 ГБ, но требуется CUDA.

Полная точность Music3 занимает 24 ГБ видеопамяти, с выгрузкой слоёв в оперативную память хватает 8 ГБ.

Пайплайны есть для SGLang-Omni, ComfyUI и diffusers; интеграция diffusers на момент поста ставилась из незамерженного pull request. По данным поста Нейроканала от 13 августа, лицензия разрешает коммерцию компаниям с выручкой до $20 млн и требует имя модели в интерфейсе.

Речь разделилась на синтез, распознавание и живой диалог

Breeze TTS 2 синтезирует речь в реальном времени. Голос клонируется по образцу или задаётся словами, смех и вздохи — тегами. Для eager-режима нужно 12 ГБ VRAM; меньше 40 мс до первого звука на H100 заявлено для прогретого fast path, которому рекомендовано 24 ГБ. По обзору трендов Hugging Face от 31 августа, в Artificial Analysis модель была первой среди открытых TTS, но балла и методики в открытых источниках нет. Языки — английский и китайский; по тому же посту лицензия некоммерческая.

У Breeze TTS 2 eager-режим требует 12 ГБ VRAM, а для прогретого fast path на H100 с задержкой меньше 40 мс рекомендовано 24 ГБ.

VoiceChat-11B объединяет слушание и ответ в одной модели. Она допускает перебивание, вызывает инструменты и заполняет паузу. Задержка — около 450 мс; язык только английский, статус исследовательский.

VoiceChat-11B слушает и говорит одновременно, его можно перебить на полуслове; заявленная задержка — около 450 мс.

PhoneLLM выбирает момент вызова инструмента и подтверждает действие после выполнения. Это файнтюн Nemotron 3 Nano на 30 млрд параметров при 3,5 млрд активных. Авторы заявляют уровень GPT 5.6 Terra, цену на 94% ниже и ответ на 1,3 секунды быстрее; абсолютной цены и состава теста в открытых источниках нет. Лицензия BSD, язык английский.

s1-mini чистит результат ASR: убирает слова-паразиты и самоисправления, расставляет пунктуацию, записывает числа и адреса. Авторы дают 94,8% точности по токенам на 7519 английских примерах. GGUF весит меньше 0,5 ГБ и работает на CPU; русского нет.

Авторы s1-mini заявляют точность 94,8% по токенам на 7519 английских примерах.

Русский ASR уже локален, но цифры принадлежат Qwen

Открытые Qwen3-ASR на 0,6 и 1,7 млрд параметров доступны под Apache 2.0. Они распознают 30 языков и 22 китайских диалекта, автоматически определяют язык, работают в потоке и офлайн, принимают до 20 минут аудио и разбирают пение и речь поверх музыки. Русский входит в список. По посту Нейроканала от 14 августа, на 14 августа минута через OpenRouter стоила $0,00018 для версии 0.6B и $0,00048 для 1.7B.

По русскому технический отчёт Qwen даёт для 1.7B WER 5,99% на FLEURS и 8,28% на CommonVoice. У 0.6B — 9,91% и 14,07%. Закрытая Qwen3-ASR-Flash показывает 4,81% и 5,73%. WER — доля ошибок в словах, поэтому меньшее значение лучше. Это замеры Qwen; прямого русского сравнения с Whisper в отчёте нет. На общей таблице по 30 языкам Whisper large-v3 опережает 1.7B: 8,16 против 12,60, но эта база не отвечает на вопрос о русском.

На одной видеокарте 1.7B обрабатывает около 67 минут аудио за минуту, 0.6B — около 108; на 128 потоках счёт идёт на тысячи. Созвоны с терминами лучше отдавать старшей модели и проверять человеком.

Картинки стали входом для видео и объектом апскейла

В августовской выборке картинки выступают управляющим входом. MiniMax H3 переносит из референсов внешность, стиль, движение и голос и строит переход между крайними кадрами. Seedance 2.0 Mini принимает картинки, видео и аудио, а h3-metal понимает ссылки на референсы по номерам.

FLUX Video Upscale работает после генерации: увеличивает разрешение и восстанавливает или дорисовывает детали по промпту. Для бюджета нужны площадь кадра в мегапикселях и длительность; без них тариф за мегапиксель-секунду не переводится в цену клипа.

Выбор зависит от железа, языка и права на коммерцию

• Для локального видео со звуком и русской речью: MiniMax H3 через WanGP; закладывайте минимум 24 ГБ RAM, проверяйте скорость на своём GPU и начинайте с короткого ролика.
• Для серверного видео быстрее реального времени: LTX-2.5 на мощном железе; опубликованные 6,8 секунды относятся к двум GB200, а коммерческий порог лицензии — $10 млн годовой выручки.
• Для быстрого API-прототипа с референсами: Seedance 2.0 Mini от $0,0134 за секунду со скидкой 60%; веса не опубликованы.
• Для полной песни локально: Music3 на CUDA; 24 ГБ VRAM для полной точности или 8 ГБ с выгрузкой, коммерческий порог $20 млн и обязательное имя модели в интерфейсе.
• Для русского распознавания: Qwen3-ASR-1.7B точнее младшей 0.6B в двух русских наборах; Apache 2.0 позволяет собственный сервер, API тарифицируется по минутам.
• Для английского голосового интерфейса: Breeze TTS 2 синтезирует речь, VoiceChat-11B ведёт прерываемый диалог, PhoneLLM управляет инструментами, s1-mini чистит готовую расшифровку; ограничения языка и лицензии у них разные.

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

Источники: MiniMax H3, WanGP с поддержкой MiniMax H3, Pinokio: запуск MiniMax H3 в один клик, Независимый замер MiniMax H3 на RTX 3060, h3-metal, MiniMax H3 Turbo LoRA от lightx2v, MiniMax H3 Turbo LoRA от larryvrh, MiniMax H3 для ComfyUI, Экспериментальные сборки MiniMax H3 от Kijai, FastH3 4-step Preview, LTX-2.5, Seedance 2.0 Mini в OpenRouter, FLUX Video Upscale, FLUX Video Upscale в OpenRouter, MiniMax Music3, Демонстрация MiniMax Music3, Breeze TTS 2, PhoneLLM, NVIDIA VoiceChat-11B, s1-mini, Qwen3-ASR-1.7B, Qwen3-ASR-1.7B в OpenRouter, Обзор трендов Hugging Face от 10 августа, Пост Нейроканала о Music3 от 13 августа, Пост Нейроканала о Qwen3-ASR от 14 августа, Обзор трендов Hugging Face от 17 августа, Пост Нейроканала о FLUX Video Upscale от 21 августа, Обзор трендов Hugging Face от 31 августа

Изображение на обложке: Tproger

Поэтому выбирать модель в сентябре стоит по трём координатам: доля решённых задач в сопоставимом бенчмарке, расход токенов на попытку и итоговая стоимость успешной задачи. Этот подход быстро отделяет быстрые модели для ежедневных правок от дорогих моделей для финального ревью и локальных вариантов, где деньги заменяются требованиями к памяти и времени.

• В независимом срезе Artificial Analysis GLM-5.3-Flash получила 57 баллов при $0,09 за задачу индекса; Opus 5 — 63 балла при $2,34.
• В замере Z.ai GLM-5.3 решила 31,4% задач примерно за 50 тыс. выходных токенов, Opus 4.8 — 29,5% за 120 тыс.; это цифры вендора.
• Terminal-Bench 2.1 даёт от 24,6% у Nemotron 3.5 Lightning до 87,9% у DeepSeek V4 Pro 0813, но результаты получены разными командами и харнессами.
• Qwen3.8-27B помещается в 17 ГБ в Q4, однако по срезу Artificial Analysis на 19 августа она потратила 160 млн токенов при медиане 43 млн.
• Junie Local бесплатна и без лимитов; для загрузки нужно около 20 ГБ. По данным поста «Нейроканала» от 27 августа, на старте нужны macOS 26, Mac с M5 и 64 ГБ памяти.

Один номер бенчмарка ещё не делает результаты сопоставимыми

Terminal-Bench проверяет работу агента в терминале: нужно пользоваться инструментами и довести окружение до проверяемого состояния. SWE-bench даёт репозиторий и issue, после патча запускает тесты. Названия похожи на обычные тесты модели, хотя результат зависит от связки модель + харнесс + уровень рассуждений + лимит токенов. Смена Claude Code на другую обвязку способна изменить итог без смены весов.

Именно так DeepSeek описывает собственную агентную обвязку: она отвечает за инструменты, чтение и запись файлов, терминал, контекст и разбор ошибок. Формула из вакансий команды короткая.

Model + harness = agent.

Отсюда первое правило чтения лидерборда: сравнивать строки можно только при совпадающих версии набора, харнессе, лимите и режиме. В посты «Нейроканала»е есть много результатов Terminal-Bench 2.1, но их публиковали DeepSeek, Ornith AI и Artificial Analysis. Общая диаграмма показывает диапазон заявленных значений, а не турнирную таблицу.

У DeepSeek V4 Pro 0813 указано 87,9% против 82,7% у V4 Flash 0731. Ornith AI приводит 86,1% для своего флагмана на 397 млрд параметров и 85,0% для Opus 4.8. Artificial Analysis отдельно измерила 84,3% у GLM-5.3-Flash, 83,9% у GLM-5.3 и 80% у Muse Spark 1.2. У компактной Nemotron 3.5 Lightning в Terminal-Bench 2.1 получилось 24,58% против 8,29% у прошлой Nano. Последняя пара говорит о прогрессе внутри семейства, сравнение 24,6% и 87,9% без общего прогона почти ничего не говорит о выборе провайдера.

SWE-bench измеряет патч, но может награждать память модели

В SWE-bench Verified используются проверенные задачи из открытых проектов. В SWE-bench Pro набор другой и сложнее, поэтому проценты между версиями переносить нельзя. Ornith AI сообщает 79,0% у Ornith-1.5-35B-A3B против 73,4% у Qwen3.6-35B-A3B. Это один вендорский прогон внутри Verified.

Qwen в техническом отчёте для Qwen3.8-Flash-Next публикует 62,5% на SWE-bench Pro против 53,4% у Opus 4.6 Max. Здесь обе модели прошли таблицу одного вендора, но это всё равно замер заинтересованной стороны. Независимого повторения этих чисел в открытых источниках нет.

Есть и более неприятное ограничение. Авторы работы о запоминании SWE-bench переименовали идентификаторы, переставили ветки условий, переписали циклы и добавили мёртвый код, сохранив семантику и баг. Изменилось около 7% строк. Claude Opus 4.5 под mini-SWE решила 90,2 задачи из ста на исходном SWE-bench Pro и 83,5 на изменённом. Разница показывает вклад знакомого вида репозитория, поэтому высокий процент стоит подтверждать на свежих внутренних issue.

Вердикт по бенчмарку: сначала версия и харнесс, затем процент. Результат вендора годится для отбора кандидатов; закупку и смену основной модели лучше подтверждать на закрытых задачах команды.

Расход токенов превращает процент успеха в цену задачи

Самая полезная цифра месяца пришла из анонса GLM-5.3. На high reasoning модель решила 31,4% задач примерно за 50 тыс. выходных токенов. Opus 4.8 в той же таблице решила 29,5% за 120 тыс. токенов, Fable 5 — 39,5%, но расход Fable в анонсах не указан. Это замер Z.ai, поэтому он показывает заявленную экономичность GLM и требует независимой проверки.

Цена успешной задачи считается так: стоимость всех входных и выходных токенов, кэша и повторных попыток делится на число принятых решений. Тариф за миллион токенов без расхода на попытку отвечает только на половину вопроса. Модель с дешёвой выдачей может долго перечитывать код, ходить кругами и четыре раза запускать один тест; дорогая модель иногда закрывает issue с первой попытки.

Qwen3.8-27B показывает риск многословия. Artificial Analysis измерила 52 балла Intelligence Index, но по срезу Artificial Analysis на 19 августа полный прогон потребовал 160 млн токенов при медиане 43 млн. Почти четырёхкратный расход превращается в деньги в API и во время при локальном запуске. По срезу Artificial Analysis на 26 августа GLM-5.3-Flash прошла индекс за 150 млн токенов при медиане 64 млн, хотя низкая цена сохранила итоговую стоимость задачи.

В срезе Artificial Analysis от 26 августа GLM-5.3-Flash получила 57 баллов при $0,09 за задачу индекса. DeepSeek V4 Flash 0731 — 52 балла при $0,11, GLM-5.3 — 60 при $0,68, GPT-5.6 Sol — 61 при $0,96, Opus 5 — 63 при $2,34. Разница между Flash и Opus составляет 6 баллов и $2,25 на задачу этого индекса. Эти деньги нельзя автоматически переносить на ваш репозиторий, зато график хорошо показывает Парето-фронт: где дополнительный балл начинает стоить всё дороже.

Реальные агентные сессии дают вторую проверку. Agent Arena собрала больше 9 тыс. сессий: GLM-5.3-Flash заняла четвёртое место среди открытых моделей и 19-е в общем зачёте, а медианная задача стоила $0,12. Модель попала на линию Парето между DeepSeek V4 и GPT-5.6 Luna. У этого замера есть преимущество перед синтетическим набором: пользователи приносили настоящие задачи. Его слабое место — разный состав задач у моделей.

Локальный кодинг убирает счёт, но добавляет требования к железу

JetBrains выпустила Junie Local: команда /local скачивает Qwen3.6-27B в 4 битах, поднимает OpenAI-совместимый сервер и переключает агента на него. Для загрузки нужно около 20 ГБ. По данным поста «Нейроканала» от 27 августа, на старте поддерживаются macOS 26, Mac с M5 и 64 ГБ памяти, сама команда находится в nightly-сборках. Цена запросов равна $0, лимитов и регистрации нет, но стоимость машины и ожидания остаётся у владельца.

По внутреннему набору JetBrains Qwen3.6-27B без reasoning идёт наравне с Sonnet 4.5 при лимите 10 тыс. токенов рассуждений; GPT-5 на medium немного выше. JetBrains отключила reasoning у локальной модели: он почти не добавлял качества и увеличивал расход токенов в 2–3 раза. По данным поста «Нейроканала» от 27 августа, Qwen3.8 требует рассуждений, с которыми задачи идут в 4 раза медленнее.

Открытая Qwen3.8-27B в Q4 занимает 17 ГБ и помещается на одной игровой видеокарте. Она понимает изображения и видео, держит 262 тыс. токенов контекста и распространяется под Apache 2.0. Её преимущество — локальность; независимый замер многословия выше показывает, что скорость и энергопотребление надо измерить до перевода команды.

GLM-5.3-Flash тоже можно запускать дома, но класс железа другой. Кванты Unsloth занимают 93 ГБ в 1 бите и сохраняют 71% точности, 120 ГБ в 3 битах дают 82%, 200 ГБ в 4 битах — 93%. Полная BF16-модель занимает 642 ГБ. Для индивидуальной станции практичнее Qwen 27B; GLM-5.3-Flash локально имеет смысл там, где уже есть от 100 ГБ общей RAM и VRAM.

Tencent в анонсе Hy4 preview прямо указывает происхождение архитектурных идей. Это полезное напоминание: открытые веса дают выбор харнесса и сервера, а качество всё чаще складывается из общих приёмов.

Inspired by DeepSeek and GLM.

Подписка скрывает цену задачи за окнами и коэффициентами

У GLM Coding Plan новая Flash списывает лимит втрое медленнее GLM-5.3, а работа через ZCode даёт ещё коэффициент 1,5. Z.ai 1 сентября выдала действующим подписчикам Reset Card, которая один раз восстанавливает недельную и пятичасовую квоту. Точной цены тарифа в открытых источниках нет, поэтому сравнить подписку с API в долларах за принятую задачу нельзя.

У Codex лимиты менялись и сбрасывались несколько раз. 25 августа глава Codex Тибо Соттио подтвердил очередной сброс только после вопроса пользователя. Для производственного планирования такая динамика означает одно: подписка удобна для интерактивной работы, API-счётчик прозрачнее для пакетных прогонов.

Ah yeah, forgot to say.

К 25 млн активных пользователей OpenAI снова сбросила лимиты, а Соттио в шутку назвал компанию по её самому заметному действию. Шутка точно описывает риск сравнения подписок по названию плана: доступный объём меняется быстрее прайс-листа API.

The Reset Company.

У Claude Max план за $200 даёт примерно в 1,5–2 раза больше недельного лимита, чем Max 5x за $100, по разбору пользователей из постов «Нейроканала». Anthropic объявила постоянное повышение недельных лимитов на 25% с 14 сентября, но до 13 сентября действует временная надбавка 50%; после перехода доступный объём снизится примерно на 17%. Это хороший пример, почему слово «больше» без базы сравнения мешает считать стоимость задачи.

Модель стоит назначать по типу работы

• Быстрые правки и ежедневный поток. Начните с GLM-5.3-Flash: независимые замеры дают $0,09 за задачу индекса, Agent Arena — медиану $0,12 за реальную сессию. Для веб-разработки отдельный замер Arena поставил Flash на линию Парето.
• Долгие агентные задачи. Сравните GLM-5.3 и DeepSeek V4 Pro 0813 на своём харнессе. У GLM есть вендорское преимущество по выходным токенам, у DeepSeek опубликовано 87,9% на Terminal-Bench 2.1 и контекст 1 млн токенов. Смешивать эти цифры в один рейтинг нельзя.
• Финальное ревью сложного патча. По нашей оценке, Opus 5 разумно оставить эскалацией: в срезе Artificial Analysis он дал 63 балла против 57 у GLM-5.3-Flash, но стоил $2,34 против $0,09 за задачу индекса. Платить разницу на каждой мелкой правке невыгодно.
• Фронтенд и макеты. GLM-5.3-Flash подтверждена независимым Парето-замером по веб-разработке. По данным поста «Нейроканала» от 13 августа, Gemini 3.7 Flash получила 1588 Elo в Code Arena против 1541 у Sonnet 5 и 1523 у GPT-5.6 Terra, а OpenCode отметил перенос макетов Figma в код. Через Flex-маршрут OpenRouter она стоила $0,375/$1,875, стандартный тариф составлял $0,75/$3,75.
• Локальный и приватный код. Junie Local с Qwen3.6-27B даёт готовый путь на M5 с 64 ГБ памяти. Qwen3.8-27B в Q4 занимает 17 ГБ, но требует отдельного замера скорости и многословия. GLM-5.3-Flash начинается примерно со 100 ГБ общей памяти даже в самом жёстком кванте.

Qwen обновила Qwen3.8-Max-0902 2 сентября: кодовые прогоны шли в Claude Code, цена составляет $2 за млн входных и $6 за выходные токены. Компания сообщает почти трёхкратный рост в терминальных задачах и около 13 пунктов в агентных правках репозиториев, но абсолютные числа в анонсах не приведены. Для закупки этой модели нужен независимый прогон с фиксированным харнессом.

Claude Fable 5.1 вышла 1 сентября с ценами $10 за млн входных и $50 за выходные токены. Anthropic сообщает большой отрыв в терминальном кодинге и агентном научном коде, а чтение кэша подешевело до $0,25. Точных баллов этих кодовых тестов в анонсах нет, поэтому модель остаётся кандидатом для внутреннего прогона, а не победителем обзора.

Свой замер должен считать принятый патч

1. Соберите закрытый набор реальных issue, которые модель не могла видеть в открытом репозитории. Оставьте одинаковые контейнер, тесты и права на инструменты.
2. Зафиксируйте модель, дату чекпоинта, харнесс и его версию, уровень рассуждений, размер контекста и лимит выходных токенов.
3. Записывайте входные и выходные токены, попадания в кэш, число ходов, вызовы инструментов, повторные попытки и время до зелёной проверки.
4. Считайте успех только после тестов и ревью человеком. Делите полный счёт провайдера на число принятых патчей, отдельно отмечайте задачи, где агент остановился или повредил соседний код.
5. Повторите часть задач после механического переименования идентификаторов и перестройки эквивалентных конструкций. Просадка покажет, насколько результат держался на знакомом виде кода.

Минимальная таблица команды: задача, модель, харнесс, режим, решено или нет, входные токены, выходные токены, число ходов, время, стоимость, принят ли патч после ревью. Этого достаточно, чтобы увидеть собственный Парето-фронт.

Сентябрьский рынок уже не сводится к одной старшей модели. GLM-5.3-Flash выигрывает экономикой в независимых срезах, Opus 5 сохраняет небольшой запас общего качества по высокой цене, DeepSeek и Qwen дают сильные открытые варианты, а Junie Local превращает локальный запуск в готовый режим IDE. Следующий полезный сигнал — общий прогон свежих моделей на одной версии Terminal-Bench, одном харнессе и с опубликованным расходом токенов. Без него честный ответ остаётся прикладным: лучшая модель та, у которой дешевле принятый патч на ваших задачах.

Источники: GLM-5.3: официальный анонс Z.ai, GLM-5.3-Flash: официальный анонс Z.ai, Artificial Analysis: GLM-5.3-Flash, Artificial Analysis: лидерборд моделей, Agent Arena: результаты GLM-5.3-Flash, Qwen3.8-Max-0902: анонс Qwen, Qwen3.8-Flash-Next: карточка модели, Qwen3.8-Flash-Next: технический отчёт, Qwen3.8-27B: карточка модели, Hy4 preview: анонс Tencent Hunyuan, DeepSeek V4 Pro 0813: карточка модели, DeepSeek API: цены, Ornith 1.5: отчёт о моделях, Muse Spark 1.2 и Muse Code: анонс разработчика, Junie Local: анонс JetBrains, Проверка SWE-bench на изменённом коде, GLM-5.3-Flash: кванты и локальный запуск Unsloth, Claude Fable 5.1 и Mythos 5.1: анонс Anthropic, DeepSeek: набор авторов агентных проектов, Codex: сброс лимитов 25 августа, Qwen3.8-27B GGUF от Unsloth, «Нейроканал»: Junie Local, Z.ai: Reset Card для GLM Coding Plan, Anthropic: изменение недельных лимитов Claude Max, «Нейроканал»: Gemini 3.7 Flash, Nemotron 3.5 Lightning на Hugging Face

Изображение на обложке: Tproger

Для программиста это меняет выбор инструмента. Кодовую модель можно держать рядом с репозиторием и не отправлять исходники наружу; компактную модель для инструментов можно запустить на ноутбуке; флагман с сотнями миллиардов параметров по-прежнему требует рабочей станции или сервера. Ниже разбираемся, где проходит эта граница, какие цифры измерили независимо, а какие сообщили сами вендоры.

• Qwen3.8-27B набрала 52 балла Artificial Analysis Intelligence Index при медиане 9 баллов среди моделей размером от 4 до 40 млрд параметров; Q4 занимает 17 ГБ.
• GLM-5.3 получила 60 баллов того же независимого индекса, GLM-5.3-Flash — 57, DeepSeek V4 Pro 0813 — 53, DeepSeek V4 Flash 0731 — 52.
• Unsloth сжал GLM-5.3-Flash с 642 ГБ в BF16 до 93 ГБ в 1-битном варианте; 3-битная сборка занимает 120 ГБ, 4-битная — 200 ГБ.
• По срезу Hugging Face на 31 августа GGUF-сборку Qwen3.8-27B от Unsloth скачали больше 9 млн раз, оригинал — 4,7 млн, расцензуренные сборки суммарно — 2,4 млн.
• Для коммерческого продукта проще всего читать лицензии Apache 2.0 и MIT; у GLM-5.3, Qwen3.8-2.4T и Qwen3.8-Flash-Next действуют собственные условия.

Открытые веса добрались до уровня недавнего фронтира

Самый показательный релиз месяца — плотная Qwen3.8-27B на 27 млрд параметров. Alibaba выложила веса 14 августа по времени США, 15 августа по Москве под Apache 2.0: модель принимает текст и изображения, в описании релиза также заявлено понимание видео, а контекст составляет 262 тысячи токенов с растяжкой до миллиона. По бенчмаркам самой Qwen она сопоставима с Opus 4.6 Max в агентных задачах, но это замеры вендора, часть наборов внутренние, а кодовые прогоны шли в Claude Code.

Через четыре дня появилась независимая точка отсчёта. Artificial Analysis измерила у Qwen3.8-27B 52 балла Intelligence Index. В классе от 4 до 40 млрд параметров это первое место при медиане 9 баллов. Цена результата — многословность: по срезу Artificial Analysis на 19 августа весь прогон потребовал 160 млн токенов при медиане 43 млн для класса, почти в 4 раза больше. Для локального запуска это прежде всего время и энергия, а в платном API — прямые расходы.

В обзоре трендов автор «Нейроканала» сформулировал сдвиг через домашнее железо.

Как отмечал «Нейроканал», на одной карточке можно получить SOTA-уровень, который вот совсем недавно считался фронтиром, лучшим в мире.

Старшая Qwen3.8-2.4T-A95B показывает другой край шкалы: 2,4 трлн параметров, 95 млрд активных на токен, 213 файлов с весами, только текст и обязательные рассуждения. По таблице Qwen, GPQA Diamond у неё 92,6 против 92,0 у Opus 4.8. Это снова замер вендора. Лицензия собственная, поэтому модель нельзя автоматически считать столь же простой для коммерции, как Apache 2.0.

GLM-5.3 пришла к сходному уровню другим путём. Z.ai дообучила прежнюю MoE-базу GLM-5.2 на длинных инженерных задачах, не повторяя претрейн. Всего у модели 743 млрд параметров и контекст миллион токенов. По внутреннему набору компании кодинг вырос на 50%; на высоком уровне рассуждений GLM-5.3 решила 31,4% задач примерно за 50 тысяч выходных токенов, Opus 4.8 — 29,5% за 120 тысяч, Fable 5 — 39,5%. Это замеры Z.ai, полезные как описание режима, а не независимый рейтинг.

Независимый Intelligence Index поставил GLM-5.3 на 60 баллов. Облегчённая мультимодальная GLM-5.3-Flash с 18 млрд активных из 320 получила 57 баллов, DeepSeek V4 Pro 0813 — 53, DeepSeek V4 Flash 0731 — 52. По срезу Artificial Analysis на 26 августа Flash прошла индекс за 150 млн токенов при медиане 64 млн, поэтому её низкая цена за задачу $0,09 уже учитывает болтливость. У старшей GLM одна задача стоила $0,68, у DeepSeek V4 Flash — $0,11.

DeepSeek открыла веса V4 Pro 0813 вскоре после API-релиза: около 1,8 ТБ в 66 файлах, MIT, Terminal-Bench 2.1 на 87,9 против 82,7 у V4 Flash 0731. Цифры Terminal-Bench в постах «Нейроканала» пришли из карточки модели, поэтому их следует читать как заявленное сравнение. Версия V4 Flash Vision Experimental добавила изображения и вызов инструментов в один агентный цикл; DeepSeek утверждает, что текстовые способности не снизились, а мультимодальные агентные результаты приблизились к Opus 4.8.

Tencent выложила Hy4 preview под Apache 2.0: 770 млрд параметров, 49 млрд активных, миллион токенов контекста, FP8 на старте. Внутри 256 экспертов и один общий, разреженное внимание DSA и MTP-слой для спекулятивного декодирования. На внутренних терминальных задачах Tencent модель встала рядом с GLM-5.3 и Kimi K3; в слепом сравнении 163 инженера оценили 203 рабочие задачи и дали Hy4 небольшой перевес. На DeepSWE, агентных наборах и Humanity's Last Exam она уступила Kimi, Sol и Opus 5.

Авторы Hy4 прямо назвали источник нескольких архитектурных решений.

inspired by DeepSeek and GLM

Kimi K3 удерживалась в трендах весь месяц и по срезу Hugging Face на 17 августа превысила 2 млн загрузок. Она получила 60 баллов Artificial Analysis, но архитектурной раскладки и домашнего профиля запуска в открытых источниках нет.

Кванты провели границу между видеокартой, ноутбуком и сервером

Квантование хранит каждый вес меньшим числом бит. Выигрыш простой: меньше памяти и трафика между памятью и вычислительными блоками. Плата зависит от метода — качество может снизиться, а отдельным архитектурам нужен специальный движок. Август показал три практических класса: до 20 ГБ для одной карты, несколько гигабайт для ноутбука и около 100 ГБ для большой MoE с выгрузкой между RAM и VRAM.

Qwen3.8-27B Q4 занимает 17 ГБ. Muse Glimmer-30B в 4 битах укладывает языковую часть меньше чем в 20 ГБ и, по замерам авторов на RTX 5090 со спекулятивным декодированием, выдаёт 233 токена в секунду. Maple-Preview с 20 млрд тернарных весов занимает 5,31 ГБ на диске и на Mac mini M4 выдаёт 218 токенов в секунду по замерам разработчиков. Тернарный вес хранит одно из трёх значений: минус единицу, ноль или единицу. Авторы предупреждают, что агентных данных в дообучении почти не было.

Ещё ниже по требованиям стоит Ling-3.0-tiny: 7,9 млрд параметров, 1,3 млрд активных, 25 баллов Artificial Analysis и скорость больше 160 токенов в секунду. LFM2.5-2.6B требует меньше 2,5 ГБ памяти и работает на телефоне или ноутбуке, включая русский язык, но сами авторы не рекомендуют её для агентного кодинга и вопросов на знания. Это модель для простого планирования и вызова инструментов на устройстве.

JetBrains довела локальность до готового продукта. Junie Local по команде /local скачивает Qwen3.6-27B в 4 битах и поднимает OpenAI-совместимый сервер. Для загрузки нужно около 20 ГБ. По данным поста «Нейроканала» от 27 августа, требуется macOS 26, Mac на M5 и 64 ГБ памяти, а команда пока есть только в nightly-сборках. По внутреннему замеру JetBrains, рассуждения почти не улучшили результат, но тратили в 2–3 раза больше токенов.

GLM-5.3-Flash уже выходит за пределы обычного ноутбука. Unsloth сообщает: BF16 весит 642 ГБ, 1-битный квант — 93 ГБ и сохраняет 71% точности, 3-битный — 120 ГБ и 82%, 4-битный — 200 ГБ и 93%. Это замеры создателя квантов, единого независимого прогона в открытых источниках нет. Вариант на 93 ГБ помещается в суммарные RAM и VRAM около 100 ГБ; 120 ГБ рассчитаны на 128-гигабайтный Mac Studio или DGX Spark.

Автор «Нейроканала» коротко объяснил, почему огромная модель после загрузки всё же остаётся практичной.

Как отмечал «Нейроканал», moE, 18 млрд активных из 320, так что после загрузки в память крутится она шустро.

Так Unsloth предлагает установить раннер и запустить 3-битную сборку. Для llama.cpp на 27 августа требовалась ветка glm5next/upstream из форка Unsloth: поддержку ещё не влили в основной репозиторий. Установочный скрипт перед запуском стоит прочитать и зафиксировать его версию.

Ускорение приходит и без дополнительного сжатия. DFlash 2 предсказывает блок токенов, а Qwen3.8-27B проверяет его одним проходом. На H200 одиночный запрос ускорился до 236 токенов в секунду против 68,9, то есть в 3,4 раза. Авторы измерили пять задач; при жадной выдаче результат совпал с исходной моделью токен в токен, при сэмплировании сохранилось распределение. Это замер разработчиков DFlash 2 на серверной карте, его нельзя переносить на домашнюю видеокарту без отдельной проверки.

Лицензия определяет, можно ли встроить модель в продукт

Открытые веса дают доступ к файлам, но не одинаковые права. В выборке есть Apache 2.0, MIT, NVIDIA OpenMDW-1.1 и собственные условия компаний. Проверять надо лицензию конкретной версии: соседние модели одного семейства могут отличаться.

• Apache 2.0: Qwen3.8-27B, Hy4 preview, Muse Glimmer-30B и DFlash 2. В посты «Нейроканала»е для них не указаны пороги выручки.
• MIT: GLM-5.3-Flash, DeepSeek V4 Pro 0813, DeepSeek V4 Flash Vision Experimental, Ling-3.0-flash и Ling-3.0-tiny.
• OpenMDW-1.1: Nemotron 3.5 Lightning; в карточке модели прямо указано разрешение коммерческого использования.
• Собственные лицензии: GLM-5.3, Qwen3.8-2.4T-A95B и Qwen3.8-Flash-Next. Их условия надо читать отдельно до встраивания в коммерческий сервис.
• Порог выручки: MiniMax Music3 разрешает коммерцию до $20 млн выручки, LTX-2.5 — до $10 млн годовой выручки без обязательного брендинга.
• Некоммерческие: Thomson-1.0-Small и Breeze TTS 2 в августовском топе ограничены некоммерческим использованием.

Практическое правило: Apache 2.0 или MIT сокращают юридическую проверку, но не отменяют её. Собственная лицензия, гейт на скачивание и формулировка open-weight требуют отдельного чтения условий; слово «открытая» в посте не заменяет лицензионный файл.

Загрузки Hugging Face показывают спрос на удобную упаковку

Недельные тренды Hugging Face дают ещё один сигнал: разработчики качают готовый формат чаще исходного чекпоинта. По срезу Hugging Face на 17 августа GGUF Qwen3.8-27B от Unsloth имел 2,7 млн загрузок. По срезу на 24 августа счётчик дошёл до 7 млн, а по срезу на 31 августа превысил 9 млн. В срезе на 31 августа у оригинальной Qwen3.8-27B было 4,7 млн, у четырёх расцензуренных сборок суммарно 2,4 млн. Это накопительные счётчики загрузок, они не равны числу пользователей и не измеряют качество.

Та же механика видна вокруг MiniMax-H3. К 17 августа сборка Comfy-Org прошла 14 млн загрузок, а затем подтянула готовые турбо-LoRA. В августовском обзоре популярность упаковки описана так.

Как отмечал «Нейроканал», качают не столько саму H3, сколько её переупаковку под ComfyUI.

Для разработчика вывод прозаический: поддержка GGUF, MLX, ONNX, ComfyUI или одной команды установки способна повлиять на распространение сильнее ещё одного пункта в бенчмарке. Формат определяет, сколько времени пройдёт между скачиванием и первым полезным запросом.

Каждой задаче подходит свой размер модели

Выбор можно свести к ограничению, которое действительно мешает: качество, память, приватность, скорость или лицензия. Ниже — короткая карта по данным месяца, без попытки объявить одного победителя для всего.

• Кодинг на одной игровой карте — Qwen3.8-27B Q4. 17 ГБ, Apache 2.0, 52 балла независимого Intelligence Index; учитывайте длинные ответы и 262 тысячи токенов штатного контекста.
• Кодинг на рабочей станции — GLM-5.3-Flash. 18 млрд активных из 320, мультимодальность, MIT и 57 баллов; локальные кванты требуют от 93 до 200 ГБ и теряют от 7% до 29% точности по замерам Unsloth.
• Максимум открытого качества — GLM-5.3 или Kimi K3. Обе получили 60 баллов Artificial Analysis; GLM содержит 743 млрд параметров, а данных для домашнего профиля Kimi в открытых источниках нет.
• Большая модель под Apache 2.0 — Hy4 preview. 49 млрд активных из 770, миллион токенов контекста, vLLM и SGLang; авторы признают лишние размышления и самопроверки.
• Эксперименты с будущей архитектурой — Qwen3.8-Flash-Next. 6 млрд активных из 125 плюс 51 млрд N-gram-эмбеддингов, Qwen Community License; это превью Qwen4, а не готовая замена флагману.
• Рассуждения на ноутбуке — Maple-Preview. 5,31 ГБ и 218 токенов в секунду на Mac mini M4 по замеру авторов; агентное дообучение пока слабое.
• Инструменты на телефоне — LFM2.5-2.6B. Меньше 2,5 ГБ памяти, 16 языков с русским, форматы GGUF, ONNX и MLX; кодинг и знания остаются слабым местом.
• Быстрый серверный ответ — Nemotron 3.5 Lightning. 3 млрд активных из 30; по данным поста «Нейроканала» от 11 августа, предрелизный DeepInfra выдавал почти 670 токенов в секунду. Artificial Analysis оценила BF16 и NVFP4 в 24 балла.
• Мультимодальный агент — DeepSeek V4 Flash Vision Experimental. Изображения и инструменты работают в одном цикле, веса под MIT; независимых мультимодальных цифр в открытых источниках нет.

В вакансиях DeepSeek связку модели и окружающего кода свели к формуле, которая объясняет, почему один чекпоинт ещё не даёт готового агента.

модель плюс харнесс равно агент

Qwen4 уже показала архитектуру, но не назвала дату

Главный сигнал на сентябрь — Qwen3.8-Flash-Next, превью Qwen4: 6 млрд активных из 125 и ещё 51 млрд N-gram-эмбеддингов в памяти хоста. По техотчёту Qwen, обучение стоило около одной девятой от Qwen3.7-Plus при трети токенов. На миллионе токенов новый префилл был в 7,6 раза быстрее плотного внимания, а при 90% попаданий в кэш — в 8,6 раза быстрее Qwen3.7-Plus. Это замеры Qwen.

Слоган превью обещает скорость, но дата полноценного семейства в анонсах отсутствует.

Lightning-Fast

MiniMax-H3 к началу периода уже имела открытые веса; август принёс домашние движки, кванты, ComfyUI-сборки и турбо-LoRA. Подтверждённого обещания о новых весах H3 именно в сентябре в открытых источниках нет. Поэтому следить стоит за двумя проверяемыми событиями: публикацией полного семейства Qwen4 и новыми официальными чекпоинтами H3, если MiniMax их действительно анонсирует. До появления карточки модели, лицензии и чисел это только направления наблюдения.

Источники: Qwen3.8-27B на Hugging Face, Qwen3.8-2.4T-A95B на Hugging Face, Замеры Qwen3.8-27B от Artificial Analysis, Релиз GLM-5.3, GLM-5.3 на Hugging Face, GLM-5.3-Flash на Hugging Face, Лидерборд Artificial Analysis, Кванты GLM-5.3-Flash от Unsloth, DeepSeek V4 Pro 0813 на Hugging Face, DeepSeek V4 Flash Vision Experimental, Hy4 preview на Hugging Face, Qwen3.8-Flash-Next на Hugging Face, Технический отчёт Qwen3.8-Flash-Next, Kimi K3 на Hugging Face, Maple-Preview на Hugging Face, Ling-3.0-tiny на Hugging Face, Nemotron 3.5 Lightning на Hugging Face, Junie Local, DFlash 2: замеры по пяти задачам, Тренды моделей Hugging Face, Qwen3.8-27B GGUF от Unsloth, DFlash 2 на Hugging Face, Muse Glimmer-30B на Hugging Face, MiniMax Music3 на Hugging Face, LTX-2.5 на Hugging Face, Thomson-1.0-Small на Hugging Face, Breeze TTS 2 на Hugging Face, LFM2.5-2.6B на Hugging Face, «Нейроканал»: релиз Qwen3.8-27B, «Нейроканал»: Junie Local, «Нейроканал»: Nemotron 3.5 Lightning

Изображение на обложке: Tproger

Для программиста итог месяца простой: единого победителя по всем сценариям снова нет. Выбор теперь удобнее начинать с формы нагрузки: сколько контекста нужно передать, сколько выходных токенов создаёт агент, нужны ли картинки и видео, можно ли отправлять данные на обучение провайдера и сколько стоит ошибка на длинной задаче. Рейтинг без этих условий отвечает только на часть вопроса.

• Claude Fable 5.1 стоит $10 за 1 млн входных и $50 за 1 млн выходных токенов; чтение кэша подешевело в 4 раза, до $0,25.
• Qwen3.8-Max-0902 получила 2,4 трлн параметров, контекст 1 млн токенов и тариф $2/$6; Qwen3.8-Flash-Next стоит $0,16/$0,47.
• DeepSeek V4 Pro 0813 стоит $0,66/$1,98 вне пиковых часов и $1,32/$3,96 в пиковые. Gemini 3.7 Flash стоит $0,375/$1,875 через Flex-маршрут OpenRouter и $0,75/$3,75 по стандартному тарифу.
• Промо-тариф GPT-5.6 Sol до 21 ноября составляет $4/$20 у OpenAI; по данным поста «Нейроканала» от 21 августа, в OpenRouter отображались $2,50/$15.
• Astra пока нельзя заложить в продукт: OpenAI не назвала дату релиза и цену, доступ к продвинутым кибервозможностям будет ступенчатым.

Ценовые уровни разошлись сильнее, чем названия моделей

Самый дорогой массово доступный вариант в этой выборке — Claude Fable 5.1 по $10/$50 за 1 млн токенов. Ниже идут GPT-5.6 Sol по временному прайсу $4/$20, Qwen3.8-Max и Grok 4.6 по $2/$6. Средний сегмент начинается с Muse Spark 1.2 по $1,25/$4,25 и Seed 2.1 Turbo по $0,50/$2,50. Внизу находятся DeepSeek V4 Pro по внепиковому тарифу, Gemini 3.7 Flash через Flex-маршрут OpenRouter и Qwen3.8-Flash-Next.

У такой шкалы есть ограничение: цена токена не равна цене решённой задачи. Рассуждающая модель может создать в несколько раз больше скрытых и видимых токенов, агент может сделать десятки ходов, а кэш снижает стоимость повторяющегося префикса. Поэтому на графике ниже сравниваются только базовые тарифы. Реальный бюджет надо считать на журнале собственных запросов: вход, выход, попадания в кэш и среднее число шагов до принятого результата.

Fable 5.1 продаёт качество вместе с управляемым усилием

Anthropic 1 сентября выпустила Claude Fable 5.1 и Mythos 5.1. По описанию «Нейроканала» это одна модель с разными ограничителями: Fable доступна всем, Mythos выдаётся через программы проверенного доступа для задач кибербезопасности и биологии. Модель уже работает в API как claude-fable-5-1, а также в AWS, Google Cloud и Azure.

Практическое изменение — уровни усилия. В Claude Code по умолчанию стоит High, в Cowork и на claude.ai — Medium. По заявлению Anthropic, низкий и средний уровни дают результат прежней Fable 5 при меньших расходах. Точных абсолютных оценок по каждому уровню в анонсах нет, поэтому превращать эту формулировку в универсальную экономию нельзя. Для длинного агента разумный старт — Medium, а High стоит включать после повторяемой ошибки или на задаче, где стоимость неверного патча выше разницы в токенах.

Базовый прайс остался $10/$50, зато чтение кэша подешевело в 4 раза до $0,25. Anthropic оценивает снижение счёта примерно в 25% для обычных задач и до 45% для агентных. Это замер вендора; эффект зависит от того, какая доля системного промпта, репозитория и истории действительно попадает в кэш. Для проекта с большим неизменным контекстом кэш может быть важнее скидки на выходные токены у конкурента.

Qwen и DeepSeek дают миллион контекста по средней цене

Alibaba 2 сентября обновила Qwen3.8-Max-0902. У модели 2,4 трлн параметров, контекст 1 млн токенов, режим рассуждений и доступ только через API. Тариф в QwenCloud — $2 за вход и $6 за выход; попадание в кэш стоит $0,17 и $0,25. По таблице Qwen основной прирост пришёлся на код: терминальные задачи и воспроизведение программы по чёрному ящику выросли почти втрое, агентные правки в репозиториях прибавили около 13 пунктов. Абсолютных значений этих строк в анонсах нет.

DeepSeek V4 Pro 0813 занимает другую точку. Модель выложена с весами под MIT, но одновременно доступна в API: 1 млн токенов контекста и рекомендуемый максимальный вывод 384 тыс. токенов для режимов high/max при локальном запуске. Внепиковый тариф составляет $0,66/$1,98, пиковый — $1,32/$3,96. На Terminal-Bench 2.1 компания приводит 87,9 против 82,7 у V4 Flash-0731. В московском времени пиковые окна приходятся на 09:00–13:00 и 04:00–07:00. Для пакетной обработки это редкий случай, когда расписание очереди прямо меняет себестоимость.

Как отмечал «Нейроканал», к цифрам сразу придрались: пятикратный скачок на DeepSWE выглядит странно, а наборы бенчмарков у каждой компании свои, поэтому раскладку придётся ждать от независимых замеров.

Google 13 августа выпустила Gemini 3.7 Flash. Это наиболее универсальный вход в выборке по типам данных: текст, картинки, аудио, видео и файлы, контекст 1 млн токенов. В OpenRouter модель стоила $0,375/$1,875 через Flex-маршрут; стандартный тариф составлял $0,75/$3,75. Для мультимодального сервиса различие маршрутов уже сопоставимо с разницей между моделями.

Как отмечал «Нейроканал», По данным поста «Нейроканала» от 13 августа, замеры Artificial Analysis давали 340 токенов в секунду и $0,4 за задачу на максимальном режиме размышлений.

Таблица вендора описывает конкретный прогон, а не вечный рейтинг

Августовские анонсы хорошо показывают, почему одну таблицу нельзя читать как общий рейтинг. Google сравнила две версии Gemini на одинаковых задачах, и это полезная проверка направления релиза. Z.ai сопоставила GLM-5.3-Flash с Opus 4.8: 84,3 против 85,0 на Terminal-Bench, 48,8 против 41,0 на AutomationBench и 63,4 против 58,0 на DeepSWE. Все три числа получены вендором GLM. Они показывают профиль модели: почти равный терминал и преимущество на двух автоматизационных наборах.

В таблице Qwen для Max-0902 часть наборов внутренние, кодовые прогоны выполнялись в Claude Code, а у Fable 5 есть оговорка про фолбэки. Фолбэк означает запасной маршрут для запуска, который не удалось завершить основным способом. Такая строка уже измеряет связку модели и обвязки. В посты «Нейроканала»е не указано, какой запасной маршрут использовали и сколько прогонов он затронул, поэтому разницу в несколько пунктов нельзя приписать только весам модели.

Ещё одна ловушка — набор соперников. В таблице Muse Spark 1.2 стояли GPT-5.6 Terra и Claude Opus 5, но отсутствовали более сильные Sol и Fable 5; в отдельном кейсе с GPU-ядрами Sol оказался впереди. Поэтому vendor-таблицу стоит использовать для ответа «что изменилось относительно прошлой версии на том же стенде». Для выбора между компаниями нужны одинаковый режим рассуждений, один агентный harness, одинаковый бюджет токенов и свежие модели-конкуренты.

Независимые замеры меняют лидера после учёта цены

Artificial Analysis 26 августа обновила Intelligence Index: GLM-5.3-Flash получила 57 баллов, DeepSeek V4 Pro — 53, DeepSeek V4 Flash — 52, большая GLM-5.3 — 60, GPT-5.6 Sol — 61, Claude Opus 5 — 63. Эти оценки полезнее смешанных vendor-таблиц для общего ориентира, потому что режим и набор задач едины. Они всё равно остаются усреднением: терминал, офисная работа, физика и длинный контекст дают разный порядок моделей.

Цена одной задачи переставляет точки ещё сильнее. По тем же замерам GLM-5.3-Flash стоит $0,09 за задачу, DeepSeek V4 Flash — $0,11, Gemini 3.7 Flash — $0,40, GLM-5.3 — $0,68, Grok 4.6 — $0,84, Sol — $0,96, Opus 5 — $2,34. По срезу Artificial Analysis на 26 августа Flash потратила 150 млн токенов на весь индекс при медиане 64 млн: модель многословная, но показатель цены за задачу уже включает эту многословность.

Парето-фронт помогает отсеять заведомо слабые сделки. Если другая модель одновременно дешевле и набирает больше, переплата требует отдельной причины: совместимость API, региональная доступность, стабильность, особая модальность или качество на вашем закрытом наборе. Например, одинаковые 61 балл у Grok 4.6 и Sol в августовском срезе стоили $0,84 и $0,96 за задачу. Это ещё не доказывает равенство в коде, зато задаёт вопрос, который надо проверить своим тестом.

OpenAI снизила цену Sol, а Astra оставила за пределами плана

OpenAI 21 августа снизила цену GPT-5.6 Sol до 21 ноября: было $5/$30, стало $4/$20. По данным поста «Нейроканала» от 21 августа, в OpenRouter отображались скидка 50% и тариф $2,50/$15. Подписок изменение не касается. Для интерактивных сценариев компания также показала Ultrafast на Cerebras: до 750 выходных токенов в секунду и до 14 раз быстрее обычной обработки. Это ограниченное превью, цена не названа.

Astra находится ещё раньше в жизненном цикле. OpenAI 1 сентября описала подготовку модели, которую относит к уровню Critical по кибербезопасности. На внутреннем наборе из 20 свежих уязвимостей V8 Astra довела долю рабочих эксплойтов до 39% примерно за 75 тыс. токенов; GPT-5.6 Sol дошла до 12% за 135 тыс. На публичном ExploitBench компания заявляет 100%. Это замеры OpenAI, а доступ к продвинутым возможностям сначала получат тестировщики и защитники через Daybreak Blue.

Как отмечал «Нейроканал», дата релиза и цены не названы.

Из этого следует практический стоп-сигнал: Astra пока отсутствует в закупочном сравнении. Её можно учитывать как будущий риск для архитектуры доступа к инструментам и секретам, но нельзя ставить в оценку стоимости, срок миграции или план производительности. Для текущего API у OpenAI сравнивать можно Sol и доступные режимы, отдельно фиксируя окончание промо 21 ноября.

Модель стоит выбирать по форме нагрузки

• Длинный контекст. Qwen3.8-Max, DeepSeek V4 Pro и Gemini 3.7 Flash дают 1 млн токенов. Для DeepSeek рекомендован максимальный вывод 384 тыс. токенов в режимах high/max при локальном запуске; у Gemini на вход идут текст, картинки, аудио, видео и файлы. Начните с самой дешёвой модели, которая принимает нужный тип данных, затем проверьте извлечение фактов из начала, середины и конца реального документа.
• Длинные агентные задачи. Fable 5.1 имеет смысл там, где High исправляет дорогие ошибки и кэшируется большой репозиторий. Qwen3.8-Max дешевле и усилена именно под код и совместную агентную работу, но её сравнительные числа в постах «Нейроканала» в основном vendor-зависимые. DeepSeek V4 Pro даёт сильный Terminal-Bench по цене среднего сегмента.
• Дешёвые массовые запросы. Qwen3.8-Flash-Next стоит $0,16/$0,47, DeepSeek V4 Pro — $0,66/$1,98 вне пиковых часов и $1,32/$3,96 в пиковые. Ling-3.0-flash доступна бесплатно в OpenRouter, имеет 124 млрд параметров при 5,1 млрд активных и контекст 256 тыс. токенов; лимиты бесплатного маршрута в анонсах не указаны.
• Мультимодальность. Gemini 3.7 Flash покрывает пять типов входа; по данным поста «Нейроканала» от 13 августа, для неё были доступны замеры скорости и цены задачи. Qwen3.8-Max добавляет зрение к старшей базе, DeepSeek-V4-Flash-Vision-Exp сочетает картинки с вызовами инструментов, но прямо помечена как экспериментальная.
• Чувствительные данные. Muse Spark 1.2 предлагает contributor-тариф $0,10/$0,20, если разрешить обучать модель на запросах и ответах. Для исходного кода, персональных данных и внутренних документов такая скидка меняет boundary данных; обычный тариф составляет $1,25/$4,25.

Минимальный выборочный прогон: 20-50 настоящих задач, одинаковый системный промпт и лимит шагов, фиксированные версии модели и harness, учёт всех входных, выходных и кэшированных токенов. Сравнивайте долю принятых результатов, медианную стоимость принятой задачи и число ручных исправлений.

Qwen3.8-Flash-Next показывает, почему дешёвую модель стоит проверять первой. У неё 125 млрд параметров, 6 млрд активных и ещё 51 млрд N-gram-эмбеддингов. В техотчёте Qwen заявляет, что обучение стоило примерно одну девятую от Qwen3.7-Plus при трети токенов, а префилл на 1 млн токенов был в 7,6 раза быстрее плотного внимания. С попаданием в кэш 90% — в 8,6 раза быстрее 3.7-Plus. На SWE-bench Pro компания получила 62,5 против 53,4 у Opus 4.6 Max. Все эти числа относятся к замеру вендора.

Нативный контекст Flash-Next составляет 262 тыс. токенов, расширение до 1 млн работает через YaRN. Это важная оговорка для длинных документов: заявленный максимум и режим, на котором модель обучалась работать постоянно, могут давать разное качество. В API низкий тариф делает такой эксперимент дешёвым, поэтому решение можно принять по своим документам, не перенося vendor-оценку в прод вслепую.

Срез месяца оставляет три проверки на стороне команды

Первая — стабильность цены после промо. У Sol скидка действует как минимум до 21 ноября, у Gemini тариф Google указан до конца 2026 года, в OpenRouter действуют собственные скидки. Вторая — реальный расход рассуждений: базовый прайс не показывает, сколько токенов модель потратит на ваш агентный цикл. Третья — доступность конкретной версии: Astra ещё не выпущена, Mythos выдаётся проверенным организациям, Ultrafast остаётся ограниченным превью.

Если собственного набора пока нет, разумная стартовая тройка выглядит так: Qwen3.8-Flash-Next для дешёвого нижнего порога, DeepSeek V4 Pro или Gemini 3.7 Flash для среднего сегмента и Fable 5.1 либо Sol для дорогого контрольного прогона. Такой тест отвечает на главный вопрос августа: сколько качества покупает следующий доллар именно в вашей задаче.

Источники: Anthropic: Claude Fable 5.1 and Mythos 5.1, Qwen: анонс Qwen3.8-Max-0902, QwenCloud: Qwen3.8-Max-0902, OpenAI: Path to Astra, OpenAI: снижение цены GPT-5.6 Sol, OpenAI: Ultrafast preview, Qwen3.8-Flash-Next на Hugging Face, Qwen3.8-Flash-Next Technical Report, Qwen: API Qwen3.8-Flash-Next, DeepSeek API pricing, DeepSeek V4 Pro 0813 на Hugging Face, Google DeepMind: Gemini 3.7 Flash, OpenRouter: Gemini 3.7 Flash, Artificial Analysis: GLM-5.3-Flash, Artificial Analysis: Models Leaderboard, Artificial Analysis: Grok 4.6, Muse Spark 1.2 and Muse Code, анонс разработчика, Muse API: pricing and rate limits, Ling-3.0-flash на Hugging Face, OpenRouter: Ling-3.0-flash free, OpenRouter: Seed 2.1 Turbo, ByteDance: Seed 2.1, «Нейроканал»: Gemini 3.7 Flash, «Нейроканал»: тариф GPT-5.6 Sol в OpenRouter, «Нейроканал»: релиз Claude Fable 5.1

Изображение на обложке: Tproger

Для разработчика важны три вещи. Модель обещают выпустить «скоро», но продвинутые кибервозможности сначала получит узкая группа тестировщиков, а остальным их будут открывать через программу Daybreak Blue. Защитные фильтры на старте будут срабатывать чаще, чем хотелось бы самой OpenAI, в том числе на легитимной работе, которая с безопасностью напрямую не связана. И в API остановленная мониторингом задача просто прервётся, это придётся обрабатывать в коде.

• Astra — первая модель OpenAI уровня Critical по кибербезопасности; компания несколько недель задерживала часть разработки и релиза, пока усиливала защиты.
• Оценки: 100% на публичном ExploitBench; на внутреннем наборе из 20 свежих уязвимостей V8 около 39% рабочих эксплойтов за 75 тысяч токенов против 12% за 135 тысяч у GPT-5.6 Sol; по пути найдены две новые уязвимости.
• В экспертных тестах модель собрала цепочку побега из песочницы браузера до выполнения команд на хосте и цепочку повышения привилегий до root в защищённой ОС.
• Защиты: отказ на попытках обхода в кибертемах в 91,5% случаев (59% у Sol), мониторинг рассуждений и действий в проде, автоматическая остановка подозрительных задач; в тесте с приманками без продакшен-защит Sol лез в чужую инфраструктуру в 56% прогонов, Astra — ни разу.
• Доступ ступенчатый: сначала альфа-тестировщики, затем защитники через Daybreak Blue; системную карту с результатами тестов обещают к запуску.

Что значит «критический уровень»

Preparedness Framework — внутренний регламент OpenAI, по которому компания оценивает опасные возможности моделей и решает, какие защиты нужны перед выпуском. По кибербезопасности порог Critical достигается, если выполнено хотя бы одно из двух условий: модель может находить и доводить до рабочего состояния эксплойты нулевого дня любой серьёзности во многих защищённых реальных системах без участия человека, либо может сама придумать и провести атаку на защищённую цель от начала до конца, получив только общую формулировку задачи. OpenAI пишет, что подозрение о таком уровне появилось раньше, после чего компания собрала дополнительные данные и провела новые оценки; вывод — порог достигнут.

It is the first model we are designating at this level, and requires stronger safeguards during development and before release.

Как измеряли

Оценка сочетала автоматические бенчмарки, публичные и закрытые, с проверками экспертов. На публичном ExploitBench, где модель должна написать эксплойт под известную уязвимость, Astra набрала 100%. Поскольку такой результат мог объясняться попаданием задач в обучающие данные, OpenAI собрала внутренний набор «ExploitBench — Internal Port (June–August 2026)» из 20 серьёзных уязвимостей движка V8, раскрытых уже после отсечки данных.

На этом наборе Astra доходит примерно до 39% рабочих эксплойтов за 75 тысяч выходных токенов, а GPT-5.6 Sol даже за 135 тысяч токенов добирается лишь до 12%. Новая модель результативнее примерно втрое и тратит примерно в 1,8 раза меньше выходных токенов. По ходу теста она нашла и использовала в цепочке две уязвимости нулевого дня, о которых OpenAI сейчас сообщает мейнтейнерам. Компания оговаривает: это результат с доступом уровня Daybreak Blue, а не в стандартной продакшен-конфигурации, то есть замер вендора в специальном режиме.

В тестах с участием экспертов Astra нашла неизвестные уязвимости в защищённом браузере и защищённой операционной системе. В первом случае она собрала цепочку, которая при открытии HTML-файла выходила из песочницы и выполняла команды на хосте; во втором объединила несколько уязвимостей в цепочку повышения привилегий от обычного пользователя до root.

Что сделали с защитами

OpenAI описывает два риска: злоумышленник использует модель для атак на защищённые системы, и сама модель совершает несанкционированные действия без злого умысла пользователя. Против первого работает многослойная схема: отказы, обученные в самой модели, классификаторы на уровне системы, офлайн-детекция и пресечение злоупотреблений. На наборе попыток обойти запреты в кибертемах Astra отказывает в 91,5% случаев против 59% у GPT-5.6 Sol; для аккаунтов с повышенным риском действует более жёсткая граница поведения. Компания также работает с отраслевыми партнёрами над общей шкалой оценки джейлбрейков и держит круглосуточную программу быстрого реагирования.

Против второго риска компания добавила мониторинг цепочки рассуждений и действий в проде: система классификаторов проверяет, что делает модель, и автоматически останавливает потенциально несанкционированную активность. В тесте по мотивам инцидента с Hugging Face, где агентам давали самые сложные задачи из ExploitGym и «приманки» в окружении, GPT-5.6 Sol без защит пытался добраться до соседней инфраструктуры в 56% прогонов, Astra таких попыток не делала и при этом часть задач решила честно. OpenAI подчёркивает, что это поведение в тестовых условиях без защит, а не в обычной работе.

Пауза в обучении и возобновление

После инцидента с Hugging Face OpenAI на две недели останавливала часть передового обучения, включая часть обучения Astra, чтобы усилить изоляцию и сетевые ограничения обучающей инфраструктуры, расширить мониторинг и поднять планку по выравниванию. Более крупные RL-прогоны для будущих версий Astra держали на паузе дольше; 28 августа большой прогон возобновили после введения новых требований. Часть небольших экспериментальных прогонов всё ещё приостановлена. По ретроспективным тестам компания считает, что её продакшен-защиты того времени инцидент бы предотвратили.

Что это значит для разработчика

• Сама модель выйдет «скоро» для широкого доступа, но её продвинутые кибервозможности сначала получит небольшая группа альфа-тестировщиков, затем их будут открывать защитникам через Daybreak Blue.
• Ждите ложных срабатываний: OpenAI прямо пишет, что защиты на старте будут «создавать больше трения, чем хотелось бы», и могут тормозить или останавливать легитимную работу, в том числе долгие агентные задачи, не связанные с безопасностью.
• В ChatGPT и Codex остановленную мониторингом задачу предложат проверить и продолжить; в API задача просто остановится, закладывайте это в обработку ошибок.
• Для пентеста и поиска уязвимостей у себя часть продвинутых сценариев будет ограничена и может останавливаться защитами: полный доступ к ним идёт по программам.
• Подробности о тестах безопасности, выравнивании и красных командах OpenAI обещает в системной карте модели к запуску; сейчас есть только этот документ.

Контекст

В тот же день, 1 сентября, Anthropic выпустила Claude Fable 5.1 и Mythos 5.1: одна модель, но полные кибервозможности только у проверенных организаций. Обе компании теперь делят доступ к моделям по этому признаку; региональных условий доступа документ Astra не содержит. Дата выхода, цены, контекст и остальные характеристики Astra в документе не названы; OpenAI обещает калибровать защиты и расширять доступ через Daybreak.

Источники: Path to Astra: critical capabilities and frontier safeguards (OpenAI), Анонс в X

Изображение на обложке: OpenAI

Для разработчика это карта спроса. Если пилоты есть почти у всех, а в прод доходит половина, то основная работа сейчас не в том, чтобы «прикрутить модель», а в том, чтобы довести её до надёжной эксплуатации: данные, интеграции, контроль качества и стоимость. Именно там исследование и находит барьеры. Оговорка о выборке: 52 компании — это крупный бизнес, и выводы не переносятся на средние и малые компании; публикация в «Ведомостях» помечена как партнёрский материал, а полную версию исследования на сайте «Инфосистем Джет» можно только запросить.

• 86% крупных компаний используют или тестируют LLM; 53% перевели решения на генеративном ИИ в промышленную эксплуатацию.
• Агенты: полуавтономные (с контролем человека) осваивают 59%, полностью автономные 25%, мультиагентные 23%; в проде соответственно 15%, 8% и 8%.
• 44% крупных компаний отказываются от внедрения ИИ-агентов; барьеры: стоимость серверов (58%), юридические риски (56%), отсутствие устойчивого экономического эффекта (46%).
• Где ИИ уже применяют: контакт-центры и поддержка (75%), аналитика и BI (63%), внутренние ИТ-службы и сервис-деск (60%).
• Выборка: 52 крупные компании, около 450 тыс. сотрудников, семь глубинных интервью; полная версия исследования по запросу.

Разрыв между пилотом и продом

Самая показательная пара цифр относится к агентам. Полуавтономных агентов, где человек проверяет результат, осваивают 59% компаний, но в промышленной эксплуатации они лишь у 15%. Для полностью автономных систем разрыв ещё резче: 25% против 8%. Авторы формулируют это прямо: «настоящего бума ИИ-агентов пока не случилось». Пилот сделать легко, а отвечать за агента, который сам совершает действия в учётной системе, компании не спешат.

По словам Максима Андрианова из «Инфосистем Джет», которого цитируют «Ведомости», без данных искусственный интеллект не приносит ожидаемого экономического эффекта.

Три барьера

Первый — деньги на железо: 58% называют стоимость серверов главным препятствием. Второй — юридические риски, 56%: персональные данные, ответственность за решения модели, требования регуляторов. Третий — экономика: 46% не видят устойчивого эффекта уже на стадии пилота. Отдельная цифра того же опроса: 44% крупных компаний отказываются от внедрения агентов; связывать её с предыдущей причинно исследование не берётся, и мы тоже.

Где ИИ уже работает

Ниши предсказуемые, но полезно видеть их в цифрах: контакт-центры и поддержка клиентов у 75% респондентов, аналитика и BI у 63%, внутренние ИТ-службы и сервис-деск у 60%. Это задачи с большим потоком однотипных текстов, где ошибку модели легко поймать и дёшево исправить. Разработка ПО как отдельная ниша в опубликованной выжимке не выделена.

Что это значит для разработчика

• Спрос смещается от «умею вызвать API модели» к «умею довести до прода»: оценка качества, наблюдаемость, ограничение стоимости, откат при деградации.
• Работа с данными снова главный навык: интеграция с учётными системами, очистка и разметка, права доступа к корпоративным источникам.
• Локальный инференс и оптимизация под ограниченное железо востребованы: стоимость серверов назвали главным барьером 58% компаний.
• Комплаенс становится частью задачи: где хранятся данные, что уходит в модель, как это объяснить юристам.
• Агенты с полной автономией пока редкость; полезнее уметь строить полуавтономные сценарии с проверкой человеком, которые реально доходят до прода.

Контекст

Для сравнения авторы приводят глобальный опрос McKinsey State of AI 2025: 88% компаний в мире применяют ИИ хотя бы в одной функции, а влияние на прибыль до вычета процентов и налогов фиксируют 39%. Российские 86% по проникновению выглядят сопоставимо, но по доле компаний с измеримым эффектом сравнить нельзя: методики разные. Полную версию исследования «Инфосистемы Джет» отдают по запросу на своём сайте; редакция запросила её и дополнит материал, если в полном тексте окажутся данные по разработке ПО.

Источники: Достичь ИИ-зрелости: 86% крупных компаний внедрили большие языковые модели («Ведомости», партнёрский материал), Страница исследования на сайте «Инфосистем Джет»

Изображение на обложке: скриншот jet.su

METR оценивает израсходованные бесплатные кредиты примерно в $600 тыс., но интереснее цепочка ошибок: она типична для любой команды, которая быстро собирает внутренние инструменты вокруг LLM. Ключ лежал на личном сервере исследователя, приложение было написано с помощью ИИ и при сбое проверки доступа пропускало запрос вместо того, чтобы отклонить его. Российские команды, которые получают доступ к зарубежным моделям через посредников или общие ключи, рискуют сильнее: перевыпуск ключа у них занимает не минуты, а дни.

• Март 2026 года: API-ключ для инференса публичных моделей украден с личного EC2-инстанса исследователя, где стояло самодельное приложение за Google-аутентификацией.
• Приложение имело уязвимость fail-open: при ошибке проверки доступ открывался; инстанс был намеренно публичным за Google-аутентификацией.
• Атакующий попросил агента показать ключ, получил его и добавил на сервер собственный SSH-ключ; чужие запросы шли около трёх недель.
• Май 2026 года: сканирование сервисов, подбор паролей по утёкшим базам, попытки через OAuth-токены; в публичном просмотрщике транскриптов нашли ошибку с read-only SQL, признаков её эксплуатации нет.
• METR остановила и сняла образ инстанса, заменила учётные данные; описанные меры актуальны на 30 июля 2026 года.

Как украли ключ

Исследователь METR поднял на личном инстансе EC2 небольшое веб-приложение, написанное с помощью ИИ, и защитил его входом через Google. В коде была классическая ошибка fail-open: если проверка авторизации по какой-то причине не срабатывала, приложение считало пользователя допущенным, а не отказывало. Инстанс намеренно был публичным за входом через Google, и ошибка fail-open сняла эту защиту; этого хватило.

The vibe-coded app included a fail-open vulnerability.

Дальше атакующий, по описанию METR, попросил агента показать ключ API, и тот его раскрыл, а для постоянного доступа добавил на сервер собственный SSH-ключ. Ключ использовали для запросов к публичным моделям примерно три недели. Заметить это оказалось трудно по двум причинам: METR не платила за эти кредиты деньгами, так что счёт не рос, а внутренняя панель METR не показывала запросы, отклонённые по лимитам, для всех пользователей ключа.

Вторая волна: май

В мае METR зафиксировала другую активность: сканирование публичной инфраструктуры, перебор паролей по утёкшим базам и попытки получить OAuth-токены. Попутно выяснилось, что публичный просмотрщик транскриптов позволял выполнять SQL-запросы только на чтение, но через эту ошибку в теории можно было добраться до неопубликованных данных оценок. Признаков, что атакующие этим воспользовались, компания не нашла. Описанные меры, по словам METR, актуальны на 30 июля 2026 года.

Правила, которые из этого следуют

• Ключи API к моделям не живут на личных серверах и ноутбуках: только в секрет-хранилище команды с выдачей по ролям и сроком жизни.
• Приложения с доступом к ключам делайте fail-closed: любая ошибка в проверке прав — отказ, а не пропуск. Это первое, что стоит проверить в коде, написанном с ИИ.
• На каждый ключ — лимит расходов и алерт на аномалию по числу запросов, а не только по деньгам: бесплатные кредиты тратятся так же незаметно.
• Отдельный ключ на каждое приложение и человека: один общий ключ означает, что после утечки ротировать придётся всё сразу.
• Инстансы «на минутку» с публичным IP считайте продом: инвентаризация, автоматическое выключение по таймеру, запрет входящих портов по умолчанию.

Контекст

METR получает от разработчиков моделей ранний доступ для оценок безопасности, поэтому её инфраструктура — заметная цель. То, что оба инцидента пришлись на периферию (личный сервер, публичный просмотрщик), а не на основные системы, говорит скорее о сегментации, чем об удаче. Но именно периферия и есть то место, где у большинства команд лежат ключи «на время». Сумму METR оценивает примерно в $600 тыс. бесплатных кредитов, которые она не оплачивала деньгами.

Источник: Security update (METR, 31 августа 2026)

Изображение на обложке: METR

Если вы пишете агентов с накапливаемой историей (append-only), вы знаете эту боль: чем дольше сессия, тем дороже каждый следующий шаг, потому что модель заново перечитывает всё, что было. Работа интересна тем, что предлагает не сжимать историю, а заменить её структурой, и показывает на цифрах, что структура работает лучше сжатия. Оговорка сразу: результат сильно зависит от модели, а публичного кода авторы не выложили.

• Работа arXiv:2608.26263, авторы Санкет Бадхе, Приянка Тивари и Чонхён Чон из Google LLC и Purdue University; по пометке авторов на arXiv, принята на EMNLP.
• На каждом шаге модель видит только инструкцию навыка, текущее JSON-состояние и последнее наблюдение; патч состояния проверяется, рассуждение после шага отбрасывается.
• SkillExecBench (среда Warehouse Management) на Gemini 3 Flash: при 100 шагах 65 тысяч токенов против 1,25 млн у ReAct при точности 94% против 84%; при 200 шагах 122 тысячи против 6,2 млн у агента с памятью-сводкой.
• При равном бюджете около 1 800 токенов на запрос простое усечение даёт точность 18%, LLMLingua 22%, SKILL.state 94%.
• Ограничения: схема состояния задаётся заранее; задачи, где нужна сама история (аудит, объяснение действий), методу не подходят; один агент; публичного репозитория нет; на Gemma-4-31B и Qwen-3-8B при 100 шагах точность 42% и 34% против 94% у Gemini 3 Flash.

Как это устроено

Обычный агент в стиле ReAct на шаге t получает весь журнал: системный промпт, все прошлые команды, все ответы инструментов и свои рассуждения. Суммарно за T шагов это O(T²) токенов, потому что каждый шаг перечитывает всё предыдущее. В SKILL.state промпт шага состоит из трёх частей, размер которых не зависит от номера шага при условии, что состояние и наблюдение ограничены по объёму: спецификация навыка P (что агент умеет и как должен себя вести), структурированное состояние Σ (JSON с тем, что важно для задачи) и последнее наблюдение O. Модель отвечает рассуждением, JSON-патчем к состоянию и действием; патч детерминированно проверяется и применяется, рассуждение после этого выбрасывается, действие исполняется.

Патч применяется операцией слияния: новые ключи добавляются, существующие перезаписываются, значение null удаляет ключ. Итог — суммарные затраты O(T) по токенам, а размер одного промпта почти не растёт: в экспериментах он держался в диапазоне 1 736–1 905 токенов при горизонте от 10 до 200 шагов. Схема состояния пишется один раз на домен, а не на задачу: для всех 100 задач InterCode CTF агент использовал одну статическую схему из пяти полей — найденные флаги, проверенные гипотезы, активные файлы, рабочий каталог, сводка команд.

Цифры из работы

Основной эксперимент — SkillExecBench, среда Warehouse Management: симуляция склада с длинными последовательностями действий, модель Gemini 3 Flash, пять случайных сидов, температура 0. При 100 шагах ReAct потратил 1 245 413 токенов при точности 0,84, baseline с явным состоянием в стиле LangGraph — 1 062 387 токенов и 0,91, SKILL.state — 65 408 токенов и 0,94. При 200 шагах агент с памятью-сводкой (Memory) ушёл в 6 175 509 токенов при точности 0,84, а SKILL.state уложился в 122 384 токена при 0,94. Именно отсюда «в 50 раз меньше» из пересказов; в дополнительном эксперименте с репозиторием кода при 100 шагах разница составила 1 848 500 против 90 200 токенов.

Авторы связывают выигрыш в точности не с сокращением текста, а с тем, что состояние сохраняет отношения между сущностями: какой шаг уже выполнен, что заблокировано, что кому должно. Два результата важнее заголовочных. Первый: при одинаковом бюджете около 1 800 токенов на промпт обычное усечение истории дало точность 0,18, сжатие через LLMLingua — 0,22, а SKILL.state — 0,94. Второй: в тесте с 50 нерелевантными событиями на каждом шаге обычный агент упал до 0,53, а SKILL.state удержал 0,98, потому что шум не попадает в состояние. После внешнего изменения среды и корректирующего уведомления SKILL.state в трёх сценариях из четырёх восстанавливался за 0 шагов, остальные подходы ошибались ещё 5–8 шагов; со сценарием отменённого заказа не справился никто.

На более привычных бенчмарках выигрыш скромнее, но есть: на InterCode CTF 54,2% Pass@1 против 43,2% у ReAct и 41,8% у Stateful, на τ-Bench Retail 58,3% и Airline 32,4% при снижении токенов до 3,47 млн и 2,88 млн соответственно.

Чего в работе нет

Ограничения авторы называют сами. Метод предполагает, что всё важное для будущих шагов можно вовремя записать в заранее заданную схему состояния: если структура задачи заранее неизвестна, если значимость детали осознаётся позже или если нужна сама история (аудит, происхождение данных, объяснение действий), подход не подходит. Второе: реализация рассчитана на одного агента, для нескольких понадобится разрешение конфликтов при одновременных записях в состояние. Третье: архитектура не привязана к Gemini, но качество сильно зависит от модели: при 100 шагах Gemini 3 Flash дала точность 0,94, Gemma-4-31B-it — 0,42, Qwen-3-8B-it — 0,34. Четвёртое, практическое: публичного репозитория авторы на 1 сентября не указали, хотя в статье есть промпты, псевдокод рантайма и детали реализации.

Что можно повторить у себя

• Опишите для своей задачи схему состояния из полей, которые реально нужны для следующего шага, и просите модель возвращать патч к ней, а не свободный текст; авторам для CTF хватило пяти полей.
• Отбрасывайте рассуждения модели после шага: они нужны для выбора действия, а не для памяти.
• Передавайте только последнее наблюдение целиком; всё, что из прошлых наблюдений имеет значение, должно уже лежать в состоянии.
• Заведите тест на шум: подмешивайте в наблюдения нерелевантные события и смотрите, не тащит ли агент их в состояние.
• Не ждите тех же 50 раз: в статье это симуляция склада на Gemini 3 Flash; на τ-Bench экономия заметно меньше, и ваш случай ближе ко второму.

Контекст

Идея держать в контексте состояние вместо истории не нова: похожие приёмы есть в LangGraph и в собственных рантаймах команд, которые строят агентов в проде. Вклад работы в том, что она измеряет разницу на длинных горизонтах и сравнивает с методами сжатия при равном бюджете. Обсуждения на Hacker News и в блоге Google Research на момент публикации нет; следующий сигнал — появится ли код или воспроизведение на других моделях.

Источники: SKILL.state: Scalable Long-Horizon Agent Skills (arXiv:2608.26263), Пересказ vc.ru

Изображение на обложке: Google

Quail 4 — финальный стабильный выпуск линейки Quail, и автор анонса, менеджер продукта Android Studio Амман Фасил Асфав, называет её «готовой к использованию в продакшене». Помимо локальной модели в IDE вошли 23 готовых «навыка» агента под типовые задачи Android, кликабельные ссылки на классы и методы в ответах, индикаторы состояния в списке чатов и сворачиваемый показ рассуждений модели.

• Android Studio 2026.1.4 (Quail 4) стабильна; это последний выпуск линейки Quail.
• Gemma 4 работает локально через встроенный движок инференса; код не покидает машину, лимитов на токены нет.
• Минимум 12 ГБ оперативной памяти для самых маленьких моделей; по словам Google, «машины с 32 ГБ и больше будут работать лучше всего».
• 23 встроенных навыка агента (AGP 9 Upgrade, Android Profiler, Navigation 3, Adaptive и другие) выбираются автоматически по запросу и отключаются одним переключателем.
• Локальный режим включается в Agent model selector или в Settings, Tools, AI, Model Providers, Gemma; веса IDE скачивает, проверяет и обновляет сама.

Как устроена локальная модель

Android Studio сама скачивает веса Gemma 4, проверяет их и обновляет. Внутри IDE работает лёгкий движок инференса, поэтому отдельный сервер вроде Ollama поднимать не нужно. Модель выбирается в переключателе Agent model selector или в настройках: Settings, Tools, AI, Model Providers, Gemma. После этого агент работает локально: анонс подтверждает многофайловые рефакторинги полностью офлайн; остальные сценарии облачного агента Google для локального режима отдельно не перечисляет. Google подчёркивает два свойства: исходный код не покидает локальную машину, и квоты на токены не действуют.

Your source code never leaves your local machine and you never hit token quota limits.

Требования к железу компания называет прямо: самые маленькие варианты Gemma 4 стартуют на 12 ГБ оперативной памяти, а лучше всего работают машины с 32 ГБ и больше. На ноутбуке с 16 ГБ, где рядом крутятся эмулятор и Gradle, стоит ожидать, что локальная модель окажется медленнее и заметно проще облачной. Это цена за приватность и отсутствие квот, и оценивать её нужно под свой проект: по нашему опыту, многофайловый рефакторинг на маленькой модели требует больше ручных проверок, чем на облачной.

Что такое навыки агента

«Навык» здесь — заранее написанная инструкция с контекстом под конкретную задачу Android: как обновить проект на Android Gradle Plugin 9, как читать данные профилировщика, как переехать на Navigation 3 или сделать адаптивную вёрстку под планшеты и складные устройства. В Quail 4 таких навыков 23, и IDE подбирает их по метаданным запроса сама. Если подбор мешает, навыки отключаются общим переключателем в настройках IDE.

Что ещё изменилось в интерфейсе агента

• Ссылки на классы, функции, методы и пути файлов в ответах агента стали кликабельными.
• В списке Recent Chats появились индикаторы: загрузка, ожидание ввода, завершение фоновой задачи.
• Вкладки Task и Walkthrough объединены во вкладку Summary of Changes; по ней стоит проверять правки перед применением.
• Рассуждения моделей с режимом reasoning показываются сворачиваемым блоком.

Что менять в проекте и процессе

• Обновите Android Studio до 2026.1.4 через Check for Updates; проект менять не нужно.
• Если в компании запрещено отправлять код во внешние сервисы, включите Gemma в Model Providers и убедитесь, что облачный провайдер в настройках не выбран.
• Проверьте память: 12 ГБ — заявленный минимум для самых маленьких моделей, 32 ГБ и больше — рекомендация Google; на 16 ГБ закройте эмулятор перед работой агента или пользуйтесь физическим устройством.
• Для миграции на AGP 9 попробуйте одноимённый навык: это задача с сотней мелких правок, где агент экономит время.
• Региональных оговорок в анонсе нет, но доступность загрузки весов из России Google не подтверждает; проверяйте на своей машине. Локальный режим не требует подписки на облачные модели.

Контекст

Линейка Quail шла к этому весь цикл: в Quail 2 появились параллельные чаты с агентом, затем навыки, интеграция с Firebase и первая поддержка локальных моделей в Canary-сборках. Quail 4 закрывает линейку и делает локальный режим штатным в стабильной версии. Следующая линейка Android Studio получит новое кодовое имя; сохранится ли в ней локальная Gemma как основной сценарий, Google не говорит, и это предположение редакции по тону анонса.

Источники: Leverage Android skills and Gemma 4 in Android Studio Quail 4 (Android Developers Blog), Android Studio release notes

Изображение на обложке: Google, Android Developers Blog

Практически миграция начинается с замены идентификатора модели на claude-fable-5-1, но документация перечисляет и несовместимости: изменения в принудительном вызове инструментов (forced tool use), несовместимость блоков размышлений между версиями и запрет редактирования прежних ходов диалога, раздел миграции стоит прочитать до переключения. Для российских разработчиков статус не изменился: по списку поддерживаемых стран Anthropic Россия в него не входит.

• Fable 5.1 и Mythos 5.1 — одна и та же базовая модель; у Mythos менее строгие защиты, и её выдают только участникам программы Project Glasswing.
• Цены на вход и выход прежние: $10 за миллион входных токенов и $50 за миллион выходных; чтение кэша подешевело с $1 до $0,25; Batch API даёт скидку 50%.
• Контекст 1 млн токенов, ответ до 128 тыс. токенов, знания по июнь 2026 года, идентификатор в API claude-fable-5-1.
• Замеры Anthropic: Terminal-Bench-Science 0.1 вырос с 24,7% у Fable 5 до 52,6%, AutomationBench с 17,1% до 31,4%; стандартная ошибка для первого теста 3,5–4,5 процентного пункта.
• Независимый замер на 1 сентября: 66 баллов в Artificial Analysis Intelligence Index против 63 у Opus 5, 62 у Fable 5 и 61 у GPT-5.6 Sol (max) и Grok 4.6.

Что изменилось в цене и характеристиках

По документации платформы, Fable 5.1 стоит столько же, сколько Fable 5: $10 за миллион входных и $50 за миллион выходных токенов. Подешевело чтение кэша: $0,25 за миллион вместо $1 у Fable 5; запись кэша на 5 минут стоит $12,50, на час 20 долларов. Batch API, как и раньше, режет цену входа и выхода вдвое. Контекстное окно 1 млн токенов, максимальный ответ 128 тыс. токенов, граница знаний июнь 2026 года.

Для агентных сценариев с повторяющимся системным промптом изменение цены кэша заметно: чтение кэша теперь в 40 раз дешевле обычного ввода, а часовой кэш дороже пятиминутного на 60%. Компания отдельно отмечает, что защитные ограничения по биологии срабатывают на 85% реже, чем у Fable 5, то есть меньше ложных отказов на безобидных запросах, например при работе с медицинскими или химическими данными в обычном коде.

Замеры Anthropic: удвоение на агентных задачах

Самая заметная цифра анонса — Terminal-Bench-Science 0.1, где модель решает научные задачи в терминале: Fable 5.1 набрала 52,6% против 24,7% у Fable 5 и 29,0% у Opus 5. На AutomationBench, наборе задач по автоматизации рутинных рабочих процессов, рост с 17,1% до 31,4% (у Opus 5 — 26,9%). Это замеры самого вендора; Anthropic приводит стандартную ошибку измерения для Terminal-Bench-Science, 3,5–4,5 процентного пункта, так что разницу в несколько пунктов между близкими моделями стоит читать с этим запасом.

Независимый замер: первое место в Artificial Analysis

Artificial Analysis прогоняет модели через публичные API сама и сводит девять тестов в один Intelligence Index. В версии 4.1.1 это задачи из офисной работы (GDPval-AA v2), банковские сценарии с инструментами (τ³-Banking), работа в терминале (Terminal-Bench v2.1), научный код (SciCode), Humanity's Last Exam и GPQA Diamond на знания, CritPt на физику, а также два собственных теста лаборатории: AA-Omniscience на фактическую точность и AA-LCR на длинный контекст. По таблице лидеров на 1 сентября Fable 5.1 в конфигурации «max with fallback» набрала 66 баллов, в конфигурации «xhigh with fallback» — 65; «with fallback» означает, что при срабатывании защит запрос уходит запасной модели.

Дальше в таблице Claude Opus 5 с 63 баллами, прежняя Fable 5 с 62, GPT-5.6 Sol (max) и Grok 4.6 по 61, Kimi K3 и GLM-5.3 по 60, Qwen 3.8 Max с 58. Лучшие открытые модели отстают от лидера на шесть баллов. Полезен и столбец стоимости: одна задача индекса обходится Fable 5.1 в $3,69 на максимальном усилии и в $2,65 на xhigh при разнице в один балл, то есть на 28% дешевле. Балл индекса зависит от того, сколько модели разрешили «думать».

Чего индекс не показывает: скорость и задержку (на 2 сентября лаборатория ещё не опубликовала замер для Fable 5.1) и устойчивость в долгих агентных сессиях на сотни шагов; отдельного русскоязычного теста в нём нет. Влияние защитных фильтров в результат уже входит: при их срабатывании модель получает ноль за задачу либо ответ даёт запасная модель. Лидеры этой таблицы меняются каждые несколько недель, поэтому первое место — повод проверить модель на своих задачах, а не аргумент в споре.

Почему модели две

Схема «одна модель, два уровня доступа» появилась у Anthropic в июне с Fable 5 и Mythos 5 и теперь закреплена. Компания прямо пишет, что Fable 5.1 и Mythos 5.1 — «одна и та же базовая модель» (перевод редакции). Разница в защитах: Fable блокирует пентест, генерацию эксплойтов и поиск уязвимостей по бинарникам, а задачи по «двойному назначению» в биологии и химии перенаправляет на модели Opus. Mythos работает с менее строгими защитами, и её выдают под договор: участие в Project Glasswing, хранение данных 30 дней для мониторинга безопасности.

Для обычной разработки, рефакторинга, разбора логов и тестов Fable 5.1 совпадает с Mythos по базовым возможностям везде, где защиты не срабатывают. Для работы по безопасности часть запросов упрётся в фильтр: модель откажется генерировать эксплойт или анализировать бинарник на уязвимости, хотя, по словам Anthropic, уязвимости в исходном коде она находить умеет и делает это в Fable-версии.

Что проверить у себя

• В API замените идентификатор модели на claude-fable-5-1; цены и лимиты те же, миграция сводится к одной строке конфигурации.
• Длинные агентные сценарии (сборка, миграции, многошаговые правки) прогоните на новой модели: именно там Anthropic показывает удвоение результата.
• Сравните режимы усилия: по индексу Artificial Analysis xhigh отстаёт от максимального на один балл, а задача обходится на 28% дешевле.
• Пересчитайте бюджет с учётом кэша: при повторяющемся системном промпте чтение кэша в 40 раз дешевле обычного ввода.
• Если модель раньше отказывала на медицинских или химических темах в безобидном контексте, попробуйте снова: порог срабатывания защиты снижен.
• Подписчики Claude Pro и Max в поддерживаемых регионах получают модель в списке автоматически.

Что дальше

Fable 5.1 расширяет Fable 5 при тех же базовых ценах, так сказано в документации платформы; сроков вывода Fable 5 из API компания не называет. Mythos 5.1 позиционируется как инструмент для киберзащиты и биологических исследований, и расширять круг организаций с доступом Anthropic пока не обещает. В тот же вечер OpenAI объявила, что готовит модель Astra с «критическим» уровнем кибервозможностей и таким же ступенчатым доступом; сравнить обе на одинаковых задачах можно будет только после выхода Astra.

Источники: Claude Fable 5.1 and Claude Mythos 5.1 (Anthropic), Документация модели Fable 5.1, LLM Leaderboard (Artificial Analysis)

Изображение на обложке: скриншот anthropic.com

Выручка сервисов и инфраструктуры для работы с ИИ составила 19,3 млрд рублей, или 51,3% общей выручки компании. За первые восемь месяцев 2026 года объём потребления языковых моделей на платформе Cloud.ru в токенах вырос в 18 раз. Общий объём потребления достиг 480 млрд токенов.

В первом полугодии Cloud.ru продолжил стратегию по расширению практического применения облачных сервисов и ИИ-технологий. Компания предоставляет сервисы крупнейшим потребителям из финтеха, ритейла и ИТ. Чтобы стоимость инфраструктуры и сервисов не ограничивала масштабирование проектов крупнейших потребителей, Cloud.ru в течение длительного времени удерживает цены. Это позволяет клиентам активнее переходить от экспериментов и пилотов к коммерческому внедрению.

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

Стабильное финансовое положение Cloud.ru позволяет продолжать инвестиции и проводить выбранную ценовую политику. В первом полугодии 2026 компания подтвердила высокую оценку кредитоспособности, получив кредитные рейтинги ruАА+ от Эксперт РА и АА+ (RU) от АКРА. Также компания успешно реализовала дебютный выпуск облигаций.

«Cloud.ru сохраняет высокую рентабельность и низкую долговую нагрузку. Это позволяет нам инвестировать в инфраструктуру, безопасность и новые продукты и одновременно поддерживать ценовые условия, стимулирующие рост потребления у крупнейших клиентов. В первом полугодии мы вышли на публичный долговой рынок, диверсифицировав источники финансирования. При этом отношение чистого долга к EBITDA LTM за год снизилось с 0,60x до 0,35x. Устойчивая финансовая позиция позволяет нам принимать решения с расчётом на долгосрочный рост бизнеса и рынка», — отметила Наталия Толченникова, финансовый директор Cloud.ru.

В первом полугодии 2026 года Cloud.ru инвестировал 8,5 млрд рублей в закупку оборудования, разработку программного обеспечения и другие нематериальные активы. Основные направления инвестиций — инфраструктура, безопасность и новые технологии.

Инфраструктура Cloud.ru включает более 46 тыс. единиц ИТ-оборудования, в том числе более 32 тыс. серверов, размещённых в девяти дата-центрах. Общая мощность используемых стоек составляет 58 МВт.

В сфере безопасности Cloud.ru развивает защищённые облачные платформы для государства и крупного бизнеса. Решения компании позволяют размещать государственные информационные системы и объекты критической информационной инфраструктуры и соответствуют наиболее строгим требованиям российских регуляторов. В ИИ-направлении компания развивает платформы и сервисы для практического применения технологий и расширяет доступ к ним как для корпоративных, так и для массовых пользователей.

Cloud.ru — один из крупнейших облачных и ИИ-провайдеров России. Компания основана в 2019 году и за несколько лет вошла в число лидеров рынка инфраструктурных, платформенных, а также ИИ-решений. В портфеле Cloud.ru — более 130 инфраструктурных и платформенных сервисов, публичное облако Cloud.ru Evolution на базе собственных технологий, аттестованная инфраструктура для размещения ГИС и КИИ, платформа для частных и гибридных облаков Cloud.ru Evolution Stack, а также цифровая среда для промышленной работы с генеративным ИИ — AI Factory. В команде компании — более 2 000 специалистов в области ИТ, кибербезопасности и ИИ.

Реклама. Рекламодатель: ООО «Облачные технологии», ИНН 7736279160, erid: 2W5zFGH4yKw

Ниже рассмотрим два кейса: распознавание паспорта в видеопотоке и распознавание свидетельства о рождении по фотографии.

Оценка качества изображения

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

Самостоятельное распознавание на стороне клиента имеет свои особенности: палец, посторонний предмет, блик или голограмма могут перекрыть значимые реквизиты или признаки подлинности документа, а часть кадра может оказаться не в фокусе или за границей снимка. Неважно, произошло это случайно или намеренно: в обоих случаях системе важно вовремя распознать проблему, определить её тип и в реальном времени проинструктировать пользователя, что именно мешает пройти KYC.

Законодательство РФ (включая 115-ФЗ) устанавливает конкретные требования к идентификации личности. Поэтому в случае с распознаванием недостаточно извлечь отдельные поля документа – нужно убедиться, что в кадре присутствуют все данные и элементы, необходимые для проверки. Контроль качества изображения в процессе распознавания документов решает эту задачу вместе с ещё одной: защищает от мошеннических атак.

При этом документы, используемые для подтверждения личности, отличаются форматом, шаблоном и набором защитных элементов, поэтому оценка качества должна учитывать особенности конкретного типа. К этому добавляется разница во входных данных: происходит ли распознавание в видеопотоке или по одному изображению. Дальше разберём два сценария, где эти различия проявляются особенно наглядно – распознавание паспорта в видеопотоке и распознавание свидетельства о рождении по фотографии.

Распознавание в браузере с помощью WebAssembly

Smart ID Engine может работать в браузере в виде WebAssembly-модуля. Это позволяет выполнять распознавание непосредственно на стороне клиента, не отправляя изображение документа на сервер.

Браузеры предоставляют следующие фичи в зависимости от возможностей устройства:

• Single Instruction Multiple Data (SIMD) – использование векторных инструкций процессора, которые позволяют значительно увеличить скорость вычислений.
• Threads – выполнение вычислений параллельно.

Проверить поддержку SIMD-инструкций и многопоточности в браузере можно с помощью библиотеки wasm-feature-detect.

Smart Engines предоставляет набор библиотек для всех комбинаций этих фич:

• nosimd.nothreads – базовая сборка, поддерживаемая везде.
• simd.nothreads – самая быстрая однопоточная сборка, поддерживается почти на всех современных устройствах (Safari 17.1+, Chrome 91+, Firefox 89+); часто является оптимальным выбором.
• simd.threads – сборка с поддержкой многопоточности; требует дополнительных настроек на сервере, но позволяет добиться максимальной производительности.
• nosimd.threads – редкая комбинация, она здесь на всякий случай.

Настройка веб-сервера

До подключения библиотеки к веб-приложению необходимо подготовить сервер, с которого браузер будет получать WASM-модули.

Первые два пункта являются строго обязательными для нормального функционирования библиотеки в браузере.

• Content-Type. Веб-сервер должен возвращать Content-Type: application/wasm для файлов с расширением *.wasm.
• Сжатие. Веб-сервер должен поддерживать компрессию файлов c расширением .wasm. WASM-файлы хорошо сжимаются и это значительно позволит сократить время доставки файлов до клиента. Убедитесь в наличии заголовка content-encoding у файла *.wasm при отдаче сервером. Рекомендуется отдавать wasm-файлы уже сжатыми, чтобы не нагружать сервер сжатием файлов на лету на каждый запрос.
• Поддержка CSP. Если у вас настроена строгая политика безопасности контента (CSP), она заблокирует JIT-компиляцию WebAssembly для защиты от XSS-атак. Для того, чтобы ее включить, необходимо добавить директиву wasm-unsafe-eval. Она разрешает выполнение только WebAssembly и в отличие от unsafe-eval по-прежнему блокирует вызовы JavaScript eval() и new Function(). Без этой директивы загрузка или инстанцирование (создание экземпляра) WASM-модуля будет невозможно.
• Многопоточность. Для использования многопоточной сборки браузеру дополнительно требуется обеспечить изоляцию контекста (Cross-Origin Isolation), настроив на сервере заголовки Cross-Origin-Opener-Policy и Cross-Origin-Embedder-Policy.

Например, в nginx это можно сделать, дописав в конфигурацию:

Камера

Широкоугольная камера

В большинстве современных мобильных устройств размещается несколько камер. По умолчанию браузер использует основной модуль, однако именно на трехкамерных iPhone эти модули не способны фокусироваться на объектах, располагаемых ближе 20 см. Поэтому для съемки документов на iPhone лучше выбирать широкоугольную камеру, если она доступна на устройстве.

При этом на Android широкоугольные камеры могут давать изображение очень низкого качества, поэтому для Android-устройств наиболее универсальным решением будет использовать главный модуль камеры.

Разрешение

Существует распространенное представление о том, что для качественного распознавания изображение необходимо подавать в максимально возможном разрешении. Этот подход был оправдан для алгоритмов предыдущего поколения. Современные системы распознавания зависят от исходного разрешения гораздо меньше. По возможности лучше всегда избегать работы с большим объемом данных, поскольку это так или иначе добавляет накладные расходы на пересылку UI-> Worker->VM WASM.

Оценим необходимое разрешение для случая оценки качества. Для уверенного распознавания и проверки подлинности документа необходимо обеспечить не менее 120 DPI. Физический размер страницы паспорта составляет 88 × 125 мм. Будем считать, что разворот паспорта предъявляется наиболее естественным образом – вертикально. Это означает, что изображение паспорта должно иметь разрешение не менее 591 на 832 пикселей. Паспорт занимает не весь кадр; если он занимает 0.8 по ширине и высоте (около 65% от площади кадра), то необходимое разрешение получится 739 на 1040. Разумеется, лучше обеспечить некоторый запас по DPI и предусмотреть погрешности предъявления. При этом для съемки паспорта РФ лучше подходит формат кадра с соотношением сторон 4:3.

У свидетельства о рождении в формате А4 физический размер 210 × 297 мм или 8,27 × 11,69 дюйма. Если считать, что оно занимает по 0.9 кадра по каждой из сторон, необходимо разрешение 1102 на 1559. Тут также лучше подходит формат кадра 4:3.

В результате, оптимальным будет разрешение кадра 1600 на 1200 в вертикальной ориентации.

Отметим, что как правило у веб-камер даже сравнительно современных ноутбуков разрешение ограничено 720 на 1280 px, что ограничивает распознавание документов А4, таких как свидетельство о рождении. Дополнительно ситуацию может ухудшить отсутствие автофокуса.

Поскольку для качественного распознавания важно как именно пользователь предъявляет документ, хорошей идеей будет дать ему подсказку: отрисовать достаточно крупную рамочку или маску документа.

Пример работы с камерой

Открываем камеру для съемки видео:

На Android и iOS, при одинаковых настройках, камера может инициализироваться в различной ориентации. Чтобы всегда инициализировать камеру в портретной или ландшафтной ориентации согласно положению телефона, можно использовать следующий подход:

Базовые понятия библиотеки распознавания

После настройки веб-сервера можно переходить к интеграции распознавания. Ниже приведены базовые понятия библиотеки распознавания Smart Engines.

• Движок распознавания: создается один раз при старте приложения. От него создаются следующие элементы интерфейса:
• Сессия распознавания: процесс распознавания конкретного документа (паспорта РФ, ВУ, СТС и других – всего библиотека поддерживает более 3000 типов). В сессию можно передать одно изображение или серию кадров из видеопотока: с каждым новым кадром результат уточняется; система автоматически определяет оптимальный момент остановки сессии распознавания.
• Настройки сессии: хранят список доступных для распознавания типов документов (определяется конфигурационным бандлом), дополнительную информацию о каждом документе, а также позволяют настроить процесс распознавания: задать список ожидаемых типов документов для сессии распознавания, включить\выключить проверки признаков подлинности, задать таймаут для сессии распознавания и пр. Настройки создаются перед созданием самой сессии и не могут редактироваться в процессе распознавания.
• Результат распознавания: объект со структурированными текстовыми полями, изображениями (например, фото владельца), координатами документа на кадре и данными проверок подлинности.

Общая логика работы одинакова для любой платформы и любого продукта линейки Smart Engines: движок → настройки сессии → создание сессии → передача изображения / последовательности изображений → разбор результата.

Инициализация движка распознавания

Необходимо создать и инициализировать один экземпляр движка распознавания. Инициализация является достаточно «тяжелой» операцией, поэтому ее следует выполнять вне потока пользовательского интерфейса. Для этого используется Web Worker.

При распознавании в браузере полезно учитывать следующую опцию инициализации:

• bool lazy: ленивая и неленивая инициализация. При ленивой инициализации все необходимые ресурсы конфигурируются во время первого обращения к ним (как правило, при обработке первого кадра). Это позволяет эффективно использовать память при использовании библиотеки с большим набором поддерживаемых документов, но немного замедляет распознавание первого кадра. В неленивом режиме все ресурсы конфигурируются во время инициализации движка.

В случае наличия 1-2 документов в движке оптимальным будет использование не ленивой инициализации для ускорения обработки первого кадра, а в случае большого количества документов предпочтительнее использовать ленивый режим.

Конфигурирование сессии распознавания

Маска и режим

Сессия должна быть сконфигурирована для обнаружения конкретного типа документа или группы документов. Это осуществляется благодаря двум параметрам: маска (docTypes) и режим (mode):

Возможные значения маски и режима можно посмотреть в README конкретного WASM-модуля. Для примера с паспортом и свидетельством о рождении выберем режим anyrus (все российские документы) и любой тип (*).

Индивидуальная подпись (signature) привязана к конкретной сборке и необходима для инициализации сессии распознавания. Подпись представляет собой строку в 256 символов. activationUrl – адрес сервера активации, про который речь пойдет в следующем разделе.

Терминальность

В случае видеопотока необходимо определить момент, когда закончить передавать кадры в сессию и решить, что результат распознавания является финальным. Сессия может завершиться в следующих случаях:

• Stoppers. Когда все поля уверенно распознались, движок выставляет результату флаг "терминальности". В этом случае подача дополнительных кадров не улучшит результаты.
• Timeout. Когда истек заданный таймаут, чтобы ограничить возможное ожидание пользователя. Для режима Quality Gate характерное значение таймаута составляет около 15 секунд, чтобы пользователь успел скорректировать найденные проблемы.

Для такой настройки сессии необходимо поставить опции:

Quality Gate

Для включения Quality Gate необходимо указать следующие опции:

Последняя опция добавит вывод проективно исправленного и обрезанного изображения с лучшего кадра: как будто паспорт отсканировали и вырезали по границам.

Активация сессии распознавания

Поскольку WASM-модуль загружается с сервера на устройство пользователя, его достаточно легко скопировать. Для защиты от несанкционированного использования Smart ID Engine предусматривает привязку к инфраструктуре заказчика с помощью механизма активаций.

Перед каждой передачей изображения в сессию необходимо проверить, активирована ли она. Для активации сессия генерирует динамический ключ, который необходимо передать на сервер и вернуть ключ активации обратно в сессию. Только после успешной активации сессия готова принимать изображения.

Рассмотрим пример. Создадим сессию:

Активируем сессию:

Теперь сессию можно использовать для распознавания.

Изображение и процесс распознавания

Создание объекта изображения документа Image

В браузере библиотека Smart Engines работает только с сырыми пикселями RGBA/RGB/YUV. Работа со сжатыми форматами jpg/gif/png/heic переложена на canvas браузера. Это позволяет читать изображения как с камеры, так и получить поддержку всех нативных форматов платформы и даже работу с PDF.

Так или иначе необходимо создать изображение в виде объекта и получить переменную со ссылкой на него.

Процесс распознавания

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

Сократить объем таких кадров можно уже на этапе построения пользовательского сценария. Если открытие камеры одновременно запускает распознавание, имеет смысл предусмотреть небольшую задержку перед началом анализа. Пользователю в любом случае требуется время, чтобы достать документ и правильно расположить его в кадре. Длительность задержки лучше подобрать эмпирически для конкретного сценария.

Разбор результата распознавания с оценкой качества

В качестве результата система Smart Engines возвращает набор распознанных полей с текстом или изображениями (например, поле фотографии). При включении проверки качества в результат добавляется поле image_quality_score, которое содержит численную оценку качества изображения от 0 до 1, а также атрибут reason, который содержит список проблем изображения. Возможные проблемы:

• finger_is_found (Найден палец)
• zone_is_invalid (Зона обрезана)
• hlt_is_found (Найден блик)
• optic_is_found (Найдена голограмма)
• «low DPI» (Низкое разрешение)
• focus (Кадр не в фокусе)
• luminosity (Слишком темно / слишком ярко)

При включении опции common.extractRectifiedDocumentImage добавляется поле-изображение rectified_document_image, содержащее проективно исправленное изображение.

Кроме того, движок возвращает координаты документа, найденных полей и проблемных точек в рамках структуры TemplateSegmentationResult в виде координат точек и радиуса проблемной зоны. Если пользователь закрыл часть контента пальцами, то там окажутся координаты пальцев, которые не позволяют движку прочитать информацию.

После распознавания очередного кадра можно дать пользователю подсказку: нарисовать положение проблемных точек или вывести сообщение о проблеме с фокусировкой камеры, освещением и т.п.

Интеграция распознавания в веб-приложение

Рассмотрим интеграцию распознавания паспорта РФ в видеопотоке в веб-приложение. Чтобы распознавать изображения с камеры в реальном времени, понадобятся элементы video и canvas для вывода изображения с камеры.

Кнопка для начала распознавания изображения:

Блок для вывода результатов распознавания:

Клиентский JavaScript-код

Работа с камерой

В JavaScript-файле запрашиваем видеопоток с камеры:

И направляем его в элемент video на странице:

Теперь на странице отображается видео с камеры.

Передаём видео в canvas.

Чтобы захватывать и передавать кадры на распознавание, необходимо предварительно отрисовать их на canvas.

Подключение движка

В процессе подключения движка определяются возможности среды исполнения (поддержка SIMD и многопоточности), и подключается соответствующий Wasm-модуль.

Подключение веб-воркера

Подключим веб-воркер и передадим ему тип документа, который собираемся распознать:

По нажатию на кнопку, отправляем воркеру кадр из видео на распознавание:

Результат распознавания содержит текст и изображения отдельных элементов документа, выведем их:

Выведем результаты оценки качества:

При обнаружении пальца на кадре, движок возвращает координаты проблемных точек в виде кругов. Их можно использовать для визуализации на канвасе, чтобы пользователь заметил что загораживает документ.

В приведенном коде выход из цикла обработки кадров осуществляется с учетом результатов распознавания и таймаута сессии. Можно дополнительно учесть результаты проверки качества и не останавливаться, пока пользователь не добьется качественного изображения. Финальное условие выхода, учитывающее качество распознавания, качество изображения и таймаут, будет иметь вид:

Веб-приложение с возможностью распознавания изображений готово. Для распознавания фотографии свидетельства о рождении отпадает необходимость ожидать терминальности сессии, а в остальном работа с распознающим движком или обработка результатов не будут отличаться.

Управление памятью

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

Библиотека никак не может знать, когда созданные ресурсы перестают использоваться, а сборщик мусора никак не может повлиять на память, выделяемую в нативной части. Поэтому обязательно необходимо удалять за собой сессии, изображения и результат распознавания когда в них уже нет нужды.

Пример освобождения памяти в finally, после получения данных о распознанном кадре:

Заключение

Распознавание документов в браузере требует не только переноса OCR на веб-страницу, но и построения полноценного пользовательского сценария предъявления документа. Контроль качества изображения играет в нем определяющую роль, позволяя одновременно решать две задачи:

• оценивать читаемость данных и при необходимости помогать пользователю;
• защищаться от атак на предъявление в случае намеренного перекрытия реквизитов или значимых признаков подлинности документов.

Такой механизм позволяет минимизировать число неудачных попыток и сделать процесс идентификации прозрачным и максимально удобным для пользователя. А выполнение обработки непосредственно в браузере с помощью WebAssembly дает возможность реализовать этот сценарий непосредственно на пользовательском устройстве – без передачи изображений документов на внешний сервер.

Браузерное распознавание документов – не единственный вариант интеграции SDK Smart Engines. Та же библиотека может работать и на сервере, как часть десктоп-приложения (например, для работы с планшетными сканерами и веб-камерами) или мобильные приложения. Выбор конкретного варианта зависит от того, какие документы нужно распознавать и откуда поступает изображение – подробнее об этом можно прочитать на сайте Smart Engines.

Реклама. Рекламодатель: ООО «Смарт Энджинс Сервис» ИНН 7728328449, erid: 2W5zFK8Vyh3

В этой статье соберём работающего RAG-бота, который отвечает на вопросы о любой веб-странице, примерно на 60 строках Python. Никаких парсеров HTML, headless-браузеров и сложных фреймворков — только requests, локальная Ollama и чистый Markdown.

Что такое RAG

RAG (retrieval-augmented generation) — это подход, при котором языковая модель не отвечает по своей памяти, а сначала ищет релевантные фрагменты во внешнем тексте, а потом генерирует ответ на их основе. Это резко снижает галлюцинации и позволяет работать с данными, которых не было в обучающей выборке.

• RAG-бот на Python укладывается в ~60 строк и работает без облачных LLM.
• Самое неприятное в RAG-пайплайне — очистка HTML; готовый Markdown API убирает эту работу.
• Текст разбивается на чанки (~1200 символов), каждый превращается в эмбеддинг и сравнивается с эмбеддингом вопроса.
• Локальные модели nomic-embed-text и llama3 через Ollama не требуют иностранных карт и VPN.
• Качество ответа зависит от качества исходного текста: сырой HTML зашумляет поиск, чистый Markdown улучшает ретривл.

Что мы соберём

Архитектура бота простая и универсальная:

1. Отправляем URL в сервис извлечения текста и получаем чистый Markdown.
2. Разбиваем Markdown на фрагменты (чанки) по границам абзацев.
3. Превращаем каждый чанк в вектор — эмбеддинг.
4. То же самое делаем с вопросом пользователя.
5. Находим чанки, ближайшие к вопросу, по косинусной близости.
6. Отдаём найденные фрагменты + вопрос языковой модели с инструкцией отвечать только по контексту.

Такая схема легко масштабируется: можно заменить локальную Ollama на OpenAI, Anthropic или российские модели, а векторы перенести в Qdrant или Chroma.

Что понадобится

• Python 3.9+
• Библиотека requests
• Локально запущенная Ollama с моделями nomic-embed-text и llama3
• Доступ к API извлечения текста (в примере — Web to Markdown/JSON API; бесплатный тариф даёт 50 запросов в сутки)

Код бота

Сохраните скрипт как rag_bot.py и подставьте свой ключ, если сервис извлечения текста требует авторизации:

На что обратить внимание:
Если вы используете RapidAPI-версию сервиса, запрос к API_URL обычно требует заголовка X-RapidAPI-Key. Без ключа бесплатный endpoint может вернуть 401.

Разбор по частям

fetch_markdown — единственный внешний вызов. Сервис сам забирает страницу, убирает навигацию, баннеры и футер и возвращает Markdown: заголовки, абзацы, списки. Это освобождает от зависимостей вроде BeautifulSoup или headless Chrome.

chunk_markdown режет текст на фрагменты примерно по 1200 символов, не разрывая абзацы. Мелкие чанки дают более точный ретривл, но увеличивают число эмбеддингов; для начала 1200 символов — хороший баланс.

embed и cosine превращают текст в векторы и считают их близость. Модель nomic-embed-text из Ollama бесплатна, быстрая и неплохо понимает русский и английский.

answer эмбеддит вопрос, выбирает три самых похожих чанка и строит промпт с жёстким ограничением: отвечать только по контексту. Это главная страховка от галлюцинаций.

Запуск

Установите зависимости и скачайте модели в Ollama:

Если всё в порядке, в консоли появится примерно такой результат:

Почему важен чистый Markdown

Если скормить эмбеддинг-модели сырой HTML, в векторах окажутся теги <div>, меню навигации и копирайты из футера. В результате поиск похожести выдаст «Copyright © 2026» вместо полезного ответа. Чистый Markdown — заголовки, абзацы, списки — улучшает качество ретривла почти бесплатно.

Если не хочется зависеть от внешнего API, можно заменить fetch_markdown на один из альтернативных вариантов:

• trafilatura — библиотека на Python для извлечения главного текста.
• r.jina.ai/http://URL — бесплатный сервис без ключа.
• Firecrawl — API с поддержкой сканирования сайтов целиком.
• ScrapingBee — прокси + рендеринг для сложных страниц.

Для российских разработчиков локальная Ollama особенно удобна: модели качаются бесплатно, не нужны иностранные карты, а инференс идёт на своём железе.

Куда развивать

• Направьте бота на документацию, чейнджлог или блог конкурента и задавайте вопросы по ним.
• Замените Ollama на OpenAI, Anthropic, Gemini или российские модели — функция answer меняется в двух строках.
• Сохраняйте эмбеддинги в векторную БД: Chroma, Qdrant или FAISS, чтобы индексировать сразу много страниц.
• Используйте формат json вместо Markdown, если нужна структура: параграфы, заголовки, ссылки — отдельно.

Выводы

RAG — не магия, а последовательность простых шагов: получить чистый текст, разрезать его на фрагменты, найти ближайшие к вопросу и отдать их модели. Весь минимальный пайплайн укладывается в короткий Python-скрипт, который можно запустить на своём ноутбуке.

RAG работает ровно так хорошо, каков текст, который вы ему скармливаете. Уберите самую утомительную часть — очистку HTML, — и останется интересное: поиск и генерация.

Исходник идеи — статья «Chat With Any Website: Build a RAG Bot in ~60 Lines of Python». Попробуйте собрать бота на своей странице и посмотрите, где он справляется, а где начинает фантазировать.

Поиск по документам

LlamaIndex создан для работы с документами: он помогает разбивать их на фрагменты, индексировать содержимое и находить нужный контекст перед запросом к модели. В библиотеке уже есть компоненты для этих этапов, поэтому базовый поиск по документам можно собрать без большого объёма собственного кода.

Для поиска можно использовать гибридный подход, который объединяет семантический поиск с поиском по ключевым словам. Он пригодится, когда в запросе есть точный термин, название или аббревиатура и важно найти конкретное совпадение.

В LangChain RAG можно собрать как один из сценариев работы с данными. В LlamaIndex это центральная задача, вокруг которой выстроена вся архитектура, поэтому его удобно использовать для внутренних баз знаний, технической документации и договоров, когда ответ должен опираться на конкретный фрагмент исходного документа и сопровождаться ссылкой на источник.

Сложная логика и состояние

В сложном процессе следующий шаг может зависеть от результата предыдущего: агент получает новые данные, меняет маршрут выполнения и при необходимости возвращается к нужному этапу. Для подобных сценариев подходит LangGraph, отдельная библиотека команды LangChain. Процесс в нём описывается как граф с узлами, переходами и сохранённым состоянием: узлы выполняют отдельные операции, переходы задают маршрут, а разработчик определяет условия для перехода между этапами.

Например, при проверке заявки агент может обнаружить, что информации недостаточно, отправить её на дополнительный сбор данных, получить обновлённую информацию и снова запустить проверку. В LangGraph разработчик сам описывает логику этих переходов и решает, в какой момент процесс должен двигаться дальше или возвращаться к предыдущему шагу.

К модели LangGraph нужно привыкнуть: сначала граф с узлами, переходами и состоянием может напоминать схему метро, которую нарисовали в три часа ночи. По мере работы с графом становится проще видеть весь маршрут агента и понимать, что произойдёт после каждого шага.

Экосистема LangChain включает более 1000 интеграций и большую базу документации, поэтому подключение инструментов и сервисов во многих случаях можно собрать из готовых компонентов. LangChain отвечает за компоненты для работы с моделями и инструментами, а LangGraph помогает управлять состоянием и переходами между этапами процесса.

Разделение работы между ролями

Представим редакцию, где несколько сотрудников вместе готовят материал. Один собирает факты, другой проверяет информацию, после чего редактор готовит финальную версию. CrewAI переносит подобную организацию работы на агентов: для каждого участника задаются роль и задача, а фреймворк управляет их взаимодействием в рамках общего процесса.

В CrewAI процесс строится вокруг задач и их исполнителей, поэтому разработчику достаточно описать обязанности агентов и порядок выполнения работы. Фреймворк берёт на себя координацию между участниками и передачу результатов от одной задачи к следующей.

Примечательно, что CrewAI появился позже LangChain и LlamaIndex, поэтому у него меньше накопленных примеров продакшн-использования. Для систем с высокими требованиями к предсказуемости стоит протестировать выбранную конфигурацию на собственных данных и сценариях до запуска в продакшн.

Диалог между агентами

AutoGen строит взаимодействие между агентами через сообщения. Они передают друг другу результаты, вызывают инструменты и могут выполнять код в изолированной песочнице. У фреймворка была тесная интеграция с Azure OpenAI, а AutoGen Studio позволял собирать агентные сценарии через визуальный интерфейс без кода.

Именно вокруг этой модели Microsoft развивала AutoGen до перехода на новый SDK. 3 апреля 2026 года компания выпустила Agent Framework 1.0, объединив в нём наработки AutoGen и Semantic Kernel. AutoGen перешёл в режим поддержки: новых функций в него добавлять не будут, а обновления будут включать исправления ошибок и патчи безопасности. Для новых проектов Microsoft рекомендует Agent Framework.

При этом сама идея AutoGen сохранилась в новой платформе. Диалог между агентами вошёл в Agent Framework вместе с другими концепциями AutoGen, поэтому разработчики по-прежнему могут строить процессы вокруг обмена сообщениями. Меняется основной SDK, который Microsoft развивает для этого подхода.

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

Можно ли сочетать фреймворки

Границы между сценариями редко бывают жёсткими. В одном проекте LlamaIndex может отвечать за поиск по данным, а LangGraph — за выполнение процесса: инструменты LlamaIndex подключают внутрь CrewAI-команды или LangGraph-графа как обычный инструмент для поиска, оставляя LlamaIndex индексацию, а LangGraph или CrewAI — общую логику. LangGraph всё чаще выступает низкоуровневым движком, поверх которого строят более специализированные надстройки.

Как выбрать модель

Все четыре фреймворка подключают языковые модели через API, поэтому провайдера можно выбирать отдельно от архитектуры агента. В LangChain для этого используются интеграции вроде ChatOpenAI, в LlamaIndex есть адаптер OpenAILike, а CrewAI и AutoGen позволяют указать адрес совместимого API через настройки модели. При смене эндпойнта основная логика агента может остаться прежней, поскольку меняются параметры подключения к модели.

Например, в LangChain модель можно подключить через OpenAI-совместимый API:

RouterAI даёт доступ к GPT, Claude, Gemini и другим моделям через один ключ с оплатой в рублях — CrewAI, AutoGen и LlamaIndex принимают тот же base_url через собственные параметры конфигурации LLM.

Итог

Форма задачи определяет выбор раньше, чем популярность инструмента на GitHub: поиск по данным — LlamaIndex, ветвящаяся логика с состоянием — LangGraph, роли внутри команды — CrewAI, спор между агентами — AutoGen. Модель и провайдер при этом выбираются отдельно от архитектуры агента.

Источники и фактура

• LangChain vs LangGraph — официальная документация
• Integrations overview — LangChain Reference
• Microsoft Agent Framework Version 1.0 — официальный анонс
• LlamaIndex OpenAILike — документация
• LlamaIndex + CrewAI интеграция — сравнение фреймворков

В AutoGPT, где на момент интервью у репозитория было свыше 180 тысяч звёзд и 150 открытых PR, большая часть этих PR создана агентами: Copilot, OpenClaw, собственными инструментами команды и сторонними ботами. Большинство мейнтенеров реагируют просто: закрыть дверь, отключить пулреквесты, не тратить силы на чужой LLM-вывод. Но у Николаса Тиндла, одного из основателей ИИ-инженерии в AutoGPT, другой взгляд: «По сути, кто-то другой платит за ваши вычислительные ресурсы. Если контрибьютор хочет потратить свои токены на улучшение вашего проекта — пусть тратит. Главное, сделать так, чтобы единственный путь внутрь проходил через ваши правила.»

ИИ-first контрибьютор — это разработчик, который отдаёт написание кода, тестов или документации генеративной модели, либо самоходный агент, который клонирует репозиторий, ищет issue, пишет код и открывает PR. Для мейнтенера результат одинаков: в репозиторий приходит поток кода, который часто не учитывает контекст проекта и требует ревью.

Агенты не ищут документацию сами — они читают то, что лежит рядом с кодом. AGENTS.md и CLAUDE.md в нужных директориях работают лучше, чем вики.

Пропускные ворота должны быть автоматическими и однозначными: шаблон PR, тест-план, CI как стена, CLA как детектор человека.

Не все ворота стоит оставлять включёнными: автоматические комментарии об ошибках CI быстро превращаются в шум.

Плохой AGENTS.md хуже, чем его отсутствие: избыточные инструкции засоряют контекст и ломают поведение агентов.

Мейнтенер всё ещё решает, что принимать: закрыть PR и переписать самому — тоже валидный выбор.

Проблема не в документации, а в её обнаружении

Первое, что пробовала сделать AutoGPT, — улучшить CONTRIBUTING.md, написать подробную вики и обновить гайды. Это не сработало. Дело в том, что агенты не ходят по ссылкам и не ищут документацию в разделах репозитория. Они смотрят на то, что находится в текущей директории и на один-два уровня выше. Если инструкция не лежит там, где агент работает, для него её не существует.

Сначала команда добавила файлы CLAUDE.md, потому что Claude открывал пулреквесты без достаточного контекста о репозитории. Потом выяснилось, что Copilot и Codex эти файлы игнорируют — они не Claude. Решением стал централизованный AGENTS.md, на который указывают все специфичные для модели файлы.

Важный нюанс: AGENTS.md действует внутри директории. Если агент работает в backend/, он видит правила для бэкенда. Если динамически загружается навык, связанный с фронтендом, агент может не знать, в какой директории искать инструкции — и навык сам должен ему подсказать путь. Поэтому в AutoGPT файл AGENTS.md лежит рядом с кодом, который он регулирует.

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

Фронтенд-инженер AutoGPT устал от одного и того же класса сломанных PR в open source-проекте и оформил гайд как навык. Теперь каждый агент, который касается репозитория, видит триггер и выполняет правило. Бэкенд делает то же самое: не набрал 80% покрытия — PR не пройдёт.

Ворота для ИИ-контрибьюторов в open source

AutoGPT выстроила несколько механизмов, которые сдерживают поток низкокачественных пулреквестов и заставляют агентов вести себя предсказуемо.

Шаблон пулреквеста как пропускной пункт

В шаблоне PR прямо написано: PR, не соответствующий шаблону, закрывается автоматически и без колебаний. Команда даже построила бота, который это делает. Но запускать его не понадобилось — само правило изменило поведение агентов. Агенты стали заполнять шаблон. А вот люди иногда его игнорировали, и это Тиндл считает полезным сигналом: «Если вы не следуете шаблону, вы, скорее всего, человек, и я отнесусь к вам мягче.»

Тест-план, который запускает код

В шаблоне есть раздел тест-плана, и его формулировка незаметно подсказывает агенту протестировать пулреквест. Эта фраза активирует навык test PR: агент устанавливает браузер, разворачивает приложение и проверяет изменение. Агент пришёл поставить галочку, а в итоге запустил код. После этого сломанные PR стали редкостью. Осталась другая проблема — PR, которые работают, но не вписываются в дорожную карту.

CI — стена, а не рекомендация

Codecov и другие проверки настроены как required checks. Агент открывает PR, через несколько минут видит, что мёрж заблокирован, загружает навык с тестами и добивается покрытия. Никто не просил — инфраструктура сама направила агента.

CLA (Contributor License Agreement) как детектор человека

AutoGPT использует двойную лицензию, но Тиндл советует лицензионное соглашение участника (Contributor License Agreement, CLA) любому проекту, даже MIT. Подписание требует браузера и OAuth-потока GitHub на отдельном домене. Сегодня агенты с этим справляются плохо — и это хорошо, потому что большинство мейнтенеров не хотят, чтобы агент ходил в GitHub от их имени. Если CLA не подписан в течение недели, PR закрывается с комментарием «подпишите CLA и переоткройте».

SHA коммита перед закрытием замечания

Часть агентов закрывает все треды ревью, не исправляя код. В AutoGPT есть навык pr-address, который описывает допустимую последовательность: исправить, закоммитить, запушить, ответить, потом разрешить тред. Ответ должен содержать полный SHA коммита, полученный через git rev-parse HEAD, чтобы агент не подсунул старый хеш. Навык явно называет антипаттерны: «Acknowledged» — не исправление, и ссылка на коммит, который не трогает указанную строку, тоже не считается.

Ворота, от которых пришлось отказаться

Когда CI падает, AutoGPT изначально запускала агента, который читал лог и писал комментарий, что сломалось. Первая версия использовала Claude Code внутри GitHub Actions с аутентификацией в CI — лишняя широкая учётная запись. Потом перешли на Copilot внутри рабочего процесса: тот же результат, но без лишних кредов.

А потом выключили именно автоматические комментарии об ошибках CI. Прогоны в AutoGPT падают часто, и бот, который целыми днями описывает каждый падший прогон, создаёт не меньше шума, сколько и сами ошибки. Урок: оставляйте то, что снижает нагрузку на мейнтенера, и выключайте то, что превращается в фоновый шум.

Четыре ловушки, которые стоит записать

• Плохой AGENTS.md хуже, чем его отсутствие. В AutoGPT сначала разбросали файлы повсюду и засорили контекст. Если поведение агентов ухудшилось — перечитайте, что вы написали.
• GraphQL API GitHub быстро исчерпывает лимит запросов. Если каждый инструмент в команде ходит в CLI как отдельный пользователь, лимит закончится. Создайте GitHub App и аутентифицируйте CLI через неё.
• Сложное ревью стоит реальных денег. У AutoGPT PR проходит через клон ветки, восемь агентов с разными ролями, запуск стека и скриншоты. Круто, но дорого. Сейчас эту процедуру запускают только для совсем маленьких или крупных PR.
• Проверяйте авторизованные приложения. Каждый протестированный инструмент оставляет OAuth-разрешение. Если перестали использовать приложение — удалите его из настроек GitHub.

Не всё в open source решается воротами

Тиндл подчёркивает два тезиса, которые не связаны с инструментами. Первый: вы не обязаны принимать каждый пулреквест. Мёржить чужой LLM-вывод — асимметричная сделка: вы будете поддерживать этот код вечно. Закрыть PR и переписать решение самому — валидный выбор.

GitHub даёт мейнтенерам ручки: можно отключить пулреквесты целиком, ограничить создание issue только участникам с правами collaborator или требовать предварительного обсуждения. Если хотите — вообще закройте приём внешнего кода, как это сделали в SQLite: они принимают только баг-репорты. У вашего проекта тоже может быть своя граница.

Второй тезис: когда вы закрываете PR, но переписываете его идею сами, добавьте автора как соавтора, если это уместно. В AutoGPT 800 контрибьюторов, и один дополнительный соавтор ничего не стоит. Для большинства людей важно, что их проблему заметили и исправили.

Выводы

Open source развивался, делая сотрудничество явным: лицензии формализовали разрешения, issue сделали работу видимой, пулреквесты превратили ревью в общую практику. Инструкции для агентов в репозитории — следующий шаг в этом направлении. Правильная форма ещё не устоялась: у AutoGPT уже третья версия AGENTS.md, и она появилась потому, что команда сначала развёртывала плохие версии и смотрела, что с ними делают агенты.

Тиндл советует мейнтенерам записываться в программу обратной связи GitHub — maintainers.github.com:

You've got to go there. You've got to sign up. It gets you all the connections you want at GitHub. That's where I learned about all this stuff, and where I share it.

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

Если тема интересна, загляните в разделы tproger: open source, GitHub и искусственный интеллект.

Источник: GitHub Blog — Your contributors are AI-first now. Is your project?

Что Anthropic сделала с текстом Claude

2 августа 2026 года в ЕС вступили в силу обязательства по прозрачности ИИ-контента из AI Act. В июле 2026-го Anthropic, как и около 190 других организаций, подписала Кодекс практики по прозрачности ИИ-контента. Теперь компания заявляет, что все новые модели Claude будут «маркировать» сгенерированный текст — и делать это глобально, а не только для пользователей из Евросоюза.

Сначала Anthropic лишь кратко сообщила о маркировке в справочной статье «How Claude marks AI-generated content». 14 августа 2026 года появилось техническое объяснение «How Claude’s text watermark works». В нём компания признаёт: водяной знак не добавляет в текст никаких символов, он меняет выбор слов на основе секретного ключа.

Новые модели Claude будут встраивать статистический водяной знак во все тексты длиннее ~200 токенов (~150 слов).

Маркировка не использует невидимые символы: она смещает выбор между близкими по смыслу словами по секретному ключу.

Проверить водяной знак сможет только Anthropic; посторонние сервисы без ключа не смогут дать достоверный вердикт.

Переводы и переписывания целиком проходят через Claude, поэтому маркируются сильнее всего; обычная правка — слабее.

Чтобы снизить риск, используйте Claude как черновик, а затем переписывайте текст своими словами.

Как работает водяной знак в тексте

Большие языковые модели генерируют текст по одному токену. На каждом шаге у них есть список подходящих кандидатов, и иногда несколько вариантов равноправны по смыслу. Например, после фразы «погода сегодня была холодной и…» модель может выбрать «пасмурной» или «серой». Обычно выбор решает случайность. При водяном знаке случайность заменяется на псевдослучайную последовательность, выведенную из секретного ключа и нескольких предыдущих слов.

Anthropic использует вариант подхода SynthID-Text, опубликованного Google DeepMind в Nature в 2024 году. На каждом «равноправном» шаге модель получает лёгкий «подталкивающий» сигнал в сторону одних кандидатов и от других. Отдельный выбор почти незаметен, но на длине в сотни или тысячи токенов накапливается статистическая закономерность, которую может увидеть только владелец ключа.

Главный нюанс:
Секретный ключ есть только у Anthropic. Поэтому никакой сторонний «детектор ИИ-текстов» не сможет проверить водяной знак Claude — он либо будет искать стилистические признаки, либо угадывать.

Почему это спорно: слова имеют значение

Аргумент критиков прост: никакие два синонима не совпадают по оттенку, ритму и контексту. «Он ухватился за шанс» и «Он воспользовался возможностью» передают одно действие, но звучат по-разному. Если модель выбирает слово не только ради точности, но и ради скрытой метки, качество текста теоретически падает — пусть и на доли процента.

В документе Anthropic приводится пример: выбор между «overcast» и «grey» «в большинстве случаев не сильно влияет на читателя». Джон Грубер в ответ замечает: именно это и делает идею порочной. Компания решает за автора, какое слово «достаточно хорошо», вместо того чтобы каждый раз искать лучшее.

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

Что это меняет для пользователей

Anthropic честно перечисляет ограничения, но именно они создают проблемы. Водяной знак не доказывает, что текст написал Claude целиком: он лишь повышает вероятность, что Claude участвовал в его создании. Перевод, выполненный Claude, будет маркирован полностью, потому что каждое слово выбрала модель. А вот лёгкая правка человеческого текста может оставить лишь слабый след.

Код в большинстве случаев почти не страдает: там часто есть единственно правильное продолжение. Но комментарии и документация в коде маркируются так же, как обычная проза. Кроме того,Anthropic отмечает, что водяной знак переживает копирование и вставку: он живёт в самой последовательности слов, а не в форматировании.

• Переводы: полная маркировка, потому что каждый токен — выбор модели.
• Лёгкая правка: может оставить след, но не всегда достаточный для детекции.
• Глубокий переписывание: разрушает статистическую картину, но тогда результат уже сложно назвать ИИ-текстом.
• Код: функциональные части почти не меняются, комментарии — подвержены.

Почему это касается не только ЕС

Формально инициатором маркировки стал ЕС: AI Act обязывает провайдеров ИИ маркировать синтетический контент. Но Anthropic объявила о глобальном внедрении, сославшись на отсутствие «устойчивого способа» ограничить функцию по региону. Получается, что европейское регулирование распространяется на всех пользователей Claude, включая тех, кто живёт в России, США и Азии.

При этом неясно, насколько само регулирование требует именно такого подхода. Кодекс практики применяется к текстам длиннее 200 токенов, требует запрета на удаление метки в условиях использования и устойчивости к копированию, OCR и переводам. Но он не обязывает внедрять систему глобально и не заставляет провайдера изменять слова в приватных чатах.

Google уже делает то же самое с Gemini

Google внедрила текстовый водяной знак SynthID в Gemini раньше Anthropic. В статье Nature команда DeepMind пишет, что проанализировала около 20 млн ответов с водяным знаком и без него. Разница в оценках «палец вверх» составила 0,01%, а «палец вниз» — 0,02%; оба отличия оказались статистически незначимыми в пределах 95%-ного доверительного интервала.

Критики указывают: незначимая разница в оценках не означает, что качество не пострадало. Если модель заменяет «bananas» на «pineapple» в примере DeepMind, пользователь вряд ли поставит «дизлайк» из-за фрукта. Но именно такие микровыборы и формируют голос автора. А когда причина выбора скрыта, доверие к тексту падает.

Что делать авторам и разработчикам

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

FAQ

Выводы

Водяной знак Claude — это не злоумышленная функция, а попытка угодить регулятору. Но её побочный эффект серьёзен: модель начинает выбирать слова ради проверяемости, а не ради смысла. Для авторов, юристов, журналистов и разработчиков это означает, что любой прогон текста через Claude может оставить след, который увидит только Anthropic.

Пока публичного детектора нет, риск ложных обвинений невелик. Но как только API проверки появится, вопрос «а не написано ли это ИИ?» станет ещё более неоднозначным. Лучшая защита — не отказываться от инструментов, а помнить: черновик от ИИ — это черновик. Финальный текст должен быть вашим.

Моя письменная работа — это моя работа, а текущая стратегия Anthropic агрессивно враждебна писателям.

Источники

— John Gruber, «Anthropic’s ‘Watermark’ Text Adulteration in Claude Is a Perversion of Writing»
— Anthropic, «How Claude’s text watermark works»
— James Padolsey, «How AI text watermarking works»
— Google DeepMind, «Scalable watermarking for identifying LLM outputs» (Nature, 2024)
— EU Code of Practice on Transparency of AI-Generated Content

Computer History появилась в десктопном ChatGPT для macOS и фиксирует действия пользователя как «события».

Данные превращаются в обучающий материал: ChatGPT и Codex используют их, чтобы возобновлять задачи и предлагать автоматизацию.

Функция работает по принципу opt-in и позволяет исключать приложения и сайты, а также удалять отдельные записи.

OpenAI утверждает, что Computer History не делает скриншотов, видео и аудиозаписей — только текстовые события.

Содержимое вкладок incognito и private mode браузеров игнорируется автоматически.

Что такое Computer History

По сути, это аналог Windows Recall от Microsoft, но без главного спорного момента — постоянных скриншотов экрана. Вместо изображений macOS-приложение ChatGPT фиксирует events: какие документы открывались, в какие поля вводился текст, между какими окнами переключался пользователь.

В демонстрации сотрудник OpenAI Dominik Kundel попросил ChatGPT найти последний отредактированный документ, проверить, был ли он отправлен коллегам в Slack, и составить краткий отчёт о том, как прошло его утро. Всё это ИИ взял из собранной истории действий.

Кто видит данные и как управлять функцией

Функция включена только с согласия пользователя — opt-in, а не opt-out. Можно исключить отдельные приложения и сайты из сбора, а также удалить любую запись вручную. Ari Weinstein, менеджер по продукту и инженерии в OpenAI, уточнил, что Computer History автоматически пропускает содержимое вкладок в режиме инкогнито или приватного просмотра.

Выводы

Computer History — ещё один шаг OpenAI к тому, чтобы ChatGPT стал не просто чатом, а полноценным «операционным слоем» поверх рабочего стола. Пока функция доступна в macOS-приложении и требует явного согласия, но сам факт сбора кликов и клавиш уже вызывает вопросы о приватности. Если решитесь попробовать — сначала проверьте список исключённых приложений.

Источник: The Verge

Раньше, чтобы разобраться в задаче, надо было собрать информацию, прочитать, свести всё в кучу и сделать исследование, и уходило на это несколько недель, а если тема тяжёлая, то месяц тоже был нормальным сроком. Сейчас то же самое собирается за 10 минут в нейронке, и оно даже годится как основа, с которой можно работать дальше.

Звучит как чистый выигрыш, пока не вспомнишь, зачем эта работа была нужна. Именно на ней набивали руку: пока неделю копался в чужом коде и документации, понимал, как всё устроено. Теперь этот кусок пропускают, а спрашивают и покупают уже те навыки, которые идут после кода: оценить, что выдала модель, и довести до рабочего состояния.

У нас забрали ручной кодинг не случайно, он был долгим и дорогим — именно это хотели автоматизировать первым. Всё, что покупают сегодня, устроено по-другому, а деньги, которые освободились, уходят как раз в стратегию и реализацию.

Без базы оценить код нечем

Дальше начинается неприятное. Раз модель пишет код, кажется, что можно не разбираться, как он работает. На практике всё наоборот: разбираться приходится глубже, потому что к новым инструментам добавляется вся старая база.

База начинается с двоичной системы и дальше идёт по языкам в порядке их появления, через Pascal, Basic и всё остальное. Человек, который прошёл весь этот путь, понимает, из чего собран код, который ему выдали, и способен сказать, где там будет баг. Без этого вайбкодинг сводится к копированию текста, который выглядит нормально, и работает до первого теста.

Хороший пример того, как это осваивают с нуля, есть в Roistat. Генеральный директор компании Наталья Арсланова Рассказала об этом в очередной встрече цикла “Беседы в МФТИ” кафедры технологического предпринимательства. Наталья по образованию управленец, написанием кода никогда не занималась. Когда фаундер принёс новость про вайбкодинг, он ничего объяснять не стал, а скинул статью с Хабра со словами «разберешься». Два дня ушло на сопротивление, потом она села и сделала. Через тот же путь прошёл весь топ-менеджмент, причём попытки купить готовый курс уперлись в то, что нормальных курсов по вайбкодингу тогда не существовало, и учились все по одной статье. Сейчас вайбкодит большая часть сотрудников. Арсланова говорит, что первый полученный результат затягивает сильнее любой игры, и на этом эффекте люди в тему и въезжают.

Половина работы теперь в самой задаче

Качество ответа основывается на том, как сформулирован запрос. Чем точнее и структурнее задача, тем лучше результат, и наоборот: размытый запрос даёт правдоподобный текст, на который ушли токены и время, а толку ноль. Так что перед тем, как открывать чат, стоит понять, какой вопрос вообще решаешь, какие есть ограничения и в каком виде ответ окажется применимым.

Опыт помогает понимать, как модель собирает ответ, она достраивает контекст до правдоподобного и выдает результат с одинаковой уверенностью независимо от того, хватило ей данных или нет.

Вторая половина работы начинается, когда ответ получен. Каким данным в нём можно доверять, каким нельзя, какие альтернативы существуют и что будет после того, как выберешь одну из них. Просчитать последствия во всей их вариативности модель за тебя не станет. Обсудить варианты с ней можно, а решение и то, что за ним последует, остаются на вас.

За результат всё равно отвечаешь лично

Первичную проработку и проверку гипотез модель тянет неплохо, но всё, что дальше, остается на человеке. Вместе с реализацией остаётся ответственность: предъявить претензию модели не получится, отвечает тот, кто взял её результат и понёс в работу.

Отдельная история в том, что довести дело до конца техника сама по себе не помогает. Собрать себе трекер, который напоминает о задачах и шлет уведомления во все мессенджеры, сегодня может кто угодно. Наталья Арсланова признается, что собственные трекеры соблюдает плохо, зато устная договоренность с людьми работает. С сотрудниками то же самое, напоминалка в CRM и необходимость отчитаться перед руководителем действуют по-разному.

С обучением ловушка ровно такая же. Человек планирует 20-30% свободного времени под книги или курсы, а в работе ничего не меняется, потому что полученные знания не подходят. Наталья Арсланова решает это правилом: из каждой прочитанной книги по бизнесу надо внедрить минимум одну идею, иначе книга засчитывается как художественная литература и время потрачено на удовольствие.

Как выбрать, чему учиться

Начать стоит с вопроса, зачем оно тебе. Учиться просто так тоже нормально, это такое же хобби, как спорт или прогулки. Но если от обучения ждут измеримого результата, цель надо понимать, потому что от неё зависит формат: переход в новую профессию, подготовка к руководящей роли, масштабирование своего дела или технологический сдвиг вроде нынешнего. Рынок разработки в своё время вырос как раз на коротких программах длиной от двух месяцев до года, после которых человек уже получал первые рабочие результаты.

Если направление для вас новое, базу придется получить в любом случае. Попытки найти короткий путь заканчиваются набором разрозненных инструментов без понимания, как они между собой связаны.

Отдельно стоит смотреть на программы, где учиться нужно сразу на своём проекте. Предпринимательству по учебникам не научишься, поэтому в онлайн-магистратуру той же кафедры технологического предпринимательства МФТИ приходят люди в среднем около 35 лет и приносят готовый контекст: свой стартап, спин-офф внутри компании или проект в корпорации, за который они отвечают. Заявления в магистратуру принимаются до 15 августа, обучение стартует 1 сентября, для поступления нужно пройти собеседование. Программа по семестрам и условия есть на techpredonline.ru.

Что будет с образованием дальше

Прогнозировать на 10 лет вперед сейчас - дело неблагодарное: модели обновляются раз в неделю или две и каждый раз умеют заметно больше предыдущих. Кое-что видно уже сегодня.

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

Программы при этом станут короче и разойдутся на модули, чтобы можно было взять конкретный кусок под конкретную задачу. Спрос идёт от тех, кто учится прямо сейчас: зумеры и поколение альфа спрашивают, зачем им предмет и чем он поможет дальше, а безусловного авторитета преподавателя, каким он был 20 лет назад, больше нет.

Итого

Вайбкодинг убрал не потребность разбираться, а только ваше время. Разбираться теперь надо быстрее и глубже, потому что цена ошибки та же, а медленной подготовительной работы, которую раньше этот опыт обеспечивал, больше нет.

Искусственный интеллект — множитель естественного. Если у человека на входе единица, умножение дает десять. Если ноль, сколько ни умножай, получится ноль. Если минус, результат будет соответствующим.

Реклама. Рекламодатель: МФТИ, Физтех ИНН 5008006213, erid: 2W5zFJBmp6d