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

Дальше всё развивается предсказуемо. Раз разобрать поток руками невозможно, на разбор ставят языковую модель — ту же технологию, которая этот поток и создала. 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

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

Учет — это всегда про прошлое

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

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

Управление — это взгляд в будущее: у какого железа через полгода заканчивается жизненный цикл? Что нужно докупить до того, как это станет проблемой? На каком оборудовании пора планировать замену, чтобы оно не умерло под нагрузкой?

«Учет сам по себе не является управлением, а управление не может существовать без учета. Учет — это фундамент», — отмечает Анастасия Монокина, администратор проектов компании «ИнфраМенеджер». Проблема в том, что большинство ИТ-отделов сидят именно на фундаменте и даже не пытаются подняться выше.

Чем оборачивается такой подход:

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

Отдельная боль — инструменты

Некоторые вендоры продают под видом ITAM-систем по сути те же таблицы, только с веб-интерфейсом.

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

Если ваш ITAM требует, чтобы вы руками поддерживали его актуальность, — это не ITAM, а еще одна задача в вашем бэклоге.

Как выглядит нормальный подход

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

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

Когда данные начинают работать

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

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

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

Если у какого-то актива истекает гарантия, вы получаете уведомление и успеваете загнать железо в ремонт по гарантии, а не через 3 дня после ее окончания.

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

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

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

Сама 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

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

ХоумВорк — помощь со сложными учебными работами

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

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

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

Где экономит время

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

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

Предметы и форматы

Жёсткой привязки к одному направлению нет: ХоумВорк принимает задания по разным специальностям и типам работ. Например, студент может передать тему курсовой, приложить методичку и остальные файлы, после чего сервис оценивает задачу и подбирает специалиста.

Для работы можно загружать PDF и DOCX, презентации PPTX, изображения конспектов и другие материалы. В брифе сервис также указывает поддержку аудиозаписей лекций.

Отдельный блок — научное направление: НИР, кандидатские диссертации, аспирантские рефераты, монографии, написание научных статей и их публикация в изданиях РИНЦ, ВАК и Scopus.

Есть и формат «сессия под ключ» — сопровождение на весь семестр. Студент один раз передаёт доступы к личному кабинету, а сервис закрывает задания по мере появления, а не по одному заказу за раз.

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

Бесплатного тарифа или триала нет: оплачивается конкретная работа. Стартовая стоимость и сроки зависят от её типа:

• дипломная — от 11 900 ₽, от 14 дней;
• магистерская — от 15 000 ₽, от 21 дня;
• курсовая — от 2 300 ₽, от 6 дней;
• отчёт по практике — от 2 200 ₽, от 4 дней;
• реферат — от 600 ₽, от 4 дней;
• контрольная — от 150 ₽, от 4 дней;
• решение задач — от 150 ₽ за задачу;
• компьютерный чертёж — от 500 ₽, от 7 дней;
• научная статья — от 1 000 ₽, публикация в РИНЦ — от 5 000 ₽, в ВАК — от 11 500 ₽;
• НИР — от 90 000 ₽, от 3 месяцев.

Итоговая цена определяется после того, как менеджер получит тему и требования. В ХоумВорк сейчас действует промокод STUD10 — скидка 10% на студенческие работы.

Платить всю сумму сразу не нужно: чтобы автор приступил, вносят предоплату 30%, остальное — после проверки. Работу можно заказать по частям или оформить рассрочку от Т‑Банка. Сервис работает и с юрлицами — по договору, с закрывающими документами.

Гарантии и конфиденциальность

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

Если эксперт не справился и работа не соответствует требованиям, сервис сделает 100% возврат стоимости.

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

Поддержка

Связаться с ХоумВорк можно через Telegram, чат внутри сервиса или по телефону 8-800-505-17-61. Поддержка и личный менеджер работают круглосуточно: оформить заказ, задать вопрос или прислать корректировку можно и в три часа ночи перед сдачей. Среднее время ответа — 13–15 минут.

Отдельный менеджер ведёт заказ: собирает требования и согласовывает детали между студентом и автором. Есть и офлайн-офисы — в Москве, Петербурге, Екатеринбурге, Казани, Новосибирске и ещё нескольких городах.

Ограничения и кому подойдёт

Сценарии, под которые сервис подходит:

• работающий студент не успевает написать диплом из-за плотного графика — работу ведут параллельно с его сменами, а правки он принимает в мессенджере;
• нужно срочно сдать сложную техническую задачу, расчёт или чертёж — и в своём вузе не у кого спросить;
• к сессии накопилось несколько долгов сразу — тогда подходит формат сопровождения на семестр;
• магистранту или аспиранту нужна НИР, диссертация или публикация в РИНЦ и ВАК — направления, где сложно найти исполнителя в одиночку.

Формат вряд ли будет удобен тому, кто хочет самостоятельно повторять материал или получить быстрый ответ от AI.

Перейти на ХоумВорк

Zaochnik — помощь по 600+ учебным дисциплинам

Zaochnik помогает готовиться к сессии и работать с курсовыми, дипломами, ВКР, рефератами, контрольными, задачами, чертежами и другими академическими работами. Он работает с 2000 года, внутри более 600 учебных дисциплин, а через платформу выполнено больше 100 000 заказов.

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

Где экономит время

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

Другой сценарий связан с дипломом или ВКР. Через сервис можно получить помощь с практической частью, расчётами и текстом, проверить оригинальность по базам «Антиплагиат.ВУЗ», подготовить презентацию и текст выступления для защиты.

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

Предметы и форматы

Работать с Zaochnik можно через личный кабинет в браузере. Есть мобильные приложения для iOS и Android, включая версию в RuStore.

Сервис принимает разные типы файлов:

• документы — PDF, DOCX, DOC, RTF, TXT и ODT;
• презентации и таблицы — PPTX, PPT, XLSX и XLS;
• изображения и сканы — JPG, PNG и WEBP;
• специализированные файлы — CDW для КОМПАС-3D, DWG и DXF для AutoCAD, а также материалы MathCAD, SPSS и 1С.

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

Поддержка

Служба поддержки работает ежедневно с 07:00 до 23:00 по московскому времени. Средний ответ в чате в рабочее время занимает 1–5 минут.

Связаться можно через онлайн-чат на сайте и в приложении, по телефону 8-800-350-69-73, через Telegram и другие мессенджеры или по почте: info@zaochnik.com и zakaz@zaochnik.com.

Ограничения и кому подойдёт

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

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

Перейти на Zaochnik

Collabis — рабочее пространство для конспектов и подготовки

Collabis — российский аналог Notion: заметки, документы, базы знаний и задачи в одном месте, плюс встроенный ИИ-агент. Сервис сделала команда «Мегаплана», серверы находятся в России, для входа не нужен VPN.

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

Где экономит время

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

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

Предметы и форматы

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

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

Есть мобильные приложения для iOS и Android, так что конспект с ноутбука открывается с телефона в очереди на консультацию.

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

Тарифы считаются за участника в месяц, при оплате за год дешевле:

• Бесплатный — 0 ₽: до 500 блоков, безлимит участников, до 10 гостей, базы данных, канбан и календарь, файлы до 10 МБ;
• Плюс — 249 ₽ при оплате за год (299 ₽ помесячно): блоки без ограничений, гости без ограничений, файлы до 100 МБ, расширенные права доступа;
• Про — 799 ₽ при оплате за год (999 ₽ помесячно): подключается Collabis AI, файлы до 1 ГБ;
• Бизнес — 1 299 ₽ при оплате за год (1 499 ₽ помесячно): в пять раз больше AI-токенов.

Отдельного студенческого тарифа или скидки по студенческому нет. Важная деталь: ИИ-агент на бесплатном тарифе не работает — он начинается с «Про».

Поддержка

Вопросы решаются через телеграм-канал сервиса и почту hello@collabis.ru, инструкции лежат в открытой базе знаний в разделе «Хелп». Отдельной круглосуточной линии или персонального менеджера нет: это self-service-инструмент, а не сервис с сопровождением.

Ограничения и кому подойдёт

Сценарии, под которые сервис заходит лучше всего:

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

Чего здесь нет: сервис не проверяет текст на уникальность, не объясняет тему за преподавателя и не делает работу за студента — это пространство для самостоятельной учёбы. Бесплатный тариф упирается в 500 блоков, и на конспекты за целый семестр этого может не хватить. А главная функция, ИИ-агент, доступна только с 799 ₽ в месяц.

Перейти на Collabis

Guru Scribe — расшифровка лекций и семинаров в текст

Guru Scribe переводит аудио и видео в текст: загружаете запись лекции, семинара или научного интервью — получаете готовый документ, по которому можно искать словами. Российский сервис, оплата картами «Мир» и через СБП, VPN не нужен.

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

Где экономит время

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

Работает не только с файлами: можно вставить ссылку на YouTube, VK, Rutube, TikTok, Dzen или Reels, и сервис вытащит звук сам. Голосовые из Telegram и WhatsApp тоже подойдут — их нужно сначала скачать.

Предметы и форматы

Поддерживаются любые аудио и видео — MP3, WAV, MP4, MKV, FLAC и ещё около сотни форматов, плюс архивы. Распознавание работает на 90+ языках с автоопределением языка, так что запись семинара на английском расшифруется без отдельных настроек.

Что сервис делает с записью, кроме перевода в текст:

• делит по спикерам — определяет голоса, отмечает, кто что сказал, и ставит таймкоды к каждой реплике. Для семинара с обсуждением это важнее, чем сплошная простыня текста;
• расставляет пунктуацию — точки, запятые и абзацы, а не поток слов;
• делает AI-саммари — краткое структурированное резюме записи с ключевыми моментами;
• собирает субтитры в SRT и VTT, в том числе по одному слову.

Результат скачивается в TXT, DOCX, PDF, XLSX, SRT или VTT — конспект сразу открывается в Word.

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

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

• Наблюдатель — 0 ₽: 60 минут при регистрации, далее 4 ₽ за минуту. Деление на спикеров подключается только после оплаты, мультизагрузки нет;
• Ученик — 690 ₽ вместо 990 ₽: пакет на 720 минут без ограничения по срокам, далее 3 ₽ за минуту, до 10 файлов за раз;
• Сенсей — 1 990 ₽ в месяц вместо 2 990 ₽: 720 минут каждый день, далее 2 ₽ за минуту, до 20 файлов;
• Гуру — 2 990 ₽ в месяц вместо 6 990 ₽: 1 800 минут каждый день, далее 1 ₽ за минуту, до 50 файлов.

Студенческий тариф здесь — «Ученик»: 690 ₽ за 12 часов записей, то есть около 58 ₽ за час аудио, и минуты не сгорают по сроку. Ежедневные пакеты «Сенсей» и «Гуру» выгоднее в пересчёте на час, но только если расшифровывать записи каждый день — для сессии это лишнее.

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

Поддержка

Вопросы решаются по почте info@guruscribe.ru и в телеграме, там же обсуждают нестандартные объёмы. На сайте отдельно разобраны типовые ошибки — повреждённый файл, ссылка на приватное видео, нехватка минут. Сервис работает и с юрлицами: выставляет счета и акты.

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

Ограничения и кому подойдёт

Сценарии, где сервис выручает перед сессией:

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

Чего ждать не стоит: это распознавание речи, а не редактор. Сервис не структурирует материал по темам и не объясняет содержание; AI-саммари даёт выжимку, но не заменяет разбор. И качество упирается в качество записи: шум в аудитории и невнятная речь лектора скажутся на точности.

Перейти на Guru Scribe

Quizlet — карточки и тесты для заучивания

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

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

Где экономит время

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

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

Предметы и форматы

Модуль — это набор карточек. Из него сервис делает четыре режима:

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

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

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

Базовый доступ бесплатный: карточки, режимы и готовые модули — с рекламой на страницах. Платные тарифы, цены в долларах:

• Quizlet Plus — 35,99 $ в год (2,99 $ в месяц) или 7,99 $ при помесячной оплате: 3 пробных теста в месяц, 3 решения из учебников в месяц, 20 раундов заучивания в месяц, без рекламы;
• Quizlet Plus без ограничений — 44,99 $ в год (3,75 $ в месяц) или 9,99 $ помесячно: пробные тесты и раунды заучивания без лимитов, доступ к решениям из учебников, без рекламы.

Есть 7-дневная пробная версия, но только при оформлении годовой подписки: после окончания списывается сразу вся сумма за год, дальше продление автоматическое. У месячных подписок пробного периода нет.

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

Поддержка

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

Ограничения и кому подойдёт

Сценарии, где Quizlet выручает:

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

Сервис зарубежный, данные хранятся за пределами России — для кого-то это принципиально. И по сути: Quizlet — тренажёр памяти, а не помощник в понимании. Он не объяснит тему, не соберёт конспект и не поможет с курсовой. Если материал не разобран, зубрёжка по карточкам его не заменит.

Перейти на Quizlet

Итого

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

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

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

Guru Scribe — если лекции записаны на диктофон, но так и не расшифрованы: из аудио делаем текст, по которому работает поиск.

Quizlet — если материал понятен, но не выучен: термины, даты и формулы можно занести в карточки для повторения.

Для тех, кто уже пользуется jj, это закрывает самую неприятную бытовую проблему инструмента, а два ломающих изменения в том же релизе стоит проверить сразу после обновления: команды jj config с флагом --user больше не спрашивают, какой файл править, а jj git import перестал подтягивать коммиты из отсоединённого HEAD в репозиториях без совмещения с Git. Предыдущая версия 0.44.0 выходила 6 августа, релизы у проекта идут примерно раз в месяц.

• jj converge заменяет две и больше видимых ревизии одного change ID одним коммитом; потомки перебазируются на решение, локальные закладки переезжают сами.
• Если эвристики не уверены, команда задаёт вопросы: слить описания, выбрать родителей, редко выбрать автора; в режиме --no-interactive операция прерывается, если нужен вопрос пользователю.
• Ломающее: jj config edit/set/unset --user теперь правит первый загруженный пользовательский конфиг, для точного выбора файла добавлен --file ПУТЬ.
• Ломающее: jj git import в неколоцированных репозиториях больше не импортирует коммиты с отсоединённого Git HEAD.
• Git HEAD теперь хранится отдельно для каждого worktree, существующие репозитории мигрируют автоматически; исправлен баг с duplicateEntries в git fsck после git add.

Откуда в jj берутся расходящиеся коммиты

В jj у каждого изменения есть постоянный change ID, который переживает перезапись коммита: можно поправить старый коммит в середине стека, и потомки перебазируются автоматически. Расхождение, или divergence, возникает, когда одно и то же изменение оказалось переписано дважды по разным веткам истории операций. Типичный сценарий: правка в двух рабочих пространствах, откат через jj undo после того, как часть работы уже ушла дальше, или неудачный конфликт при синхронизации с удалённым Git-репозиторием. В логе это выглядит как два коммита с одинаковым change ID, и до 0.45 их приходилось сводить руками через jj abandon, jj squash и jj rebase.

Что делает jj converge на самом деле

По описанию команды в исходниках, jj converge берёт ревизии из аргумента --revisions или из настройки revsets.converge, группирует их по change ID и считает расходящимися те группы, где ревизий больше одной. Если расходящихся изменений несколько, команда спросит, какое сводить. Дальше она применяет эвристики, чтобы собрать новую ревизию, а если те дали неоднозначный результат, задаёт вопросы: объединить ли описания, каких родителей выбрать и, в редких случаях, кого считать автором.

Когда решение найдено, новая ревизия заменяет расходящиеся, потомки перебазируются на неё, а локальные закладки, указывавшие на любую из старых версий, переезжают на новую. Два ограничения авторы оговаривают прямо. Во-первых, сводятся только ревизии, попавшие в revset: если у того же change ID есть видимые версии вне выборки, расхождение уменьшится, но не исчезнет. Во-вторых, в результате могут появиться файловые конфликты, даже если до этого их не было. Проверить, что именно сделала команда, можно через jj op show -p, посмотреть историю изменения через jj evolog, а откатить всё одним jj undo.

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

Что сломается после обновления

Первое ломающее изменение касается конфигов. Раньше jj config edit --user, set --user и unset --user при нескольких пользовательских файлах, например ~/.config/jj/config.toml плюс каталог conf.d/, спрашивали, какой файл править. Теперь они молча берут первый загруженный. Если у вас конфиг разложен по нескольким файлам, нужный указывается явно:

Второе касается репозиториев, где jj живёт рядом с Git, но не в колоцированном режиме, то есть .jj и .git не делят один рабочий каталог. jj git import в них больше не импортирует коммиты с отсоединённого Git HEAD. Если рабочий процесс опирался на то, что jj подхватит коммит, сделанный в Git в состоянии detached HEAD, теперь такой коммит нужно закрепить веткой или тегом на стороне Git.

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

Исправления, которые заметят те, кто уже обжигался

• В колоцированных репозиториях git add после команды jj больше не оставляет в индексе устаревший cache-tree, из-за которого git fsck ругался на duplicateEntries. Уже испорченные репозитории исправление не лечит.
• Ctrl+C в пейджере less теперь выходит чисто: во флаги по умолчанию добавили -K, раньше терминал мог остаться в raw-режиме с мусором из escape-последовательностей.
• Сторона конфликта, оканчивающаяся на символ возврата каретки, больше не теряет этот байт при повторном разборе материализованного конфликта.
• jj run останавливается на первой ревизии, где процесс завершился с ненулевым кодом, вместо того чтобы идти дальше.
• Набор immutable_heads() по умолчанию теперь включает untracked_remote_tags(); jj bisect предупреждает, когда из-за пропусков не может однозначно назвать первую плохую ревизию; починен краш jj log на скрытых ревизиях с revset log-graph-prioritize.

Как обновиться

Готовые сборки для Windows, macOS и Linux лежат на странице релиза, вариант с musl должен работать на любом дистрибутиве. По документации установить последний релиз можно так:

Кому обновление ничего не изменит: тем, кто держит jj в одном файле конфига и работает только в колоцированных репозиториях. Им достанется jj converge и исправления, а ломающие изменения не затронут. Следующий сигнал, за которым стоит следить, это планируемая поддержка нескольких Git worktree, под которую в 0.45 подготовили хранение HEAD.

Источники: Релиз jj v0.45.0 на GitHub, Документация: установка и настройка jj 0.45, Исходник команды converge (описание в cli/src/commands/converge.rs)

Изображение на обложке: Логотип: J. Jennings, CC BY 4.0

Для разработчика это готовый способ прогнать свой репозиторий через тот же процесс, которым 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

Для тех, кто держит workspace на десятки пакетов, это ускорение pnpm install без изменений в конфигурации. Для пользователей Windows это ещё и конец .cmd и .ps1-обёрток: их заменяет .exe. Обратная сторона видна по патчу 12.3.1: обновление с 12.2 через self-update ломало миграцию старых shim, и это исправили в тот же день.

• Установка в больших workspace ускорена: lockfile читается во время discovery проектов, граф workspace обрабатывается один раз вместо полного копирования lockfile.
• Контекстно-зависимые глобальные команды и shim стали нативными исполняемыми файлами; в Windows .exe вместо .cmd и .ps1, старые shim мигрируют при следующей глобальной установке или self-update.
• Флаги доверия --trust-lockfile, --no-trust-lockfile, --trust-policy, --trust-policy-exclude и --trust-policy-ignore-after теперь работают и для remove и update.
• Исправлено зависание recursive run и exec, в том числе с --filter и --workspace-concurrency=1.
• Системный резолвер на Linux использует getaddrinfo и больше не должен молча обращаться к Google Public DNS при неподдерживаемой опции no_tld_query.

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

По заметкам к релизу, раньше pnpm сначала обходил все проекты workspace, а потом отдельно разбирал lockfile и копировал его целиком для резолвера. В 12.3 lockfile читается уже на этапе discovery, а граф workspace строится один раз и передаётся резолверу и генератору lockfile без полного копирования. Конкретных цифр ускорения команда pnpm в заметках не приводит, формулировка звучит как «sped up installs in large workspaces»; эффект тем заметнее, чем больше пакетов и чем толще lockfile.

Что изменилось для глобальных команд и Windows

pnpm умеет ставить node, deno и bun как глобальные команды, которые подбирают версию по контексту проекта. До 12.3 в Windows такие команды были скриптами .cmd и .ps1, а на других платформах shell-обёртками. Теперь везде это нативные исполняемые файлы. Старые shim от pnpm 12 мигрируют при следующей глобальной установке или self-update; именно этот переход и сломался при обновлении с 12.2, что исправили в 12.3.1: нативный shim теперь мигрирует при первом запуске.

Безопасность: trust-флаги и скрытие секретов

Механизм доверия к lockfile появился в pnpm 12 как защита от атак на цепочку поставок: пакеты, не прошедшие политику доверия, не ставятся. В 12.2 флаги были только у install и add; 12.3 добавляет их к remove и update. Второе изменение того же ряда: учётные данные и query-параметры из URL реестров теперь скрываются в сообщениях об ошибках fetch и загрузки tarball, так что токен приватного реестра больше не утекает в лог CI при обрыве соединения.

Исправления, которые стоит знать

• Добавление локальных директорий, tarball-файлов и tarball по URL через pnpm add снова работает.
• recursive run и recursive exec больше не зависают, включая варианты с --filter и --workspace-concurrency=1.
• Дочерние процессы в Windows запускаются корректно.
• Linux: системный резолвер переведён на getaddrinfo; при неподдерживаемой опции no_tld_query в resolv.conf pnpm больше не должен молча уходить к Google Public DNS, что важно в закрытых сетях и там, где внешние DNS фильтруются.
• 12.3.1: исправлены обработка workspace anchor и параллельная проверка lockfile.

Как обновиться

Обновляться стоит сразу на 12.3.1, минуя 12.3.0. Если pnpm установлен через Corepack или npm i -g pnpm, обновление идёт обычным способом; если через self-update, после перехода с 12.2 стоит один раз запустить любую глобальную команду, чтобы shim мигрировал. Проверить, что всё на месте: pnpm --version должен показать 12.3.1, а pnpm shim ls (если пользуетесь shim) не должен ругаться на старые обёртки.

Кому обновление ничего не изменит: одиночным проектам без workspace и тем, кто не пользуется глобальными командами pnpm. Из соседних новостей про инструменты JavaScript на сайте: GitHub CLI 2.99 и Wasmi 2.0. Полный список изменений с номерами issue лежит на странице релиза.

Источники: pnpm v12.3.0 на GitHub, pnpm v12.3.1 на GitHub

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

Для команд, которые пускают агента в репозиторий с .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

Для разработчика это значит, что самая нудная часть жизни 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

Главный пример месяца — 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

Где резервная копия теряет защиту

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

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

Быстрая синхронизация снижает RPO, то есть допустимый объём потери данных. Одновременно сокращается время, за которое команда может заметить заражение до записи данных на резервной площадке. Для восстановления нужна история версий, защищённая от изменений после записи.

Как Object Lock сохраняет версии

Object Lock реализует модель WORM, Write Once, Read Many. Записанную версию объекта нельзя изменить или удалить до окончания установленного срока. Подробно эта механика описана в документации Amazon Web Services S3.

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

Само включение Object Lock ещё не защищает записанные объекты. После этого необходимо настроить retention для отдельных версий или для всех новых версий, попадающих в бакета. Примеры обеих конфигураций приведены в базе знаний Linx Cloud.

При обычном запросе на удаление S3 может создать delete marker. Объект перестанет отображаться как текущий, но его заблокированная версия сохранится. Для восстановления потребуется выбрать нужную версию или удалить маркер. Поведение delete marker при включённом Object Lock разобрано в документации AWS.

Как выбрать режим удержания

Object Lock поддерживает два режима:

• Governance: защищённую версию может удалить пользователь с разрешением s3:Bypass Governance Retention, если он явно запросит обход защиты. Это разрешение следует отделить от повседневных административных и резервных учётных записей.
• Compliance: защищённую версию нельзя удалить до окончания срока удержания, включая действиями root-пользователя. Режим также запрещает сокращать уже установленный срок.

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

Как рассчитать срок хранения

Правило 3-2-1 определяет структуру резервирования: три копии данных, два типа носителей и одна копия за пределами основной площадки. Такое определение приводит CISA в рекомендациях по резервному копированию. Глубина истории рассчитывается отдельно.

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

При отсутствии собственной статистики архитекторы Linx Cloud рекомендуют рассматривать 30 дней как начальный ориентир. Затем срок корректируют с учётом частоты копирования, времени обнаружения инцидентов, внутренних регламентов и результатов тестовых восстановлений. Если компания может обнаружить компрометацию позже, историю увеличивают.

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

Что проверить перед восстановлением

Object Lock сохраняет записанную версию, но не проверяет её содержимое. Если заражённые данные попали в копию до блокировки, хранилище сохранит их вместе с остальными объектами.

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

Перед восстановлением:

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

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

Бэкапы Шрёдингера

Народная мудрость гласит: “Если никто не проверяет бэкапы, они одновременно существуют и не существуют. Чаще всего — второе.”

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

Как часто надо проверять? Чем чаще, тем лучше.

Идеальный вариант — сразу после завершения создания резервной копии. Да, это непросто в настройке (хотя некоторые СРК умеют в автоматическую проверку), да, это затратно с точки зрения ресурсов и стоимости исходящего трафика (если он есть в тарифе). Но все эти недостатки нивелируются максимальным снижением риска, что в час X что-то пойдёт не так.

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

Как сервисы Linx Cloud участвуют в этой схеме

В Linx Cloud задачи хранения, создания копий и аварийного запуска инфраструктуры разделены между разными сервисами.

Объектное хранилище S3 поддерживает версионирование и Object Lock. Режим Governance или Compliance, а также срок удержания задаются для отдельных объектов или всего бакета. А вариант тарификации без дополнительной оплаты за исходящий трафик позволит на регулярной основе тестировать восстановление, не боясь переплатить за трафик.

Резервное копирование для бизнеса используется для создания и хранения копий виртуальных машин, серверов и баз данных.Аварийное восстановление (DRaaS) отвечает за максимально быстрый запуск инфраструктуры на резервной площадке при аварии. Набор сервисов зависит от требуемой глубины хранения, времени восстановления и устройства основной инфраструктуры.

Порядок действий во время атаки шифровальщика отдельно разобран в материале Linx Cloud «Киберсхватка: как действовать во время атаки вируса-шифровальщика».

Что должно быть настроено

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

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

• 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

Функция вышла в public preview для тарифов Copilot Pro, Pro+, Max, Business и Enterprise. По умолчанию она выключена: администраторам придётся включить её явно, и сделать это можно на уровне enterprise, организации или отдельного репозитория. GitHub при этом ничего не говорит о региональной доступности, поэтому для аккаунтов из России действуют те же условия, что и у самого Copilot: нужна платная подписка, а вопрос её оплаты публикация не затрагивает.

• Каждый обзор Copilot теперь содержит вердикт «готов к одобрению или нет»; сам по себе вердикт в merge-требования не засчитывается.
• Если администратор включит настройку, Copilot будет ставить настоящий approve, и он считается наравне с одобрением человека.
• Настройка выключена по умолчанию; управляется на уровне enterprise, организации и репозитория.
• В репозитории можно ограничить approve списком путей: за пределами списка Copilot только комментирует.
• Новый коммит после approve автоматически снимает одобрение, как и у обычных ревьюеров.

Вердикт и approve теперь разные вещи

До этого релиза Copilot code review оставлял замечания и общий комментарий, а решение «можно ли мержить» оставалось за людьми. Теперь в каждом обзоре появился approval assessment: Copilot пишет, считает ли он pull request готовым к одобрению. GitHub прямо оговаривает, что «одна только оценка готовности не засчитывается в merge-требования» (здесь и далее перевод редакции). Это информационный сигнал, и он появляется у всех, кто пользуется Copilot code review, без дополнительных настроек.

Второй уровень включается отдельно. Если администратор разрешил Copilot одобрять, то при положительной оценке Copilot отправляет обычный approve через штатный механизм ревью. Такой approve участвует в правилах защиты веток: если branch protection требует одно одобрение, оно будет выполнено. По нашей оценке, именно эта деталь и есть новость: Copilot code review теперь формально закрывает требование ревью.

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

Три уровня контроля и фильтр по путям

GitHub построил включение по каскаду. Администратор enterprise может запретить функцию всем организациям сразу. Администратор организации включает её выборочно для репозиториев. Администратор репозитория включает или выключает approve у себя и, что важнее, может задать список путей, к которым Copilot имеет право применять approve.

На практике это значит, что разумная конфигурация выглядит не как «Copilot одобряет всё», а как «Copilot одобряет документацию, тесты и локализацию, а к src/auth/ и инфраструктурному коду не прикасается». Если pull request задевает файлы вне списка, Copilot по-прежнему оставит замечания, но approve не поставит.

Что GitHub не сказал: по каким критериям Copilot принимает решение о готовности, как часто он ошибается и есть ли у компании собственные замеры доли ложных одобрений. Публикация описывает только механику и настройки. Пока функция в public preview, GitHub оставляет за собой право менять её поведение.

Что проверить у себя сегодня

1. Убедиться, что в организации функция по-прежнему выключена: она отключена по умолчанию, но проверить настройки Copilot в разделе организации стоит, особенно если администраторов несколько.
2. Если approve от Copilot нужен, включать его точечно: сначала в репозиториях без критичного кода и с фильтром по путям, а не на всю организацию.
3. Пересмотреть правила защиты веток. Если merge требует ровно одно одобрение и Copilot попадает в число допустимых ревьюеров, стоит поднять требование до двух или добавить в CODEOWNERS обязательного человека для чувствительных каталогов.
4. Договориться в команде, что approve Copilot не заменяет ревью человека для изменений в аутентификации, платежах, миграциях и CI-конфигурации.

Approve от Copilot снимается новым коммитом: как только в ветку приходит изменение, одобрение отзывается, и Copilot пересматривает pull request заново. Про истечение одобрения по времени GitHub ничего не пишет.

Почему это шаг дальше, чем автообзор

Автоматический обзор Copilot существует давно, и у многих команд он включён на каждый pull request. Но роль у него была совещательная: комментарии можно проигнорировать, а merge всё равно требовал одобрения человека. С 1 сентября GitHub позволяет передать ИИ часть формальной ответственности за merge-gate. Для маленьких команд и соло-проектов это удобно: правило «одно одобрение» перестаёт блокировать работу, когда второго человека просто нет. Для больших организаций это ещё один пункт в аудите доступов.

Следить стоит за двумя вещами: когда функция выйдет из public preview и появятся ли у GitHub публичные данные о точности вердиктов. Редакция проверит, изменятся ли значения по умолчанию к стабильному релизу.

Источник: Changelog GitHub: Copilot code review can now approve pull requests

Изображение на обложке: GitHub

Линкер склеивает скомпилированные объектные файлы в исполняемый файл, и на больших проектах это минуты ожидания при каждой пересборке. mold появился в 2021 году именно как ответ на это: по свежему бенчмарку автора он в 4,9 раза быстрее lld по медиане. Но проекты, которые собираются через сложные линкер-скрипты GNU ld, вроде ядра Linux, до сих пор были для него закрыты; 3.0 должна это изменить.

• mold переписывают на Rust; новая версия выйдет как mold 3.0, дата не названа.
• Цель: поддержка линкер-скриптов, чтобы mold собирал всё, что умеет GNU ld, включая ядра и прошивки.
• Текущий mold написан на C++20; по бенчмарку августа 2026 года он быстрее lld в 4,9 раза, а wild в 1,9 раза по медиане.
• Debug-сборка Chromium 145 на Threadripper 7980X: lld 16,64 с, wild 3,98 с, mold 1,65 с; TensorFlow 2.21: lld 50,73 с, mold 3,15 с.
• Текущий mold продолжает работать как замена ld и lld; включается флагом -fuse-ld=mold или через .cargo/config.toml.

Зачем линкеру скрипты

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

Уэяма пишет, что цель новой версии — совместимость со всем, что умеет собирать GNU ld. Именно это открывает дорогу к тому, чтобы дистрибутивы Linux сделали mold линкером по умолчанию: пока хоть один важный пакет не собирается, менять умолчание никто не будет. Конкретных дистрибутивов с такими планами в README пока не названо.

We are rewriting the mold linker in Rust. This will be mold 3.0.

Насколько mold быстрее сегодня

Автор обновил бенчмарки в README репозитория в августе: девять крупных программ, медиана трёх запусков после прогрева, два стенда — Threadripper 7980X с 64 ядрами и Apple M1 Ultra, у которого использовались 16 производительных ядер. Сравнивались lld, wild (ещё один линкер на Rust) и mold. Результаты на Threadripper выглядят так.

На Chromium 145 lld тратит 16,64 секунды, wild 3,98, mold 1,65. На TensorFlow 2.21 разрыв ещё больше: 50,73 секунды у lld против 3,15 у mold. На Apple M1 Ultra картина ровнее: debug-сборка Clang 21 линкуется за 2,96 секунды у mold, 4,40 у lld и 2,78 у wild, то есть в этом тесте конкурент на Rust слегка впереди, хотя на большинстве остальных задач M1-стенда mold быстрее. Артефакты бенчмарка опубликованы на Zenodo, их можно повторить.

Почему Rust, если и так быстро

В сообщении Уэямы причин не названо. Из README видно другое: текущий mold требует GCC 10.2 или Clang 16 и написан на C++20, а конкурент wild с самого начала на Rust и на части задач уже догоняет. Переписывание с добавлением линкер-скриптов означает во многом новую кодовую базу, и выбор языка для неё делается один раз. Всё остальное — предположения, и мы их не делаем.

Как включить mold сегодня

Для C и C++ с GCC или Clang достаточно флага компоновки -fuse-ld=mold. Для Rust README предлагает настройку в .cargo/config.toml:

• Проекты с собственными линкер-скриптами (ядра, прошивки, загрузчики) пока остаются на GNU ld; ждите mold 3.0.
• Если пользуетесь wild, сравните на своём проекте: на M1 Ultra он выигрывает лишь в части тестов, по общей медиане бенчмарка mold быстрее в 1,9 раза.
• mold распространяется под лицензией MIT через GitHub и пакеты дистрибутивов; наличие пакета в репозиториях Astra Linux и РЕД ОС проверяйте отдельно, в README они не перечислены.

Что дальше

mold используется в проде с 2021 года, и текущая C++-версия никуда не денется до выхода 3.0. Следить стоит за двумя сигналами: появится ли в репозитории ветка на Rust с первыми тестами линкер-скриптов и объявит ли какой-нибудь дистрибутив о планах сделать mold линкером по умолчанию. Второе и будет настоящей новостью.

Источники: Сообщение Руи Уэямы в X, Репозиторий mold с бенчмарками

Изображение на обложке: Tproger по данным README mold

Практически миграция начинается с замены идентификатора модели на 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

В 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?

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

Что такое DR-план и какие задачи он закрывает

План аварийного восстановления (disaster recovery plan, DRP) — это документ, который фиксирует, что и в каком порядке нужно делать, чтобы вернуть ИТ-системы к жизни после серьёзного сбоя. В нём прописаны ситуации, от которых защищаемся, приоритеты восстановления сервисов, ответственные люди, доступы, целевые сроки и критерий, по которому аварию считают закрытой.

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

Чем DR-план отличается от резервного копирования

Резервное копирование в облако и DR часто путают. Бэкап отвечает за наличие копии данных. DR-план отвечает за восстановление работающего сервиса в заданный срок с заданным процентом потери данных.

Разницу легко понять на примере.

У компании есть резервные копии всех баз. Они лежат на отдельном хранилище, регулярно обновляются. Всё хорошо. Но в один день дата-центр становится недоступным из-за аварии на подстанции, а ИБП и ДГУ не справились с нагрузкой. Серверы выключены, доступ к ним потерян. Копии есть, но развернуть их негде — резервной площадки нет. А даже если она есть, никто не отрабатывал их восстановление, а потому доподлинно не знает, в какой последовательности поднимать сервисы, кто за что отвечает, какие пароли использовать и т.п.. Копии есть, а работающего сервиса нет. DR-план как раз и закрывает эту проблему: он описывает, как из копий собрать работающую систему в нужный срок.

Как DR-план связан с BCP

BCP (business continuity plan) — это план непрерывности бизнеса. Он описывает, как компания будет работать в кризисной ситуации в целом: куда переедет офис, как сотрудники будут связываться друг с другом, как выполнять ключевые бизнес-функции без привычных инструментов. DR-план — это часть BCP, его ИТ-составляющая.

Порядок разработки обычно такой: сначала проводится бизнес-анализ (BIA — business impact analysis) и составляется перечень критичных бизнес-процессов. Для каждого процесса определяют, какие ИТ-системы его обеспечивают. И уже под эти системы пишут DR-план. Не наоборот. Нельзя взять и описать восстановление всех систем подряд — нужно понимать, какой сервис для чего нужен и сколько компания готова за него заплатить.

Сколько стоит простой и как это меняет требования к плану

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

В июне 2026 года на Cnews были опубликованы результаты CX-исследования, проведённого на основе глубинных интервью со 180 заказчиками. У 39% компаний за последний год стоимость часа простоя значительно выросла. Ещё 35% сказали, что она осталась на прежнем уровне. 14% отметили снижение благодаря внедрению резервных систем и процедур.

Рост стоимости простоя связан с несколькими факторами:

• бизнес сильнее зависит от бесперебойной работы цифровых сервисов;
• оборудование стареет, восстановление после сбоев усложняется;
• инфраструктура становится неоднородной — сложнее понять, как всё связано;
• вендорская поддержка сокращается, особенно по зарубежному оборудованию и ПО.

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

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

Приоритет смещается в сторону мер, которые снижают риск отказов и сокращают время восстановления. Наиболее эффективными респонденты назвали создание запасной инсталляционной базы на всех уровнях инфраструктуры (46%) и разработку детальных планов и регламентов аварийного восстановления (32%).

Ещё один способ снижать потери от недоступности ИТ-систем — страхование в облаке: решение, которое помогает управлять рисками и рационально распределять финансовые потоки. Провайдер Linx Cloud предлагает собственную инфраструктуру на базе двух сертифицированных ЦОД уровня TIER III в Москве и Санкт‑Петербурге, что позволяет строить катастрофоустойчивые архитектуры с гарантированным уровнем доступности.

Как рассчитать RTO и RPO для своих систем

RTO (Recovery Time Objective) — это время, за которое система должна быть восстановлена после аварии. Считается от момента, когда принято решение о переключении на резерв, до момента, когда сервис снова доступен пользователям.

RPO (Recovery Point Objective) — это допустимый объём потери данных. Показывает, на сколько часов (или минут) можно откатить систему назад. Если RPO = 1 час, значит, при аварии допустима потеря данных, созданные не более чем за последний час. Всё, что было раньше, должно сохраниться.

Показатели назначаются на каждый сервис отдельно. Нельзя поставить один RTO на всю инфраструктуру — у платежной системы и внутреннего чата для сотрудников требования к восстановлению будут разными.

Методика расчёта идёт от бизнеса, а не от ИТ. Сначала считают, сколько компания теряет за час простоя конкретного сервиса. Потом определяют, какой простой бизнес готов терпеть, — это и будет RTO. Аналогично с RPO: оценивается, сколько данных можно потерять без катастрофических последствий.

Пример.

Интернет-магазин с выручкой 5 млн руб. в сутки. В пиковые часы (10:00–22:00) это около 300–400 тысяч в час. Допустим, бизнес готов терпеть простой не больше двух часов — иначе убытки (денежные и репутационные) становятся критическими. Значит, RTO = 2 часа. Потеря данных за час — это потеря заказов, которые могли бы быть оформлены. Если за час через сайт проходит 30 заказов на сумму 50 тыс. руб., бизнес может с этим смириться. RPO = 1 час. Если такая потеря неприемлема, нужно снижать RPO до 15–30 минут и использовать более частую репликацию.

Матрица критичности сервисов

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

Типичные ошибки при назначении показателей

1. RTO назначает ИТ-отдел без согласования с бизнесом. Инженеры берут цифры «с потолка», исходя из того, что им кажется разумным или на что хватает существующих ресурсов. Бизнес потом удивляется, почему платёжная система простаивала четыре часа, хотя каждый час простоя стоит миллион. RTO должен утверждаться на уровне топ-менеджмента — это бизнес-решение, а не техническое. Часто после оценки стоимости обеспечения RTO со стороны ИТ, бизнесу приходится корректировать свои аппетиты и пересматривать метрику. Но в конечном итоге она точно должна согласовываться бизнесом.
2. Один общий показатель на все системы. Платёжный шлюз и система для внутренних отчётов не могут восстанавливаться за одно и то же время. Это просто-напросто сжигание бюджета расфокусировка ИТ команды. Разные уровни критичности систем — разные RTO и RPO.
3. В RTO не заложено время на принятие решения и проверку данных. В плане написано «восстановить за 2 часа», но забыли, что сначала нужно созвониться, принять решение о переключении,. Реальное время может оказаться в два раза больше, если процесс инициации восстановления не описан и не отработан..
4. Показатели ни разу не подтверждались измерением на реальном восстановлении. RTO и RPO, которые никто не проверял, — это просто цифры в документе. Без тестов они не имеют никакой ценности.

Из каких разделов состоит рабочий DR-план

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

1. Область действия и перечень охваченных систем. Чётко указать, какие сервисы, площадки и компоненты инфраструктуры входят в план, а какие — нет. Если какой-то сервис не охвачен, это должно быть написано явно.
2. Карта сервисов и зависимостей. Схема, которая показывает, как сервисы связаны друг с другом и с внешними системами. Если упадёт база данных, какие приложения перестанут работать? Если откажет внешний API, что сломается внутри? Без этой карты восстановление существенно усложняется.
3. Целевые RTO и RPO по каждому сервису. Таблица с показателями для каждого сервиса из перечня. Цифры должны быть согласованы с бизнесом и утверждены.
4. Роли, зоны ответственности, матрица эскалации. Кто принимает решение о переключении на резерв. Кто выполняет технические действия. Кто проверяет целостность данных. Кто связывается с подрядчиками. Кто информирует руководство и пользователей. Если ответственный недоступен, кто его заменяет. Схема связи при недоступности корпоративных каналов — телефоны, мессенджеры, резервная почта.
5. Критерии активации плана и лица, принимающие решения. План не активируется автоматически при любом сбое. Должны быть чёткие критерии: время недоступности, характер отказа, оценка ущерба. И конкретный человек (или группа), который принимает решение и даёт команду «переключаемся на резерв».
6. Пошаговые сценарии восстановления (runbook). Самая объёмная часть. Для каждого сценария — последовательность команд, скриншоты интерфейсов, порядок проверок. Runbook должен быть настолько подробным, чтобы по нему можно было восстановить систему даже в 3 ночи в выходной.
7. Доступы, учётные записи, ключи шифрования, места хранения резервных копий. Где лежат пароли, как получить доступ к резервным копиям, если основная площадка недоступна, какие ключи нужны для расшифровки данных. Вся эта информация хранится отдельно от основного документа, в защищённом месте, но в плане должно быть описано, как до неё добраться.
8. Процедура проверки целостности данных после восстановления. После того как системы подняты, нужно убедиться, что данные не повреждены и доступны для использования информационными системами и конечными пользователями Эта процедура прописывается для каждого типа систем отдельно.
9. Критерии завершения аварии и порядок возврата на основную площадку. Авария считается закрытой, когда все критичные сервисы работают на резервной площадке и пользователи получили доступ. Но рано или поздно нужно вернуться на основную площадку — в плане указано, как это делается, в какой последовательности и с какими проверками.
10. Контакты подрядчиков, провайдеров, вендоров с номерами договоров и SLA. Когда падает оборудование, нужно звонить поставщику, когда отказывает облако — провайдеру. В плане должны быть актуальные контакты, номера договоров и согласованные SLA по времени реакции и решения инцидентов.
11. Журнал версий и ответственный за актуализацию. DR-план — живой документ. В нём фиксируется, кто и когда вносил изменения, какая версия сейчас действует, кто отвечает за его обновление.

Сценарии аварий, которые нужно описать в плане

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

Отказ отдельного узла или дискового массива. Самый частый сценарий. Отказал один сервер или СХД . Признак: сервер недоступен, ошибки в логах хранилища. Первое действие: переключить нагрузку на другой узел в том же ЦОД. Целевой RTO: 15–30 минут. Восстановление происходит в пределах одной площадки, без переключения на резервный ЦОД.

Полная потеря площадки. Авария в ЦОД — пожар, затопление, отключение электричества, обрыв кабеля на входе. Признак: все сервисы на площадке недоступны одновременно. Первое действие: активировать резервную площадку, переключить DNS. Целевой RTO: от 1 до 4 часов в зависимости от класса сервиса.

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

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

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

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

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

Как выбрать резервную площадку и схему аварийного восстановления ИТ-инфраструктуры

Выбор резервной площадки определяется целевыми показателями RTO и RPO. Чем жёстче требования, тем дороже и сложнее схема. Основные варианты — холодный, тёплый и горячий резерв.

Холодный, тёплый и горячий резерв

DRaaS как резервная площадка

DRaaS (Disaster Recovery as a Service) — модель, при которой резервная площадка арендуется у провайдера. Компания не строит собственный резервный ЦОД, а использует облачную инфраструктуру провайдера.

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

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

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

• Какой RPO может обеспечить сервис?
• Как часто можно проводить тестовые переключения без дополнительной оплаты?
• Где физически размещены данные — в каком регионе, в каком ЦОД?
• Кто выполняет переключение — команда провайдера/ собственная команда заказчика/совместно?
• Как организована поддержка в нерабочее время и в выходные?

Облачная инфраструктура IaaS — модель аренды виртуальных сервисов и других ресурсов, при которой компании платят только за фактическое использование мощностей. Такой подход даёт гибкость и прозрачность расходов, но многое зависит от надёжности платформы. Компания Linx Cloud строит IaaS на базе собственных ЦОД — это даёт предсказуемую отказоустойчивость и возможность географически распределять нагрузки без оглядки на сторонние площадки. Плюс платформа работает на OpenStack, что упрощает интеграцию с существующей инфраструктурой и автоматизацию.

Разнесение площадок и каналы связи

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

Каналы связи между площадками нужно резервировать. Если основной канал оборвётся, репликация остановится, и RPO будет нарушено. В плане должно быть описано, как и кем переключаются DNS и публичные IP-адреса при переключении на резервную площадку.

Вариант размещения оборудования в ЦОД — colocation, то есть использование сторонних площадок для своих ресурсов. Задействуются виртуальные частные сети — выделенные каналы связи L2VPN.

Требования регуляторов РФ к плану восстановления

Для многих компаний DR-план — юридическое требование.

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

152-ФЗ о персональных данных. Операторы персональных данных обязаны обеспечивать восстановление данных, изменённых или уничтоженных вследствие несанкционированного доступа. Требования детализированы в постановлении Правительства № 1119 и приказе ФСТЭК № 21. Приказ ФСТЭК № 21 содержит группу мер по обеспечению доступности, включая резервирование и восстановление. Актуальная редакция приказа — от 14 мая 2020 года. С 1 сентября 2026 года вступают в силу новые меры, в том числе защита от современных угроз.

187-ФЗ о безопасности критической информационной инфраструктуры. Для значимых объектов КИИ (ЗОКИИ) предусмотрены меры по реагированию на инциденты и действиям в нештатных ситуациях, включая планирование восстановления. Поправки к закону вступили в силу 1 сентября 2025 года.

26 февраля 2026 года Правительство РФ утвердило распоряжением № 360-р единый перечень типовых отраслевых объектов КИИ. Документ насчитывает 397 типовых объектов по отраслям: банки и финансовые рынки, наука, здравоохранение, энергетика, транспорт, связь, оборонная и ракетно-космическая промышленность.

Для отдельных отраслей приняты отраслевые особенности категорирования: для атомной энергии (постановление № 4 от 16.01.2026), для банковской сферы (постановление № 92 от 06.02.2026), для науки (постановление от 07.03.2026).

Приказ ФСТЭК № 117. С 1 марта 2026 года вступил в силу приказ ФСТЭК № 117 от 11.04.2025, который обновил требования к защите информации в государственных информационных системах (ГИС). Документ распространяется не только на ГИС, но и на иные информационные системы государственных органов, государственных унитарных предприятий и государственных учреждений. Требования включают политику информационной безопасности, подразделения защиты, цикл Деминга и новый показатель защищённости КЗИ.

ГОСТ Р 53647 (менеджмент непрерывности бизнеса). Серия стандартов, которые задают методическую рамку для управления непрерывностью. Включает практическое руководство, управление человеческими ресурсами, управление организацией в условиях кризиса. Документы действуют в настоящий момент.

ГОСТ Р 57580.1 для финансовых организаций. Стандарт содержит более 400 организационных и технических мер защиты информации для банков, страховых, клиринговых компаний и финтех-стартапов. В ноябре 2025 года Банк России разослал финансовым организациям письма, обязывающие требовать от поставщиков ИТ- и ИБ-услуг соответствия стандарту. В феврале 2026 года проведены первые проверки крупнейших финансовых организаций.

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

Тестирование DR-плана

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

Виды тестов

Разные уровни сложности — от простых до максимально реалистичных.

1. Разбор сценария на бумаге (tabletop exercise). Участники собираются и проходят сценарий устно: «что делаем, если упала база?», «кто кому звонит?», «какие команды выполняет?». Проверяются логика, последовательность действий, понимание ролей. Риска для продуктивной среды нет.
2. Восстановление одной системы на изолированном стенде. Берётся отдельный сервис и восстанавливается из бэкапов на тестовой среде. Проверяется, что бэкапы читаются, данные консистентны , восстановление проходит без ошибок.
3. Тестовое переключение группы связанных сервисов. Несколько сервисов, которые зависят друг от друга, переключаются на резервную площадку в тестовом режиме. Проверяются зависимости, порядок запуска, работа интеграций.
4. Полномасштабное учение с переводом продуктивной нагрузки. Самый сложный и рискованный вариант. Реальная нагрузка переключается на резервную площадку, пользователи работают с резервной средой. Проверяется всё: от инфраструктуры до пользовательского опыта. Риск — если что-то пойдёт не так, бизнес пострадает. Поэтому такие учения планируют на периоды низкой нагрузки и с полным планом отката.

Периодичность и критерии успешного теста

Полный пересмотр и проверка плана — не реже раза в полгода. Частичные проверки типа восстановления отдельной системы можно делать чаще — раз в месяц или после каждого значимого изменения инфраструктуры.

Критерии успешного теста:

• сервис поднят и доступен пользователям;
• данные прошли проверку целостности;
• фактическое время восстановления уложилось в целевой RTO;
• потеря данных не превысила целевой RPO.

В протоколе теста фиксируется фактическое время каждого шага. Не «восстановили за 2 часа», а «базу подняли за 35 минут, веб-серверы за 50 минут, проверка данных заняла 20 минут, итого 1 час 45 минут».

Что делать с результатами

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

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

Как поддерживать DR-план в актуальном состоянии

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

Внеплановый пересмотр нужен в следующих случаях:

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

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

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

Чек-лист готовности DR-плана

Пройдите по пунктам и отметьте, что уже сделано, а что ещё нет:

☐ Перечень всех ИТ-систем, которые должны восстанавливаться, составлен и утверждён.

☐ Для каждой системы назначены RTO и RPO, согласованные с бизнесом.

☐ По каждому сервису назначен ответственный за восстановление и его заместитель.

☐ Критерии активации плана записаны, лицо, принимающее решение о переключении, определено.

☐ Доступы, пароли, ключи шифрования хранятся в защищённом месте, порядок доступа к ним описан.

☐ Порядок действий при недоступности основной площадки прописан и проверен.

☐ Дата последних учений и их результат зафиксированы в протоколе.

☐ Дата последнего обновления плана — не старше 6 месяцев.

☐ Офлайн-копия плана существует и хранится отдельно от корпоративных систем.

☐ Контакты подрядчиков, провайдеров и вендоров актуальны, номера договоров и SLA записаны.

DR-план — это постоянный рабочий процесс. Документ написали, протестировали, обновили, снова протестировали. Без тестирования и регулярной актуализации план — просто текст. С тестированием и актуализацией — инструмент, который реально помогает в аварии.

Если собственной резервной площадки нет или строить её дорого, стоит обратить внимание на сервис аренды резервной инфраструктуры от DRaaS от Linx Cloud. Ресурсы компании позволяют снять вопросы с оборудованием, каналами и поддержкой, оставляя заказчику только настройку и управление процессом.

Timetta — российская PPM-платформа с финансовым учётом, портфелями и on-premise для крупных компаний.

GanttPRO — специализированный онлайн-инструмент для диаграмм Ганта с импортом MS Project и простым интерфейсом.

Kaiten — российский сервис для гибридного управления: Kanban, Scrum, Гант и модульная тарификация.

Redmine — бесплатное open-source решение для команд, готовых самостоятельно разворачивать и дорабатывать систему.

Как мы выбирали

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

Все участники проверены по официальным источникам. Цены и условия указаны по данным сайтов на лето 2026 года и могут меняться, поэтому перед покупкой стоит свериться с актуальным прайс-листом.

1. Timetta — портфели и финансы

Timetta — российская корпоративная система для управления проектами, ресурсами, трудозатратами и финансами. Она ориентирована на проектные офисы, ИТ-интеграторов, консалтинговые и инжиниринговые компании, которым нужно вести сроки, людей и деньги в одном пространстве.

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

• Проектный офис крупной ИТ-компании. В Газпром ЦПС Timetta используется как единое пространство для управления портфелем из 180+ проектов.
• Руководители проектов и финансисты. Комита ЦТ собирает трудозатраты через таймшиты и контролирует рентабельность проектов.
• Ресурсные менеджеры. В GMCS система помогла сделать прозрачной загрузку сотрудников и снизить конфликты за ресурсы между направлениями.

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

Платформа покрывает полный цикл проектного бизнеса:

• проекты, программы и портфели
• диаграммы Ганта с вехами, зависимостями и критическим путём
  
• таск-трекер с бэклогом и спринтами
  
• бронирование ресурсов и загрузка сотрудников
  
• таймшиты и учёт отсутствий
• заявки на затраты, платёжные календари и процесс почасового биллинга,
• P&L-отчёты, клиенты и сделки
  
• корпоративная вики и ИИ-ассистент
  

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

Timetta работает в облаке (SaaS) и в виде on-premise-развёртывания в инфраструктуре заказчика. Данные хранятся на защищённых российских серверах, система соответствует 152-ФЗ и включена в реестр российского ПО (запись № 18250 от 05.07.2023). Доступен OData API с авторизацией OAuth 2.0, готовые интеграции с 1С:УХ и 1С:ЗУП, обработчики и сценарии автоматизации.

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

Среди публичных клиентов — Газпром ЦПС, Комита ЦТ, GMCS. Вендор публикует кейсы внедрений на сайте, но агрегированных рейтингов на независимых площадках мало, поэтому сравнивать по звёздам затруднительно.

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

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

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

Стоимость зависит от выбранных приложений, числа пользователей и срока лицензии. По данным прайс-листа, лицензии на отдельные приложения начинаются от 350 ₽ за пользователя в месяц (например, Timetta Expenses), до 3500 ₽ за Timetta Corp.

Для небольших команд есть отдельная бесплатная сборка Timetta Lite: тариф Free доступен без ограничения по сроку для 10 активных пользователей и теперь включает таймшиты, а для команд на 11–50 человек действует платный тариф Team — 1 490 ₽ за пользователя в месяц (подробнее — в блоге Timetta). On-premise доступен для корпоративных клиентов, стоимость рассчитывается индивидуально. Работа с юрлицами ведётся по договору с закрывающими документами.

Официальный сайт: timetta.com

2. GanttPRO — специализация на Гантах

GanttPRO — онлайн-инструмент для управления проектами, построенный вокруг интерактивной диаграммы Ганта. Он подходит командам, которым нужна быстрая визуализация сроков, зависимостей и ресурсов без сложного внедрения.

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

• Менеджеры проектов среднего звена. Интерфейс заточен под планирование сроков и контроль дедлайнов без IT-отдела.
• Маркетинговые и event-команды. Удобно строить таймлайны кампаний, делиться планами с заказчиками по публичной ссылке.
• Команды, мигрирующие с MS Project. Поддерживается импорт из MS Project, что упрощает перенос существующих планов.

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

GanttPRO предлагает диаграмму Ганта с зависимостями, автопланированием и критическим путём; иерархию задач и WBS; представления доски, списка, календаря, дашборда, портфеля и загрузки ресурсов; учёт рабочей нагрузки, бюджетирование и тайм-трекинг на старших тарифах; комментарии к задачам, вложения, упоминания и публичные ссылки для демонстрации планов; экспорт в PDF, PNG и Excel.

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

Решение работает полностью в браузере, без установки десктопного клиента. Данные хранятся в дата-центрах Microsoft Azure в ЕС. Поддерживаются основные платежные методы, включая карты и PayPal; для компаний доступна оплата по счёту. API есть, но собственная экосистема интеграций у GanttPRO уже, чем у крупных платформ вроде monday.com или Wrike.

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

По данным GanttPRO, инструментом пользуются более 1 млн проектных менеджеров. На Capterra сервис получает высокие оценки за удобство диаграмм Ганта (около 4,8/5). Часто отмечают чистый интерфейс и быстрый старт; среди ограничений — узкая экосистема интеграций и менее глубокие отчёты по сравнению с enterprise-PPM.

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

Поддержка доступна через email и базу знаний. На тарифе Enterprise предусмотрен приоритетный канал поддержки и enterprise onboarding. Документация и обучающие материалы публикуются на сайте.

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

GanttPRO работает по подписке. Тариф Core стоит от $7 за пользователя в месяц при годовой оплате, Advanced — $10, Business — $17, Enterprise — $25. Бесплатного тарифа нет, но доступен 14-дневный пробный период без привязки карты. Некоторые функции, например workload management и портфели, открываются только на тарифах Business и выше.

Официальный сайт: ganttpro.com

3. Kaiten — Agile и Гант

Kaiten — российская платформа для управления задачами, проектами и командами. Изначально позиционировалась как альтернатива Jira, Trello и Asana, но сегодня покрывает и классическое планирование через диаграмму Ганта, и гибкие методологии.

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

• IT-команды и продуктовые подразделения. X5 Tech использовала Kaiten при миграции из Jira, сохранив привычный подход к задачам.
• Ритейл и производство. Сервис работает в компаниях ВкусВилл, Мегафон, Додо Пицца, технопарке «Сколково».
• Команды, которым нужен единый инструмент. В Kaiten совмещены Kanban, Scrum, Гант, документы, базы знаний и служба поддержки.

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

Доступны канбан-доски с WIP-лимитами и дорожками, скрам-доски со спринтами, burndown-диаграммами и velocity; диаграмма Ганта, ресурсное планирование и зависимости между задачами; документы и базы знаний; автоматизации через конструктор правил и триггеров; AI-транскрибатор встреч и AI-помощник для оформления задач; отчёты по загрузке, lead time, block time и cumulative flow; мобильные приложения для iOS и Android.

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

Kaiten работает в облаке и предлагает серверную версию на Docker для тарифа «Корпорация» (от 300 пользователей). Продукт включён в реестр российского ПО, данные хранятся в России, оплата производится в рублях. Интеграции включают Jira, Trello, Notion, Asana, ClickUp, GitHub, GitLab, Slack, Telegram, Google Календарь и Яндекс Календарь.

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

По данным сайта, сервисом пользуются более 200 тысяч компаний. Публикуются именные кейсы клиентов: Buzzolls, «Сколково», X5 Tech, «Продман», «Авиационный Консалтинг-ТЕХНО». В независимых обзорах отмечают удобный интерфейс и рублёвую оплату; ограничения — функционал для портфельного управления и глубокого финансового учёта уступает специализированным PPM-системам.

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

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

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

Бесплатный тариф — до 5 пользователей с базовыми функциями. Платные тарифы: «Старт» от 185 ₽ за пользователя в месяц (при оплате на 36 месяцев), до 15 пользователей, включены модули Scrum и Kanban; «Стандарт» от 430 ₽ за пользователя в месяц, до 250 пользователей, два модуля на выбор; «Бизнес» от 580 ₽ за пользователя, до 250 пользователей, шесть модулей; «Корпорация» — индивидуальная цена, on-premise, от 300 пользователей. Каждый дополнительный модуль — от 80 ₽ за пользователя. Пробный период — 14 дней со всеми модулями.

Официальный сайт: kaiten.ru

4. Redmine — open source

Redmine — бесплатная open-source система управления проектами на Ruby on Rails. Это выбор для команд, у которых есть технические ресурсы для развёртывания и настройки, и которые не хотят зависеть от вендора и регулярных лицензионных платежей.

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

• Разработческие и IT-команды. Встроенная интеграция с Git, SVN, Mercurial, CVS и гибкая система трекинга задач.
• Компании с жёсткими требованиями к данным. Можно развернуть полностью в собственной инфраструктуре и контролировать доступ.
• Бюджетные проекты. Подходит стартапам, образовательным учреждениям и НКО, готовым потратить время на настройку вместо денег на лицензии.

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

Redmine поддерживает управление несколькими проектами, гибкую ролевую модель доступа, трекинг задач с кастомными полями и workflows, диаграмму Ганта и календарь, wiki и форумы для каждого проекта, учёт времени, документы и файлы, email-уведомления, интеграцию с LDAP и SCM, создание задач по email. Функциональность расширяется сотнями плагинов сообщества.

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

Решение распространяется под лицензией GNU GPL v2 и разворачивается на собственных серверах или в облаке. Поддерживаются разные СУБД (PostgreSQL, MySQL, SQLite) и ОС. API доступен для интеграций, но большинство интеграций реализуется через плагины или собственную разработку.

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

Redmine существует с 2006 года и имеет активное международное сообщество. Среди известных пользователей — множество open-source проектов, компаний в сфере IT, инжиниринга и консалтинга. В обзорах отмечают гибкость и отсутствие лицензионных платежей; к недостаткам относят устаревший интерфейс и необходимость в администрировании.

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

Официальная поддержка сообщества: форумы Redmine, IRC-канал #redmine в сети libera.chat, неофициальный Slack. Документация включает User's Guide, Developer's Guide, FAQ и HowTos. Коммерческую поддержку и хостинг предоставляют сторонние провайдеры, цены зависят от поставщика.

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

Сам Redmine бесплатен: нет лицензионных платежей и ограничений по числу пользователей или проектов. Реальные затраты — на собственное железо или облачный хостинг, администрирование и нужные плагины. Готовые хостинговые версии от сторонних провайдеров стоят от $10–25 за пользователя в месяц, но это цена провайдера, а не вендора.

Официальный сайт: redmine.org

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

Диаграмма Ганта и зависимости. Timetta и GanttPRO предлагают наиболее зрелый Гант с критическим путём и автопланированием. У Kaiten Гант доступен как подключаемый модуль, у Redmine — базовый, но функциональный.

Управление ресурсами. Timetta выделяется ресурсным планированием, бронированием и портфельной загрузкой. GanttPRO и Kaiten дают workload-вид, Redmine требует плагинов для глубокого ресурсного учёта.

Финансы и бюджеты. Timetta — единственный из четырёх с полноценным P&L, себестоимостью и взаиморасчётами. GanttPRO и Kaiten закрывают базовое бюджетирование, Redmine — через плагины.

Гибкие методологии. Kaiten лидирует по Kanban и Scrum из коробки. Timetta поддерживает гибридные схемы, GanttPRO ориентирован на классику, Redmine гибок через настройку workflows.

Размещение данных. Timetta и Kaiten предлагают российское облако и on-premise. GanttPRO хранит данные в Azure ЕС. Redmine разворачивается где угодно, включая собственный сервер.

Стоимость. Redmine бесплатен по лицензии, но требует ресурсов на поддержку. Kaiten стартует с бесплатного тарифа и далее от 185 ₽. GanttPRO — от $7. Timetta — индивидуально, с бесплатным тарифом Timetta Lite (Free) для команд до 10 пользователей.

Выводы

Прямого универсального заменителя MS Project не существует: каждый инструмент делает ставку на свои сценарии. Для крупного проектного офиса с финансовым контролем и портфелями логичнее смотреть на Timetta. Если главное — удобная диаграмма Ганта с быстрым стартом и импортом из MS Project, выбор GanttPRO выглядит естественным. Командам, которые живут в Kanban/Scrum, но иногда нужен Гант, подойдёт Kaiten. А Redmine остаётся рабочей лошадкой для технических команд, готовых взять на себя развёртывание и поддержку.

Но awk - это не утилита для вырезания колонок, это полноценный язык программирования с ассоциативными массивами, регулярками, форматированным выводом и управляющими конструкциями. Все то, ради чего обычно тянутся за Python-скриптом, awk умеет в одну строку прямо в терминале.

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

Задача 1: сумма по группам.

Дан файл /root/spend.txt - категория трат и сумма:

Нужно просуммировать по каждой категории.

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

Это работает. Но это три прохода по файлу на каждую категорию, внешний цикл в shell, и на большом файле оно будет работать очень медленно.

Да, awk '{sum += $2}' умеет накапливать одно число - общую сумму по всему файлу. Но как только сумм нужно несколько - по одной на категорию - рука тянется наружу, к циклу в shell, потому что "одна переменная - одна сумма". Но в awk не одна переменная. Здесь также есть ассоциативные массивы, где индексом может выступать строка.

Итого, решение через awk может выглядеть следующим образом:

Вот как это работает:

s[$1] += $2 - берем ячейку массива s с ключом "первое поле" и прибавляем к ней второе. Для строки food 10 это s["food"] += 10, для toys 5 - s["toys"] += 5. awk сам заводит новую ячейку когда встречает новый ключ, обнулять ничего не надо. Прошли весь файл - в массиве накопились суммы по всем категориям за один проход.

Блок END выполняется после того как файл закончился. for(k in s) обходит все ключи массива, print k, s[k] печатает ключ и накопленную по нему сумму.

Задача 2: уникальные строки с сохранением порядка

Дан файл /root/items.txt, строки в нем повторяются:

Нужно оставить только уникальные, сохранив порядок первого появления.

Тут даже awk сначала не вспоминаешь - есть же готовый инструмент:

Запускаем, получаем a b c. Вроде совпало. Но совпало случайно - в этом примере уникальные значения итак идут по алфавиту. sort -u сортирует, а значит **порядок первого появления теряется

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

Более простое решение задачи через awk:

По шагам:

$0 - это вся текущая строка целиком. seen[$0] - ячейка массива с ключом "эта строка". Для новой, еще не встречавшейся строки ее значение пустое, а в числовом контексте awk считает пустое за 0.

seen[$0]++ - это постфиксный инкремент: awk сначала возвращает текущее значение ячейки, а потом увеличивает его на 1. То есть при первой встрече строки выражение отдает 0 и тут же делает ячейку равной 1. При второй встрече отдает 1 (и делает равной 2), и так далее.

И ключевой момент: в awk, если условие написано без блока {...}, то то по умолчанию выполняется действие print - "напечатать строку"

Задача 3: строки между маркерами

В log.txt есть блок, обернутый в строки-маркеры --START-- и --END--:

Нужно вытащить то, что между маркерами - line1 и line2

И раз есть четкие границы, напрашивается grep или sed по диапазону. У sed даже есть готовый синтаксис "от x до y":

Но так мы получаем блок вместе с маркерами. Далее, чтобы выкинуть маркеры, можно начать городить что-то вроде sed -n '/--START--/,/--END--/{/--START--/d; /--END--/d; p}'. Но это уже не для слабонервных.

grep тут вообще не поможет - он смотрит на каждую строку отдельно и не знает, внутри блока она или снаружи. А вся суть задачи именно в этом - определить, находится ли текущая строка внутри интересующего нас блока. Инструменту надо помнить, где он находится, переходя от строки к строке. То есть нужна переменная-состояние - а это как раз задача для awk:

Здесь f - флаг. По умолчанию у неинициализированной переменной значение 0 = "не печатать".

Вся "программа" - это 3 правила подряд:

/--START--/{f=1; next} - строка совпала со стартовым маркером: ставим флаг в 1 и через next сразу прыгаем к следующей строке, не доходя до печати. Сам маркер не выводится.

/--END--/{f=0} - встретили конечный маркер, обнуляем флаг.

f - это третье правило, и оно ключевое. Голое условие без блока {...} в awk значит "напечатать строку, если условие истинно" (мы это уже видели в !seen[$0]++). Здесь условие - просто значение f. Когда f равен 1, строка печатается. Когда f равен 0, строка молча пропускается.

На выходе получаем ровно line1 и line2.

Задача 4: соединить два файла по ключу

Даны два файла с общим ключом в первом поле.

names.txt:

ages.txt:

Нужно соединить их по ключу-id и получить имя возраст.

По сути - обычный JOIN из SQL, только над двумя текстовыми файлами.

Как вариант, решить скриптом:

Работает, но каждая строка первого файла запускает отдельный grep по всему второму. Для 3-х строк неважно, но для файла на сотни тысяч строк это O(n²) и будет ползти очень долго.

Решение с помощью awk:

awk читает несколько файлов подряд как один поток и ведет два счетчика строк:

NR - общий номер строки с начала, сквозной по всем файлам.

FNR - номер строки внутри текущего файла, сбрасывается в 1 на каждом новом файле.

Пока awk идет по первому файлу, счетчики идут одинаково: FNR == NR. Как только awk переходит ко второму файлу, FNR обнуляется и стартует заново, а NR продолжает расти - равенство ломается. То есть FNR == NR - это способ понять, какой файл читается в данный момент.

FNR == NR {name[$1]=$2; next} - пока идем по names.txt, запоминаем: в ячейку name с ключом-id кладем имя.

{print name[$1], $2} - для каждой строки id возраст печатаем name[id] (имя, которое достаем из хэша по ключу мгновенно) и $2 (возраст).

Задача 5: awk на реальном файле - разбор /etc/passwd

/etc/passwd устроен так: семь полей, разделенных двоеточиями (имя, пароль-заглушка, UID, GID, комментарий, домашний каталог, login shell):

Нужно выписать имена пользователей, у которых shell - /bin/bash

Без awk эту задачу решают через grep | cut:

Работает, но с нюансом: grep '/bin/bash' матчит подстроку в любом месте строки, а не только в поле shell. Если у пользователя, скажем, домашний каталог /home/bin/bash-fan - grep его ошибочно поймает. Чтобы точно, надо якорить на конец: grep '/bin/bash$'. А потом еще cut отдельно. Два инструмента, и надо помнить про якорь.

awk же фильтрует именно по седьмому полю ($7 == "/bin/bash") - точное сравнение поля целиком, ложных срабатываний нет, и фильтр с извлечением в одной команде. Но чтобы обращаться к "седьмому полю", awk сначала надо объяснить, что поля здесь разделены не пробелами.

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

Для этого у awk есть флаг -F, определяющий разделитель полей.

Пример:

С -F: поле $1 - имя, $7 - shell. Двоеточие как разделитель, все семь полей сразу доступны по номерам.

Нужны только строки, где седьмое поле равно /bin/bash:

$7 == "/bin/bash" - правило-условие: блок выполняется только для строк, где shell именно /bin/bash. Системные аккаунты с nologin отсеиваются сами. И печатаем только $1 - имя.

Ни в одной из пяти задач не пришлось тянуться за Python или склеивать пайп из четырех утилит - awk справился сам. Все потому, что это не "вырезалка колонок", а язык с ассоциативными массивами, состоянием между строками и полями.

И учить его целиком не надо. Достаточно нескольких шаблонов:

массив[ключ] += значение - суммы по группам

!seen[$0]++ - убрать дубли, сохранив порядок

f=1 … f=0 … f - вырезать блок между маркерами

FNR == NR{…; next} {…} - склеить два файла по ключу

-F: - сменить разделитель

Задачи я взял из своего сервиса для практики в изучении Linux и DevOps - IzzyLab.ru. Там команды набираешь в живом терминале в браузере, а решение проверяется автоматически по состоянию системы, а не по тому, что ты ввел. Задач по Linux и DevOps там еще несколько сотен.

Timetta — российская платформа с таймшитами и управлением экономикой проектов; подходит компаниям, где зарплаты — основная статья расходов.

Clockify — щедрый бесплатный план и низкий порог входа в платные тарифы для небольших команд.

Toggl Track — минималистичный трекер с сильными отчётами, удобен фрилансерам и агентствам.

TimeCamp — акцент на автоматический учёт по ключевым словам и контроль бюджетов проектов.

Everhour — встраивает таймер прямо в задачи Asana, Jira, ClickUp и других таск-трекеров.

Как мы выбирали

Отбирали решения по критериям, важным для проектного бизнеса:

• возможность вести учёт времени по проектам и задачам
• биллинг
• отчётность
• интеграции
• мобильный доступ
• наличие бесплатного тарифа
• прозрачное ценообразование

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

1. Timetta — учёт через таймшиты

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

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

Решение в первую очередь выбирают компании с долей ФОТ свыше 60%:

• консалтинг
• аудит
• ИТ-интеграция
• разработка ПО
• дизайн и так далее

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

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

Платформа покрывает полный цикл проектного бизнеса:

• проекты, программы и портфели
• диаграммы Ганта с вехами, зависимостями и критическим путём
• таск-трекер с бэклогом и спринтами
• бронирование ресурсов и загрузка сотрудников
• таймшиты и учёт отсутствий, заявки на затраты, платёжные календари и процесс почасового биллинга, P&L-отчёты, клиенты и сделки
• корпоративная вики и ИИ-ассистент

В рамках Timetta доступны приложения: Timetta Projects, Timetta Finance, Timetta Resources, Timetta Timesheets, Timetta Clients, Timetta Tasks, Timetta Expenses и Timetta Wiki.

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

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

Система поставляется по модели SaaS или on-premise для установки на собственные серверы. Предусмотрены готовые интеграции с «1С:Зарплата и управление персоналом» и «1С:Управление холдингом», открытый API, а также авторизация через корпоративные каталоги (SSO/AD). Данные хранятся в дата-центрах Yandex Cloud на территории России, резервные копии сохраняются 30 дней.

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

В предоставленном брифе публичные агрегированные оценки и кейсы крупных клиентов не указаны, поэтому не формируем собственный рейтинг.

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

Техническая поддержка работает по электронной почте support@timetta.com с регламентированным временем ответа в течение часа. Документация размещена на сайте в разделе timetta.com/ru/docs. При внедрении возможна помощь инженеров вендора, включая миграцию данных из других систем.

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

Функции учёта рабочего времени вынесены в отдельное приложение Timetta Timesheets. Лицензии на него начинаются от 524 ₽ за пользователя в месяц с регрессионными скидками.

Недавно компания выпустила новую сборку Timetta Lite: она доступна бесплатно для команд до 10 активных пользователей без ограничения срока и теперь включает таймшиты. Для 11–50 пользователей предусмотрен платный тариф Team — 1 490 ₽ за пользователя в месяц. Подробности о релизе — в блоге Timetta. Мобильное приложение находится в разработке, а пока доступна адаптированная мобильная версия в браузере.

Официальный сайт: timetta.com

2. Clockify — бесплатный старт

Clockify — облачный тайм-трекер от CAKE.com с акцентом на простоту и щедрый бесплатный план. Подходит командам, которым нужно быстро начать учёт часов без сложного внедрения.

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

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

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

• веб-приложение, десктопные клиенты (Windows, macOS, Linux), мобильные приложения iOS/Android и расширения для браузеров
• таймер, ручной ввод, таймшиты, календарь, автотрекер, Pomodoro, обнаружение простоя, интеграции с внешними сервисами
• в платных тарифах — киоск, биллинговые ставки, инвойсы, утверждение таймшитов, отпуска, бюджеты, GPS и скриншоты

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

Clockify работает в облаке AWS, сертифицирован по ISO/IEC 27001, соответствует SOC 2 Type II и GDPR. В Pro-плане доступен выбор региона хранения данных. Интеграции охватывают более 80 приложений; есть публичный API и вебхуки.

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

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

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

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

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

Бесплатный план включает неограниченный трекинг, проекты и клиентов, но ограничен пятью пользователями. Платные тарифы при годовой оплате: Basic — $3,99, Standard — $5,49, Pro — $7,99, Enterprise — $11,99 за пользователя в месяц. Все платные планы можно протестировать в течение семи дней.

Официальный сайт: clockify.me

3. Toggl Track — минималистичный трекер

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

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

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

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

• веб, десктоп (Windows, macOS, Linux), мобильные приложения iOS/Android и браузерные расширения
• таймер, ручной ввод, офлайн-трекинг, автоматическое обнаружение простоя, Pomodoro, личные и командные цели, более 100 интеграций, API и вебхуки
• встроенного инвойсинга нет — данные выгружаются или передаются через интеграции

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

Toggl Track сертифицирован по ISO/IEC 27001, поддерживает 2FA и SSO, заявлено соответствие GDPR. Производитель декларирует доступность 99,9%, однако SLA в публичных источниках не публикуется.

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

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

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

Доступны база знаний, community-форум и email-поддержка. Приоритетная поддержка по email открывается на Premium, персональный менеджер — на Enterprise. Телефонной поддержки нет.

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

Бесплатный план рассчитан на команды до пяти пользователей и включает неограниченные проекты и клиентов. Платные планы: Starter — от $9, Premium — от $18 за лицензию в месяц, Enterprise — индивидуальные условия. Есть 30-дневная пробная версия.

Официальный сайт: toggl.com/track

4. TimeCamp — автоматический контроль

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

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

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

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

• веб-приложение, десктопный агент, мобильные приложения и расширения
• таймер, таймшиты, keyword-based автоучёт, attendance и overtime, отпуска, бюджеты и сметы, биллинговые ставки, инвойсинг, утверждение таймшитов и ролевая модель
• интеграции с Asana, Trello, Jira, Monday, ClickUp, Wrike и другими инструментами

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

Штаб-квартира компании находится в ЕС (Польша), обработка данных ведётся в соответствии с GDPR. Для бизнес-клиентов доступно соглашение DPA. Для организаций от 50 пользователей предлагаются on-premise и private SaaS на основе годового Ultimate-тарифа.

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

Публичная агрегированная оценка или число клиентов в официальных источниках не раскрыты.

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

Поддержка доступна по email help@timecamp.com и через базу знаний на сайте. На Enterprise плане заявлен приоритетный support с SLA.

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

Бесплатный план доступен для неограниченного числа пользователей и включает проекты, таймшиты и приложения. Платные тарифы при годовой оплате: Starter — $3,99, Premium — $6,99, Ultimate — $9,99 за пользователя в месяц, Enterprise — по запросу. Все платные планы можно протестировать 14 дней.

Официальный сайт: timecamp.com

5. Everhour — бюджеты проектов

Everhour встраивает учёт времени непосредственно в популярные таск-трекеры: кнопка таймера появляется рядом с задачей в Asana, Trello, Jira, ClickUp и других инструментах. Это снижает переключение контекста и упрощает контроль бюджетов.

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

Решение подходит агентствам, продуктовым командам и консалтинговым компаниям, которые уже ведут задачи в Asana, Jira, Monday или ClickUp. Минимальное отвлечение сотрудников — основное преимущество для команд, привыкших работать внутри одного инструмента.

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

• работа через веб-приложение и расширение для Chrome, которое добавляет элементы управления в интерфейс таск-трекера
• таймер, ручной ввод, бюджеты проектов в часах и деньгах, счета на оплату, отслеживание расходов, планирование ресурсов, отчёты с экспортом CSV/PDF, SSO и гибкие права доступа

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

Everhour — облачный SaaS. Нативные интеграции охватывают Asana, Trello, Jira, ClickUp, Monday, Basecamp, GitHub, Notion, Linear, а также Slack, Google Calendar, QuickBooks, FreshBooks, Xero и другие сервисы. Мобильных и десктопных приложений нет, офлайн-режим не поддерживается.

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

На официальном сайте указан рейтинг 4,7 из 5 на платформе G2. Детальная методология или число отзывов не раскрыты.

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

Поддержка через email и базу знаний. На тарифе Custom доступен персональный менеджер и приоритетная поддержка с ускоренным ответом.

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

Бесплатный план рассчитан на команды до пяти мест. Платный Team — $8,50 за место в месяц при годовой оплате, минимум пять мест. Тариф Custom для крупных организаций рассчитывается индивидуально. Пробный период — 14 дней.

Официальный сайт: everhour.com

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

Бесплатный тариф: у Timetta — Timetta Lite до 10 активных пользователей, теперь с таймшитами; Clockify и Toggl Track ограничивают 5 пользователями; TimeCamp позволяет неограниченное число пользователей; Everhour — до 5 мест.

Минимальная цена: Timetta — от 524 ₽ за модуль Timesheets; Clockify и TimeCamp — от $3,99; Everhour — $8,50; Toggl Track — $9.

Автоматический трекинг: реализован в TimeCamp по ключевым словам и в Clockify/Toggl Track через десктопные агенты; Timetta и Everhour ориентированы на ручные таймшиты и таймеры.

Биллинг и инвойсы: встроены в Timetta, Clockify (с Standard), TimeCamp (Ultimate+) и Everhour; Toggl Track предлагает только отчёты с возможностью экспорта.

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

Вывод

Для российских проектных компаний с жёсткими требованиями к учёту экономики и локализации данных логичнее смотреть на Timetta. Если приоритет — минимальная цена или бесплатный старт, стоит протестировать Clockify или TimeCamp. Toggl Track удобен для быстрого учёта без лишних настроек, а Everhour — для команд, которые уже работают в Asana, Jira или ClickUp. Перед выбором стоит проверить, какой формат трекинга привычен команде: ручные таймшиты, автоматический контроль или встроенные кнопки в задачи.

В августе 2026 года рынок моделей для генерации кода уперся в новый потолок: Anthropic выпустила Claude Opus 5, OpenAI показала GPT-5.6 Sol в ограниченном доступе, а китайские разработчики предложили открытые веса с результатами уровня флагманов прошлого квартала. Разбираем, что из этого реально купить и как не переплатить.

Что такое SWE-bench и почему он стал главным аргументом

SWE-bench Verified — это набор из 500 реальных задач с GitHub: модели видят описание бага и должны сгенерировать патч, который проходит существующие тесты проекта. Не задачи из LeetCode, а настоящие репозитории с чужой архитектурой и зависимостями. Для оценки кодогенерации это ближе к продакшену, чем большинство альтернатив.

С апреля 2026 года Verified «насытился»: топ выстроился в узкий коридор 95-96%. Поэтому внимание переключилось на SWE-bench Pro — 1865 более сложных задач из 41 репозитория на нескольких языках. Именно здесь видна разница между «хорошо пишет функции» и «разбирается в большом коде».

Claude Opus 5 — лучший баланс качества, цены и доступности: 96,0% на SWE-bench Verified и $5/$25 за миллион токенов.

Claude Mythos 5 лидирует на SWE-bench Pro (80,3%), но доступен лишь ~100 партнёрам программы Glasswing.

GPT-5.6 Sol теоретически первый по Verified (96,2%), но цифра не подтверждена OpenAI, а доступ ограничен ~20 партнёрами.

GLM-5.2 — сильнейший открытый вариант: 62,1% на SWE-bench Pro под лицензией MIT, но сжигает в 2-3 раза больше выходных токенов.

Gemini 3.1 Pro и DeepSeek V4-Pro предлагают ~80% на Verified за $2-3 за миллион токенов — лучшее соотношение цена/качество для массовых задач.

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

Claude Opus 5 — практичный выбор

Anthropic выпустила Claude Opus 5 24 июля 2026 года по цене старого Opus 4.8: $5 за входящий и $25 за исходящий миллион токенов. На SWE-bench Verified модель набрала 96,0%, а на более сложном SWE-bench Pro — 79,2%. Этого хватает для большинства инженерных задач, а цена остаётся вдвое ниже, чем у Mythos-класса.

Главное ограничение Opus 5 — уступка собственным старшим собратьям на Pro. Если ваша работа связана с большими межрепозиторными изменениями, Mythos 5 и Fable 5 дают 80,0-80,3%, но вы платите $10/$50 за миллион токенов и, в случае Mythos, ещё и проходите отбор в программу Glasswing.

Mythos 5 и Fable 5 — потолок, до которого не дотянуться

В июне Anthropic представила Claude Fable 5 и Claude Mythos 5 — первые модели, преодолевшие 90% на SWE-bench Verified. Обе показывают 95,0% Verified, а Mythos 5 держит лучший результат на Pro — 80,3%. Fable 5 доступен через обычный API любому клиенту, готовому платить Mythos-тариф.

Mythos 5 закрыт примерно для 100 партнёров в рамках программы Glasswing, в основном для исследований в области кибербезопасности и биобезопасности. Это важный нюанс для российских команд: даже если у вас есть бюджет, доступ к модели зависит от одобрения Anthropic, а не только от платёжной карты.

GPT-5.6 Sol — красивое число, которое никто не проверил

OpenAI выпустила GPT-5.6 Sol в ограниченном превью для примерно 20 партнёров, прошедших правительственную проверку. Компания не опубликовала официальных результатов SWE-bench, но сторонние трекеры, включая vals.ai, сообщают 96,2% на Verified.

Пока это не результат, на который можно ориентироваться при выборе инструмента. Цена, если доступ появится, составляет $5/$30 за миллион токенов — чуть дороже Opus 5. Для российских пользователей добавляется и стандартная проблема доступа к API OpenAI, которая уже несколько лет сильнее ограничена, чем у Anthropic или Google.

GLM-5.2 — открытые веса с реальными цифрами

Zhipu AI выпустила GLM-5.2 под лицензией MIT. Модель показывает 62,1% на SWE-bench Pro — выше, чем GPT-5.5 (58,6%), и выше предшественника GLM-5.1 (58,4%). Контекстное окно составляет 1 млн токенов, а обучение проходило на чипах Huawei Ascend, а не NVIDIA.

Цена API — $1,40/$4,40 за миллион токенов, но на практике GLM-5.2 расходует около 43 000 выходных токенов на одну кодинговую задачу против 16 000 у GPT-5.5. Поэтому итоговая стоимость за выполненную задачу ближе к флагманам, чем кажется по прайс-листу. Главное преимущество — возможность скачать веса и развернуть модель у себя. Для команд с требованиями к локальному хранению кода это может перевесить экономию на API.

Gemini 3.1 Pro и DeepSeek V4-Pro — флагманы за разумные деньги

DeepSeek V4-Pro и Gemini 3.1 Pro показывают по 80,6% на SWE-bench Verified — ровно тот уровень, который в апреле считался потолком. DeepSeek стоит $1,74/$3,48 и работает с полностью открытыми весами. Gemini 3.1 Pro стоит $2/$12, имеет окно в 1 млн токенов и 91,7% на LiveCodeBench.

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

Как читать таблицу моделей

Результаты можно свести к трём осям: качество на Verified, качество на Pro и реальная доступность. Если смотреть только на Verified, четыре модели стоят плечом к плечу в диапазоне 95,0-96,2%. Разница появляется, когда добавляешь цену, условия доступа и более жёсткий бенчмарк.

Как ориентироваться в ценах:
Цены указаны за 1 млн входящих / 1 млн исходящих токенов. На практике важнее стоимость за завершённую задачу: одна модель может быть дешевле за токен, но генерировать в 2-3 раза больше текста.

Вот как распределяются роли:

• Claude Opus 5 — универсальный выбор, если нужен API без листов ожидания и цена ниже Mythos.
• Claude Mythos 5 — для команд с доступом к Glasswing, которые решают самые сложные многофайловые задачи.
• GLM-5.2 — для self-hosted сценариев и требований к открытым весам.
• DeepSeek V4-Pro и Gemini 3.1 Pro — для высоконагруженных сценариев, где важна цена за токен.

Методология: почему Verified больше не разделяет лидеров

Авторы обзора используют три сигнала. SWE-bench Verified даёт понять, справляется ли модель с реальными багами. SWE-bench Pro проверяет, как модель работает с более крупными и разнообразными репозиториями. Третий сигнал — это статус доступа и независимость проверки: официальная цифра, сторонний трекер или собственная оценка вендора.

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

Историческая динамика: бенчмарки устаревают быстрее моделей

В марте 2025 года лидером был Claude 3.5 Sonnet с около 49%. В январе 2026 четыре модели одновременно преодолели 78%. В апреле Verified «сел» на плато 76-81%, и внимание перешло на Pro. В июне Mythos-класс впервые превысил 90%, а к концу июля Opus 5 почти догнал его по цене вдвое ниже.

Этот цикл повторяется: бенчмарк насыщается, появляется более сложная версия, цена становится главным разделителем. Для команд это означает, что не нужно гнаться за каждым новым релизом. Достаточно раз в квартал пересматривать соотношение цена/качество и проверять, не появился ли модель с доступным API, который закрывает 80% ваших задач за меньшие деньги.

Что выбрать: чек-лист для команды

Чтобы не утонуть в таблицах, можно пройти по четырём вопросам:

1. Есть ли у вас доступ к API Anthropic, OpenAI или Google? Если нет, открытые веса DeepSeek или GLM-5.2 остаются единственной рабочей опцией.
2. Решаете ли вы локальные баги в одном репозитории или межрепозиторные изменения? Для второго важнее SWE-bench Pro.
3. Какой бюджет на 1 млн исходящих токенов? При высоких объёмах разница между $25 и $3 за миллион ощутима уже на первой неделе.
4. Нужно ли хранить код внутри периметра? В этом случае self-hosted GLM-5.2 или DeepSeek выигрывают у облачных API независимо от бенчмарков.

Когда Verified перестаёт разделять модели, выбор сдвигается с 'кто умнее' на 'кого я могу купить и сколько это будет стоить за реальную задачу'.

FAQ

Выводы

В июле 2026 года рынок моделей для генерации кода разделился на два лагеря. Первый — закрытые флагманы, которые достигли потолка Verified и теперь конкурируют по цене и доступности. Второй — открытые и полуоткрытые модели, которые отстают по верхним цифрам, но выигрывают у крупных вендоров в контроле над данными и стоимости инфраструктуры.

Для российских команд ключевой вопрос не в том, какая модель «умнее», а в том, какая из них реально доступна, не требует сложных схем оплаты и укладывается в бюджет. В этом контексте Claude Opus 5, DeepSeek V4-Pro и GLM-5.2 выглядят наиболее практичными вариантами — каждый под свои ограничения.

Источник: обзор Best AI Models for Code Generation — July 2026 на Awesome Agents. Данные по бенчмаркам и ценам приведены по состоянию на 29 июля 2026 года.

Qwen 3.8-Max — флагман Alibaba с 2,4 трлн параметров (95 млрд активных).

Это первая модель линейки Max, чьи веса выложат в open source.

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

Доступна через API QwenCloud с параметром reasoning_effort и интегрируется с Claude Code, Codex и Qoder.

Что анонсировали

Qwen 3.8-Max построена на архитектуре Qwen 3.5 и насчитывает 2,4 трлн параметров, из которых активируются примерно 95 млрд. Это делает её одной из крупнейших публично анонсированных моделей и первой мультимодальной системой Qwen, преодолевшей отметку в 1 трлн параметров.

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

Ключевые возможности

• Автономный кодинг. В демонстрации модель 16 дней без участия человека развивала проект oh-my-cli: 265 коммитов, 127 pull request'ов и 151 issue. Главная фишка — самообучающийся цикл: требования превращаются в задачи, которые агенты берут в работу, тестируют и сливают в main.
• Научные исследования. Qwen 3.8-Max воспроизвела эксперимент из статьи «Unified Data Selection for LLM Reasoning» с нуля — около 7 600 строк кода, 33 цикла обучения на GPU — а затем улучшила результат на 2,7 балла на бенчмарке AIME24.
• Соревнования. За 24 часа модель построила решение для конкурса WWW2025 Multimodal Dialogue Intent Recognition на платформе Tianchi и обошла 458 из 526 человеческих команд (87%).
• Рабочие сценарии. В тестах Qwen 3.8-Max проектировала интерфейсы, составляла меню ресторана с расчётом себестоимости, проверяла юридические документы и строила сейсмические модели зданий.
• Чип-дизайн. Модель самостоятельно прошла весь фронтенд-флоу цифровой схемы: от RTL до физического layout в OpenROAD, сократив площадь кристалла на 81% и добившись тактовой частоты 500 МГц.

Бенчмарки

В опубликованной таблице Qwen 3.8-Max сравнивается с Claude Opus 4.8, Claude Fable 5, GPT 5.6 Sol и предшественником Qwen 3.7-Max. По внутренним тестам Alibaba новинка обгоняет Qwen 3.7-Max на большинстве задач и приближается к лучшим закрытым моделям в кодинге и мультимодальных бенчмарках. Отдельно отметим PaperBench — 93,0 балла против 90,5 у GPT 5.6 Sol и 64,8 у Qwen 3.7-Max.

Как попробовать

Модель уже доступна через QwenCloud. API совместим с OpenAI и Anthropic, поэтому подключение занимает буквально минуту. Поддерживаются три уровня глубины рассуждений: xhigh, medium и low. По умолчанию включён preserve_thinking.

Минимальный пример на Python:

Кроме прямого API, модель завели в Claude Code, Codex, Qoder CLI, Qwen Code и OpenClaw. Контекстное окно — до 1 млн токенов, максимальная длина ответа — 65 536 токенов.

FAQ

Выводы

Qwen 3.8-Max — это попытка Alibaba вывести флагманскую линейку в open source и при этом конкурировать с лучшими закрытыми моделями. Если открытые веса действительно выйдут под пермиссивной лицензией, у разработчиков появится серьёзная альтернатива для локального запуска и дообучения. Пока же модель можно протестировать через QwenCloud.

Источник: Qwen 3.8-Max: A New Bar for Coding and Cowork.

В этой статье разберём, почему стандартные assert-тесты и record-and-replay плохо справляются с автономными агентами, как теория графов помогает выделить обязательные этапы задачи и что из этого следует для российских команд, которые уже пробуют GitHub Copilot или собственных агентов в CI/CD.

Исследование, опубликованное 6 мая 2026 года в блоге GitHub, описывает метод валидации агентского поведения, который не требует ручного написания скриптов для каждого сценария и не верит агенту на слово. Вместо этого он строит модель «ground truth» из 2–10 успешных выполнений и проверяет новые запуски по структуре, а не по совпадению шагов.

• ИИ-агенты с Computer Use недетерминированы: один и тот же задача может решаться разными путями.
• GitHub предлагает Trust Layer — внешний слой валидации, который учится на успешных запусках и выделяет обязательные этапы.
• В основе — Prefix Tree Acceptor (PTA) и dominator analysis из теории компиляторов.
• В эксперименте метод показал 100% accuracy, precision, recall и F1 против 82,2%, 83,3%, 60,0% и 69,8% у самооценки агента.
• Trust Layer лучше определяет «не баг, а шум»: F1 52,2% против 0% у внутренней самопроверки агента.

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

Почему классические тесты сдаются

Привычные инструменты тестирования хороши, пока путь выполнения фиксирован. Как только поведение начинает ветвиться, они начинают ломаться не от плохой инженерии, а от неверной посылки: «правильность = точное совпадение последовательности состояний».

• Assertion-based testing требует вручную прописывать каждую проверку и не терпит допустимых альтернативных путей.
• Record-and-replay чувствителен к задержкам сети, рендерингу и незначительным изменениям интерфейса.
• Visual regression сравнивает скриншоты изолированно, не понимая контекста выполнения и семантики состояний.
• ML-оракулы — чёрный ящик: нужны тысячи примеров обучения, и невозможно объяснить, почему помечен конкретный прогон как ошибочный.

В России эта проблема особенно актуальна для команд, которые используют self-hosted runners или зеркала репозиториев. Сетевые лаги, доступ к зарубежным API и особенности локальной инфраструктуры добавляют ещё больше «шума», не связанного с качеством кода. В результате CI начинает «краснеть» по чужой вине, а разработчики привыкают игнорировать падения.

Что значит «правильно» для агента

GitHub предлагает переформулировать определение корректности: не «агент повторил записанный сценарий», а «агент достиг обязательных результатов». Это разделяет поведение на три категории.

• Обязательные состояния (essential states). Этапы, без которых успех невозможен. Например, открытие диалога поиска и появление результатов.
• Опциональные вариации (optional variations). Случайный шум: спиннер загрузки, небольшая задержка, временное уведомление.
• Сходящиеся пути (convergent paths). Разные последовательности действий, которые приводят к одному и тому же итоговому состоянию.

Ключевой инсайт: если состояние «спиннер загрузки» можно пропустить в быстром прогоне, оно не может быть обязательным. А вот состояние «диалог поиска открыт» доминирует результат: без него невозможно получить список найденного. Эта идея напрямую заимствована из теории компиляторов — dominator analysis.

Как устроен Trust Layer

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

От трасс к графу

Вместо линейного скрипта каждое выполнение представляется как направленный граф. Узлы — наблюдаемые состояния: скриншоты интерфейса, снапшоты кода или структуры DOM. Рёбра — действия агента: клики, нажатия клавиш, вызовы API. Несколько успешных трасс объединяются в Prefix Tree Acceptor (PTA) — дерево, которое сохраняет общие префиксы и разветвляет пути там, где выполнения действительно расходятся.

Три уровня эквивалентности

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

1. Визуальные метрики. Быстрые perceptual hash и SSIM ловят почти идентичные скриншоты.
2. Семантический анализ через LLM. Мультимодальная модель решает, значима ли разница: timestamp или декорация окна игнорируются, пропавшая кнопка или другое сообщение об ошибке — фиксируются.
3. Консервативное слияние. Состояния объединяются только при высокой уверенности, чтобы не потерять реальное расхождение.

Доминаторы выделяют суть

После слияния к графу применяется dominator analysis. Состояние A доминирует состояние B, если любой путь от начала к B проходит через A. Те состояния, которые доминируют успешное завершение задачи, становятся обязательными. Всё остальное автоматически классифицируется как опциональный шум.

При проверке нового прогона алгоритм не ищет точное совпадение. Он проверяет, что обязательные состояния появились в правильном порядке. Если эталонная последовательность A → B → C, а агент выполнил A → X → B → Y → C, тест проходит: X и Y считаются случайными вставками. Если пропущено B или нарушен порядок — фиксируется конкретная ошибка с пояснением, какое состояние не достигнуто.

Цифры: насколько это лучше

Авторы сравнили свой метод PTA (Dominator Tree) с самооценкой агента Computer-Use Agent (CUA) на наборе тестов кастомного расширения VS Code. Разница оказалась впечатляющей.

• Accuracy: CUA — 82,2%, PTA — 100% (+17,8 п. п.).
• Precision: CUA — 83,3%, PTA — 100% (+16,7 п. п.).
• Recall: CUA — 60,0%, PTA — 100% (+40,0 п. п.).
• F1-Score: CUA — 69,8%, PTA — 100% (+30,2 п. п.).

Ещё важнее метрика «не баг, а шум» (not-a-bug). Сам агент не смог корректно классифицировать такие сценарии: F1 оказался 0%. Trust Layer на основе структурного анализа достиг F1 52,2%. Это означает, что разработчики тратят меньше времени на разбор ложных падений.

We don’t need black-box models to judge other black-box models. We need structural guarantees developers can inspect, reason about, and trust.

Как это применить в своём CI/CD

Полноценная реализация Trust Layer требует исследовательского прототипа, но идеи можно перенести и в повседневную работу команд.

1. Собирайте «золотые» трассы. Сохраняйте 2–10 успешных выполнений критичного сценария, чтобы у будущих прогонов была эталонная структура.
2. Отделяйте «должен быть» от «может быть». Вместо проверки каждого шага фиксируйте ключевые чекпоинты: авторизация выполнена, данные сохранены, ответ получен.
3. Делайте тесты толерантными к порядку. Если несколько допустимых путей ведут к одному результату, проверяйте результат и наличие обязательных промежуточных состояний, а не точную последовательность.
4. Используйте семантику, а не пиксели. Визуальные регрессии должны понимать, что изменилось, а не просто считать разницу между скриншотами.
5. Не верьте агенту на слово. Внешняя валидация по состояниям среды надёжнее самооценки модели, особенно в недетерминированных задачах.

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

Выводы

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

Подход GitHub с Trust Layer, PTA и dominator analysis даёт объяснимую и лёгкую модель корректности, которую можно встроить в CI/CD. Она не требует тысяч примеров и не превращается в чёрный ящик. А главное — снижает количество ложных падений, за которыми теряются настоящие баги.

Источник: Validating agentic behavior when “correct” isn’t deterministic — The GitHub Blog.

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

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

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

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

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

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

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

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

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

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

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

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

Из интересных моментов, где мне пришлось немного больше возиться, чем с остальными сервисами это nextcloud настройка:

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

Synapse требовал слишком много ресурсов, впустую расходовал оперативку домашнего ПК и усложнял конфиг Nginx. При этом реальной пользы для семьи он не приносил. Для критических алертов инфраструктуры и повседневного общения проще и эффективнее оказалось использовать Telegram. (плюс алертинг настроен именно через него) В итоге я полностью выпилил Synapse из стека, освободив ресурсы.

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

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

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

Также благодаря Ansible я удобно реализовал переносимость проекта. Так как я решил не использовать тома docker, и вместо этого храню все в папках, чтобы перенести старые данные проекта нужно просто скопировать папку apps-data и положить ее в нужное место и все само заработает после повторного развертывания проекта. В Ansible выделяется отдельная пауза для этого.

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

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

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

Главная проблема при бэкапе работающих Docker-контейнеров — риск скопировать базу данных в «битом» или неконсистентном состоянии, если в момент создания архива в нее шла активная запись. Чтобы решить эту проблему, я задействовал механизм хуков в конфигурации Borgmatic.

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

Он эффективно собирает логи со всех запущенных Docker-контейнеров, парсит их и передает в Loki. Теперь вся история событий, ошибок веб-сервера Nginx или падений внутренних приложений доступна в едином интерфейсе Grafana с возможностью удобной фильтрации через LogQL, что значительно упрощает отладку.

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

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

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

Заключение

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

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Это моя первая статья на этом сайте и в то же время первый личный проект, которому я отдал так много времени (3 месяца). Буду рад вашему фидбеку в комментариях!

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

Исследователь Cereblab перехватил трафик Grok Build 0.2.93 и обнаружил загрузку 5,1 ГБ в корзину Google Cloud — в 27 800 раз больше, чем требовала задача.

В выгрузку попадали файлы, которые агент никогда не открывал, а также неотредактированные credentials из .env и SSH-ключи.

xAI отключила сервер загрузки 13 июля, а 15 июля опубликовала код под Apache 2.0.

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

По данным издания DevOps.com, исследователь под псевдонимом Cereblab использовал mitmproxy, чтобы перехватить сетевой трафик версии 0.2.93. Тестовый репозиторий объёмом 12 ГБ привёл к передаче около 192 КБ полезного трафика, но параллельно в корзину grok-code-session-traces ушло 5,1 ГБ в 73 частях. Внутри оказались файлы, не связанные с текущей задачей, включая SSH-ключи, базу паролей, личные документы и фотографии.

Переключатель «Improve the model» не влиял на поведение: загрузка шла независимо от настроек приватности. Это противоречит маркетинговым заявлениям xAI о том, что во время сессии код не покидает компьютер пользователя. 13 июля серверную сторону отключили без security advisory, а Илон Маск пообещал «полностью и безвозвратно» удалить все ранее собранные данные.

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

Что делать разработчикам

• Если до 13 июля запускали Grok Build на репозиториях с живыми credentials — смените пароли, SSH-ключи и токены.
• Проверяйте сетевую активность любых агентов с доступом к файловой системе через инструменты вроде mitmproxy.
• Запускайте ИИ-агентов в изолированном окружении с ограниченными правами.
• Требуйте от вендора письменной политики обработки данных до развёртывания инструмента.

Инцидент с Grok Build показывает, что кодовые агенты — это неконтролируемые нечеловеческие идентификаторы с постоянным доступом к коду, учётным данным и инфраструктуре, но программы безопасности всё ещё управляют ими как обычным инструментом разработчика. Публикация исходного кода после факта не заменяет доказуемые средства контроля безопасности.

Источник: DevOps.com.

Godot Engine — это открытый кроссплатформенный игровой движок, который многие инди-разработчики рассматривают как альтернативу Unity. Проектом управляет некоммерческая Godot Foundation, а код собирается из пул-реквестов со всего мира. Это делает правила contributions ключевым инструментом выживания экосистемы.

Основной тезис обновления: любой существенный код должен быть написан человеком, который способен отвечать за него. Автономные ИИ-агенты, «vibe-coded» PR и ИИ-сгенерированный текст в обсуждениях попадают под запрет. Мелкие вспомогательные задачи — code completion, регулярки, find-and-replace — остаются, но с обязательным раскрытиием.

• Godot Foundation запретила ИИ-агентам и «vibe coding» создавать пул-реквесты с существенным кодом.
• Разрешены только мелкие вспомогательные операции: code completion, regex, find-and-replace с обязательным дисклеймером.
• Новички (≤3 принятых PR) теперь должны получать одобрение мейнтейнеров перед новыми фичами и крупными рефакторингами.
• Главный аргумент — ревью кода — это не только проверка, но и менторство будущих мейнтейнеров, а ИИ из этого контура выпадает.
• Похожие ограничения уже ввели Zig, Ghostty и curl: проблема AI slop стала системной для open source.

Что именно запрещено

В официальном посте Changes to our Contribution Policies Foundation перечисляет три запрещённые категории. Важно, что они касаются не только ботов, но и людей, которые копируют ИИ-вывод в PR, даже если потом вручную проверяют и дисклейсят.

• Автономные ИИ-агенты и «vibe coding». PR, созданные без глубокого участия человека, уже отклоняются автоматически.
• ИИ как автор существенного кода. Блоки логики, сгенерированные моделью, не принимаются независимо от того, кто нажал «Submit».
• ИИ-сгенерированный текст в коммуникации. Обсуждения с мейнтейнерами должны вестись людьми; исключение — машинный перевод человеческого текста.

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

Почему это больше, чем «слишком много PR»

Сама по себе нагрузка на ревьюеров — старая open-source-боль. Но здесь добавляется другой эффект: обратная связь на ИИ-код не учит никого. Если модель сгенерировала патч, комментарий мейнтейнера не улучшит следующий выход той же модели, а автор-человек часто не понимает кода достаточно, чтобы довести правку до ума.

Reviewing PRs is already tedious work, but it is rewarding because reviewers generally feel that their efforts are contributing to educating a new contributor — who may become a future maintainer/reviewer. If your feedback on PRs is just being absorbed by a machine and not going towards mentoring a potential future maintainer, it becomes much harder to justify spending your free time on PR review.

В интервью Game Developer Foundation прямо говорит: «AI cannot take responsibility, and we can’t trust heavy users of AI to understand their code enough to fix it». Это не ненависть к ИИ как технологии, а признание, что ответственность за код должен нести конкретный человек.

«Contributor poker»: инвестиция в человека, а не в код

Эта логика не нова. В апреле 2026 года язык программирования Zig ввёл схожий zero-tolerance policy для ИИ-помощи в contributions. Вице-президент Zig Software Foundation Лорис Кро назвал ревью «contributor poker»: в покере вы играете против человека, а не против карт. Аналогично мейнтейнер вкладывает время не в конкретный PR, а в человека, который его прислал.

In contributor poker, you bet on the contributor, not on the contents of their first PR.

Когда PR написан ИИ, ставка срывается: ревью не превращает автора в будущего мейнтейнера, потому что автор не учится. Именно поэтому Godot и Zig формулируют запрет не как «ИИ плох», а как «менторская петля разрывается».

Godot не один: Zig, Ghostty и curl

Та же проблема AI slop в разных проявлениях встречается и в других крупных проектах. Терминал Ghostty ограничил поток ИИ-сгенерированных issue, а библиотека curl пережила настоящий DDoS фальшивыми security-репортами.

curl — самый известный пример. Создатель проекта Даниэль Стенберг писал, что в 2025 году доля валидных security-репортов упала примерно до одной из двадцати: «We are effectively being DDoSed». Часть отчётов содержала GDB-сессии и дампы регистров для функций, которых в curl не существует. В ответ команда закрыла bug bounty на HackerOne и перешла к более жёсткой модерации.

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

Пайплайн талантов под угрозой

Godot и Zig формулируют свой запрет в терминах mentorship pipeline — цепочки, по которой первый контрибьютор превращается в ревьюера, а ревьюер — в мейнтейнера. Если между «новичок» и «опытный разработчик» встает ИИ, обратная связь не доходит до человека, и вся цепочка останавливается.

В корпоративной среде эта же проблема звучит иначе: The New Stack в апреле цитировал Марка Руссиновича и Скотта Хансельмана из Microsoft, которые предупреждали: если компании будут заменять junior-разработчиков senior-инженерами с ИИ-ассистентами, «the profession’s talent pipeline collapses».

We need to take steps to reduce the burden on maintainers while ensuring we still have a pipeline to mentor new contributors to become future maintainers.

Что делать разработчикам

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

1. Читайте правила contributions конкретного проекта перед отправкой PR.
2. Раскрывайте использование ИИ для autocomplete, regex и мелких правок — честность ускоряет ревью.
3. Не отправляйте сгенерированные моделью блоки логики как «свой» код: вы должны понимать каждую строку.
4. Если у вас ≤3 принятых PR в Godot, начинайте с багфиксов и документации, а не с новых фич.
5. Проверяйте ИИ-репорты безопасности вручную: hallucinated уязвимости тратят время мейнтейнеров зря.

FAQ

Выводы

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

Things change every day with respect to the current suite of AI tools available. We will continue taking a conservative approach in our policies towards them, but we will re-evaluate as things evolve.

Источники: The New Stack, Godot Foundation, Game Developer.

В статье loops определяются просто: агент повторяет циклы работы до тех пор, пока не выполнится условие остановки. Разница между типами циклов Anthropic выводит из четырёх вещей: что запускает цикл, что его останавливает, какая примитивная команда Claude Code используется и для каких задач это подходит.

Что такое loop в Claude Code

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

Для российских разработчиков, которые часто запускают Claude Code на удалённом сервере по SSH, это особенно удобно: можно настроить цикл, который работает, пока вы спите, и присылает отчёт утром в Telegram или Slack. Главное — не забыть про лимиты токенов, потому что неограниченный цикл способен съесть месячный бюджет за одну ночь.

Claude Code предлагает четыре типа loops: turn-based, goal-based, time-based и proactive.

Каждый цикл характеризуется триггером, условием остановки и подходящей командой: ручной prompt, /goal, /loop//schedule или автоматическая рутина.

Качество результата зависит от проверочных навыков (SKILL.md) и чистоты кодовой базы, а не только от самого цикла.

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

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

Четыре типа циклов

Turn-based: ручной цикл

Самый простой и самый знакомый вид. Пользователь отправляет prompt, Claude собирает контекст, вносит правки, запускает тесты и возвращает результат. После этого человек проверяет работу и пишет следующий prompt. Каждый такой оборот — это один turn.

По мнению команды Claude Code, здесь ключевой рычаг — не более длинный prompt, а проверочный SKILL.md. Если вы обычно вручную открываете dev-сервер, кликаете по новой кнопке, проверяете консоль и запускаете Lighthouse, эти шаги стоит записать в skill. Чем более количественные проверки вы зададите, тем чаще Claude сможет сам понять, что задача выполнена.

Goal-based: цикл с целью через /goal

Когда задача сложная и одного оборота недостаточно, помогает команда /goal. Вы явно описываете критерий успеха и максимальное число попыток. Каждый раз, когда Claude хочет остановиться, оценочная модель проверяет условие: если цель не достигнута — агент возвращается к работе.

Чем более детерминирован критерий, тем лучше. «Сделай хорошо» — плохая цель. «Добейся Lighthouse Performance ≥ 90, не более 5 попыток» — хорошая. То же самое работает для числа пройденных тестов, покрытия кода или отсутствия ошибок линтера.

Time-based: цикл по расписанию /loop и /schedule

Некоторые задачи не требуют вашего присутствия: утренняя сводка по Slack, проверка PR на ревью, мониторинг CI. Для таких случаев есть /loop: команда повторяет prompt через заданный интервал, пока вы её не отмените или пока работа не закончится.

/loop работает на вашем компьютере, поэтому при выключении терминала цикл остановится. Если нужно, чтобы агент работал в облаке даже с закрытым ноутбуком, используется /schedule — эта команда создаёт рутину, которая запускается по расписанию на серверах Anthropic (research preview).

Proactive: проактивные рутины

Проактивные циклы объединяют всё вышеперечисленное: /schedule для запуска по событию или расписанию, /goal для критерия готовности, skills для проверки, dynamic workflows для параллельной обработки и auto mode, чтобы цикл не останавливался на каждом разрешении.

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

Как не потерять качество кода

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

• Чистая кодовая база. Claude копирует паттерны, которые уже есть в проекте. Если в репозитории хаос, агент будет его множить.
• Проверочные skills. SKILL.md должен содержать конкретные шаги, инструменты и критерии, по которым Claude сам оценивает результат.
• Актуальная документация. Фреймворки и библиотеки меняются, и агенту нужны свежие best practices.
• Второй агент для ревью. Проверяющий со свежим контекстом менее предвзят, чем основной агент. Можно использовать встроенный /code-review или Code Review for GitHub.

Важный совет: когда отдельный результат не дотягивает до стандарта, не исправляйте только конкретный случай — закодируйте правило в skill или CLAUDE.md, чтобы все будущие итерации работали лучше.

Как не сжечь бюджет на токенах

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

• Выбирайте подходящий примитив и модель: мелкие задачи не нуждаются в сложных оркестрациях.
• Формулируйте чёткие критерии завершения: конкретнее цель — меньше лишних итераций.
• Запускайте пилот на малой выборке перед массовым прогоном.
• Используйте скрипты для детерминированной работы: запуск готового скрипта дешевле, чем рассуждение модели.
• Не запускайте рутины чаще, чем меняется объект мониторинга.
• Регулярно смотрите /usage, /goal без аргументов и /workflows, чтобы видеть, куда уходят токены.

С чего начать

Авторы гайда предлагают не начинать с proactive-рутин, а посмотреть на свою повседневную работу и найти одно место, где вы сами являетесь узким звеном. Задайте три вопроса:

• Могу ли я описать проверку результата так, чтобы Claude мог сам её выполнить?
• Достаточно ли чётко я понимаю, что значит «готово»?
• Эта работа приходит по расписанию или в ответ на внешние события?

Если ответ на первый вопрос «да» — начните с turn-based цикла и проверочного skill. Если на второй — попробуйте /goal. Если на третий — /loop или /schedule. Запустите цикл, понаблюдайте, где он застревает или перегибает палку, и дорабатывайте harness, а не только prompt.

Сводка: какой цикл когда использовать

FAQ

Выводы

Гайд Anthropic — не просто описание четырёх команд. Это попытка дать разработчикам общий язык для обсуждения того, как ИИ-агенты переходят из разряда «помощников в чате» в разряд «автономных рабочих процессов». Turn-based, goal-based, time-based и proactive loops — это не конкуренты, а ступени одной эволюции: от ручного управления каждым шагом к проектированию систем, которые управляют сами собой.

Главная метафора, которую стоит уносить с собой: ваш вклад перестаёт измеряться качеством очередного prompt, а начинает измеряться качеством harness — системы проверок, остановок и триггеров. Если вы ещё не пробовали /goal или /loop, начните с одной повторяющейся задачи на этой неделе. Скорее всего, вы удивитесь, как много ручной работы можно отдать циклу.

I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.

Источники:

• Getting started with loops — официальный гайд Anthropic
• @ClaudeDevs on X
• Loop Engineering — Addy Osmani

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

Selectel: серверные платформы с полным циклом разработки

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

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

От эксплуатации к разработке

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

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

Собственная аппаратная архитектура

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

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

Платформа Selectel поддерживает процессоры Intel Xeon 6, память DDR5, интерфейс PCI Express Gen5, модуль доверенной платформы TPM 2.0, а также предусматривает установку современных сетевых адаптеров и ускорителей вычислений.

Для задач искусственного интеллекта и высокопроизводительных вычислений используются серверы форм-фактора 8U с несколькими GPU, тогда как платформы 1U и 2U применяются для виртуализации, корпоративной инфраструктуры, баз данных, облачных сервисов и других сценариев эксплуатации.

BIOS, BMC и управление платформой

Разработка аппаратной части ведется одновременно с развитием встроенного программного обеспечения.

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

Для управления оборудованием Selectel использует собственный интерфейс Selectel Management Interface (SMI), разработанный на базе OpenBMC.

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

Программный уровень платформы

Следующий уровень образуют операционная система, средства виртуализации и программные инструменты управления инфраструктурой. На этом уровне оборудование интегрируется в облачную платформу и становится частью сервисов, которыми пользуются клиенты. Это позволяет проектировать совместимость аппаратной и программной частей заранее, а не адаптировать программное обеспечение после выпуска нового оборудования.

От платформы к решению под конкретную задачу

После того как серверная платформа разработана и проверена, она становится основой для инженерной работы с конкретными проектами.

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

Для CPU-интенсивных задач приоритетом становятся вычислительные ресурсы процессора и организация многопоточной нагрузки. Для систем хранения — производительность дисковой подсистемы и сетевых интерфейсов. При работе с GPU оцениваются баланс между центральным и графическими процессорами, пропускная способность PCI Express, требования к питанию и охлаждению. При необходимости проектируются конфигурации под storage- и backup-системы.

На этапе проектирования также анализируются особенности будущей инфраструктуры: тип рабочей нагрузки (CPU-bound, memory-bound, IO-bound или GPU-bound), требования к доступности и SLA, особенности электропитания, тепловыделения, размещения оборудования в стойке и существующей сетевой инфраструктуры.

Проверка гипотез до закупки оборудования

Для проверки используется Proof of Concept (PoC) — инженеры воспроизводят профиль нагрузки клиента на тестовом стенде, сочетая синтетические и прикладные тесты. Это помогает заранее оценить производительность, задержки, температурные режимы и запас вычислительных ресурсов.

Во время таких испытаний анализируются параметры, которые невозможно оценить по спецификации оборудования: NUMA-топология, баланс между CPU и GPU, производительность подсистемы хранения, влияние вариантов конфигурации памяти, пропускная способность сетевых интерфейсов и шин PCI Express.

По итогам команда получает рекомендации по конфигурации с учетом характера нагрузки и ожидаемой производительности.

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

После формирования конфигурации сервер проходит комплексную проверку.

На производственном этапе контролируются комплектность оборудования, версии компонентов и прошивок. BIOS, BMC, сетевые адаптеры, RAID- и HBA-контроллеры приводятся к согласованным версиям, что обеспечивает воспроизводимость конфигурации. Затем проверяется работа памяти, накопителей, сетевых интерфейсов, аппаратных датчиков и других компонентов платформы.

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

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

Что отличает подход Selectel

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

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

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

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

Deckhouse: Kubernetes-платформа и экосистема для Cloud Native

Deckhouse — экосистема инструментов для разработки, доставки и эксплуатации Cloud Native-приложений. В основе — Deckhouse Kubernetes Platform (DKP), которая автоматизирует управление кластерами Kubernetes поверх любой инфраструктуры: публичные и частные облака, bare metal, закрытые контуры без доступа в интернет. Вокруг платформы выстроен набор продуктов — управление виртуализацией, хранение секретов, CI/CD, мониторинг — всё в одной экосистеме с общим API и интерфейсом.

Продукты разрабатываются и размещаются на территории РФ. Платформа поддерживает российские ОС: РЕД ОС, Astra Linux, ALT Linux. Deckhouse Kubernetes Platform CSE имеет сертификат ФСТЭК России №4860, платформа внесена в реестр российского ПО.

Что входит в экосистему

Deckhouse Kubernetes Platform (DKP) — ядро. Управляет кластерами Kubernetes, системным ПО на узлах, базовыми компонентами. После установки платформа готова к работе: автомасштабирование, мониторинг, мультитенантность — из коробки, без ручной сборки из отдельных компонентов.

Deckhouse Virtualization Platform (DVP) — управление виртуальными машинами и контейнерами из одного интерфейса. Масштабируется до 1000 серверов и 50 000 виртуальных машин. Поддерживает IaC-подход через открытый API, что позволяет автоматизировать развёртывание и управление средой полностью декларативно.

Deckhouse Stronghold — управление жизненным циклом секретов: пароли, ключи API, сертификаты, SSH-ключи, токены. Совместим с API HashiCorp Vault, что упрощает миграцию с него — без выгрузки секретов наружу через внешние утилиты. Поддерживает двойное шифрование через внешние HSM (AES + ГОСТ, AES + RSA), автоматическое резервное копирование и межкластерную репликацию.

Как устроен процесс работы

Установка и конфигурация

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

Развёртывание в закрытых контурах

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

DevSecOps-практики

Сквозное применение DevSecOps на всех этапах поставки: управление сетевыми политиками, аутентификация и авторизация, заказ TLS-сертификатов, аудит-логирование, изолированные контейнеры.

Для кого это полезно

• Техлиды и архитекторы получают платформу, которая закрывает инфраструктурный слой: не нужно собирать стек из отдельных компонентов — мониторинг, service mesh, хранение секретов, балансировка уже встроены.
• Разработчики получают сокращение времени подготовки среды разработки до 15 раз, единый UI и API для управления всей инфраструктурой, понятный CI/CD-конвейер. DVP позволяет использовать IaC для управления виртуальными машинами так же, как контейнерами — через манифесты.
• QA-инженеры и SRE работают с уже настроенным мониторингом из коробки, автоматическими алертами и механизмами восстановления.

Что отличает подход

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

Кластеры поддерживают любой тип инфраструктуры без изменения подхода к управлению: одни и те же практики работают в Yandex Cloud, в собственном ЦОД и на bare metal одновременно. В кейсе «Лемана ПРО» именно это позволило объединить кластеры из разных облачных провайдеров и дата-центров в единую инфраструктуру.

Высокая доступность из коробки: SLA 99,99% достигается за счёт отказоустойчивости компонентов платформы, геораспределённых конфигураций (Multicluster на базе Istio, MetroCluster) и fencing-механизмов для безопасного восстановления при сбоях узлов.

Техническая база

• Поддерживаемые ОС (host): Astra Linux SE, РЕД ОС, РОСА Сервер, ALT Linux, CentOS, Debian, Ubuntu
• Поддерживаемые ОС (guest в DVP): любые ОС на x86-64
• Интеграции: LDAP, OIDC, внешние HSM, аппаратные СХД (TATLIN, Huawei, HPE, NetApp), SCSI-протокол, LACP, VLAN
• API: открытый, совместим с HashiCorp Vault API (для Stronghold)
• Форматы дисков ВМ: VMDK, Qcow2, Raw
• Сертификация: ФСТЭК России №4860, реестр российского ПО

Управление и поддержка

Единый канал поддержки покрывает все продукты экосистемы. Для обучения работает Deckhouse Академия с курсами по платформе и инструментам безопасности. Обновления платформы приходят автоматически в выбранное окно обслуживания. Для знакомства с продуктами доступна 30-дневная пробная версия.

ELMA365 BPM: автоматизация бизнес-процессов на Low-code платформе

ELMA365 — Low-code BPM-платформа для оцифровки, автоматизации и оптимизации бизнес-процессов. В основе — процессный движок, который автоматически ставит задачи участникам, маршрутизирует процессы по заданной логике и собирает данные на каждом этапе. Моделирование ведётся в визуальном дизайнере по нотации BPMN 2.0 — без привлечения разработчиков. Сценарии и кастомная бизнес-логика пишутся на TypeScript с подсветкой синтаксиса и автодополнением прямо в интерфейсе.

Платформа разворачивается в облаке на серверах Яндекса — без установки дополнительных компонентов, всё работает через браузер. По данным TAdviser, ELMA BPM — самая внедряемая BPM-система в России и СНГ.

Продукт используют в корпоративной автоматизации: согласование документов, управление задачами и поручениями, электронный документооборот, CRM-процессы, КЭДО.

Как устроен процесс работы

Моделирование процессов

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

Формы и данные

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

Запуск и исполнение

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

Отладка и мониторинг

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

Быстрая оптимизация

Процессы редактируются без остановки уже запущенных экземпляров. Изменения вступают в силу сразу после публикации. Платформа поддерживает версионность процессов — можно откатиться к предыдущему состоянию, если что-то пошло не так. Это важно для компаний, у которых одновременно живут десятки «живых» процессов: по оценке ELMA, для компании в 500 человек таких процессов от 50 до 100, и каждый меняется со временем.

Для кого это полезно

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

Что отличает подход

Платформа сочетает Low-code-скорость с гибкостью полноценного кода. Большинство процессов настраивается без программирования, но там, где нужна кастомная логика, TypeScript-сценарии дают полный контроль. Это позволяет аналитикам закрывать задачи самостоятельно, не ставя каждое изменение в очередь к разработчикам.

Версионность и редактирование «на лету» — принципиальная особенность для enterprise: процессы живут годами и постоянно меняются. ELMA365 позволяет управлять этим циклом без остановки операционной работы и без риска сломать уже запущенные экземпляры.

Интеграционная шина покрывает основные корпоративные сценарии: ЭДО через операторов ЮЗДО и Контур.Диадок, CRM с встроенной телефонией и мессенджерами через ChatDesk, КЭДО с электронной подписью, которая полностью легитимна и позволяет убрать бумажные носители.

Техническая база

• Язык сценариев: TypeScript (встроенная IDE с автодополнением и отладчиком)
• Нотация процессов: BPMN 2.0
• API: стандартный REST API для запуска процессов и управления ими из внешних систем
• Интеграции: ЭДО (ЮЗДО, Контур.Диадок), мессенджеры (ChatDesk), телефония, внешние БД и веб-сервисы через вебхуки и скрипты
• Развёртывание: облако (серверы Яндекс), браузерный интерфейс без установки компонентов

Управление и поддержка

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

Т1 Сфера: платформа полного цикла производства ПО

«Сфера» (SFERA — Scaled Framework for Enterprise Resilience and Agility) — платформа для управления разработкой, тестированием, эксплуатацией и поставкой ПО. Более 40 инструментов в одном контуре: таск-трекер, Git-репозиторий, CI/CD-конвейер, хранение артефактов, управление тестированием, мониторинг, документация. Платформа разрабатывается с 2020 года на основе опыта внедрения ИТ-конвейеров в крупнейших российских компаниях, включая банковский сектор.

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

Как устроена платформа

Управление процессами и задачами

Сфера.Задачи — таск-трекер с настройкой под любую методологию: Agile, Scrum, SAFe, Kanban. Управляет бэклогом, декомпозицией задач, приоритизацией, назначением ответственных и дедлайнов. Закрывает те же сценарии, что Jira, Notion, Trello и Azure DevOps — в одном инструменте.

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

DevOps-инструментарий

Сфера.DevOps — сквозная автоматизация цикла от написания кода до деплоя. Включает:

• Git-инструмент для хранения, рецензирования и версионирования кода
• CI/CD-конвейер для непрерывной интеграции, тестирования и развёртывания
• Единое хранилище артефактов разработки
• DevOps-сервис самообслуживания для операций первого и второго дня — создание компонентов, сборка, проверка, раскатка

Тестирование

Комплекс инструментов для автоматизированного тестирования встроен в DevOps-конвейер. Поддерживает быстрый и автоматизированный процесс проверки на всех этапах жизненного цикла — от написания тест-кейсов до интеграционного и регрессионного тестирования в пайплайне.​

Мониторинг и эксплуатация

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

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

Для кого это полезно

Техлиды и архитекторы получают единую среду, в которой живут архитектурные схемы, API-документация, код и задачи — всё связано и не расползается по разным системам. Инструмент для проектирования архитектуры на разных уровнях входит в состав платформы отдельным модулем.​

Разработчики работают в знакомом Git-workflow с code review, CI/CD-конвейером и хранилищем артефактов — без необходимости настраивать интеграции между десятком разных инструментов. DevOps-сервис самообслуживания сокращает время на рутинные операции: создание компонентов, настройку сборок, деплой.​

QA-инженеры используют встроенный тест-менеджмент в связке с CI/CD — тест-кейсы, автоматизация, отчётность по покрытию в одном контуре.

Что отличает подход

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

Техническая база

• Методологии: Agile, Scrum, SAFe, Kanban​
• Инструменты: таск-трекер, Git, CI/CD, хранилище артефактов, тест-менеджмент, база знаний, документооборот, мониторинг, управление инцидентами​
• Интеграции: существующие системы контроля версий (GitLab и другие), внешние DevOps-инструменты​
• Развёртывание: корпоративный контур без выхода в интернет​
• Реестр: входит в реестр российского ПО​

Управление и поддержка

Платформа разработана совместно с VK, «1С», Лабораторией Касперского и Ростелекомом в рамках дорожной карты «Новое общесистемное ПО». Поддержка охватывает все модули платформы через единый канал. Новые команды могут опираться на встроенный методологический фреймворк для выстраивания процессов производства ПО с нуля.

Comindware Platform: Low-code BPM для автоматизации сложных процессов

Comindware Platform — Low-code BPM-платформа для моделирования, автоматизации и оптимизации бизнес-процессов предприятия. В одной среде работают корпоративная архитектура, процессный движок, кейс-менеджмент, управление данными и интеграции с внешними системами. Процессы описываются в визуальном дизайнере по нотации BPMN, исполняются движком точно в соответствии с моделью — без разночтений при переносе логики из схемы в код.

Среднее время реализации MVP на стороне клиента — 4 недели. Один из подтверждённых кейсов: бизнес-аналитик ABPMP в одиночку автоматизировал процесс обработки заявок за 30 часов, ускорив его в пять раз. Платформа применяется в промышленности, финансовом секторе, ритейле, телекоме, строительстве, медицине и государственных структурах. Среди кейсов нашла проекты для Газпром Авиа, НСПК, UCS, UserGate.

Как устроен процесс работы

Моделирование и автоматизация процессов

Процессы моделируются в BPMN-нотации, движок исполняет их в точности с моделью. Настройка большинства сценариев ведётся без написания кода, для сложной кастомной логики доступны C# и N3.

Управление данными и интерфейсами

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

Событийная оркестрация

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

Встроенные коннекторы покрывают стандартные корпоративные интеграции: Git, OpenLDAP/Active Directory, SMTP/IMAP, Exchange, OData (ERP), RabbitMQ/MSMQ, MSSQL/MySQL. Для событийных сценариев поддерживаются вебхуки — обмен данными с Telegram, Viber, JivoSite, телефонией (Novofon, Mango Office), почтовыми сервисами и любыми внешними системами через HTTP.

Для кого это полезно

• Архитекторы и аналитики управляют всей картой процессов компании в одной среде — от верхнеуровневой модели до исполняемых процессов. Изменения вносятся без остановки запущенных экземпляров, логика модели напрямую транслируется в поведение системы без ручной интерпретации.​
• Разработчики работают с самогенерирующимся REST API с Swagger-документацией, встроенными коннекторами к популярным сервисам и возможностью подключать кастомную логику на C#.
• PM получает прозрачность по статусу процессов в реальном времени и аналитику по отклонениям.
• QA и аналитики проверяют логику процессов на моделях до выхода в прод. Изменения можно откатить или протестировать на отдельном контуре.

Что отличает подход

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

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

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

Техническая база

• Нотация процессов: BPMN 2.0
• Языки кастомной логики: C#, N3
• API: самогенерирующийся REST API, документирование через Swagger/OpenAPI​
• Коннекторы: Git, Active Directory/OpenLDAP, Exchange, SMTP/IMAP, OData, RabbitMQ, MSMQ, MSSQL, MySQL​
• Интеграции через вебхуки: Telegram, Viber, JivoSite, Novofon, Mango Office, Unisender, Mailchimp, CRM-системы (Bitrix24, Megaplan, MS Dynamics)​
• Развёртывание: on-premise, частное и публичное облако, гибридная схема​

Управление и поддержка

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

***

Общая закономерность у всех рассмотренных решений одна: экспертиза видна в глубине проработки конкретного слоя. Selectel копает до уровня BIOS/BMC и изучает, как ведёт себя железо под нагрузкой — потому что сами на нём работают. Чек-лист, который стоит держать в голове при выборе инструментов и подрядчиков для сложных задач:

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

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

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

Данные: кандидаты не против AI — они против того, как его применяют

Начнём с масштаба. По данным SHRM Talent Trends 2025, доля AI в HR-процессах за год почти удвоилась — с 26% до 43% рабочих сценариев. Это говорит о том, что AI в найме больше не эксперимент, а новая норма.

Проблема в том, что кандидатский опыт за этой скоростью не поспевает. Свежий отчёт Greenhouse 2026 Candidate AI Interview Report (опрошено 2 950 активных соискателей в пяти странах) рисует довольно мрачную картину:

• 63% кандидатов проходили AI-интервью за последний год — рост на 13% всего за полгода;
• 38% уже снимались с процесса найма именно из-за AI-интервью, ещё 12% готовы уйти, если их обяжут его проходить;
• 51% из тех, кто всё-таки прошёл AI-интервью, не получили никакого результата — их либо проигнорировали, либо они всё ещё ждут ответа;
• 34% после AI-интервью стали хуже относиться к компании;
• 70% вообще не предупредили заранее, что их будет оценивать AI.

Отдельно стоит гостинг (ghosting) — внезапное молчание компании, когда кандидату просто перестают отвечать. По данным, которые приводит Fortune, в 2026 году с ним столкнулись 53% соискателей, это трёхлетний максимум (против 48% в 2025 и 38% в 2024). И связывают этот рост напрямую с AI: инструменты позволяют кандидатам рассылать отклики пачками, рекрутеров заваливает и они просто не отвечают тем, кому отказ пришёл автоматически. Классическая петля обратной связи: чем больше автооткликов, тем больше автоотказов.

Мы решили проверить это на своей аудитории

Чтобы не опираться только на публичные отчёты, мы провели два анонимных опроса в наших Telegram-каналах: один про главную боль в AI-найме (2 633 голоса), второй — про влияние на отношение к компании (2 273 голоса).

Результаты близки к мировыми. Раздражает хотя бы что-то в AI-найме 90,7% опрошенных — вариант «меня это не раздражает» выбрали лишь 9,3%. Две главные боли идут вровень: невозможно достучаться до живого человека (30,4%) и шаблонный отказ без объяснения причин (30,2%). То есть сильнее всего бьёт не сама технология, а дегуманизация — ощущение, что тебя обрабатывает конвейер, а не рассматривает человек.

И, что важнее, это конвертируется в ущерб бренду. Отношение к компании после плохого AI-опыта меняется у 82,4% (не меняется только у 17,6%). А 22,2% готовы активно отговаривать знакомых от взаимодействия с такой компанией. Почти каждый четвёртый кандидат превращается в канал антирекламы.

Ключевой вывод из всех цифр один, и его хорошо сформулировали в Greenhouse: только 19% кандидатов хотят меньше AI в найме. Люди не против автоматизации — они против того, как её внедряют: без предупреждения, без объяснений и без возможности достучаться до человека.

Как компания «переAIивается»

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

Эйфория. Поток откликов вырос в разы, рекрутеры тонут, «Хоризон» покупает систему автоскрининга. Первый год — восторг: время до шортлиста падает, стоимость найма снижается. Именно на этом успехе компании и «переAIиваются», он выглядит как повод автоматизировать всё подряд.

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

Автоотказы приводят к судебному иску. Чтобы разгрузить рекрутеров, «Хоризон» включает критерии автоматического отказа. Так поступила iTutorGroup: её софт автоматически отклонял женщин от 55 лет и мужчин от 60, отсеяв больше 200 квалифицированных кандидатов. Вскрылось случайно: кандидатка подала две одинаковые анкеты, отличавшиеся только датой рождения, и приглашение на собеседование получила только с более «молодой» версией резюме. Итог — 365 000 долларов по мировому соглашению с EEOC, первому в истории по AI-дискриминации в найме. И урок для каждого HR-отдела: даже когда дискриминацию автоматизирует технология, ответственность всё равно несёт работодатель.

Doom loop и системный риск. Опыт кандидата иногда схлопывается ещё до конвейера. Как в деле против Workday: истец подал больше сотни заявок через платформу и получил отказы по всем, причём часто в течение минут, иногда посреди ночи. Так он заподозрил, что решение принимала машина. В мае 2025 суд разрешил вести иск как коллективный, от лица потенциально сотен миллионов соискателей, а по собственным данным компании за спорный период через её инструменты было отклонено 1,1 млрд заявок. Workday обвинения отрицает и настаивает, что её инструменты не принимают решений о найме, но в июне 2026 суд в Калифорнии позволил части претензий двигаться дальше. Суть здесь в том, что ответственность может лечь и на вендора, а не только на конкретного работодателя.

Где «Хоризон» теряет не деньги, а бренд. Кандидаты, отсеянные «за секунды в два часа ночи», редко идут в суд — они пишут отзывы и предупреждают знакомых. Это ровно то, что показал наш опрос: 82,4% меняют отношение к компании, 22,2% отговаривают других. Юридический иск довольно редкое явление, а репутационные потери — ежедневное и почти неизбежное.

Найм в «Хоризон» сломал не сам AI, а три конкретные вещи: решения без человека, отказ без объяснения причины и полное исчезновение живого контакта. По сути, компания автоматизировала не рутину, а именно те точки, где кандидат ждёт человека.

Чек-лист: где AI работает, а где вредит

Если свести все прецеденты и данные вместе, станет понятно, что граница проходит не по технологии, а по тому, ждёт ли кандидат в этой точке человека. Там, где взаимодействие и так безличное, AI должен выступать ассистентом, оптимизировать процесс. Риск начинается там, где AI перестаёт помогать человеку и начинает принимать за него решения — именно эти сценарии привели к судебным искам из кейсов выше, и 22,2% готовых к антирекламе в нашем опросе.

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

AI помогает:

• Написание и оптимизация текстов вакансий;
• Первичный парсинг и сортировка резюме — как один из сигналов, а не как решение;
• Планирование, перенос интервью, напоминания;
• Ответы на типовые вопросы о вакансии и статусе заявки;
• Черновики писем, которые редактирует человек.

AI вредит:

• Автоматический отказ без проверки живым рекрутером;
• Отказ без внятной причины;
• AI-видеоинтервью «с роботом» как единственный этап;
• Полное отсутствие человека на всём пути;
• Анализ мимики и эмоций — запрещён EU AI Act с февраля 2025 года.

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

Фреймворк «Human-in-the-loop»: алгоритм советует, человек решает

Хорошая новость: кандидаты сами подсказывают, как надо. В том же отчёте Greenhouse они называют, чего им не хватает: раскрытия факта использования AI (44%), понятного объяснения, что именно AI оценивает (39%), возможности запросить человека вместо робота (46%), гарантии, что человек проверяет оценку AI до решения (38%), и доказательств, что систему проверяли на предвзятость (29%). Это, по сути, готовое ТЗ на здоровый процесс.

Всё это складывается в один принцип: алгоритм советует — человек решает. Ни одно значимое кадровое решение (найм, отказ, повышение) не отдаётся модели единолично; её оценка — лишь один сигнал среди многих.

На практике принцип держится на трёх опорах:

• Объяснимость: вы должны уметь сказать, почему кандидат А оказался выше кандидата Б, причём сказать это самому кандидату, а не только себе;
• Аудируемость: должна быть возможность проверить, что живой рекрутер видел и подтвердил рекомендацию AI, а не проштамповал её вслепую;
• Тест на предвзятость: систему нужно регулярно проверять на демографические перекосы и другие отклонения, иначе повторится история Amazon, где модель годами воспроизводила состав команды, пока это не всплыло.

Про прозрачность. Стоит ли открыто говорить кандидатам о том, какие этапы автоматизированы? Обычно это воспринимают как риск, хотя это наоборот хороший сигнал от работодателя кандидатам. Раз 70% кандидатов узнают об участии AI уже постфактум, то честное «вот здесь у нас работает машина, а здесь — человек» само по себе выделяет работодателя на общем фоне и повышает уровень доверия кандидатов.

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

Что в итоге

AI в найме — не зло и не мода, от которой можно отмахнуться: 43% HR-процессов уже так или иначе на нём. Но данные с обеих сторон — и отчёты, и наш опрос — сходятся в одном: кандидаты уходят не от самого AI, а от плохого опыта, который создаёт неправильно выстроенный AI-процесс. У кандидатов должно оставаться ощущение, что их рассматривают, а не просто обрабатывают на конвейере.

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

Хотите провести свой опрос или разместить материал? Пишите нам.

В этой статье разбираем, как работают usage tiers, мягкие и жёсткие лимиты расходов, алерты и rate limits. И главное — что нужно учесть в коде, чтобы приложение корректно обработало отказ API.

OpenAI API делит аккаунты на usage tiers: чем больше суммарно оплачено, тем выше месячный потолок расходов.

В настройках Limits можно задать собственный лимит трат, включить жёсткое ограничение и настроить email-алерты.

Жёсткий лимит отключает API при превышении бюджета: запросы начинают возвращать ошибку 429.

Rate limits ограничивают RPM, RPD, TPM и TPD по моделям; при превышении помогает экспоненциальный бэкофф.

В коде важно перехватывать 429, повторять запросы с задержкой и логировать расход токенов.

Как устроены usage tiers

Usage tiers — это автоматические уровни аккаунта, которые OpenAI выдаёт в зависимости от суммы уже оплаченных API-вызовов. Чем выше tier, тем больше месячный потолок трат и выше rate limits. Для новичка это двойная защита: даже если вы ничего не настраивали, система не даст потратить больше, чем разрешено текущему уровню.

Таблица tiers по состоянию на июль 2026

Данные взяты из документации OpenAI.

• Free — доступен из разрешённых регионов, лимит $100 / месяц.
• Tier 1 — нужно оплатить от $5, лимит $100 / месяц.
• Tier 2 — оплачено от $50, лимит $500 / месяц.
• Tier 3 — оплачено от $100, лимит $1 000 / месяц.
• Tier 4 — оплачено от $250, лимит $5 000 / месяц.
• Tier 5 — оплачено от $1 000, лимит $200 000 / месяц.

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

Лимит расходов: мягкий, жёсткий и алерты

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

• Spend limit — мягкий потолок. OpenAI показывает предупреждение, но фактические траты могут его немного превысить.
• Enforce hard limit — жёсткий потолок. При достижении лимита API начинает возвращать ошибку 429 и больше не списывает деньги.
• Spend alerts — email-уведомление при достижении заданного процента от бюджета.
• Auto recharge — автоматическое пополнение баланса с привязанной карты. При риске перерасхода его стоит отключить.

Рекомендация простая: для продакшена включайте Enforce hard limit и настраивайте алерты на 50% и 80%. Так у вас будет время разобраться, пока API ещё работает.

Rate limits: почему API отвечает 429

Rate limits — это не про деньги, а про нагрузку. OpenAI ограничивает количество запросов в минуту/день и токенов в минуту/день для каждой модели. Лимиты зависят от tier и модели: например, для gpt-4o и gpt-4o-mini они различаются.

• RPM — requests per minute, запросы в минуту.
• RPD — requests per day, запросы в день.
• TPM — tokens per minute, токены в минуту.
• TPD — tokens per day, токены в день.
• IPM — images per minute, изображения в минуту (для моделей генерации картинок).

При превышении любого из лимитов API возвращает 429 Too Many Requests. OpenAI рекомендует обрабатывать эту ошибку через экспоненциальный бэкофф: повторять запрос с увеличивающейся паузой.

Что делать в коде

1. Перехватывайте 429 и различайте причину: rate limit, hard spend limit или квота по токенам.
2. Используйте экспоненциальный бэкофф с джиттером, чтобы не «дудосить» API своими ретраями.
3. Логируйте количество токенов и стоимость каждого вызова — лучше всего через поля usage в ответе.
4. Для агентов добавьте circuit breaker: если бюджет исчерпан или ошибки 429 идут подряд, остановите цикл и уведомите команду.
5. Не храните API-ключ в клиентском коде: утечка ключа — самый быстрый способ получить чужой счёт.

Пошаговая настройка

Выводы

OpenAI API даёт в руки разработчика все нужные рычаги: usage tiers, spend limits, spend alerts, rate limits и жёсткое ограничение. Проблема не в отсутствии инструментов, а в том, что ими редко пользуются до первого «сюрприза» в биллинге.

Минимальный must have для любого проекта: включить Enforce Hard Limit, настроить алерты на 50% и 80%, отключить автопополнение, если бюджет критичен, и добавить в код обработку 429. Так вы защитите не только карту, но и репутацию команды.

Set up spend limits so rogue AIs don't exceed your budget. Rate limits are very easy to configure, making them a no-brainer for protecting your account.

Источники:
ZDNET — How I set OpenAI API usage limits to stop agent overspending
OpenAI Docs — Rate limits

В своей колонке Daily Drivers редактор Hackaday Дженни Лист скачала ISO-образ, запустила KolibriOS на современном ThinkPad и удивилась: система выглядит зрелой, стабильной и по-настоящему быстрой. Разбираем, что это за проект, откуда он взялся и кому пригодится сегодня.

Что такое KolibriOS

KolibriOS — российский форк MenuetOS, созданный в 2004 году. В то время как автор оригинального MenuetOS Вилле Турьянмаа переключился на закрытую 64-битную версию, сообщество вокруг русскоязычного порта сохранило код открытым и продолжило развивать 32-битную ветку. Название «Колибри» выбрано неслучайно: система маленькая и быстрая, как птица-колибри.

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

Версия 0.7.7

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

Дженни Лист отмечает, что на ThinkPad 2020-х годов KolibriOS загружается «в мгновение ока» и сразу показывает рабочий стол. Интерфейс выглядит пиксельным, как в 1990-х: нет сглаживания, есть ощущение ретро. Но при этом всё работает — без синих экранов и зависаний.

• KolibriOS 0.7.7 — 32-битная ОС с ядром на ассемблере, базовый образ весит около 1 МБ.
• Минимальные требования: i586, 8 МБ ОЗУ, 1 МБ на диске.
• В комплекте браузеры, игры, эмуляторы, графические редакторы и среда разработки.
• Главное ограничение для повседневного использования — отсутствие поддержки HTTPS.
• Лучше всего подходит для старого железа, тонких клиентов, обучения и ретрокомпьютинга.

Как устроена система

Ядро на ассемблере

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

Важная оговорка: несмотря на миф «всё на ассемблере», часть приложений и драйверов портирована или написана на C, Free Pascal, Oberon и даже Python. Но ядро, графическая подсистема и системные вызовы остаются ассемблерными.

Файловые системы и загрузка

KolibriOS умеет загружаться с CD/DVD, USB, жёстких дисков и даже с классической дискеты 1,44 МБ. Поддерживаются файловые системы FAT12/16/32, exFAT, NTFS и ext2/3/4. Есть варианты для Coreboot и загрузка прямо из Windows.

Что внутри: программы и игры

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

Из игр и развлечений — порты эмуляторов, DOSBox, а также shareware-версии классики вроде DOOM и Wolfenstein 3D на полноценном CD-образе. Есть поддержка SDL, что позволяет переносить проекты с «больших» систем.

Something this polished deserves a while to play around.

Главное ограничение: интернет без HTTPS

Дженни Лист называет именно этот момент решающим: встроенные браузеры KolibriOS, включая Netsurf и Webview, не поддерживают HTTPS. Без этого современный веб практически закрыт: большинство сайтов, включая сам Hackaday, просто не откроются.

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

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

Кому и где пригодится KolibriOS

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

• Воскрешение старого железа. Pentium- и ранние Core-машины получают рабочий стол, браузер для локальных страниц и офисные утилиты.
• Тонкие клиенты. Низкие требования к RAM и CPU делают KolibriOS кандидатом для терминалов с удалённым рабочим столом.
• Обучение. Ядро на ассемблере, простые системные вызовы и небольшой кодовой базы — отличная площадка для изучения устройства ОС.
• Ретрокомпьютинг. Запуск DOS-игр через эмулятор, классические 2D-игры и ностальгический интерфейс 1990-х.
• Встроенные системы. Сборка Kolibri-A ориентирована на специализированное железо и железные проекты.

Как попробовать KolibriOS

Попробовать систему проще всего в виртуальной машине. Скачайте ISO-образ с официального сайта, создайте VM с 64 МБ ОЗУ и загрузитесь с образа. Для реального железа подойдёт запись образа на USB-флешку или CD.

• Скачайте ISO или образ дискеты с официального сайта KolibriOS.
• Для VM: создайте 32-битную машину с 64 МБ RAM и VESA-видео.
• Для железа: запишите ISO на CD или USB через обычную утилиту.
• Загрузитесь и выберите разрешение экрана из меню загрузчика.
• Исследуйте меню «Пуск»: игры, утилиты, терминал и браузер.

Если планируете использовать сетевые функции, проверьте совместимость сетевой карты по списку оборудования. Поддерживаются многие чипы Realtek, Intel и 3Com.

Выводы

KolibriOS 0.7.7 — это не замена Windows или Linux, а демонстрация того, какой отклик может давать компьютер, когда софт пишут под железо, а не под абстракции. В эпоху, когда операционки растут гигабайтами, проект напоминает: минимализм ещё жив.

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

Главный вопрос — нужна ли вам такая система прямо сейчас. Если у вас есть старый 32-битный ноутбук, интерес к ассемблеру или просто ностальгия по быстрым ОС — попробуйте. А для повседневной работы с интернетом пока придётся держать под рукой что-то посовременнее.

Источники:

• Jenny’s Daily Drivers: KolibriOS 0.7.7 — Hackaday
• KolibriOS на DistroWatch
• Официальная вики KolibriOS

Android 17 вышел 16 июня. API 37, AppFunctions для ИИ-агентов, adaptive-first и Compose-first, строгие лимиты памяти и новые API приватности.

Google Play расширяет выбор платёжных систем и снижает комиссии: с 30 июня 2026 сервисный сбор отдельно от платёжного, первый $1M — 10%.

Безопасность: июньский бюллетень закрыл 124 уязвимости, включая zero-day CVE-2025-48595 в Framework. С 30 сентября 2026 начинается обязательная верификация разработчиков в четырёх странах.

Инструменты: Android CLI 1.0, 17+ Android skills, Android Bench с Gemma 4 и Gemini 3.5 Flash, Android XR SDK DP4 и Eclipsa Video для HDR.

Android 17: релиз 16 июня и API 37

16 июня 2026 года Google выпустил Android 17. Платформа переходит от «операционной системы» к «интеллектуальной системе»: центральную роль занимают AppFunctions — функции приложений, которые ИИ-агенты могут обнаруживать и вызывать через Jetpack-библиотеку. Разработчики аннотируют класс, добавляют KDoc, и Gemini получает доступ к локальному состоянию приложения.

Главное архитектурное изменение — adaptive-first: на больших экранах (sw > 600 dp) для приложений с targetSdk 37 игнорируются ограничения ориентации и размера. Вместе с этим появились App Bubbles, Bubble Bar и интерактивный Picture-in-Picture для десктопа. Google заявляет, что Compose теперь является первым классом UI: View-компоненты и View-based библиотеки переведены в режим обслуживания.

Производительность и приватность

Android 17 вводит лимиты памяти на основе объёма RAM устройства и убивает процессы, их нарушающие. Для диагностики добавили интеграцию LeakCanary в Android Studio Panda и on-device аномалию в ProfilingManager. ART получил generational GC, а MessageQueue для targetSdk 37 стал lock-free — это ускоряет старт и снижает пропуск кадров, но ломает рефлексию над приватными полями.

Из приватных нововведений — системный Contact Picker без разрешения READ_CONTACTS, системный Eyedropper для выбора цвета, временный доступ к локальной сети через ACCESS_LOCAL_NETWORK и post-quantum криптография с ML-DSA и гибридной подписью APK v3.2.

Инструменты и продуктивность: Android CLI 1.0, skills и Bench

9 июня в блоге Android Developers подвели итоги I/O по продуктивности. Главное — стабильный релиз Android CLI 1.0: теперь инструмент доступен через npm и Homebrew, умеет Journeys и команду studio для моста с Android Studio, а также интегрируется с Google Antigravity.

Каталог Android skills вырос до 17+ сценариев: адаптивный UI, CameraX, Perfetto SQL, Engage SDK, Wear OS, AppFunctions и другие. А Android Bench обзавёлся открытыми моделями, включая локальную Gemma 4, и свежими Gemini 3.5 Flash. В ближайшее время в бенчмарк добавят долгие многошаговые задачи.

Google Play: биллинг, комиссии и поиск

24 июня Google расширила выбор платёжных систем в Великобритании, ЕЭЗ и США. Разработчики могут предлагать альтернативный биллинг или внешние ссылки на свой сайт. С 30 июня 2026 сервисный сбор отделяется от платёжного: первый $1M в год — 10%, все автообновляемые подписки — 10%, остальное зависит от новой/существующей установки. Платёжная комиссия при использовании Google Play billing — 5% в этих регионах; при альтернативном биллинге она не берётся.

Также Google запустила программы Games Level Up и Apps Experience с пониженными ставками, а в Play Store появился AI-поиск Ask Play, Trusted Contributor-значки и более заметные скидки. Для разработчиков это означает, что ASO и монетизацию придётся пересматривать под новые механики отображения цен.

Безопасность: zero-day и верификация разработчиков

Июньский Android Security Bulletin закрыл 124 уязвимости. Самая неприятная — CVE-2025-48595 в Framework, уже эксплуатируемая в ограниченных целевых атаках. Она затрагивает Android 14–16 QPR2 и позволяет повысить привилегии без взаимодействия с пользователем. Критичный патч — уровень 2026-06-05, так как он включает исправления чипсетов Qualcomm и MediaTek.

18 июня Google обновила статус верификации разработчиков. С 30 сентября 2026 в Бразилии, Индонезии, Сингапуре и Таиланде станут обязательными регистрация приложений в семи магазинах. В июне на устройствах начали раскатывать системный сервис, который позже будет проверять регистрацию. В июле–августе появятся Android Developer ID Status API и Developer Console API для массовой регистрации через CI/CD.

Android XR: DP4, движки и Geospatial API

15 июня вышел Developer Preview 4 Android XR SDK. Для очков дополненной реальности добавили Jetpack Projected с Device Availability API, а Compose Glimmer оптимизирован под прозрачные дисплеи и тачпад. Для иммерсивных приложений — ранняя версия Geospatial API на базе ARCore и Visual Positioning System.

Кроме Unity для проводных XR-очков появилась официальная поддержка Unreal Engine и Godot, а также Android XR Engine Hub — десктопный инструмент для Windows с real-time тестированием прямо во вьюпорте движка. Программа Android XR Developer Catalyst Program открыта для заявок и даёт доступ к pre-release железу.

Premium-опыт: R8, Glance и Media3

В посте 2 июня о премиум-опыте Google акцентировала R8 Configuration Analyzer: он показывает, какие keep-rules мешают оптимизации. Monzo за счёт настройки R8 получили 30% прирост холодного старта и 35% снижение ANR.

Jetpack Glance теперь унифицирует виджеты для телефонов, часов и автомобилей на базе Compose, а RemoteCompose позволяет рендерить UI на внешних поверхностях. Media3 получил AI Effects, CodecDB, Scrubbing Mode в ExoPlayer и улучшенный CastPlayer. CameraX 1.5+ добавляет CameraXViewfinder Composable и динамические диапазоны.

Eclipsa Video: единый стандарт HDR

29 июня Google представила Eclipsa Video — стандарт HDR на базе SMPTE ST 2094-50, разработанный совместно с Apple и NBCUniversal. Он задаёт единый HDR reference white, адаптирует яркие участки под возможности дисплея и сохраняет творческий замысел кадр за кадром. Поддержка встроена в Android 17, ExoPlayer/Media3 обрабатывают метаданные автоматически.

FAQ

Выводы

Июнь 2026 показал, что Google делает ставку на три вещи: ИИ-агентов как часть рабочего процесса (AppFunctions, Android CLI, skills), адаптивность интерфейсов под любые форм-факторы и жёсткий контроль за безопасностью экосистемы. Разработчикам стоит в первую очередь протестировать приложения под Android 17, проверить R8-конфигурацию и подготовиться к новым правилам биллинга и верификации.

Самый быстрый способ не отстать — поставить Android CLI, добавить пару skills под свой проект и прогнать релиз на Android 17 эмуляторе, прежде чем OEM-партнёры начнут массово раскатывать обновление.

Источники: Android 17 is here, Top 3 updates for Android developer productivity, Expanded billing choice and lower fees on Google Play, Android developer verification, What's New in Android XR, Building Premium Android Experiences, Eclipsa Video.

Для российских разработчиков это особенно близкая история: Kotlin создавался в JetBrains, компании, основанной выпускниками Санкт-Петербургского политехнического университета. Язык, названный в честь острова в Балтийском море, стал одним из самых заметных российских технологических экспортов последнего десятилетия.

15 лет Kotlin. Первый анонс состоялся в июле 2011 года, стабильная 1.0 — в феврале 2016-го.

Kotlin 2.4.0. Стабильные context parameters, explicit backing fields, поддержка Java 26, Swift packages в Kotlin/Native и совместимость с Gradle 9.5.0.

Kotlin Toolchain 0.11. Amper эволюционировал в единый инструментарий: одна команда kotlin для создания, сборки, тестирования и публикации проектов.

Koog 1.0. JetBrains выпустила стабильный фреймворк для AI-агентов на Kotlin и Java с годовой гарантией совместимости ядра.

Compose Multiplatform 1.12.0-beta01 и Compose Hot Reload 1.2.0-beta01 развивают shared UI и экспериментальный MCP-сервер для AI-агентов.

Гранты Kotlin Foundation 2026. Приём заявок на финансирование open-source библиотек и инструментов открыт до 14 июля 2026 года.

Пятнадцать лет: от внутреннего проекта до мейнстрима

История Kotlin началась в 2010 году как попытка JetBrains решить собственные проблемы с Java. В 2011-м язык впервые показали публике, а в феврале 2016 года вышла стабильная версия 1.0. Переломным моментом стал Google I/O 2017: Kotlin получил статус первоклассного языка для Android, после чего интерес к нему резко вырос.

Сегодня Kotlin используется не только в мобильной разработке. На нём пишут backend на Spring и Ktor, делают кроссплатформенные приложения через Kotlin Multiplatform, экспериментируют с Kotlin/Wasm и даже строят AI-агентов. По данным ежегодных опросов JetBrains, доля Kotlin в коммерческих проектах стабильно растёт как в Европе, так и в России, несмотря на санкционные ограничения в части корпоративных лицензий.

If I were to choose one word to describe Kotlin's design, it would be pragmatism. For us it means caring about the usefulness.

Kotlin 2.4.0: что вошло в релиз

3 июня 2026 года JetBrains выпустила стабильный Kotlin 2.4.0. Это не инкрементальный патч, а полноценная мажорная версия с изменениями в языке, стандартной библиотеке, компиляторе и всех целевых платформах.

• Язык. Стабилизированы context parameters и explicit backing fields, добавлены новые target'ы для аннотаций.
• Стандартная библиотека. UUID API вышел из экспериментального статуса, появились функции для проверки отсортированности коллекций.
• Kotlin/JVM. Поддержка Java 26 и аннотации в метаданных включены по умолчанию.
• Kotlin/Native. Swift packages можно использовать как зависимости, обновлён Swift export, по умолчанию включён CMS GC.
• Kotlin/Wasm. Инкрементальная компиляция по умолчанию и поддержка WebAssembly Component Model.
• Kotlin/JS. Экспорт value-класс и возможности ES2015 при инлайнинге JS-кода.
• Gradle. Совместимость с Gradle 9.5.0.
• Maven. Автоматическое выравнивание версий Java и JVM target.
• Компилятор. Более предсказуемое поведение inline-функций при компиляции .klib.

Для практики это означает: если ваш проект живёт на JVM, можно обновляться ради Java 26 и улучшений stdlib; если вы работаете с iOS через Kotlin/Native — стоит посмотреть на Swift packages; для WebAssembly-экспериментов 2.4.0 делает сборку заметно быстрее.

Как обновиться

Обновление до 2.4.0 проходит через указание версии в Gradle или Maven. В Android Studio и IntelliJ IDEA новая версия уже включена в последние сборки.

Kotlin Toolchain 0.11: Amper уходит в прошлое

В июне 2026 года JetBrains окончательно переименовала Amper в Kotlin Toolchain и выпустила версию 0.11. Это не просто ребрендинг: инструмент позиционируется как единая точка входа для работы с Kotlin-проектами. Одной командой kotlin можно создать, собрать, протестировать и опубликовать проект.

В 0.11 появилась возможность публиковать JVM-библиотеки, улучшена разработка плагинов и упрощена начальная настройка. Для российских команд, часть которых уходит от корпоративных Gradle-лицензий к open-source инструментам, Kotlin Toolchain может стать интересной альтернативой для новых проектов и прототипов.

Важно: Kotlin Toolchain пока в статусе Alpha. Для существующих Gradle-проектов массово мигрировать смысла нет — инструмент ещё не покрывает все сценарии зрелых сборок. Но пробовать на небольших сервисах и pet-проектах уже можно.

Koog 1.0: AI-агенты на Kotlin

Фреймворк Koog от JetBrains вышел в версии 1.0. Он предоставляет примитивы для построения агентных приложений: инструменты, workflow, персистентность, память, observability и интеграции с JVM/KMP-проектами. Главное для Java-команд: Koog теперь предлагает идиоматичный Java API, то есть переходить на Kotlin ради агентов не обязательно.

Koog интегрируется со Spring AI, что делает его естественным выбором для backend-разработчиков, которые уже используют Spring Boot. Появилась мультиплатформенная observability и годовая гарантия совместимости ядра — это важно для команд, которые рассматривают агентов не как прототип, а как часть продакшена.

Compose и инструменты UI

Для UI-разработчиков в выпуске два значимых обновления. Compose Multiplatform 1.12.0-beta01 продолжает развивать shared UI: новые графические возможности, улучшения accessibility на iOS, обновления поведения UI-тестов и исправления для десктопа, веба и Gradle-плагина.

Отдельно стоит Compose Hot Reload 1.2.0-beta01. В нём развивается экспериментальный MCP-сервер: AI-агенты получают доступ к логам, ошибкам UI, могут перезапускать приложение и управлять его жизненным циклом. Это ещё не production-ready, но демонстрирует направление: разработка интерфейсов становится более визуальной и интерактивной.

Экосистема: библиотеки, гранты и корпоративный опыт

В обзоре JetBrains упомянуты три KMP-библиотеки, которые стоит изучить: ComposeMediaPlayer для кроссплатформенного видео, NSExceptionKt для улучшенной обработки крэшей на Apple-платформах и multiplatform-settings для хранения key-value данных в shared-коде.

Кроме того, Kotlin Foundation открыл грантовую программу 2026. Финансирование могут получить open-source проекты вокруг Kotlin Multiplatform, AI и больших языковых моделей. Заявки принимаются до 14 июля 2026 года. Для российских авторов библиотек это реальный способ поддержать проект, особенно если он пользуется спросом у зарубежного комьюнити.

Ещё один сигнал зрелости экосистемы — история Booking.com. Компания внедрила Kotlin Multiplatform для экспериментальной библиотеки и получила результаты выше ожиданий: улучшилась консистентность между Android и iOS, при этом команды не отказывались от платформенно-специфичной разработки.

Обучение: бесплатные курсы на Hyperskill

К юбилею JetBrains сделала часть Kotlin-курсов на Hyperskill бесплатными. Это проектно-ориентированная платформа: можно укрепить основы или пойти в сторону мобильной и backend-разработки. Для тех, кто только начинает или переходит с Java, это удобный способ получить практику, а не только теорию.

Выводы

15 лет Kotlin — это не только юбилей, но и точка, где язык перешёл из фазы «быстрого роста» в фазу «экосистемного инструмента». Kotlin 2.4.0 делает язык зрелее на всех платформах, Kotlin Toolchain упрощает вход в экосистему, а Koog и Compose Hot Reload показывают, что Kotlin активно используется в новой волне AI-разработки.

Для работающих проектов самый безопасный шаг — обновиться до Kotlin 2.4.0 в тестовом окружении и проверить совместимость. Новые инструменты вроде Toolchain и Koog стоит пробовать на pet-проектах, прежде чем тащить в продакшен. А если у вас есть open-source библиотека вокруг Kotlin — грантовая программа Kotlin Foundation может стать хорошим подспорьем.

Источник: Kodee's Kotlin Roundup: Kotlin Turns 15, Kotlin 2.4.0, and the Kotlin Toolchain — блог JetBrains.

SelectOS 2.0 работает на базе Debian 13 с ядром Linux 6.12.86.

Система ориентирована на корпоративный сегмент: управляемая цепочка поставок и отдельный канал security-обновлений.

Для команд на Debian/Uuntu это позволяет развивать инфраструктуру без миграции на другое семейство дистрибутивов.

SelectOS 2.0 протестирована с драйверами ведущих производителей GPU и готова к ИИ-нагрузкам.

Доступна в форматах ISO, QCOW2 и контейнерных образах; входит в реестр российского ПО.

Чем SelectOS 2.0 отличается от предыдущей версии

Главное преимущество обновлённой системы — сочетание актуальной технологической базы и удобной модели эксплуатации. SelectOS 2.0 использует привычные инструменты управления пакетами и обновлениями из мира Debian, поэтому администраторам не нужно переучиваться. Это снижает операционные риски, уменьшает затраты на обучение и упрощает внедрение в существующие ИТ-процессы.

Отдельное внимание уделено безопасности и прозрачности поставок. Собственные репозитории Selectel с GPG-подписью дают контроль происхождения каждого пакета, а серверный фокус дистрибутива — отсутствие лишних десктопных компонентов — сокращает поверхность атаки. Для специалистов по ИБ есть отдельный канал security-обновлений и прозрачность изменений.

Система также готова к ИИ-нагрузкам: заявлена совместимость с драйверами ведущих производителей GPU, что позволяет использовать SelectOS 2.0 как основу для инфраструктуры машинного обучения, нейросетевых моделей и генеративного ИИ.

Где взять и как развернуть

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

Реклама. Рекламодатель: АО «Селектел», ИНН 7810962785, erid: 2W5zFGNNGXb

Макхост — низкий порог входа и российские документы.

UFO.Hosting — широкая линейка VPS и выделенных серверов.

SmartApe — гибкие конфигурации и быстрый старт.

PSB Hosting — зарубежные локации и безлимитный трафик.

FirstVDS — бюджетный массовый вариант для простых проектов.

Hetzner Cloud — иностранная облачная альтернатива с ограничениями для РФ.

Как мы выбирали

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

1. Макхост — низкий порог входа

Макхост — российский хостинг-провайдер с собственными панелями управления и низким стартовым тарифом. Входит в реестр хостинг-провайдеров, работает с юрлицами и предлагает VPS в России и Европе.

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

• Сайты-визитки и лендинги на минимальной конфигурации с 1 CPU и 1 GB RAM.
• Интернет-магазины на популярных CMS и телеграм-боты: по данным провайдера, часто выбирают KVM-2 с 2 GB RAM.
• 1С:Предприятие и корпоративные сайты с модулем синхронизации: рекомендуют конфигурации от 4 GB RAM.
• VPN-серверы личного использования и небольшие тестовые окружения.

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

• Операционные системы: Ubuntu, Debian, AlmaLinux, CentOS Stream.
• Панели управления: ISPmanager, FastPanel; на тарифах VPS первый месяц ISPmanager 6 в подарок.
• Готовые образы и стеки: WordPress, 1С, Docker, LAMP, почта, DNS, SSL.
• SSH и root-доступ для произвольной настройки окружения.

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

• Виртуализация KVM с гарантированными ресурсами.
• Дата-центры: DataPro в Москве и площадка в Амстердаме.
• Диски: NVMe и DDR4 на всех VPS-тарифах, кроме самого дешёвого KVM-NEW с SSD.
• Сеть: порт до 1 Гбит/с, безлимитный трафик на всех тарифах, кроме KVM-NEW (2 ТБ).
• Соответствие 152-ФЗ, реестр хостинг-провайдеров; закрывающие документы для юрлиц.

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

На странице VPS у Макхоста указана средняя оценка 5 на основе 13 оценок. Пользователи отмечают круглосуточную поддержку и быструю помощь в сложных ситуациях; провайдер позиционирует себя как лидер авторитетных рейтингов.

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

• Каналы: тикет-система и онлайн-чат на сайте.
• Среднее время первого ответа: 10–20 минут.
• Для корпоративных клиентов и крупных проектов возможен персональный менеджер.
• База знаний, блог со статьями и платное администрирование VPS при необходимости.

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

• Стартовый KVM-NEW: 1 CPU, 0.6 GB RAM, 5 GB SSD, 2 ТБ трафика — 143 ₽/мес.
• Популярный KVM-2: 1 CPU, 2 GB RAM, 30–60 GB NVMe — от 693 ₽/мес при оплате за год.
• Топовый VPS KVM-12: 6 CPU, 12 GB RAM, 180–360 GB NVMe — от 3465 ₽/мес при оплате за год.
• Скидки за предоплату: 3%, 6%, 12%, 24% за 3, 6, 12, 24 месяца соответственно.
• Тестовый период: 3 дня с активационным платежом 290 ₽, который остаётся на балансе.
• Апгрейд без пересоздания сервера, обычно с кратковременной перезагрузкой.

Официальный сайт: Макхост

2. UFO.Hosting — широкая линейка

UFO.Hosting предлагает виртуальные и выделенные серверы в России с акцентом на широкую линейку конфигураций и NVMe-диски. Подходит тем, кто рассматривает и VPS, и bare-metal в одном кабинете.

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

• Небольшие проекты и сайты-визитки на тарифе Naos с 1 CPU и 1 GB RAM.
• Интернет-магазины, корпоративные сайты и телеграм-боты с вебхуками на Brachium с 2 CPU и 4 GB RAM.
• 1С:Предприятие и нагруженные CMS: рекомендуют от 4 CPU и 8 GB RAM.
• Проекты, которым нужны выделенные серверы без соседей.

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

• Операционные системы: различные дистрибутивы Linux и Windows (ISO-образы доступны на старших тарифах).
• Панели управления: ISPmanager, Vesta, Hestia, Cyberpanel, Virtualmin.
• Готовые шаблоны ПО в зависимости от выбранной ОС.
• Дополнительные IP-адреса, аренда подсетей, настройка BGP.

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

• Виртуализация KVM; процессоры Intel Xeon E5-2697A v4.
• Дата-центр IXcellerate в Москве, сертифицированный Tier III+.
• NVMe-диски в RAID10 на VPS/VDS; Enterprise SSD на выделенных серверах.
• Сеть: порт до 10 Гбит/с на ноде, 32 ТБ трафика в месяц на VPS (далее ограничение 100 Мбит/с); на выделенных серверах — без ограничений.
• Работа по 152-ФЗ, реестр хостинг-провайдеров; документы для юрлиц через ЭДО.

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

Публичные отзывы и агрегированные рейтинги в предоставленных материалах не указаны. Провайдер акцентирует внимание на Tier III+ инфраструктуре и запуске серверов до 15 минут.

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

• Каналы: онлайн-чат на сайте и тикет-система в биллинге 24/7; телефон в будни с 9:00 до 18:00.
• Среднее время первого ответа: не более 30 минут в любое время суток.
• База знаний в блоге ufo.hosting/blog.
• Продажи и поддержка готовы консультировать B2B-клиентов.

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

• Минимальный VPS Naos: 1 vCPU, 1 GB RAM, 25 GB NVMe — 605.85 ₽/мес.
• Популярный Brachium: 2 vCPU, 4 GB RAM, 60 GB NVMe — 1025.85 ₽/мес.
• Топовый VPS Intercrus: 32 vCPU, 64 GB RAM, 510 GB NVMe — 16 800 ₽/мес.
• Выделенный сервер Восток-1: 2x E5-2697v4, 384 GB RAM ECC, 4x960 GB Enterprise SSD — 43 050 ₽/мес.
• Скидки за предоплату: 5%, 10%, 15% за 3, 6, 12 месяцев.
• Тестовый период: 3 дня на VPS после полной верификации аккаунта; на выделенных серверах — обсуждается персонально.
• Апгрейд тарифа из личного кабинета без пересоздания сервера, вступает в силу после перезагрузки.

Официальный сайт: UFO.Hosting

3. SmartApe — гибкие конфигурации

SmartApe делает ставку на гибкость: кроме фиксированных линеек есть полностью конфигурируемые тарифы, где можно менять ресурсы под задачу. Провайдер использует процессоры Intel Xeon Platinum, AMD EPYC и AMD Ryzen.

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

• Лендинги и сайты-визитки на минимальных конфигурациях с 2 CPU и 1 GB RAM.
• WordPress, корпоративные сайты и интернет-магазины до 10 тыс. посетителей в сутки.
• Bitrix, CRM, ERP и 1С: рекомендуют от 4 CPU и 8 GB RAM.
• Нагруженные API, базы данных и высоконагруженные проекты на конфигурируемых тарифах.

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

• Linux- и Windows-серверы, панели управления ISPmanager, Hestia и другие.
• Готовые стеки под Docker, базы данных, веб-приложения.
• Автоматическое развёртывание сервера за 1–2 минуты; бесплатная помощь с переносом сайтов при использовании ISPmanager или Hestia.

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

• Виртуализация KVM с изоляцией и гарантированными ресурсами.
• Процессоры: Intel Xeon E5-2696 v4, Intel Xeon Platinum, AMD EPYC, AMD Ryzen 9.
• Диски: серверные NVMe SSD или HDD + SSD-кэш, RAID-10.
• Дата-центры: DataPro Moscow I, II, III в России; Host-Telecom в Чехии; Partner Group в Израиле; уровни Tier III и Tier IV.
• Сеть: безлимитный трафик на всех VPS, канал до 200 Мбит/с.
• SLA 99.9%, заявленный фактический uptime 99.982%.
• Соблюдение 152-ФЗ, договор на обработку персональных данных.

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

Публичные отзывы и рейтинги в предоставленных материалах не указаны. Провайдер акцентирует внимание на показателях NVMe-хранилища: до 680 тыс. IOPS на чтение и до 185 тыс. IOPS на запись.

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

• Каналы: тикеты в личном кабинете, онлайн-чат, телефон.
• Среднее время первого ответа: 10–15 минут.
• Раздел помощи на smartape.ru/help.
• Персональный менеджер обсуждается индивидуально для B2B.

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

• Минимальные тарифы: HDD S1 (2 CPU, 1 GB RAM, 50 GB HDD+SSD) — 345 ₽/мес; NVMe X1 (2 CPU, 1 GB RAM, 10 GB NVMe) — 495 ₽/мес; Turbo R1 AMD Ryzen (2 CPU, 1 GB RAM, 20 GB NVMe) — 645 ₽/мес.
• Топовый VPS NVMe X64: 24 CPU, 64 GB RAM, 640 GB NVMe — 11 870 ₽/мес.
• Скидки за предоплату: 5%, 15%, 30%, 50% за 3, 6, 12, 24 месяца.
• Тестовый период: 10 дней без привязки банковской карты, нужно подтверждение номера телефона.
• Резервное копирование со стороны провайдера не предусмотрено; можно настроить самостоятельно или заказать FTP-хранилище.
• Апгрейд фиксированных тарифов — по запросу в поддержку с перезагрузкой; конфигурируемые тарифы меняются в личном кабинете.

Официальный сайт: SmartApe

4. PSB Hosting — зарубежные локации

PSB Hosting ориентирован на международные дата-центры и широкий выбор операционных систем. Подходит проектам, которым важны европейские и американские площадки, безлимитный трафик и подсеть IPv6 /64 на всех тарифах.

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

• Сайты и веб-приложения, ориентированные на аудиторию в Европе и США.
• VPN-серверы, прокси и сетевые сервисы благодаря безлимитному трафику и IPv6 /64.
• Проекты на Node.js, Django, Docker, WordPress и других стеках.
• Разработчики, которым нужна нестандартная ОС или загрузка собственного ISO.

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

• Операционные системы: Ubuntu, Debian, CentOS, Windows, Astra Linux, AlmaLinux, Rocky Linux, FreeBSD, Oracle Linux; можно загрузить свою ОС через ISO.
• Предустановленное ПО: Docker, LAMP, Keitaro, FastPanel, Node.js, Portainer, WordPress, Django, Outline, OpenVPN, Wireguard, HestiaCP, VestaCP, Bitrix.
• Полноценная панель управления DNS-записями доменов.

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

• Виртуализация KVM, NVMe-диски.
• Дата-центры: euNetworks в Амстердаме, Frankfurt 1 Data Center в Германии, Digita в Хельсинки, Long Island Interconnect в Нью-Йорке.
• Сеть: порт до 10 Гбит/с, безлимитный трафик, подсеть /64 IPv6 на всех тарифах.
• SLA 99.7%; мониторинг состояния сервера встроен в панель.
• Договор на обработку персональных данных; оплата картами РФ, СНГ, ЕС и криптовалютой.

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

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

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

• Каналы: тикеты и Telegram 24/7.
• Время ответа зависит от загрузки; поддержка работает круглосуточно.
• Документация и API на сайте.
• Персональный менеджер доступен для B2B-клиентов.

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

• Популярная конфигурация: 4 vCPU, 8 GB RAM, 100 GB SSD — $25/мес.
• Скидки за предоплату: 5%, 10%, 15% за 3, 6, 12 месяцев.
• Бесплатного тестового периода нет.
• Резервные копии платные, создаются ежедневно; количество не ограничено.
• Апгрейд без потери данных с перезагрузкой сервера.
• Сервер выделяется за 5–10 минут после установки ОС.

Официальный сайт: PSB Hosting

5. FirstVDS — бюджетный VPS/VDS для простого старта

FirstVDS — российский VPS/VDS-провайдер с готовыми тарифами и быстрым запуском сервера. Он подходит для простых веб-проектов, тестовых окружений и задач, где важны понятная стартовая цена, российские площадки и базовые дополнительные услуги.

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

• Небольшие сайты, pet-проекты, тестовые стенды и простые backend-сервисы.
• Проекты, где важнее низкая цена входа и быстрый запуск, чем детальный подбор ресурсов под нагрузку.
• Сценарии, где можно начать с готового тарифа и позже мигрировать на более производительную линейку.

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

• Linux/VDS для сайтов, блогов, небольших баз данных и веб-приложений.
• Windows-серверы: на сайте есть отдельная линейка VDS для Windows Server 2019 и 2022.
• Дополнительные услуги: S3, автоматическое резервное копирование, администрирование, DDoS-защита, мониторинг сайтов.

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

На официальной странице FirstVDS указаны серверы в России, Нидерландах и Казахстане, запуск готового сервера за 2 минуты, отдельные линейки VDS Форсаж, CPU.Турбо, VDS Atlant, Storage и GPU. Это вариант для тех, кто хочет выбрать готовую линейку, а не собирать конфигурацию вручную.

Тарифы и ограничения

• Стартовая цена на сайте: VPS/VDS от 249 ₽/мес.
• Плюс: круглосуточный бесплатный телефон 8 800 775-38-37 и большое количество отзывов на сайте.
• Особенность: параметры под конкретный сценарий лучше дополнительно проверять в конфигураторе и на тестовой конфигурации.

Официальный сайт: FirstVDS

6. Hetzner Cloud — зарубежное облако для международных проектов

Hetzner Cloud — европейский облачный провайдер с API и дата-центрами в Германии, Финляндии, США и Сингапуре. Он подходит для международных проектов, тестовых окружений и команд, которым важны автоматизация, сети, firewalls и понятная облачная модель. Для российских юридических и регуляторных требований условия нужно проверять отдельно.

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

• Тестовые окружения, личные проекты, международные веб-сервисы и инфраструктура для разработчиков.
• Команды, которым нужны API, CLI, Terraform/Ansible-интеграции, private networks и firewalls.
• Проекты с аудиторией в Европе, США или Азии, где российская юрисдикция и документы не критичны.

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

• Linux-дистрибутивы: Ubuntu, Debian, Fedora и другие образы.
• One-click apps: Docker, WordPress, Nextcloud, GitLab, Grafana, Jitsi Meet, WireGuard и другие.
• Облачная инфраструктура с networks, firewalls, load balancers, API, CLI и интеграциями для CI/CD.

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

Hetzner описывает shared cloud как вариант для разработки, тестов, личных сайтов, небольших баз данных и веб-серверов со средней нагрузкой. Dedicated cloud рассчитан на бизнес-приложения и устойчивую высокую нагрузку. На сайте также указаны GDPR, ISO/IEC 27001 для дата-центров в Германии и Финляндии, 99,9% uptime и поддержка 24/7 по email.

Тарифы и ограничения

• Цены и конфигурации зависят от выбранной страны, валюты и типа cloud-сервера; в статье лучше считать их отдельно в калькуляторе Hetzner.
• Плюс: зрелая европейская облачная экосистема и сильная автоматизация.
• Особенность: иностранная юрисдикция и документы отличаются от российских провайдеров, поэтому для проектов с персональными данными и 152-ФЗ условия нужно проверять отдельно.

Официальный сайт: Hetzner Cloud

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

Минимальный вход: у Макхоста самый дешёвый стартовый тариф — 143 ₽/мес, но с ограниченным трафиком и SSD. SmartApe предлагает старт от 345 ₽/мес с двумя ядрами и HDD+SSD-кэшем; FirstVDS начинается от 249 ₽/мес и подходит как бюджетная точка входа. UFO.Hosting, PSB Hosting и Hetzner Cloud стоит считать по конфигурации и требованиям к географии.

Популярные конфигурации: Макхост и UFO.Hosting выделяют тарифы с 2 GB RAM для магазинов и CMS; у SmartApe стартовый NVMe-тариф даёт 2 CPU и 1 GB RAM; у PSB Hosting популярный тариф — 4 CPU и 8 GB RAM за $25/мес. FirstVDS удобен для простых стартовых задач, а Hetzner Cloud — для международных проектов и команд, которым нужны API, сети и автоматизация.

Диски и трафик: у каждого провайдера разные акценты по дискам, портам, бэкапам и ограничениям. FirstVDS даёт массовую VPS/VDS-линейку и дополнительные сервисы вроде S3, бэкапов и мониторинга. Hetzner Cloud силён по API, сетям, firewalls и included traffic; его условия нужно пересчитывать отдельно под регион и валюту.

Тестовый период: SmartApe даёт 10 дней без карты, Макхост и UFO.Hosting — 3 дня с условиями, PSB Hosting — не предусмотрен. Для FirstVDS и Hetzner Cloud тестовый период и условия пробного запуска лучше проверять на момент заказа.

География и документы: Макхост, UFO.Hosting и SmartApe подтверждают работу по 152-ФЗ и наличие российских площадок; PSB Hosting работает только из зарубежных дата-центров и предлагает оплату криптовалютой. FirstVDS имеет российские и зарубежные площадки. Hetzner Cloud работает в иностранной юрисдикции, поэтому для проектов с персональными данными россиян нужно заранее проверить документы, обработку данных и требования 152-ФЗ.

Выводы

Выбор VPS начинается с честной оценки нагрузки: 1 CPU и 1 GB RAM хватит для статического лендинга или простого бота, но для CMS с плагинами, интернет-магазина или 1С стоит закладывать минимум 2 CPU и 4 GB RAM, а лучше — тестировать реальную нагрузку на выбранной панели.

Если важен минимальный бюджет и российские документы — смотрите на Макхост. Если нужна широкая линейка от VPS до выделенных серверов в одном кабинете — на UFO.Hosting. Для гибкого подбора ресурсов под растущую нагрузку подойдёт SmartApe. Если проект ориентирован на зарубежную аудиторию и нужен безлимитный трафик — PSB Hosting.

FirstVDS подойдёт для недорогих и простых запусков с российскими и зарубежными площадками. Hetzner Cloud — для международной инфраструктуры, где важны API, сети и дата-центры за пределами России; юридические и регуляторные требования нужно проверять отдельно.

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

Что такое NixOS

NixOS — это дистрибутив Linux, в котором всё системное окружение описывается декларативно на языке Nix и воспроизводится из одного конфигурационного файла. Каждая сборка помещает зависимости в /nix/store, что даёт атомарные откаты и воспроизводимость, но при этом легко разрастается размер.

Одна из удобных фич — команда nixos-rebuild build-vm: она превращает конфигурацию в виртуальную машину. Но иногда нужен не «тонкий» образ, привязанный к хосту, а самодостаточный ISO, который можно записать на флешку или загрузить в облаке.

• Базовый NixOS ISO занимает 458 МБ: 416 МБ — squashfs с пользовательским окружением, 26 МБ — initrd, 13 МБ — ядро.
• Главные «тяжеловесы» внутри образа: модули ядра (144 МБ), Python 3 (128 МБ), systemd (60 МБ), Perl (56 МБ), GRUB (около 62 МБ).
• Отключение Nix, документации, SSH, firewall и лишних зависимостей сокращает ISO до 197 МБ.
• Замена Perl-активации на экспериментальные system.etc.overlay и services.userborn даёт финальный размер около 183 МБ.
• Это игрушечный эксперимент: для десктопа и сервера такие отсечения небезопасны, но полезны как источник идей.

От VM к ISO за несколько строк

Минимальная виртуальная машина на NixOS собирается из файла примерно такого вида:

Запуск: $(nix-build basic-vm.nix --attr vm --no-out-link)/bin/run-nixos-vm. При этом /nix/store монтируется с хоста, поэтому VM «тонкая». Для независимого ISO импортируем модуль iso-image.nix и собираем атрибут isoImage:

ISO собирается, загружается в QEMU, но размер сразу бросается в глаза.

458 МБ — из чего они сложились

Автор примонтировал полученный ISO и посмотрел распределение места. Вот ключевые цифры:

• 416 МБ — сжатый nix-store.squashfs с пользовательским окружением.
• 26 МБ — начальная загрузочная среда initrd.
• 13 МБ — ядро Linux.
• 3 МБ — загрузчик isolinux.

При распаковке squashfs картина ещё интереснее:

• 144 МБ — модули ядра (linux-6.18.35-modules).
• 128 МБ — Python 3.13.
• 60 МБ — systemd.
• 56 МБ — Perl.
• ~62 МБ суммарно — две копии GRUB (UEFI + BIOS).

Поскольку ISO собирается локально, все пакеты из него есть и в хостовом /nix/store. Это позволяет использовать nix why-depends, чтобы найти, кто тащит каждую зависимость.

Отключаем Nix, документацию и лишние сервисы

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

Результат: 384 МБ. Экономия скромная, потому что часть зависимостей Nix всё ещё тянется через сервис register-nix-paths. Он регистрирует содержимое хранилища ISO при загрузке — но Nix-то мы уже убрали. Отключаем и его:

Теперь ISO уменьшился до 360 МБ, а зависимость от Boost исчезла полностью.

SSH: модуль без выключателя

Следующий кандидат на удаление — OpenSSH-клиент. Проблема в том, что модуль programs/ssh.nix добавляет его в environment.corePackages, а отдельного переключателя programs.ssh.enable нет.

Попытка полностью исключить модуль через disabledModules ломает другие модули, например Plasma 6, которые ожидают существования опций programs.ssh. Выход — подменить опцию «пустышкой», не затрагивающей реальную конфигурацию:

Параллельно автор убрал firewall, documentation.man.enable и принудительно очистил environment.defaultPackages.

GRUB: зачем две копии загрузчика

ISO-пресет NixOS включает сразу и UEFI-, и BIOS-версии GRUB — отсюда около 62 МБ. Чёткого флага для отключения одной из них нет, поэтому автор пошёл грубым путём: сбросил system.extraDependencies и environment.systemPackages, оставив только environment.corePackages, чтобы shell хотя бы стартовал.

Ядерные модули: четверть образа

Модули ядра весили 144 МБ — больше, чем весь Alpine ISO. NixOS не предоставляет удобного способа ограничить их набор для runtime, поэтому автор просто удалил папку модулей из системы после сборки:

Это полностью отключает динамическую загрузку модулей. Если что-то нужно — оно должно оказаться в boot.initrd.kernelModules или availableKernelModules. После этого образ уменьшился до 197 МБ.

Perl: заменяем активацию системы

Perl в образе нужен только для скриптов активации: настройки /etc и создания пользователей. В nixpkgs уже есть экспериментальные замены — system.etc.overlay и нативный менеджер пользователей userborn.

Оба механизма помечены как экспериментальные, но в контексте «самодельного минимального ISO» это уже не самая безумная идея. Финальный размер: 183 МБ.

Что получилось и стоит ли повторять

За несколько итераций образ сократился с 458 МБ до 183 МБ — почти в 2,5 раза. При этом система всё ещё загружается, автор смог залогиниться под root, правда разрешение экрана перестало переключаться.

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

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

Выводы

Эксперимент показывает, что NixOS позволяет не только собирать сложные системы, но и жёстко урезать их — иногда в ущерб удобству. Главный инструмент здесь не волшебная опция, а последовательный анализ: смотреть, что занимает место, находить виновника через nix why-depends и решать, готовы ли вы от него отказаться.

«At some point I just kept going because I got curious.»

Если захотите повторить — начните с отключения Nix и документации, а дальше решайте, какие модули и пакеты действительно нужны в вашем live-образе. Исходный материал — в блоге автора: I can haz smoller NixOS ISOs?.

Что делает time.sleep()

Функция time.sleep(seconds) приостанавливает выполнение текущего потока на указанное время. Аргумент — число секунд, включая дробные значения. Например, 0.001 — это одна миллисекунда, а 1.5 — полторы секунды.

Важный нюанс: time.sleep() гарантирует лишь минимальную задержку. Реальная пауза почти всегда чуть дольше из-за планировщика операционной системы и текущей нагрузки. Для большинства задач это не критично, но для высокоточного тайминга лучше искать другие инструменты.

Типичные сценарии использования

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

• Распределение запросов к API с ограничением rate limit.
• Повторные попытки выполнения ненадёжных операций.
• Пауза между итерациями мониторинга или парсинга.

Мониторинг сайта с интервалом в 60 секунд

Простой аптайм-бот опрашивает страницу и засыпает на минуту. Без задержки скрипт уйдёт в бесконечный цикл и может получить бан по IP.

Совет:
Для реального мониторинга добавьте логирование или уведомления, иначе ошибки останутся только в консоли.

Декоратор для повторных попыток

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

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

Паузы в потоках: Event.wait()

В потоках можно использовать time.sleep(), но он непрерываен: поток не сможет быстро завершиться, пока спит. Для корректной остановки лучше применять threading.Event().wait(). Этот метод прерывается, как только событие установлено через event.set().

Такой подход позволяет аккуратно завершить все потоки по Ctrl+C: event.set() мгновенно будит все ожидающие wait().

Неблокирующие паузы в asyncio

Асинхронный код в Python появился в версии 3.4 модуля asyncio и получил синтаксис async/await в 3.5. Внутри корутин нельзя использовать обычный time.sleep(): он заморозит весь event loop. Для паузы в асинхронном коде есть asyncio.sleep().

Ключевое отличие: asyncio.sleep() приостанавливает только текущую корутину, уступая управление event loop. Остальные задачи продолжают выполняться. Это особенно важно при соблюдении rate limit при параллельных запросах.

Как не заморозить GUI

В GUI-фреймворках весь интерфейс работает в главном потоке с собственным циклом событий. Если вызвать time.sleep() в обработчике кнопки, окно повиснет: не будет отрисовки, не сработают клики, а в Windows может появиться предупреждение о неответствии.

Метод .after() в Tkinter планирует callback через заданное число миллисекунд и сразу возвращает управление циклу событий. Аналог в wxPython — wx.CallLater(). Паттерн универсален: не блокируйте поток, планируйте отложенный вызов.

• time.sleep() — универсальный способ поставить синхронную паузу, но он блокирует поток целиком.
• Для повторных попыток удобен декоратор с задержкой, который ловит исключения и делает retry.
• В потоках предпочитайте Event.wait(): его можно прервать через event.set().
• В асинхронном коде используйте asyncio.sleep(), иначе заморозите весь event loop.
• В GUI применяйте фреймворковые методы вроде Tkinter.after(), чтобы интерфейс оставался отзывчивым.

Выводы

Пауза в коде — это не просто «подождать секунду». В синхронном скрипте достаточно time.sleep(), в потоке важно уметь выходить по сигналу, в асинхронном коде нельзя блокировать event loop, а в GUI нужно работать в рамках фреймворкового цикла событий. Правильный инструмент зависит от контекста, и выбор влияет на отзывчивость и стабильность приложения.

Не блокируйте поток без причины. Если можно уступить управление — уступите.

Источник и дополнительные материалы: Real Python — Python sleep(): How to Add Time Delays to Your Code.

• Apache Airflow — мощный оркестратор для сложных Python-конвейеров, но требует инфраструктуры и DevOps-культуры.
• n8n — визуальный конструктор с открытым исходным кодом: удобен для средних нагрузок, можно бесплатно хостить на своём сервере.
• Make (бывший Integromat) — облачный визуальный автоматизатор для бизнес-команд, дешевле Zapier, но тарифицирует каждый шаг сценария.
• Для российских команд критичны: возможность self-hosting, стоимость инфраструктуры и риски доступности зарубежного SaaS.
• Нет универсального победителя — выбор зависит от размера команды, сложности логики и требований к контролю над данными.

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

Apache Airflow: тяжёлый артиллерист

Airflow появился в Airbnb и за десять лет стал стандартом для data-пайплайнов. Его используют Netflix, Spotify и Uber — там, где нужно управлять сотнями зависимых задач с контролем SLA и аудитом. Главная идея: вы описываете workflow как Python-код в виде направленного ациклического графа (DAG), а scheduler отвечает за порядок, ретраи и мониторинг.

Зачем выбирать Airflow

• Сложная логика: ветвления, условия, ретраи, расписания через cron.
• Полный контроль над кодом: любые библиотеки Python, кастомные операторы, unit-тесты.
• Зрелая экосистема: SLA-мониторинг, audit trail, интеграция с Kubernetes и Spark.
• Open Source: можно развернуть на своей инфраструктуре, в том числе на российских облаках.

Честный взгляд на минусы

• Высокий порог входа: нужно разворачивать БД, Redis, воркеры и веб-интерфейс.
• Минимальный кластер на VPS обходится примерно в €50/месяц без учёта времени администратора.
• При 50+ задачах DAG превращается в большой Python-файл, который сложно поддерживать без дисциплины.
• Коммуникация между задачами через XCom требует внимания: забыли очистить — получили memory leak.

Пример простого DAG, который забирает пользователя, его посты и считает количество:

Airflow хорош, когда у вас уже есть data-команда, Kubernetes и понимание, зачем нужны DAG. Для стартапа из трёх человек это, скорее, оверинжиниринг.

n8n: визуальный middle ground

n8n занимает промежуточную нишу между кодом и no-code. Это node-based редактор: вы перетаскиваете блоки, соединяете их стрелками, а логика — в JavaScript-функциях и условиях. Главное преимущество: n8n open-source, его можно поднять на собственном сервере, и за это не придётся платить пошагово.

Зачем выбирать n8n

• Быстрый старт: визуальный конструктор позволяет собрать пайплайн за час, а не день.
• Self-hosting: контейнер на VPS за $5–10/мес может обрабатывать тысячи запусков в день.
• Гибридный подход: 90 % задач решается мышкой, сложную трансформацию можно написать на JS.
• Прозрачная цена облака: плата за выполнение workflow, а не за каждый модуль.

Ограничения

• При сотнях задач в одном workflow визуальная схема становится громоздкой.
• Нативные узлы покрывают не всё: экзотический API придётся звать через HTTP Request.
• Self-hosted версия требует обновлений и бэкапов — это всё ещё инфраструктура, хоть и простая.
• Для России: облако n8n — европейский сервис, но self-hosted можно развернуть на Selectel, Yandex Cloud или любом другом провайдере.

Пример JSON-экспорта workflow, который забирает пользователей, преобразует данные и пишет в PostgreSQL:

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

Make: бизнес-автоматизация по шагам

Make (ранее Integromat) — это облачный визуальный автоматизатор для бизнес-команд. Его сценарии собираются из модулей: триггер → действие → фильтр → маршрутизатор. По сравнению с Zapier у Make глубже логика, а цена ниже, но он остаётся полностью SaaS-решением.

Зачем выбирать Make

• Быстрая интеграция с популярными сервисами: Google Sheets, Slack, Telegram, CRM, email-рассылки.
• Визуальные маршрутизаторы (routers), итераторы и агрегаторы позволяют строить ветвления без кода.
• Низкий порог входа для маркетологов, менеджеров продукта и операционистов.
• План Core стоит от $9/мес за 10 000 операций — дешевле многих конкурентов.

Подводные камни

• Тарификация по операциям: каждый модуль в сценарии считается отдельно. Десять шагов × тысяча запусков = 10 000 операций.
• Нельзя self-host: данные обрабатываются на серверах Make, что может быть проблемой для чувствительных данных.
• Для России: сервис работает как зарубежный SaaS, есть риски доступности и оплаты.
• Сложные сценарии сложнее отлаживать: приходится кликать по модулям в истории выполнений.

Типичный сценарий в Make выглядит так: вебхук из формы → проверка дубликата в Google Sheets → запись в CRM → отправка уведомления в Telegram. Всё это строится мышкой, но стоит добавить кастомную логику — и придётся использовать HTTP-модуль или встроенные функции.

Сравнение в цифрах

Сводная таблица по ключевым параметрам. Вместо абстрактных «плюсов» смотрите на конкретные ограничения:

• Airflow — код Python, self-hosted, сложность высокая, стоимость от €50/мес + администрирование, лучше для data-платформ.
• n8n — визуальный + JS, self-hosted или cloud, средняя сложность, self-hosted от $5–10/мес, лучше для средних нагрузок и гибридных команд.
• Make — визуальный no-code, только cloud, низкая сложность входа, от $9/мес за 10K операций, лучше для бизнес-автоматизации.
• Модель оплаты: Airflow — инфраструктура; n8n — инфраструктура или executions в облаке; Make — операции (каждый модуль отдельно).
• Контроль данных: максимальный у Airflow и self-hosted n8n; минимальный у Make как SaaS.

Российская специфика:
Для команд в РФ критичен self-hosted путь: Airflow и n8n можно развернуть на отечественных VPS или в Yandex Cloud/Selectel. Make, Zapier и другие зарубежные SaaS не дают гарантий доступности и оплаты. Если данные не могут покидать страну — выбор очевиден.

Как выбрать инструмент

FAQ

Выводы

Нет единого лучшего инструмента для API-оркестрации — есть подходящий под ваши ограничения. Airflow остаётся выбором зрелых data-команд, которым нужна масштабируемость и контроль. n8n закрывает большинство задач среднего уровня и даёт свободу self-hosting. Make — удобный SaaS для бизнес-автоматизации, но с привязкой к облаку и пошаговой тарификацией.

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

Источник: материал основан на публикации «Airflow vs n8n vs Make for API orchestration» автора Raizan в DEV Community — dev.to/chasebot/airflow-vs-n8n-vs-make-for-api-orchestration-1lb8. Раздел про Make и сравнительный анализ дополнены редакционным контекстом.

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

OpenAI выпустила GPT-5.5-Cyber — модель для поиска и исправления уязвимостей в больших кодовых базах.

Codex Security получил апдейт: глубокие сканы, триаж, генерация патчей и предотвращение новых багов в production.

Запущена инициатива Patch the Planet совместно с Trail of Bits для помощи мейнтейнерам open source.

Инициатива Daybreak уже помогла найти десятки уязвимостей в Linux, FreeBSD, Chrome, Safari, Firefox и других проектах.

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

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

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

Что уже нашла Daybreak

В рамках Daybreak OpenAI уже публиковала результаты совместной работы моделей и исследователей:

• 8 утечек указателей ядра Linux и 24 эксплойта повышения привилегий;
• 23-летнюю use-after-free в реализации System V semaphores в OpenBSD;
• 34 уязвимости и 7 эксплойтов повышения привилегий в FreeBSD;
• 6 уязвимостей в dnsmasq;
• технику отказа в обслуживании HTTP/2 Bomb, затронувшую NGINX, Apache, IIS и Pingora;
• 5 эксплуатируемых уязвимостей в движке V8 Google Chrome, 10 — в Apple Safari и уязвимость WebAssembly в Mozilla Firefox.

Patch the Planet для open source

Новая программа Patch the Planet, запущенная совместно с Trail of Bits, направлена на снятие нагрузки с мейнтейнеров. Инженеры будут напрямую работать с проектами — от cURL и Python до Go, freenginx, NATS Server, pyca/cryptography, Sigstore и aiohttp — помогать готовить патчи, тесты и reusable workflow для поиска багов.

Выводы

GPT-5.5-Cyber и обновлённый Codex Security — попытка перевести ИИ-инструменты кибербезопасности от простого нахождения багов к полному циклу исправления. Главный вопрос — успеют ли защитники адаптироваться быстрее атакующих.

Frontier AI models are anticipated to exceed current industry expectations, fundamentally transforming both offensive and defensive cyber capabilities. The timeline is not years, it is months.

Источники

• OpenAI Expands Daybreak With GPT-5.5-Cyber — The Hacker News

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

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

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

Возвращаться к фичам стало неинтересно. В инфраструктуре задачи сложнее, результат измеряется метриками — latency, error rate, скорость релизов, — а влияние на всю систему, а не на один экран.

Что Android даёт для инфраструктуры — а чему учиться с нуля

Мобильный бэкграунд оказался не балластом, а преимуществом. Я понимал ограничения изнутри. Backend-инженер может прочитать, что мобильные сети ненадёжны, память ограничена, а батарея — критичный ресурс. Но прочитать и прочувствовать — разное. Я годами наблюдал, как приложение “захлёбывается” на устройствах среднего сегмента. Знал, что 60% пользователей сидят именно на таких. Видел, как баг, который мы починили за день, продолжает висеть у людей неделями — просто потому, что они не успели обновиться.

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

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

Чему пришлось учиться с нуля? Операционному мышлению. В Android ты выпускаешь релиз — и он либо работает, либо нет. Если крашится, починишь в следующей версии. В инфраструктуре нет «следующей версии». Если gateway падает, всё приложение ложится для миллионов пользователей прямо сейчас.

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

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

Этому в мобильной разработке не учат.

Как я учился: пробелы, сроки и смена мышления

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

Учился итеративно, не пытаясь объять необъятное сразу. Gateway начинался как простой прокси. Затем добавили агрегацию ответов, потом — конфигурационные определения экранов. Каждый такой шаг вынуждал осваивать следующий уровень: circuit breakers, стратегии повторов, observability, планирование мощностей.

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

Что означает «выдающийся уровень» в инфраструктуре

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

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

Затем — миграция живой системы, где права на ошибку практически нет. Приложение нельзя выключить или отрепетировать в реальном масштабе. Остаётся только постепенный перевод трафика: shadow mode → 1% → 5% → 25% → 50% → 100%, с автоматическим откатом при любом росте ошибок. И всё это — пока миллионы пользователей активно работают с продуктом, не подозревая, что под капотом идёт замена двигателя на ходу. Такой уровень дисциплины и инструментации приходит только с практикой.

Наконец, владение надёжностью. Gateway — единая точка отказа: упал он, упало всё. Годы уходят на то, чтобы сделать его скучным и предсказуемым: резервирование, автомасштабирование, circuit breakers, режимы деградации, еженедельный пересмотр мощностей. Высший пилотаж — когда о системе просто не думаешь, потому что она работает.

Почему путь в инфраструктуру доступнее, чем кажется?

Карьерные траектории в инфраструктуре редко бывают чётко описаны. Здесь нет готового чек-листа в духе «диплом по Computer Science, пять лет в бэкенде, обязательное знание Kafka и Kubernetes». С одной стороны, такая неопределённость пугает. С другой — именно она и делает этот путь более доступным, чем принято думать.

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

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

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

Мобильный бэкграунд как преимущество архитектора

Считаю ли я, что мобильный опыт сделал меня лучшим архитектором для mobile-first продуктов? Безоговорочно, да.

Я помнил, как ощущается медленный экран на устройстве среднего сегмента. Помнил, что случается, когда API возвращает слегка неправильные данные и приложение падает при парсинге. Помнил то чувство, когда баг уже в проде, а ты ждёшь App Store Review и ничего не можешь исправить.

Поэтому когда я проектировал gateway, я не занимался абстрактной «оптимизацией перформанса». Я опирался на совершенно конкретный опыт. Знал, что убрать один сетевой round trip — это подарок каждому мобильному разработчику. Знал, что перенос логики на сервер означает перенос в место, где я могу починить всё за минуты, а не за недели.

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

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

• Найдите промежуточный шаг. Не прыгайте сразу в бэкенд. Начните с задач на стыке: оптимизация API, инструменты для мобильных разработчиков, улучшение сетевого слоя.
• Используйте мобильный контекст как рычаг. Вы понимаете то, о чём бэкенд-инженеры только догадываются. Говорите об этом вслух.
• Учитесь измерять невидимое. В инфраструктуре результат — это метрики: latency, error rate, скорость релизов. Учитесь рассказывать историю через цифры.
• Проектируйте под отказ, а не тушите пожары. Senior-уровень — это определить, что сломается и кто за это отвечает, до того, как оно сломается.
• Не ждите разрешения. Путь не размечен, но он открыт. Начните с малого — и двигайтесь туда, где задачи становятся интереснее.

EchoBird — это open-source настольный лаунчер для ИИ-агентов и локальных больших языковых моделей (LLM). Написан на Rust + Tauri, работает на Windows, macOS и Linux. Автор, разработчик с ником edison7009, собрал его после того, как друзья не раз просили помочь «поставить этот ваш ИИ» на новой машине. Сейчас проект насчитывает 2200 звёзд на GitHub, 162 ответвления и 112 релизов; актуальная версия — v5.2.7.

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

• EchoBird — это open-source менеджер ИИ-инструментов на Rust + Tauri для Windows, macOS и Linux.
• Четыре сценария: установка и починка агентов, локальные LLM, личные ИИ-проекты и единое средство запуска приложений.
• Model Nexus объединяет API-ключи, модели и протоколы OpenAI / Anthropic в одном центре конфигурации.
• Локальные модели запускаются через llama.cpp, vLLM или SGLang с автоподбором под железо.
• Расширяется через plugin.json: новый инструмент можно добавить без изменения кода приложения.

Четыре сценария, которые покрывает EchoBird

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

Установка и починка агентов

EchoBird сканирует систему, находит уже установленные инструменты и проверяет зависимости. Если чего-то не хватает, ведёт установку в режиме диалога. Если что-то сломалось — запускает починку. Поддерживаются Claude Code, Codex CLI, OpenCode, Aider, Hermes Agent, MiMo Code от Xiaomi и собственная линейка агентов автора — OpenClaw, ZeroClaw, NanoBot и PicoClaw. Новый инструмент добавляется через файл plugin.json, поэтому сообщество может расширять список без запросов на слияние в основной репозиторий.

Локальные LLM в один клик

Встроены три runtime'а под разное железо: llama.cpp для CPU и слабых машин, vLLM для серверных GPU NVIDIA на Linux и SGLang для агентских сценариев с жёстко заданным выводом — например, когда модель должна вернуть JSON строго по схеме. EchoBird сам определяет наличие видеокарты NVIDIA и предлагает runtime с подходящими параметрами — например, размер батча и offloading слоёв на GPU. После запуска модель отдаёт совместимые с OpenAI и Anthropic endpoints — остальные инструменты не замечают подмены. Про локальный запуск LLM через Ollama у нас есть пошаговый гайд.

Мои ИИ-проекты

Раздел для утилит, демок, игр и скриптов, созданных в режиме vibe coding (импровизационной разработки с ИИ), которые рождаются за один вечер с ИИ-помощником. Вместо того чтобы искать директорию и вспоминать команду запуска, проект живёт в едином списке с кнопкой «старт».

Менеджер приложений

Центральная панель запуска для всего, что уже установлено. Можно запустить Claude Code, Codex CLI или локальную модель из одного списка, не открывая отдельные терминалы и окна.

Model Nexus: единая точка входа для моделей

Главная архитектурная идея — Model Nexus. Это прослойка между приложением и поставщиками моделей, которая хранит API-ключи, проверяет задержки, транслирует OpenAI- и Anthropic-совместимые протоколы.

Без него каждый инструмент требует своей конфигурации: Claude Code требует свой API-ключ, Codex CLI — свой .env, Hermes Agent — свой config.toml, а локальный vLLM — свой путь к модели. Model Nexus заменяет это на «ввёл один раз, используешь везде».

Поддерживаются 14+ поставщиков: Anthropic, OpenAI, Gemini, xAI Grok, Mistral, Together AI, DeepSeek, MiniMax, GLM, SiliconFlow, а также Ollama, llama.cpp, vLLM, SGLang, OpenRouter и любой OpenAI-совместимый endpoint. Каждому агенту можно назначить свой протокол независимо от остальных.

Почему Tauri + Rust, а не Electron

Выбор стека для менеджера, который управляет чужими тяжёлыми моделями, логичен. Tauri даёт бинарник менее 10 МБ против типичных 100+ МБ у Electron. Rust напрямую дёргает системные API, работает с файловой системой, процессами и детекцией GPU без лишних мостов. Для инструмента, который постоянно запускает подпроцессы и читает конфигурации, это надёжнее и предсказуемее.

Сравнение: классическая установка Claude Code и EchoBird

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

1. Проверить версию Node.js (нужен 18+).
2. Убедиться, что права npm настроены правильно.
3. Выполнить npm install -g @anthropic-ai/claude-code.
4. Прописать переменную окружения ANTHROPIC_API_KEY.
5. Проверить: claude --version. При смене машины — повторить.

Путь через EchoBird — короче в разы:

1. Открыть EchoBird.
2. Install & Repair → Claude Code → установить в один клик.
3. Model Nexus → ввести API-ключ один раз для всех инструментов.

Расширение через plugin.json

Новый инструмент описывается JSON-файлом с командами установки, проверки, починки и запуска. Пример минимального плагина:

Такой подход отделяет ядро приложения от рецептов установки. Теоретически сообщество может добавить плагины для российских моделей — например, GigaChat, YandexGPT или локальных сборок на базе Saiga — без необходимости ждать официальных обновлений.

Что нового в ветке v5.x

Релизы выходят активно. Несколько примечательных изменений последних недель:

• v5.2.4 — зеркала для установки из Китая (Tsinghua, Alibaba, Huawei), чтобы зависимости качались без VPN.
• v5.2.0 — переключатель Responses-протокола OpenAI для моделей, которые говорят на нём нативно, например MiniMax-M3 и Qwen3.7.
• v5.2.6 — поддержка MiMo Code от Xiaomi и починка автоуплотнения контекста в Codex V2, из-за которого разговоры обрывались.
• v5.2.4 — нативные элементы управления окном и стандартные горячие клавиши macOS (⌘W, ⌘M, ⌘,).

Как попробовать

Безопасность:
Перед запуском любого установочного скрипта из интерната рекомендуем открыть его в редакторе или скачать официальный инсталлятор из GitHub Releases.

После установки: открываете Model Nexus, добавляете ключи; переходите в Install & Repair, выбираете инструменты; запускаете их из App Manager. Для локальных моделей — Local LLM → runtime → модель.

Кому пригодится

• Тимлидам и DevRel'ам, которым часто нужно «поднять окружение» на новой машине коллеги.
• Разработчикам, кто переключается между рабочими и личными ПК и устал от повторяющегося адаптации.
• Энтузиастам локальных LLM, которым надоело вручную ставить CUDA, vLLM и искать пути к моделям.
• Авторам плагинов, которые хотят добавить поддержку отечественных или нишевых ИИ-сервисов.

Выводы

EchoBird не изобретает ИИ-инструменты заново — он убирает трение на границе между «хочу попробовать» и «уже работает». Model Nexus решает проблему разрозненных конфигураций, встроенные runtime'ы — проблему локальных моделей, а плагины — проблему поддержки новых сервисов. Выбор Rust + Tauri выглядит обоснованным: приложение остаётся лёгким, хотя самые тяжёлые модели грузятся вне его.

EchoBird родился из собственной боли: друзья постоянно просили меня установить Claude Code на их машины. Я хотел, чтобы любой мог нажать одну кнопку и получить рабочее окружение, не разбираясь в Node.js, npm и переменных окружения.

Если в вашем рабочем процессе регулярно фигурируют Claude Code, Codex CLI, Aider или локальные LLM, стоит потратить несколько минут на установку и посмотреть, сколько ручных шагов отпадёт.

Источники

Оригинальный материал: Open Source Project of the Day (#97): EchoBird — DEV Community. Дополнительно: репозиторий EchoBird на GitHub, официальный сайт.

Мы рады анонсировать выпуск MDN MCP server. MCP (Model Context Protocol) — открытый стандарт, который позволяет ИИ-инструментам подключаться к внешним источникам данных. MDN MCP server использует этот протокол, чтобы перенести документацию MDN и данные о совместимости браузеров прямо в вашего ИИ-агента или IDE.

• MDN MCP server — экспериментальный сервер по протоколу MCP.
• Даёт ИИ-агентам и IDE доступ к актуальной документации MDN и данным о совместимости браузеров.
• Работает с VS Code, Zed, Cursor, Claude Code, Codex CLI, Antigravity CLI и Claude Desktop.
• В тестах с Claude Code Opus 4.7 MDN MCP дал гораздо точнее и надёжнее результаты о поддержке браузеров.
• Ответы с MDN MCP были вдвое быстрее, чем без него.

Зачем мы создали MDN MCP

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

Например, LLM или агент для написания кода может не знать, что существует функция вроде @view-transition CSS at-rule, или не знать, достигла ли она статуса Widely Available в Baseline и безопасна ли для использования во всех браузерах.

MDN MCP даёт вашему агенту для написания кода доступ к точной и актуальной информации о веб-платформе. Также он упрощает доступ к последней документации, не покидая привычные инструменты.

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

Как использовать MDN MCP

MDN MCP server работает с любым MCP-совместимым клиентом, включая:

• Редакторы: VS Code, Zed и Cursor.
• CLI-агенты: Claude Code, Codex CLI и Antigravity CLI (ранее Gemini CLI).
• Чат-приложения: Claude Desktop.

Ссылки в этом списке ведут к инструкциям по настройке MCP для каждого инструмента. Инструкции по установке и другие детали — на нашей странице MDN MCP server.

Как быстрый пример, чтобы использовать его с Claude Code, нужно выполнить следующую команду:

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

Какую разницу даёт MCP

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

Мы протестировали Claude Code Opus 4.7 с MDN MCP и без него на нескольких функциях, недавно появившихся в Firefox 150 и 151, спрашивая, как использовать функции и какая у них поддержка браузеров. А именно:

1. Как использовать CSS-функцию light-dark() для изображений и какие браузеры её поддерживают?
2. Как использовать CSS-псевдокласс :buffering и какие браузеры его поддерживают?
3. Как использовать атрибут shadowrootslotassignment на элементе и какие браузеры его поддерживают?
4. Как использовать Web Serial API и какие браузеры его поддерживают?

Мы заметили определённые закономерности в результатах. В большинстве случаев заметки по использованию от Claude Code с MDN MCP и без него были сопоставимы. Часть ответов, использовавших MCP, была структурирована лучше и полнее. Например, заметки для CSS-функции light-dark() также включали примеры с линейными градиентами, которые не были прямо упомянуты в вопросе, но тоже поддерживаются.

Когда дело дошло до информации о поддержке браузеров, победитель был очевиден: MDN MCP дал намного точнее и надёжнее результаты. Claude Code без MCP правильно определил поддержку браузеров только в одном случае — для псевдокласса :buffering.

Например, Claude Code без MCP настаивал, что декларативный атрибут shadowrootslotassignment поддерживается в Chrome 120 и Safari 18.3, возможно, путая его с опцией slotAssignment метода Element.attachShadow(). Но на самом деле Firefox 151 — первый браузер, в котором появилась поддержка этого атрибута.

Без MCP Claude Code также не дал никакой конкретной информации о поддержке браузеров для использования изображений в функции light-dark(): «поддержка менее однородна, чем вариант с цветом», тогда как с MCP он выдал полную таблицу с указанием Firefox 150 и Chrome (за флагом) как поддерживающих браузеров.

Худший результат Claude Code без MCP показал на вопросе про Web Serial API. Firefox 151 получил поддержку Web Serial API в мае 2026 года. Однако Claude Code без MCP правильно упомянул браузеры на базе Chromium как поддерживающие эту функцию, но также настаивал, что в Firefox она:

Не реализовано (и не в планах — см. позицию Mozilla по стандартам: «вредно»).

С включённым MCP Claude Code правильно определил, что Firefox 151 поставляет поддержку Web Serial API, согласно примечаниям к выпуску.

Кроме того, мы заметили, что в наших тестах ответы с использованием MDN MCP были вдвое быстрее. Без MCP Claude Code приходилось загружать и парсить немало HTML-страниц, чтобы найти актуальную информацию, что занимало время, но даже тогда не давало точных результатов.

Поучаствовать

Ваш отзыв помогает нам становиться лучше. Если вы столкнулись с проблемами, есть комментарии или предложения или хотите поделиться, как используете MDN MCP, мы будем рады услышать вас. Заходите в канал platform в нашем Discord. Если заметили проблемы, сообщайте о них в репозиторий mdn/mcp на GitHub.

Что дальше

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

Источник: Introducing the MDN MCP server — MDN Blog.

Попробуйте подключить MDN MCP к своему редактору или агенту и проверьте, насколько точнее станут ответы о веб-платформе.

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

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

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

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

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

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

После сотен тестов вот те гуманизаторы ИИ, которые стабильно давали мне самые естественные результаты.

GPTHuman AI показал лучший баланс читаемости и естественности: сохраняет смысл и требует минимальной доработки.

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

UndetectedGPT хорошо варьирует предложения, однако может усложнять простые объяснения.

Grammarly Humanizer скорее напоминает продвинутого редактора, чем специализированный гуманизатор ИИ.

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

Главное качество хорошего гуманизатора — не масштаб изменений, а их точность: сохранение смысла, улучшение читаемости и естественность.

1. GPTHuman AI

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

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

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

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

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

Он идеален? Нет. Я всё равно редактирую каждую статью перед публикацией. Но по сравнению с большинством альтернатив он требует меньше всего доработки.

2. StealthGPT

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

Скорость обработки — одна из самых высоких среди протестированных.

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

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

Для коротких текстов это не было серьёзной проблемой.

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

3. UndetectedGPT

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

Инструмент в целом хорошо справляется со статьями среднего размера и информационным контентом.

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

Минус в том, что иногда он добавляет сложность там, где она не нужна. Простые объяснения иногда становятся длиннее и труднее для чтения. Это не всегда плохо, но читаемость важна.

Лучший текст часто — самый простой текст. Тем не менее UndetectedGPT стабильно выдавал достойные результаты на протяжении всех тестов.

4. Grammarly Humanizer

Большинство людей знает Grammarly как инструмент для проверки грамматики и корректуры. Функции humanizer у него относительно новые по сравнению с некоторыми конкурентами.

То, что Grammarly делает исключительно хорошо, — это полировка.

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

Инструмент отлично справляется с исправлением грамматики, устранением неловких формулировок и уплотнением структуры предложений.

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

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

5. AIHumanize

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

Я нашёл её особенно полезной для коротких материалов: писем, постов в соцсетях и небольших статей.

Где она спотыкалась, так это в стабильности.

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

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

Что делает гуманизатор ИИ по-настоящему хорошим?

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

Цель не в том, чтобы полностью преобразовать текст. Цель — улучшить его.

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

Лучшие инструменты — не те, которые меняют текст больше всего. А те, которые вносят самые точные изменения.

Мои финальные мысли

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

У каждой — слабые. И у каждого автора — свои приоритеты.

Кому-то нужна максимальная переработка текста. Кому-то — минимальная правка.

Кто-то ценит скорость. Кто-то — читаемость. Для меня главный фактор — звучит ли финальный текст так, как его мог бы написать настоящий человек.

Исходя из этого критерия, GPTHuman AI стабильно показывал лучшие результаты на протяжении тестирования.

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

А это в итоге то, что ищет большинство писателей.

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

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

ТОП‑8 сервисов для массовой рассылки писем в 2026 году

1. Notisend — конструктор писем с поддержкой массовых, триггерных и транзакционных кампаний и шаблонами для ускоренного запуска.
2. Майло — базовый сервис рассылки писем, который позволяет легко создать шаблон и отслеживать статистику доставляемости и открытия сообщений.
3. Dashamail — инструмент с расширенной аналитикой, сегментацией и тестированием кампаний, а также поддержкой различных типов рассылок.
4. Brevo — многофункциональная платформа с управлением контактами и аналитикой, которая подходит для сложных маркетинговых сценариев.
5. Мейлганер — система автоматизации с сегментацией, стандартами данных и валидацией контактов, ориентированная на триггерные email‑кампании.
6. Carrot quest — комплексная CRM‑платформа с A/B‑тестами, в которой триггерные email‑цепочки вплетены в общую маркетинговую стратегию.
7. RuSender — отечественный сервис email‑рассылок с адаптивным конструктором, персонализацией писем и встроенной аналитикой по поведению получателей.
8. Sendsay — омниканальный инструмент, который поддерживает email, SMS и push‑уведомления и анализирует кликабельность сообщений.

1. Notisend

Платформа помогает выстраивать коммуникации с клиентами через email-рассылки, SMS и мессенджеры. Внутри есть гибкие настройки отправки, готовые шаблоны и визуальный редактор писем, с которым можно собрать кампанию без помощи разработчика. Сервис поддерживает сегментацию базы, аналитику и персонализацию, поэтому маркетолог может точнее настраивать сообщения под разные группы аудитории. Для автоматизации доступны триггерные цепочки, A/B-тестирование и детальная статистика, в том числе данные о доставке писем во «Входящие» и спам.

• Стоимость: от 0,51 ₽/сообщение, подписка начинается от 580 руб./мес. за 1000 контактов (неограниченные письма)
• Бесплатный тариф: 5 000 писем в подарок при регистрации
• Регистрация: по email, Yandex, VK

Для кого подходит: сервис подойдет малому и среднему бизнесу, маркетологам и агентствам, которым нужен единый инструмент для email, SMS и рассылок в мессенджерах.

Возможности

• визуальный редактор для создания писем;
• коллекция готовых шаблонов для разных сценариев;
• разделение контактов по различным характеристикам;
• интеграции с системами CRM, CMS и через API.

Преимущества

• объединяет несколько каналов коммуникации в одном инструменте;
• интерфейс позволяет запускать кампании без помощи разработчиков;
• аналитика и тесты A/B помогают улучшить эффективность рассылок;
• гибкие тарифные планы, включая возможность бесплатного начала работы.

Что стоит учесть

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

Ознакомиться с сервисом >>>

2. Майло

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

• Стоимость: от 430 ₽/месяц
• Бесплатный тариф: бесплатное использование с базой до 200 подписчиков
• Регистрация: через email, Yandex, Google, VK

Для кого подходит: блогерам, онлайн-школам и маркетологам, которым важны простота настройки рассылок и гибкая модель оплаты.

Возможности

• автоматическое удаление повторяющихся и неактивных контактов при загрузке базы;
• импорт и экспорт списка подписчиков через Excel за несколько кликов;
• гибкая тарификация по числу контактов или объему писем;
• настройка автоматических триггерных сообщений.

Преимущества

• оплата только за фактический объем отправок;
• ускоренная работа с базой за счет очистки лишних контактов;
• запуск писем по событиям, например, поздравления с днем рождения;
• стабильная работа с большими базами без задержек.

Что стоит учесть

• поддерживается только email-канал, омниканальные рассылки отсутствуют;
• часть расширенных функций доступна только в платных тарифах.

Ознакомиться с сервисом >>>

3. Dashamail

Сервис для управления email‑кампаниями, позволяет работать с любыми видами рассылок от рекламных сообщений до транзакционных уведомлений и автоматизированных последовательностей. Платформа поддерживает не только массовую отправку писем, но и веб-уведомления на сайте. Есть возможность делить аудиторию на сегменты, персонализировать письма и проводить A/B‑тесты для повышения вовлеченности подписчиков. Отчеты по эффективности обновляются в реальном времени, что облегчает корректировку стратегий.

• Стоимость: от 2 200 ₽ за 10 000 писем
• Бесплатный тариф: использование без оплаты до ~100 подписчиков и до ~2000 писем
• Регистрация: через email

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

Возможности

• создание и отправка массовых, триггерных и транзакционных писем;
• блочный онлайн-редактор с готовыми шаблонами;
• настройка автоматизированных цепочек и A/B‑тестирование;
• подробная статистика и интеграция с внешними аналитическими системами.

Преимущества

• поддержка разных типов рассылок в одной платформе;
• возможность отправки web‑push‑уведомлений дополнительно к email;
• простой редактор для формирования писем без навыков программирования;
• анализ данных в реальном времени с подключением внешних систем.

Что стоит учесть

• функционал может показаться сложным для новичков в email‑маркетинге;
• расширенные возможности доступны только в платных планах.

Ознакомиться с сервисом >>>

4. Brevo

Платформа объединяет управление рассылками по email и SMS с инструментами CRM и автоматизации в едином облачном сервисе, что делает коммуникацию с клиентами более прозрачной и организованной. С помощью системы можно отправлять маркетинговые и транзакционные сообщения, создавать сегменты подписчиков и запускать многоканальные кампании через email, SMS и WhatsApp. Дополнительно встроенный CRM-модуль позволяет вести учет контактов, отслеживать историю взаимодействий и синхронизировать продажи с маркетинговыми активностями.

• Стоимость: от €6.33 в месяц
• Бесплатный тариф: до 300 писем в день
• Регистрация: через email

Для кого подходит: e‑commerce проектов, маркетинговых команд и отделов продаж, которым важно строить комплексные многоканальные стратегии, а не ограничиваться отправкой отдельных писем.

Возможности

• рассылка сообщений по email, SMS и WhatsApp;
• встроенные CRM-инструменты для учета контактов и истории взаимодействий;
• управление базой подписчиков и сегментация аудитории;
• создание лендингов и pop-up форм для сбора подписок.

Преимущества

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

Что стоит учесть

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

Ознакомиться с сервисом >>>

5. Mailganer

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

• Стоимость: от 3 500 ₽ в месяц
• Бесплатный тариф: предоставляется
• Регистрация: по email

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

Возможности

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

Преимущества

• автоматизация процессов экономит время и повышает конверсию;
• улучшенная репутация домена и высокая доставляемость благодаря проверке базы;
• гибкая интеграция через API и готовые модули;
• отчеты позволяют оперативно оценивать эффективность кампаний.

Что стоит учесть

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

Ознакомиться с сервисом >>>

6. Carrotquest

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

• Стоимость: от 8 792 ₽ в месяц
• Бесплатный тариф: бесплатный пробный период на 7 дней
• Регистрация: через email

Для кого подходит: актуально для e‑commerce, онлайн‑сервисов и маркетинговых команд, которые хотят автоматизировать взаимодействие с посетителями сайта и повысить конверсии на всех этапах воронки продаж.

Возможности

• автоматический сбор и анализ действий пользователей;
• сегментирование аудитории по различным параметрам;
• встроенный чат на сайте с интеграцией в CRM и мессенджеры;
• аналитика воронки, A/B‑тестирование и подробные отчеты по взаимодействию.

Преимущества

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

Что стоит учесть

• высокая цена по сравнению с конкурентами;
• освоение платформы требует времени из-за широкого функционала.

Ознакомиться с сервисом >>>

7. RuSender

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

• Стоимость: от 792 ₽/месяц
• Бесплатный тариф: 2 000 писем в месяц, рассылки по сегментам
• Регистрация: через email

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

Возможности

• блочный редактор и адаптивные макеты для писем;
• проверка разных вариантов рассылки через A/B-тесты;
• отчеты по кампаниям, открытиям и переходам;
• бесплатный план до 500 подписчиков и 2000 писем в месяц.

Преимущества

• понятный интерфейс для быстрого запуска кампаний;
• надежная защита пользовательских данных;
• комфортный старт для новичков в email-маркетинге;
• статистика помогает улучшать следующие рассылки.

Что стоит учесть

• основной фокус сделан на email, а дополнительные каналы представлены ограниченно;
• на бесплатном плане действует лимит по количеству отправляемых писем.

Ознакомиться с сервисом >>>

8. Sendsay

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

• Стоимость: от 848 ₽ в месяц
• Бесплатный тариф: есть
• Регистрация: через email

Для кого подходит: маркетинговым командам, которые хотят автоматизировать коммуникации не только по email, но и через SMS, push‑уведомления и мессенджеры.

Возможности

• массовая отправка email‑сообщений;
• омниканальные уведомления (SMS, Web-Push, мобильные push);
• визуальный редактор и адаптивные шаблоны;
• сбор базы через формы и сегментация подписчиков.

Преимущества

• все каналы коммуникации управляются из одной платформы;
• высокая вероятность доставки писем и уведомлений;
• рост вовлеченности клиентов;
• интеграция с внешними системами и CRM.

Что стоит учесть

• часть расширенного функционала доступна только на платных планах;
• при отправке в пиковые часы рассылка может идти дольше.

Ознакомиться с сервисом >>>

Для чего нужен сервис email-рассылок

Такие платформы становятся не просто инструментом отправки писем. Они превращают коммуникацию с аудиторией в управляемый процесс. С их помощью компании могут выстраивать долгосрочные отношения, экономя время и одновременно повышая отдачу от маркетинга.

Привлечение и прогрев аудитории

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

Прямые продажи

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

Автоматические сценарии

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

Работа с текущими клиентами

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

Информационные и сервисные письма

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

Сбор и анализ поведения аудитории

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

Основные типы сервисов email-рассылок

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

Массовые рассылки

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

Триггерные и автоматизированные сервисы

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

CRM‑ориентированные платформы

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

Транзакционные сервисы

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

Универсальные омниканальные платформы

Современные системы объединяют email, SMS, push‑уведомления и мессенджеры в одном месте. Такой подход позволяет строить комплексные сценарии коммуникаций и контролировать весь путь клиента в рамках единого интерфейса.

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

Каким должен быть хороший сервис email-рассылок

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

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

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

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

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

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

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

В совокупности эти функции превращают сервис email‑рассылок не просто в инструмент отправки писем, а в полноценную платформу для управления коммуникацией, оптимизации маркетинга и повышения продаж.

Как выбрать сервис email-рассылок

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

Масштаб бизнеса и размер базы

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

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

Цель использования: продажи, прогрев или сервисные письма

Для рекламных кампаний важны шаблоны, персонализация, A/B-тесты и понятная статистика по кликам. Для прогрева аудитории больше ценятся цепочки писем, поведенческие сегменты и сценарии, которые ведут подписчика от первого клика к покупке.

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

Уровень автоматизации

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

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

Нагрузка и частота рассылок

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

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

Бюджет и модель оплаты

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

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

Интеграции с текущими системами

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

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

На что смотреть в итоге

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

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

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

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

Ниже — пять сервисов, которые я проверил на реальных задачах. Без воды.

Зачем вообще делать презентацию онлайн?

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

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

Теперь по делу.

5 сервисов для онлайн-презентации: разбираю каждый

Тестировал в таком порядке: сначала самые известные, потом менее очевидные. Начну с Canva — ее знают все.

1. Canva — для тех, кто хочет красиво

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

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

Плюсы: ✅ Сотни профессиональных шаблонов ✅ Богатый редактор: шрифты, иконки, фото, анимации ✅ Удобно для брендированных презентаций

Минусы: ➡️ AI-генерация работает хуже с русскоязычным контентом ➡️ Часть функций — только в платной версии

Для кого: дизайнеры, маркетологи, те, кому важен визуальный результат и есть время на редактирование.

2. Google Slides — надежный и бесплатный

Google Slides — это фактически бесплатный PowerPoint в браузере. Никакой AI-генерации нет: все делаешь сам, зато полный контроль над каждым слайдом.

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

Технически к Google Slides можно подключить Gemini AI — но это требует VPN и оплаты картой, которая принимает зарубежные сервисы. Для большинства российских пользователей этот путь закрыт.

Плюсы: ✅ Полностью бесплатно ✅ Русский интерфейс ✅ Совместное редактирование в реальном времени ✅ Привычный для всех формат

Минусы: ➡️ Нет AI-генерации в доступном виде — Gemini требует VPN и зарубежную карту ➡️ Дизайн по умолчанию простой, шаблонов мало

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

3. Gamma — мощный AI, но на английском

Gamma — серьезный конкурент в нише AI-презентаций. Генерирует структуру и дизайн по описанию, умеет делать не только слайды, но и веб-страницы, документы. Дизайн получается современным и аккуратным.

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

Плюсы: ✅ Сильный AI, хороший дизайн ✅ Много возможностей для публикации и шеринга ✅ Экспорт в PPT и Google Slides

Минусы: ➡️ Большинство шаблонов — платные ➡️ Подписку с российской картой не оплатить ➡️ Русскоязычная генерация уступает специализированным русскоязычным сервисам

Для кого: англоязычные проекты, международные презентации.

4. Slidy AI — если нужно быстро и на русском

Принцип slidy ai простой: ввел тему — нейросеть сама собирает структуру слайдов, пишет тексты и подбирает дизайн. Я проверял на задаче «Маркетинговая стратегия для малого бизнеса» — черновик из 10 слайдов был готов примерно за 40 секунд.

Что приятно: можно не просто скачать результат, а доработать его прямо в браузере — как в упрощенном PowerPoint. Менял текст, переставлял блоки, добавил пару картинок. Потом экспортировал в PPTX.

Из особенностей: работает без VPN, интерфейс и генерация на русском. Для тех, кто делает презентации на русском языке регулярно, это имеет значение — у Gamma и Canva с этим заметно хуже.

Плюсы: ✅ Интерфейс и генерация полностью на русском ✅ Встроенный редактор прямо в браузере ✅ Экспорт в PPTX и PDF ✅ Есть каталог готовых презентаций по темам

Минусы: ➡️ AI дает хороший черновик, но не идеальный финал — иногда нужно подправить формулировки ➡️ Для сложных брендированных проектов может не хватить гибкости дизайна

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

5. Slidesgo — если нужен красивый шаблон

Slidesgo — большой каталог шаблонов для презентаций, и AI-генерация там есть. Вводишь тему, выбираешь стиль — сервис собирает слайды. Бесплатно дают три генерации, потом нужна подписка.

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

Плюсы: ✅ Красивые и разнообразные шаблоны ✅ AI-генерация есть ✅ Три бесплатные генерации

Минусы: ➡️ Большинство шаблонов — платные ➡️ Подписку с российской картой не оплатить ➡️ Интерфейс на английском

Для кого: разовая задача в рамках трех бесплатных попыток — ок. Для регулярной работы не подходит.

Для кого какой сервис

Студент с дедлайном завтра → Slidy AI. Нет времени разбираться, нужен результат за минуту, бесплатно и по-русски.

Преподаватель, который готовит лекции каждую неделю → Slidy AI или Google Slides. Первый сэкономит время на структуре, второй — привычнее для тех, кто любит полный контроль.

Маркетолог с презентацией для клиента → Canva (если важен дизайн и есть час) или Slidy AI (если важна скорость и русский язык).

Предприниматель, готовит питч-дек → Slidy AI для черновика, потом доработка в редакторе или экспорт в PowerPoint. Для международного питча — посмотреть на Gamma.

Дизайнер, которому нужна красивая основа → Canva или Slidesgo — там лучший выбор шаблонов.

Итого

Онлайн-презентаций больше не нужно бояться. Браузер, тема, три минуты — и у тебя есть с чем работать.

Если нужна скорость и русский язык без VPN — для меня в этом наборе задач лучше всего сработал Slidy AI. Если важнее дизайн и есть время — Canva. Если нужна командная работа — Google Slides.

Попробуй сам: в худшем случае потратишь минуту. В лучшем — выспишься перед защитой.

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

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

Допустим, клиент выбирает большую 4-местную кемпинговую палатку (Фактор А) и одновременно добавляет в корзину два детских спальных мешка (Фактор Б). LLM не просто ищет товары с тегом «кемпинг» . Она сопоставляет эти данные со своими знаниями о мире и делает логический вывод (Вывод В): планируется семейный выезд на природу с маленькими детьми. На основе этого синтеза система рекомендует не банальный фонарик, а мощный фумигатор повышенной безопасности для закрытых тентов или портативный подогреватель детского питания, работающий от прикуривателя.

Где потолок?

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

1. Холодный старт. Стандартные подходы полностью зависят от активности аудитории. При загрузке в онлайн-кинотеатр нового фильма алгоритмы чистой коллаборативной фильтрации сталкиваются с проблемой «нулевого вектора» (отсутствием строки или столбца взаимодействий в матрице). Система не может рассчитать близость нового объекта к интересам пользователей, из-за чего новинки могут неделями оставаться мертвым грузом на дне каталога.
2. Проблема «усредненного товара». В классических системах и покупатель, и товар — это лишь векторы в пространстве. Когда пользователь вводит сложный запрос (например, «мощный игровой ноутбук, который не перегревается и выглядит строго для офиса»), классический алгоритм пытается найти точку где-то посередине между мощностью и дизайном. В итоге вектор запроса смещается в зону универсальных домашних ноутбуков, которые не тянут игры и выглядят дешево. В этом случае система усредняет координаты, теряя специфические требования. LLM же не усредняет, а рассуждает: она видит каждое условие как отдельный логический фильтр и ищет товар, который удовлетворяет всем критериям одновременно.
3. Гибкость без переписывания кода. В традиционной архитектуре признаки товара жестко заданы инженерами (цена, бренд, категория). Если бизнес хочет внедрить новый критерий, например «экологичность материалов», начинается долгий процесс: нужно нанять людей для разметки тысяч товаров, изменить структуру базы данных и переобучить модель. Это занимает месяцы. В LLM-архитектуре этот признак уже существует бесплатно. Модель может извлечь информацию об экологичности напрямую из описаний или отзывов в момент запроса. Не нужно менять код или переучивать систему, достаточно просто попросить модель учитывать этот параметр.

Уровни интеграции LLM: архитектура LLMERS

Интеграция LLM в рекомендательные системы требует разделения контуров вычислений. Важно разделять архитектуры: если классические трансформеры в RecSys (например, модели класса BERT4Rec) оптимизированы под обработку последовательностей action_id и ID товаров, то большие генеративные языковые модели работают с сырым текстом и смыслами. Если заставить тяжелую авторегрессионную LLM обрабатывать каждый клик пользователя в реальном времени, серверная инфраструктура рухнет из-за огромных задержек ответа (latency).

Ключевые паттерны интеграции (на примере e-commerce):

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

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

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

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

• Zero-shot ранжирование. На самом последнем этапе шорт-лист из 20 релевантных кандидатов передается в промпт для LLM, которая пересортирует их с учетом последних действий пользователя. Это дает высочайшую точность смыслов, но применяется точечно из-за высоких задержек.

Защита от галлюцинаций: мощь паттернов RAG

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

Для жесткого контроля трансформеров инженеры применяют пайплайны Retrieval-Augmented Generation (RAG). Механизм работает в три этапа:

1. Семантический поиск. База данных (векторное хранилище) отбирает топ реальных продуктов из каталога на основе текущего запроса клиента.
2. Формирование контекста. Система автоматически собирает системный промпт, оборачивая в него строгие факты (точные артикулы, цены, характеристики) о найденных товарах.
3. Аналитическая генерация. LLM выдает финальный результат или текстовую консультацию строго в рамках переданного узкого списка товаров, теряя возможность выдумать что-то новое.

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

Шаг к агентным системам будущего

Мы наблюдаем важнейший эволюционный переход: статические алгоритмы уступают место агентным рекомендательным системам (Agentic Workflows). Классическая модель просто получает данные и отдает результат. Агент же способен вести диалог, логически рассуждать и вызывать сторонние инструменты по API.

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

LLM-агент работает иначе: он превращает строку поиска во вдумчивого аналитика. Используя метод пошагового рассуждения (Chain-of-Thought), нейросеть перед выдачей результата формирует скрытый внутренний логический монолог:

• Анализ аудитории. В запросе указаны дети. Значит, в приоритете повышенная защита от насекомых, плотное дно и хорошая вентиляция.

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

• Анализ локации. В Карелии высокая влажность и вероятность дождей. Требуется двухслойная конструкция с высоким показателем водонепроницаемости тента (от 4000 мм в.ст.).

• Формирование фильтров. Ищем: кемпинговая палатка, 3-4 места, двухслойная, водостойкая, с москитными сетками.

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

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

Персонализация и миф одного запроса

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

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

Новые метрики: почему точности мало

Традиционно качество измеряли метриками конверсии (CTR, Conversion Rate) и угадывания конкретного клика (Hit Rate). Но семантический подход требует перехода к концепции Beyond Accuracy. Оптимизация только под вероятность клика приводит к информационному пузырю и система может назойливо предлагать детективы целый месяц после одной покупки.

Новые классы метрик эффективно лечат эту болезнь:

• Контролируемая серендипность. Оценивает внезапные приятные сюрпризы. Если любителю детективов предложить аудиокнигу про историю джаза (похожую по нуарной атмосфере), он будет искренне доволен. Классика не смогла бы проложить такой маршрут.
• Внутрисписочное сходство (разнообразие). Оценивает способность собрать подборку из фильмов абсолютно разных жанров, каждый из которых при этом точно попадает во вкус зрителя.
• Объяснимость рекомендаций. Способность нейросети генерировать короткие тексты-подсказки (например, «Я советую вам этот курс, так как вы недавно искали статьи по Python»). Это повышает прозрачность и снижает барьер недоверия.
• Калибровка. Жесткая проверка честности системы. Выдача обязана соответствовать реальным долговременным интересам пользователя, не скатываясь в дешевый кликбейт.
• Покрытие каталога. Показывает глубину поиска. Семантический векторный движок обязан эффективно поднимать хорошие товары из самого длинного «хвоста» базы.

Инженерные барьеры и безопасность данных

Внедрение умных технологий всегда несет риски. Команды разработки регулярно решают сложнейшие инфраструктурные ребусы:

1. Время задержки сервера (Latency). Пользователь ждет результат миллисекунды, а гигантские трансформеры думают секундами. Инженерам приходится агрессивно кешировать результаты, батчить запросы и выносить максимум расчетов в офлайн-процессы.
2. Приватность и дообучение. Логи пользователей нельзя отправлять во внешнее облако. Приходится разворачивать локальные открытые модели внутри закрытого контура компании. Для экономии ресурсов видеокарт применяют методы адаптеров (PEFT): базовые веса замораживаются, и тренируются только крошечные слои, что позволяет быстро адаптировать нейросеть под специфику магазина.
3. Проблема выравнивания (Alignment). Базово LLM учится просто предсказывать следующее слово. Но продуктовой команде нужно растить бизнес-метрики (например, время удержания в приложении). С помощью обучения с подкреплением (RLHF) поведение модели подстраивают под реальные бизнес-цели компании.

Если на практике: мультимодальная языковая модель

Пример такого технического внедрения — мультимодальная языковая модель (MMLM) команды AI VK. Она сравнивает контент по смыслу и тематике, объясняет комментарии, описывает интересы пользователя к конкретным сценам и учитывает эмоциональный тон материалов. Нейросеть обучена более чем на трех миллионах русскоязычных материалов и может анализировать видео, изображения, тексты и аудио. С ней рекомендательные алгоритмы быстрее показывают новый контент в продуктах VK без необходимости получения первых пользовательских реакций.

Чек-лист: когда стоит внедрять технологию

Решение о трансформации должно иметь четкий финансовый расчет. Оцените ваш продукт перед внедрением LLM.

Дайте зеленый свет экспериментам, если:

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

Включите красный свет, если:

• Сценарии потребления просты и рутинны (заказ бумажных полотенец, покупка кабеля по известному артикулу).
• Намерение пользователя прозрачно и не требует глубокого анализа.
• У вас жесткие аппаратные ограничения на обработку онлайн-запросов (вы просто сожжете бюджет на аренду GPU без выгоды для бизнеса).

Cloudflare приобрела VoidZero — компанию-основателя Vite, Vitest, Rolldown, Oxc и Vite+.

Вся команда VoidZero переходит в Cloudflare, включая Эвана Ю.

Проекты сохраняют открытый исходный код, лицензию MIT и независимость от поставщика.

Cloudflare выделяет $1 млн на фонд экосистемы Vite для поддержки сопровождающих.

Vite набирает около 129 млн загрузок в неделю; плагин Cloudflare для Vite — 14 млн.

Дашборд Cloudflare уже работает на Vite, а CLI компания переведёт на него в будущем.

VoidZero появилась как попытка собрать в единую экосистему наиболее востребованные инструменты фронтенд-разработки. Vite — система сборки, ставшая фактическим стандартом для современных JavaScript-приложений. Vitest отвечает за тестирование, Rolldown заменяет Rollup на Rust, а Oxc — это платформа инструментов для JavaScript/TypeScript на Rust, включающая компилятор, линтер Oxlint, форматировщик и другие компоненты.

Cloudflare подчёркивает, что не собирается перекраивать планы развития проектов под свои нужды. По аналогии с приобретением Astro ранее в этом году, команды сохраняют автономию, а код остаётся открытым. Главное отличие в том, что Vite — это не просто фреймворк, а фундамент, на котором строятся Vue, SvelteKit, Nuxt, Astro, Solid, Qwik, Angular, React Router, TanStack Start и даже Next.js — в экспериментальном проекте vinext.

Что меняется для разработчиков

В краткосрочной перспективе — ничего. Vite, Vitest, Rolldown, Oxc и Vite+ продолжат развиваться по прежним планам. Эван Ю и команда VoidZero остаются лидерами проектов. Cloudflare обещает направлять инженерные ресурсы на развитие инструментов, а не на их смену бренда или закрытие.

В долгосрочной перспективе Cloudflare намерена построить собственный CLI cf поверх Vite. Цель — чтобы команды cf dev, cf build и cf deploy чувствовали себя как расширение привычного vite dev. Это должно упростить развёртывание Vite-приложений на платформу Cloudflare Workers, сохранив при этом переносимость кода между любыми хостингами.

Почему это важно

Vite сегодня — один из немногих инструментов, которые объединяют всю JavaScript-экосистему. По данным Cloudflare, Vite набирает 129 млн загрузок в неделю, а официальный плагин @cloudflare/vite-plugin — 14 млн. С ростом ИИ-агентов, которые генерируют код и выполняют итерации с ним в цикле, скорость сборки, тестирования и линтинга становится критичной. Весь стек VoidZero оптимизирован для таких сценариев: Rust-инструменты работают на порядок быстрее аналогов на JavaScript.

Кроме того, Cloudflare выделяет $1 млн в фонд экосистемы Vite. Деньги пойдут на поддержку сопровождающих и участников — администрировать фонд будет ядро команды Vite. Это редкий случай, когда крупная инфраструктурная компания инвестирует напрямую в открытый исходный код, не пытаясь монополизировать его.

Выводы

Приобретение VoidZero — значимый корпоративный вклад в открытую инфраструктуру JavaScript. Cloudflare получает влияние на инструмент, который используют миллионы разработчиков, а сообщество — гарантии независимости и $1 млн на развитие экосистемы.

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

Источник: Cloudflare Blog — VoidZero is joining Cloudflare

Хотите попробовать Vite на Cloudflare прямо сейчас — выполните npm create vite@latest, а затем npx wrangler deploy.