Такая модель нужна там, где ответ читает код: отправить обращение в нужную очередь, проверить документ по списку правил, решить, вызывать ли агенту инструмент. Программа получает вероятность и сравнивает её с порогом, разбирать сгенерированный JSON не приходится. Google вышла с таким API вслед за стартапом TypeSafe с моделью Jev и OpenAI, которая открыла Decisions API на GPT-6 Luna в октябре. От обоих Gemini Decision 1, по документации трёх компаний, отличается приёмом аудио, видео и PDF.

• Модель gemini-decision-1 с 11 ноября работает через Gemini API версии v1beta и в Google AI Studio; поддержку в Google Cloud компания обещает «скоро», без даты.
• Вопросы трёх типов: «да/нет», выбор из 2–255 вариантов и оценка по рубрике из 2–255 уровней; в одном запросе до 1000 вопросов и до 262 144 токенов на общий вход вместе с вопросами.
• Цена — $0,10 за млн входных токенов, выход не тарифицируется; бесплатный уровень — 200 запросов в минуту, 50 000 токенов в минуту и 10 000 запросов в день на проект.
• По замерам самой Google, модель обходит и Jev 1.14, и GPT-6 Luna в 5 из 7 общих тестов; ошибка калибровки Top-1 ECE — 0,0250 против 0,0494 и 0,0721, но прогон этих тестов у Jev дешевле: $0,68 против $0,88.
• Кеширования, Batch API, Flex и Priority нет; России нет в списке регионов Gemini API; у агрегаторов модель уже появилась: в OpenRouter это google/gemini-decision-1.

Что такое модель решений и чем она отличается от обычной LLM?

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

Запрос состоит из общего входа input (текст, изображения, аудио, видео, PDF) и карты вопросов questions. У каждого вопроса один из трёх типов:

Типы вопросов Decisions API

Источник: ai.google.dev/gemini-api/docs/decisions-api

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

Скорость авторы анонса в блоге Google описывают одной фразой:

Gemini Decision 1 scores options without token-by-token decoding, keeping median latency 50-100 ms of model compute (150-250 ms end-to-end), across multimodal inputs and contexts up to 16K tokens, remaining nearly flat from 1 to 100 questions per request.

Перевод редакции: «Gemini Decision 1 оценивает варианты без потокенного декодирования и удерживает медианную задержку 50–100 мс на вычисления модели (150–250 мс на весь запрос) для мультимодальных входов и контекстов до 16 тыс. токенов; задержка почти не меняется от 1 до 100 вопросов в запросе».

Оговорки стоят в самой цитате: это медиана, контекст до 16 тыс. токенов и не больше 100 вопросов. Для входа ближе к пределу в 262 144 токена и для 1000 вопросов цифр задержки компания не приводит. Внутри Google, по словам авторов, API уже выбирает модель и уровень размышлений для запросов в Gemini Notebook, где повседневные запросы обслуживаются с задержкой до 40% ниже, и подбирает эмодзи-реакцию из более чем 200 вариантов в сервисе CC из Google Labs.

Сколько стоит Gemini Decision 1 и что входит в бесплатный уровень?

На платном уровне модель стоит $0,10 за млн входных токенов любого типа: текст, изображения, видео, аудио, PDF. В строке Output price на странице цен Gemini API стоит «Not applicable (0 output tokens)». Общий вход тарифицируется один раз за запрос независимо от числа вопросов, каждый вопрос добавляет токены своих инструкций и критериев. Кадры видео и страницы PDF считаются как токены изображений. Руководитель продукта Google AI Studio и Gemini API Логан Килпатрик представил модель в X так:

Introducing Gemini Decision 1, our new frontier decision model in the Gemini API. It is $0.10 per 1M input tokens with no additional cost. With support for image, audio, video, and PDF natively, 256K context window, & 1K questions. You can try it for free in the API!

Перевод: «Представляем Gemini Decision 1, нашу новую передовую модель решений в Gemini API. Она стоит $0,10 за 1 млн входных токенов без дополнительных платежей. Нативно поддерживает изображения, аудио, видео и PDF, контекстное окно 256K и 1 тыс. вопросов. Попробовать можно бесплатно через API!» «No additional cost» здесь означает нулевую цену выхода: в анонсе Google перечисляет, что нет платы за выходные токены, токены размышлений, отдельную расшифровку аудио и распознавание текста. Скидок тоже нет. Модель не поддерживает кеширование контекста, Batch API, режимы Flex и Priority, и повторяющийся вход в каждом запросе оплачивается полностью.

Лимиты на странице квот действуют на проект целиком, сколько бы API-ключей в нём ни было. Дневная квота обнуляется в полночь по тихоокеанскому времени, и Google оговаривает, что указанные значения не гарантированы.

Лимиты Gemini Decision 1 в Decisions API

Источник: ai.google.dev/gemini-api/docs/rate-limits, проверено 11 ноября 2026 года

За бесплатный уровень разработчик платит данными: в таблице цен в строке «Used to improve our products» для Free Tier стоит Yes, для платного — No. Условия Gemini API просят не отправлять в бесплатные сервисы чувствительную, конфиденциальную и персональную информацию; для пользователей из Европейской экономической зоны, Швейцарии и Великобритании на бесплатную квоту распространяются правила платных сервисов. Другие варианты с постоянной бесплатной квотой собраны в списке бесплатных API для LLM.

Чем Gemini Decision 1 отличается от Jev и OpenAI Decisions API?

Главные отличия по документации — модальности входа и лимиты запроса. По цене токена Google совпадает с OpenAI и примерно в 2,4 раза дороже Jev. Сравнение собрано по документации Google, руководству OpenAI Decisions и странице моделей TypeSafe:

Три API моделей решений по официальной документации

Источники: документация Google, OpenAI и TypeSafe, проверено 11 ноября 2026 года

У Jev изображения и вопросы типа Box, по документации TypeSafe, пока не считаются готовыми для продакшена, а длинный контекст включается отдельным заголовком и работает медленнее и менее точно, чем запросы в обычных пределах. OpenAI поддерживает кеширование промптов, историю диалога с вызовами инструментов и изображения внутри вопросов. У Gemini Decision 1 инструкции вопросов принимают только текст, а многоходовой контекст нужно сериализовать в текст. Модель GPT-6 Luna, вышедшая в API в сентябре, у OpenAI универсальная, Google же выпустила под решения отдельную модель. Ту же развилку цены и модальностей отмечают в обсуждении запуска на Hacker News:

Its bit more expensive than other other Decision Models in the same lane. However, it can accept Audio and Video as input as well and for those specific cases it can be extremely useful.

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

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

Все числа ниже — замеры самой Google из таблицы в анонсе; независимых замеров на день запуска нет. По этой таблице Gemini Decision 1 обходит одновременно Jev 1.14 и GPT-6 Luna в пяти из семи тестов, где есть результаты всех моделей, а GPT-6 Luna — во всех семи. Jev 1.14 выше на Mind2Web Multimodal и When2Call. В тексте анонса при этом сказано, что модель «leads across the suite», то есть лидирует по всему набору.

Бенчмарки из анонса Gemini Decision 1 (замеры Google)

Источник: таблица в анонсе Google от 11 ноября 2026 года; замеры Google

Методика уместилась в сноску под таблицей: отказы, блокировки фильтрами безопасности и запросы, которые модель не смогла принять, засчитаны как ошибки, знаменатель — полный бенчмарк, метрика — Top-1 Accuracy, если не указано иное (у Amazon ESCI это Macro-F1). MMAU и Video-MME прогнаны только на моделях Gemini: прямого ввода аудио и видео в документации Jev и OpenAI Decisions API нет. Отдельной страницы с промптами и логами прогонов Google не опубликовала; как отбирались тесты, в анонсе не сказано.

Сильнее всего отрыв в калибровке. Top-1 ECE, ожидаемая ошибка калибровки, показывает, насколько заявленная уверенность модели расходится с фактической долей верных ответов. На семи общих тестах у Gemini Decision 1 она равна 0,0250, у Jev 1.14 — 0,0494, у GPT-6 Luna — 0,0721. На этих тестах вероятности модели Google лучше согласуются с её точностью; о калибровке на других данных таблица ничего не говорит.

По цене прогона тех же семи тестов первая Jev: $0,68 против $0,88 у Gemini Decision 1 и $0,93 у GPT-6 Luna. Генеративная Gemini 3.5 Flash-Lite через Interactions API обошлась в $4,14, отсюда заявление Google о почти пятикратной экономии.

Проверять такие модели на глаз труднее, чем обычные LLM. Об этом ещё в октябре, в обсуждении беты OpenAI Decisions API, писал на Hacker News разработчик Саймон Уиллисон:

Anyone using a decision model like this is going to have to spin up their own evals - these are far harder to vibe-check than regular text output LLMs.

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

Где попробовать и как вызвать API?

В Google AI Studio и через Gemini API версии v1beta; нужны API-ключ и SDK google-genai версии 3.2 или новее. Без кода вопросы всех трёх типов можно проверить в Decisions Playground и выгрузить оттуда готовый код; рядом лежат демо-приложения Doorstep Parcels и Find the Zookeeper. Команды установки SDK из документации:

В Python запрос отправляет метод client.decisions.create, клиент создаётся с http_options={"api_version": "v1beta"}. Тот же вызов через REST, дословно из раздела Quickstart:

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

Доступ ограничен географией: в списке стран и территорий, где работают Gemini API и Google AI Studio, России нет. Интеграции с OpenRouter, LangChain, Vercel, LiteLLM, Pydantic AI, Pipecat, LiveKit и OpenCode, по анонсу, выкатываются постепенно. Первые уже видны: на странице модели в OpenRouter она значится как google/gemini-decision-1 с провайдером Google AI Studio, ценой $0,10 за млн входных токенов и контекстом 262 144 токена. Вызывается модель там через отдельный OpenRouter Decisions API, SDK для chat completions с ней не работают, а в общем списке /api/v1/models в ночь на 12 ноября её не было. Карточка с ценой $0,10 и примером вызова есть и в Vercel AI Gateway.

Какие ограничения перечисляет документация?

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

• Вероятность в вопросах «да/нет» всегда лежит в диапазоне 0,01–0,99: проверка порога выше 0,99 не сработает никогда.
• Вопрос choice распределяет вероятность между вариантами, даже если не подходит ни один. Документация советует порог по confidence, отдельную проверку «да/нет» или вариант other с явным описанием. Ключи вариантов сортируются по алфавиту, порядок в JSON на результат не влияет.
• score — среднее номеров уровней, поэтому шкалу нужно держать линейной, а одно и то же значение могут дать разные распределения вероятностей.
• Медиа передаётся только в общем входе: через Files API, публичный или подписанный HTTPS-URL (до 15 МБ) либо base64 (до 100 МБ на запрос, PDF до 50 МБ). Ссылки YouTube и gs:// не поддерживаются.
• При срабатывании входных фильтров безопасности API возвращает HTTP 400 без ответов, с кодом safety, prohibited_content, blocklist, image_safety или content_blocked.
• Вход считается недоверенным: пользовательский текст может сам убеждать модель в нужной классификации. Для действий с высокой ценой ошибки, например выплат, документация советует оставлять человека или вторую проверку.

Что сделать разработчику сейчас?

1. Обновить SDK google-genai до версии 3.2 или новее и получить ключ в Google AI Studio; на бесплатном уровне не отправлять конфиденциальные и персональные данные.
2. Собрать размеченные примеры из своего трафика и подобрать пороги по ним: документация советует именно так и предлагает взвешивать цену ложного срабатывания против цены пропуска.
3. Держать пороги для noul внутри диапазона 0,01–0,99 и проверять confidence перед автоматическим действием.
4. Считать бюджет по входу: кеша нет, общий вход оплачивается в каждом запросе заново, поэтому независимые вопросы к одним данным выгоднее класть в один запрос, до 1000 штук.
5. Если нужны Batch API, кеширование или запуск в Google Cloud, закладывать ожидание: первых двух модель не поддерживает, срока для третьего нет.

Открытыми остаются три вопроса: когда модель появится в Google Cloud, как она покажет себя в независимых замерах и как меняется задержка на контекстах больше 16 тыс. токенов. На странице модели и в анонсе нет ссылки на model card; в журнале изменений Gemini API запуск отмечен одной записью от 11 ноября.

Источники: Google: Gemini Decisions API: Fast, calibrated multimodal decisions, Gemini API: Decisions API, Gemini API: модель Gemini Decision, Gemini API: Pricing, Gemini API: Rate limits, Gemini API: Available regions, Gemini API: Terms of Service, Gemini API: Release notes, Logan Kilpatrick в X, OpenAI: Decisions guide, OpenAI: модель GPT-6 Luna, TypeSafe: Models, TypeSafe: Images, Обсуждение на Hacker News, OpenRouter: Gemini Decision 1, Vercel AI Gateway: Gemini Decision 1

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

Для тех, кто пишет на Claude API или работает в Claude Code, это готовая схема расходов: входные токены у четырёх моделей стоят от $0,10 до $8 за миллион, выходные — от $0,50 до $40, и ошибка с выбором модели или уровня effort меняет счёт в разы. Все рекомендации и почти все замеры ниже принадлежат самой Anthropic: это советы вендора о собственных моделях, независимый замер вынесен в отдельный раздел. О выходе старшей модели мы писали в новости «Anthropic выпустила Claude Fable 5.2 и снизила цену на 20%».

• Стартовая точка по гайду — Opus 5.5 на effort medium: $4 за миллион входных и $20 за миллион выходных токенов, вдвое дешевле Fable 5.2 ($8 и $40).
• Sonnet 5.5 ($2 и $10) — для чётко очерченных задач, Haiku 5.5 ($0,10 и $0,50 при промпте до 100 тыс. токенов) — для классификации, маршрутизации и субагентов, Fable 5.2 — для самых сложных проектов и когда Opus 5.5 на high не справляется.
• Effort — более тонкая ручка, чем модель: по замерам Anthropic на подмножестве SWE-bench Pro Opus 5.5 на medium теряет около 2,5 пункта к high при примерно 70% стоимости, а xhigh даёт около 1,4 пункта за 2,5 цены high.
• Выше high один шаг effort может стоить как переход на старшую модель: на FrontierCode 2.0 Fable 5.2 на high набрала 45,3% против 45,5% у Opus 5.5 на max примерно за половину стоимости задачи.
• Связка «Opus 5.5 руководит, до 25 исполнителей на Sonnet 5.5» на внутреннем тесте Anthropic обошлась примерно на треть дешевле одного Opus 5.5 при том же результате; советник (advisor) в замерах компании явного выигрыша не дал.

Какую модель Claude ставить на какую задачу?

Если задача ещё не понятна, гайд советует Opus 5.5 на medium: эта модель стоит по умолчанию в Claude Code на тарифах Pro, Max, Ultra, Team, Enterprise и при работе через Anthropic API. От неё двигаются вниз, когда задача хорошо очерчена или массовая, и вверх, когда она трудная или должна долго идти без присмотра.

The quick answer is that you should start most work on Opus 5.5 at its default effort level, medium.

Задача, стартовая модель и effort по гайду Anthropic

Оговорка из гайда: наличие чёткой спецификации само по себе не повод брать Sonnet. Миграция или оптимизация производительности могут быть описаны подробно и всё равно оказаться достаточно трудными для Opus 5.5, а крупные — для Fable 5.2. Пятая модель, Claude Mythos 5.2, в выбор не входит: она доступна только через программы верификации Anthropic. Страница документации о выборе модели даёт ту же отправную точку: большинство нагрузок начинается с Opus 5.5.

Сколько стоят четыре модели и чем они различаются?

От Sonnet 5.5 к Fable 5.2 каждая ступень удваивает цену токена: Sonnet 5.5 — $2 и $10 за миллион входных и выходных токенов, Opus 5.5 — $4 и $20, Fable 5.2 — $8 и $40. Haiku 5.5 стоит $0,10 и $0,50, пока промпт не длиннее 100 тыс. токенов, то есть в 20 раз дешевле Sonnet 5.5. Это прайс-лист Claude API со страницы цен в документации.

Четыре модели Claude: цены и характеристики (данные Anthropic)

Три детали из таблицы влияют на счёт сильнее остальных. Первая: Haiku 5.5 — единственная модель, у которой цена зависит от длины промпта. Свыше 100 тыс. токенов тариф вырастает в пять раз, хотя и тогда остаётся вчетверо ниже цены Sonnet 5.5; на коротких промптах входные токены Haiku в 20 раз дешевле, чем у Sonnet. Если каждый вызов требует длинного промпта, гайд советует сравнивать Haiku 5.5 и Sonnet 5.5 по стоимости завершённой задачи.

Вторая: чтение из кэша у Fable 5.2 стоит столько же, сколько у Opus 5.5, — $0,20 за миллион токенов. Поэтому на длинном прогоне, где большая часть входа читается из кэша, разница между ними сводится к некэшированному входу и выходу, где Fable вдвое дороже. Третья: fast mode есть только у Opus 5.5 и Fable 5.2; по документации он даёт до 2,5 раза больше выходных токенов в секунду и стоит $8 и $40 за миллион токенов у Opus 5.5 и $16 и $80 у Fable 5.2.

Как эти цены выглядят рядом с GPT, Gemini и недорогими Flash-моделями, мы разбирали в обзоре «Fable 5.1, GPT-6 Astra и дешёвые Flash: что брать в API в сентябре 2026»; гайд Anthropic моделей других компаний не касается.

Почему effort стоит менять раньше, чем модель?

Потому что шаг effort меньше шага между моделями и по цене, и по результату. Effort — параметр запроса с пятью уровнями (low, medium, high, xhigh, max), который задаёт, сколько токенов модель тратит на размышление, вызовы инструментов и самопроверку. Гайд приводит замер Anthropic на SWE-bench Pro для Opus 5.5 относительно уровня high:

• medium — примерно на 2,5 пункта ниже при около 70% стоимости;
• low — примерно на 8 пунктов ниже при около трети стоимости;
• xhigh — примерно на 1,4 пункта выше при стоимости в 2,5 раза больше.

Абсолютные значения есть в руководстве Claude Platform по стоимости и качеству: на подмножестве SWE-bench Pro из 478 задач Opus 5.5 решил 87,4% на low при $0,11 за задачу, 92,8% на medium при $0,21, 95,3% на high при $0,29 и 96,7% на xhigh при $0,74. Значения для low, medium и high усреднены по двум прогонам, для xhigh прогон был один. Anthropic оговаривает, что это внутренние замеры и что баллы на подмножестве нельзя сравнивать с публичным лидербордом.

Before you move models, try adjusting your effort level. It's a finer dial for both cost and capability.

У ручки есть пределы. Более высокий effort добавляет задержку и не даёт модели знаний и навыков, которых у неё нет: за ними нужно идти на модель выше. Выше high один шаг effort может стоить как старшая модель, поэтому гайд советует в этой точке проверить следующую модель на более низком effort. Два примера из замеров Anthropic показывают это с обеих сторон. На Terminal-Bench 3.0, как описано в посте «Spending your effort», предыдущая Fable 5.1 на max набрала 58,0%, а Opus 5.5 на high — 58,9%, потратив вдвое меньше токенов. На FrontierCode 2.0 новая Fable 5.2 на high показала 45,3% против 45,5% у Opus 5.5 на max примерно за половину стоимости задачи.

A higher price per token doesn't always mean a higher cost per task, or a better result.

Когда модель не справляется, гайд предлагает три шага строго по порядку:

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

Если результат проверяется автоматически, выгоднее гонять всё на низком уровне и перезапускать на высоком только провалы. На том же подмножестве SWE-bench Pro схема «Opus 5.5 на low, неудачи повторно на high» даёт около 97% решённых задач примерно по $0,17 за задачу, тогда как прогон всех задач на high — 95,3% по $0,29. Это расчётная оценка: Anthropic посчитала её по отдельным задачам из уже проведённых прогонов на low и high, отдельно такую схему не запускали.

В API уровень задаётся полем output_config.effort; без него действует уровень по умолчанию для модели. Пример из документации:

В Claude Code уровень меняет команда /effort, а /effort status показывает текущий: по документации о настройке моделей, значение в Claude Code может отличаться от умолчания API. Так, Sonnet 5.5 и Fable 5.2 в API стартуют на high, а в Claude Code — на medium.

Как сочетать модели, чтобы платить меньше?

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

Keep the expensive model's context for the decisions, and let cheaper subagents do the verbose reading.

Смена модели посреди работы. Кэш промпта принадлежит модели, которая его записала, поэтому первый ход на новой модели оплачивается по цене записи кэша за весь разговор. Чтобы этот ход был меньше, в Claude Code перед переключением стоит выполнить /compact или начать новую сессию с коротким письменным планом, а в API — открыть разговор с новой моделью сводкой сделанного вместо полной истории. Блоки thinking тоже привязаны к модели: старшая читает блоки младших (Fable 5.2 — блоки Opus 5.5, Sonnet 5.5 и Haiku 5.5), а модель ступенью ниже прежних рассуждений не видит. Запрос при этом проходит: API исключает из него блоки, которые новая модель прочитать не может, и она работает без них. Документация советует продолжать отправлять полную историю: сами блоки в ней остаются и пропадают насовсем, только если их удалит клиент. Все случаи перечислены на странице «Preserved thinking».

Субагенты на младших моделях. Субагент работает в собственном контекстном окне и возвращает сводку, а его токены оплачиваются по тарифу модели, на которой он запущен. В Claude Code модель задаётся строкой model: haiku или model: sonnet в определении субагента; переменная окружения CLAUDE_CODE_SUBAGENT_MODEL задаёт умолчание для субагентов без указанной модели. Пример из гайда — файл .claude/agents/log-reader.md:

Младшим моделям гайд советует оставлять работу, где ошибку дёшево заметить: поиск файлов, запуск тестов, чтение логов. Правки кода и решения остаются на главной модели: если маленькая модель неверно прочитает результат поиска, главная откроет не тот файл и потратит на него токены. Две ловушки из гайда. Встроенный субагент Explore в текущих версиях Claude Code работает на модели сессии, а не всегда на Haiku. Исключение по документации — сессия на Fable: при подписке Claude, аккаунте Anthropic Console или шлюзе через ANTHROPIC_BASE_URL Explore идёт на модели алиаса opus, а в Amazon Bedrock, Google Cloud, Microsoft Foundry и Claude Platform on AWS остаётся на модели сессии. Чтобы разведка оставалась дешёвой, нужно определить собственного субагента с именем Explore и model: haiku. Алиас haiku указывает на Haiku 5.5 только в Anthropic API и начиная с Claude Code v2.1.293; в Amazon Bedrock, Google Cloud, Microsoft Foundry и Claude Platform on AWS он по-прежнему ведёт на Haiku 4.5. Зафиксировать модель алиаса можно переменной ANTHROPIC_DEFAULT_HAIKU_MODEL.

Алиас opusplan устроен наоборот: Opus планирует в режиме плана, Sonnet исполняет, то есть правки кода уходят на младшую модель. Автор советует измерить opusplan на своих задачах, прежде чем делать его режимом по умолчанию.

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

Про пользу советника гайд говорит сдержанно. В таблице из руководства по стоимости ни одна из четырёх пар явно не обошла своего исполнителя в одиночку. Одна из них — Opus 5.5 на high с советником Fable 5.1 на внутреннем тесте по коду: 90,1% при $2,92 за попытку, на 1,7 пункта выше одного Opus 5.5 на high примерно за 2,1 раза больше денег. Такой прирост, по оценке Anthropic, лежит на границе шума между прогонами и сопоставим с тем, что дал бы более высокий effort. Советник помогает, только когда исполнитель к нему обращается, а на низком effort это случается реже, поэтому сначала стоит измерить частоту обращений.

Оркестратор и исполнители. Для работы, которая не помещается в одно контекстное окно, старшая модель делит задачу, раздаёт части множеству дешёвых исполнителей параллельно и сводит результаты. На внутреннем тесте Anthropic по поиску дефектов в исходном коде объёмом около 22 млн токенов Opus 5.5 во главе исполнителей на Sonnet 5.5, до 25 одновременно, обошёлся примерно на треть дешевле одного Opus 5.5 на его effort по умолчанию и набрал примерно столько же. На Claude Platform такую схему даёт мультиагентная оркестрация в Claude Managed Agents. Для одной цепочки зависимых шагов и для работы, которая помещается в одно окно, гайд советует её не использовать: планирование и слияние стоят больше, чем экономят.

Что проверить перед переносом запросов на другую модель?

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

• История запросов и Fable 5.2. API отвечает ошибкой 400, если изменилось что-либо перед блоком thinking от Fable 5.2: системный промпт, инструменты или более раннее сообщение. Исключение — явное согласие отбрасывать затронутые блоки. Если запросы собирают Claude Code, Claude Agent SDK или Claude Managed Agents, менять ничего не нужно; если историю редактирует ваш код, её стоит держать только дополняемой.
• Thinking. Opus 5.5 и Fable 5.2 думают всегда, запрос с отключённым thinking вернёт ошибку. У Sonnet 5.5 режим between_tools ограничивает размышления промежутками между вызовами инструментов; по документации он работает на effort low, medium и high, а на xhigh и max запрос с ним вернёт ошибку 400. У Haiku 5.5 thinking можно выключить на effort не выше high. Блоки ответа нужно читать по полю type: ответ может начинаться с блока thinking.
• Принудительный вызов инструмента. tool_choice со значением any или tool возвращает ошибку 400 на Sonnet 5.5, Opus 5.5 и Fable 5.2. Вместо этого гайд советует отправлять auto, помечать инструмент strict: true и писать в промпте, когда его применять.
• Переход с Haiku 4.5 на Haiku 5.5. budget_tokens заменяется уровнем effort; нестандартные temperature, top_p и top_k возвращают ошибку 400, как и история, которая заканчивается ходом ассистента для продолжения.
• Защитные откаты. У Opus 5.5, Sonnet 5.5 и Fable 5.2 работают классификаторы безопасности, которые чаще всего срабатывают на темы кибербезопасности и биологии. В Claude Code помеченный запрос может быть перезапущен на более старой модели с уведомлением в транскрипте.

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

Как измерить всё это на своих задачах?

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

1. Собрать выборку реальных задач и написать для каждой проверку результата: проходящий тест, закрытый тикет, верное число строк.
2. Прогнать каждую модель-кандидата на двух-трёх уровнях effort, каждый прогон в отдельной сессии, чтобы они не делили кэш. Стоимость каждой завершённой задачи записывать из поля usage ответов.
3. Построить график «результат против расходов». Связку из нескольких моделей оставлять, только если она лучше любой точки с одной моделью.
4. Перед переключением запустить победителя в теневом режиме на части реального трафика.

При сравнении двух моделей гайд советует считать отдельно самые трудные задачи набора: на них приходится большая часть расходов. В одном прогоне из 20 поисковых задач две задачи дали 43% всех трат. Быстрая проверка в Claude Code: выполнить одну задачу из бэклога на двух моделях, переключая их командой /model, и сравнить отчёты /usage. Другие способы сократить счёт из того же руководства Claude Platform мы пересказывали в новости «Anthropic показала, как срезать счёт за Claude без потери качества».

Что показывает независимый замер?

Цифры гайда получены самой Anthropic, и результатов моделей других компаний в нём нет. Из независимых данных на 9 ноября есть замер Artificial Analysis: Fable 5.2 на effort max набрала 65 баллов в Intelligence Index v5 при средней стоимости $26,5 за задачу, примерно в 2,6 раза больше, чем у Opus 5.5 на max ($10,0, 59 баллов). На high и xhigh у Fable 5.2 62 балла при 98 тыс. выходных токенов на задачу против 173 тыс. у Opus 5.5 на max. Вывод Artificial Analysis совпадает с логикой гайда: на max Fable 5.2 заметно дороже, а на более низких уровнях effort может обойти Opus 5.5 при меньшей стоимости задачи. Как устроен сам индекс, мы писали в новости «Artificial Analysis обновила Intelligence Index до v5».

Результаты бенчмарков Fable 5.2 Anthropic держит на странице модели. Предыдущий гайд команды, о циклах в Claude Code, мы разбирали в статье «Claude Code научился работать в циклах: разбираем официальный гайд Anthropic». Цены и умолчания в тексте действительны на 9 ноября 2026 года; у Anthropic они меняются с выходом каждой модели, поэтому перед расчётом бюджета стоит сверяться со страницей цен.

Источники: Anthropic: Which Claude model should you build with? Fable, Opus, Sonnet, or Haiku, Claude Platform: Optimizing for cost and intelligence, Claude Platform: Effort, Claude Platform: Pricing, Claude Platform: Choosing a model, Claude Platform: Advisor tool, Claude Platform: Preserved thinking, Claude Platform: Fast mode, Claude Code: Model configuration, Claude Code: Subagents, Anthropic: Spending your effort, Anthropic: страница Claude Fable 5.2, Artificial Analysis: замер Claude Fable 5.2, 9 ноября 2026 года

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

Когда HTTP 200 уже недостаточно

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

Классический health-check отвечает на бинарный вопрос: сервис доступен или нет. Например, HAProxy отправляет HTTP-запрос на заданный URL и, получив ожидаемый код ответа, считает backend работоспособным. Если проверка не проходит, узел исключается из балансировки.

Но между состояниями «полностью исправен» и «полностью недоступен» есть промежуточная зона. Узел может продолжать отвечать HTTP 200 и при этом:

• находиться под высокой загрузкой CPU;
• испытывать нехватку оперативной памяти;
• активно использовать swap;
• иметь заканчивающееся место на диске или inode;
• потерять связь с PostgreSQL;
• частично потерять связь с RabbitMQ;
• иметь недоступный PreviewService, IntegrationService или LogService;
• содержать контейнер Directum RX в состоянии Restarting или Exited.

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

Именно для этой задачи появился проект Self-Healing Directum RX.

Что было предложено

Текущая версия проекта — v0/MVP, реализованная в виде Bash health-agent. Ее задача не в том, чтобы самостоятельно перезапускать каждый проблемный компонент, а в том, чтобы дать HAProxy более точную информацию о состоянии backend-узла.

RX-health-agent работает непосредственно на backend-узлах, выполняет локальные и сетевые проверки, объединяет результаты и передает итоговое состояние HAProxy через механизм agent-check.

В результате балансировщик получает не только сигнал «сервер доступен или недоступен», но и рекомендацию по весу backend-а:

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

Что проверяет health-agent

В версии v0 реализованы проверки:

• проверка доступности ключевых HTTP endpoint Directum RX;
• проверка /client/api/health;
• проверка /client/health;
• проверка StorageService;
• проверка PreviewService;
• проверка IntegrationService;
• проверка LogService;
• проверка состояния контейнеров Directum RX;
• проверка доступности Docker daemon;
• проверка свободного места на файловой системе;
• проверка inode;
• проверка CPU и load average;
• проверка RAM;
• проверка swap;

Кроме того, агент:

• формирует причину деградации;
• рассчитывает итоговый вес узла;
• поддерживает мягкую деградацию без полного отключения backend-а;
• позволяет вручную перевести узел в maintenance;
• поддерживает режим drain;
• использует recovery window перед полноценным возвратом backend-а в балансировку.

При этом уже сейчас важно четко обозначить границу возможностей это версии.

Health-agent не является системой общего мониторинга и не заменяет HAProxy, Keepalived, Patroni, RabbitMQ или решение «Мониторинг Directum RX». Его задача — максимально быстро принять решение о пригодности конкретного RX backend-а для дальнейшей обработки пользовательского трафика.

Архитектура тестового стенда

Для разработки и тестирования проекта развернут отдельный стенд Directum RX 26.1 на РЕД ОС 8.

В составе стенда для первой версии агента используются следующие группы узлов.

Для кластера балансировки используются два HAProxy-узла и Keepalived. Пользовательский трафик поступает на виртуальный IP и далее распределяется между backend-узлами Directum RX.

Для взаимодействия HAProxy с health-agent используется TCP-порт 9505.

Кто за что отвечает

В текущей архитектуре важно не смешивать функции 3-х компонентов.

rx-health-agent

Агент работает в контексте backend-узла Directum RX и оценивает:

· состояние самого RX;

· состояние контейнерной среды;

· ресурсы операционной системы.

Результатом становится агрегированное состояние узла, например 100%, 75% или 50%, down, maint или drain.

HAProxy

HAProxy выполняет две проверки:

· штатный HTTP health-check конкретного сервиса Directum RX;

· получение дополнительного состояния backend-а через agent-check.

Именно HAProxy принимает окончательное решение о доступности узла и его весе в балансировке.

Keepalived

Keepalived отвечает не за отдельный backend Directum RX, а за доступность самого слоя балансировки. Если первый HAProxy-узел перестает выполнять свою функцию, Keepalived должен переключить виртуальный IP на второй HAProxy.

Проверку состояния HAProxy и Keepalived не следует смешивать с проверками RX health-agent. Для балансировщиков планируется отдельный локальный механизм.

Как устроена версия v0

Health-agent устанавливается непосредственно на backend-узлы Directum RX. В тестовом контуре это dev-ddc-rx261a и dev-ddc-rx261b. Для взаимодействия с HAProxy используется TCP-порт 9505.

Состав файлов

Основной сценарий агента располагается в:

Конфигурационный файл:

Текущее состояние агента сохраняется в:

Для административного управления backend-узлом дополнительно используются marker-файлы:

Режимы maintenance, drain и механизм recovery уже входят в возможности Bash-версии v0.

В конфигурации задаются проверяемые endpoint-ы Directum RX, допустимые HTTP-коды, таймауты, пороги ресурсов операционной системы и параметры инфраструктурных проверок.

Для Client API используется endpoint:

с ожидаемым HTTP-кодом 200.

Отдельные warning- и critical-пороги предусмотрены для диска, inode, CPU/load average, RAM и swap.

Основная логика v0 реализована на Bash. За один вызов агент выполняет проверки, определяет найденные проблемы и формирует итоговое решение для HAProxy. Затем результат передается через systemd socket activation на TCP-порту 9505.

Для подключения к HAProxy используются agent-check и отдельный период проверки agent-inter.

После изменения конфигурации HAProxy она проверяется командой:

После успешной проверки конфигурацию можно применить через:

Политика для сервисов Directum RX

Для разных компонентов используются разные реакции на отказ:

На выходе агент может сформировать несколько состояний.

Client API, Web Client и StorageService считаются критичными. Если проверка одного из них не проходит, backend исключается из балансировки.

PreviewService и IntegrationService переводят узел в состояние с весом 50%, а LogService — с весом 75%. Пользовательский трафик продолжает обслуживаться обоими серверами, но HAProxy отдает предпочтение полностью исправному backend-у.

Административные режимы

Для планового вывода узла используется режим maintenance:

После этого агент возвращает состояние maint, а HAProxy переводит backend в MAINT.

После окончания работ marker-файл удаляется:

Для более мягкого вывода используется режим drain:

touch /var/lib/rx-health-agent/drain

В этом случае агент возвращает drain, а HAProxy не должен направлять на backend новые обычные запросы.

После окончания работ файл также удаляется:

В v0 предусмотрен и recovery window. После состояния down агент не сразу возвращает backend к полной нагрузке. Сначала узел проходит переходное состояние восстановления, после чего возвращается к рабочему весу.

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

Пример мягкого вывода с помощью drain

Пример мягкого вывода с помощью recovery window

Как проверять работу

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

Сценарий 1: Высокая загрузка CPU

Приложение может продолжать отвечать HTTP 200, хотя сервер уже находится под высокой нагрузкой. Для теста на RX-узле создается CPU-нагрузка:

Агент контролирует load average и при превышении warning-порога уменьшает вес backend-а.

Ожидаемый результат:

При этом первый сервер не переводится в DOWN: он продолжает работать, но HAProxy начинает отдавать предпочтение второму backend-у.

HAProxy Stats во время CPU-теста

Сценарий 2: Остановка критичного контейнера

Второй сценарий — отказ компонента, без которого RX backend уже нельзя считать нормально работоспособным.

На одном из RX-узлов останавливаем нужный критичный контейнер:

Его состояние можно проверить командой:

Если контейнер Web Client или другого критичного компонента переходит в Exited либо другое проблемное состояние, соответствующий health-check перестает проходить. Backend переводится в down, а трафик продолжает обслуживаться вторым RX-узлом.

Ожидаемое состояние:

HAProxy Stats после остановки контейнера веб-сервера

После завершения теста контейнер запускается обратно:

После успешных проверок и прохождения recovery window backend возвращается в балансировку.

Сценарий 3: Отказ PreviewService

Не каждый отказ должен приводить к полному отключению узла. Для PreviewService используется endpoint:

Если проверка перестает проходить, backend не переводится в down. Вместо этого агент уменьшает его вес до 50%:

Оба сервера продолжают обслуживать трафик, но HAProxy отдает предпочтение полностью исправному backend-у.

Почему для v0 выбрали Bash

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

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

· HTTP-проверки выполняются через curl;

· состояние файловой системы получают через df;

· сведения о памяти — через free;

· load average — из /proc;

· состояние контейнеров — командами Docker.

Bash-агент не требует тяжелого runtime и может быть размещен непосредственно на RX-узле. Сценарий легко изменить, проверить через bash -n, выполнить на сервере и сопоставить результат с состоянием HAProxy.

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

Что планируется дальше

В следующих версиях планируется:

· развить более глубокую диагностику RabbitMQ и PostgreSQL;

· учитывать время ответа сервисов;

· анализировать HTTP-ошибки за временной интервал;

· хранить историю состояний;

· улучшить защиту от частого изменения веса;

· реализовать полноценную проверку очередей RabbitMQ и SQL-проверка PostgreSQL;

· рассчитывать p95/p99 времени ответа HTTP-сервисов.

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

Наши рекомендации

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

Главное, что стоит проверить до смены модели в коде: ставка за токен осталась как у GPT-Image-2.5, но калькулятор в документации OpenAI умножает число выходных токенов у 2.6 на 4,2 при quality=low и на 3,3 при medium — картинка 1024x1024 на low дорожает с $0,0059 до $0,0247. Кроме того, у новых моделей нет Batch API и датированного снапшота. Ниже — что изменилось, как OpenAI мерила скорость, сколько стоит картинка у конкурентов и что делать тем, кто сидит на 2.5.

• Images 2.6 доступна с 4 ноября в ChatGPT и Codex на всех тарифах; в API — gpt-image-2.6-flare и gpt-image-2.6-sunburst.
• OpenAI заявляет генерацию «на 50% быстрее»; в демо компании Flare на quality=low уложилась в 4,84 с против 7,08 с у 2.5 Flare — это 46% прироста скорости.
• Ставки за токен те же, что у 2.5 ($8 за 1 млн входных и $30 за 1 млн выходных токенов изображения), но по калькулятору OpenAI картинка 1024x1024 на quality=low стоит $0,0247 против $0,0059 у 2.5 (в 4,2 раза), на medium — $0,0435 против $0,0132 (в 3,3 раза); high и выше без изменений.
• В API добавили GIF (2–16 кадров), SVG, разметку правок и параметр complexity (low, medium, high; по умолчанию high).
• Batch API и датированного снапшота у 2.6 пока нет; в России ChatGPT и API OpenAI официально недоступны.

Что именно ускорилось и как это мерили

В анонсе OpenAI пишет, что Images 2.6 «генерирует изображения на 50% быстрее, чем раньше» (перевод редакции). Методику компания не раскрывает: ни набора промптов, ни режима качества, ни того, по какой метрике считались проценты. Единственный замер, который опубликовала сама компания, — демо-ролик в том же анонсе: одна и та же задача (реклама путешествий, «Luxury Travel Ad») на quality=low у GPT-Image-2.5 Flare занял 7,08 с, у GPT-Image-2.6 Flare — 4,84 с. Таймеры, как подписано в ролике, показывают реальное время API-запроса при ускоренном воспроизведении.

Эти два числа дают 46% прироста скорости (7,08 / 4,84), как и написано на самом ролике, или сокращение времени ожидания на 32%. Это один пример, а не бенчмарк, и он не подтверждает ровно «50%» для любого запроса. В документации OpenAI отдельно предупреждает, что сложные промпты по-прежнему могут обрабатываться до 2 минут.

Flare и Sunburst — две модели одной версии с разным назначением, по описанию OpenAI. Flare рассчитана на быстрые итерации: при quality=low она «может генерировать изображения всего за шесть секунд», а ещё, по словам компании, лучше верстает постеры и продуктовые картинки. Sunburst — для детальной работы: при quality=medium и high она даёт более высокое качество и лучше сохраняет детали между правками. Из этого позиционирования, по нашей оценке, следует простое правило: черновики и перебор вариантов — Flare на low; финальные картинки, где важны текст, композиция и повторяемость персонажа или продукта от правки к правке, — Sunburst на medium или high. Независимого сравнения двух моделей на одинаковой выборке пока нет.

Что нового в API: GIF, SVG, разметка и complexity

Все четыре новшества описаны в руководстве по генерации изображений. Анимированный GIF запрашивается через POST /v1/images/generations с output_format: "gif"; движение и зацикливание описываются в промпте. Параметры: frame_count от 2 до 16 кадров (по умолчанию 9) и frame_duration_ms от 20 до 2000 мс на кадр (по умолчанию 200). GIF не поддерживает стриминг и частичные изображения, а эндпоинт правок GIF не возвращает. В ChatGPT ту же функцию подают как анимацию маскота, персонажа или простого наброска.

SVG включается через output_format: "svg" на том же эндпоинте генерации, обязательно с n: 1. Модель сначала рисует растровый референс (его качество задаёт quality), а затем языковая модель пишет по нему векторный файл — поэтому в ответе приходит base64 с UTF-8 XML, который надо сохранить как .svg. Документ статичный: без скриптов, внешних ресурсов и встроенного растра. Правки в SVG не поддерживаются, и SVG нельзя подать на вход эндпоинту правок. Платится и растровый референс по ставке модели изображений, и токены языковой модели, которая пишет векторный код.

Разметка правок (image markup) пришла в API из ChatGPT: к запросу POST /v1/images/edits прикладывается отдельный прозрачный PNG того же размера, что исходник, с кружками или штрихами там, где нужна правка, а описание самой правки идёт в prompt. Пример из документации OpenAI — перекрасить вазу, обведённую красным кружком:

Параметр complexity управляет тем, «сколько модель планирует перед рендером»: значения low, medium и high, отдельной платы за него нет. Низкий уровень подходит для точечных правок вроде замены фона или вывески, высокий помогает с плотным текстом, сложной вёрсткой и взаимным расположением объектов, но, по предупреждению OpenAI, увеличивает задержку и может внести нежелательные изменения. Важная деталь: если параметр не указан, обе модели работают на high. В анонсе компания советует для большинства правок ставить complexity=low, а качество подбирать под задачу. Это два независимых параметра: quality отвечает за рендер, complexity — за планирование.

Запрос выше собран из полей документации OpenAI: complexity задан явно, чтобы не использовать high по умолчанию, а quality=low выбран для примера. Ответ сначала сохраняется в файл, чтобы посмотреть поле usage — именно по нему видно, сколько токенов ушло на картинку.

Сколько стоит картинка у OpenAI и конкурентов

По прайсу OpenAI на 5 ноября 2026 года обе модели 2.6 стоят ровно столько же, сколько 2.5 Flare и Sunburst: $8 за 1 млн входных токенов изображения, $30 за 1 млн выходных, $2 за кэшированный вход; текстовый вход — $5 за 1 млн токенов. Но ставка за токен и цена картинки — разные вещи. Калькулятор в той же документации для GPT-Image-2.6 на quality=low и размере 1024x1024 показывает 823 выходных токена ($0,0247), тогда как для 2.5 при тех же настройках — 196 токенов ($0,0059). Редакция посмотрела код калькулятора: для модели 2.6 он умножает расчётное число токенов на фиксированные коэффициенты — 4,2 для low, 3,3 для medium и 1 для high, xhigh и max. На medium выходит 1449 токенов ($0,0435) против 439 ($0,0132) у 2.5, на high — 1756 токенов ($0,0527) у обеих версий. В прайсе и анонсе OpenAI об этом не говорится ни слова; объяснения, почему дешёвые режимы стали дороже, компания не дала.

Для сравнения взяты официальные прайсы на ту же дату. Google в прайсе Gemini API считает картинку 1K у Nano Banana 2.1 как 1120 токенов по $30 за миллион — $0,0336; у Gemini 3.1 Flash Image (Nano Banana 2) те же 1120 токенов стоят $60 за миллион — $0,067; у Gemini 3 Pro Image (Nano Banana Pro) — $0,134 за 1K или 2K; старая Gemini 2.5 Flash Image — $0,039. xAI по таблице моделей берёт за Grok Imagine Image 2.0 от $0,04 за 1K на quality=low до $0,08 за 2K на medium. BytePlus на странице Seedream 5.0 Pro указывает «от $0,045 за изображение», первый референс бесплатно, следующие от $0,003 (рядом на той же странице — скидки для новых клиентов, в сравнении они не учтены). По базовым ставкам за выходную генерацию GPT-Image-2.6 на low дешевле перечисленных конкурентов, а 2.5 на low — ещё в 4 раза дешевле; но качество, тарифные условия и состав счёта у всех различаются, и сравнивать их напрямую можно только после прогона своих промптов.

С реальной стоимостью как раз и возник первый спор. Участник форума разработчиков OpenAI _j (отображаемое имя Jay) опубликовал замер на одном промпте: GPT-Image-2.5 на quality=medium вернула 344 выходных токена, GPT-Image-2.6 на том же medium — 1136. Его вывод (перевод редакции): «quality: low и medium дают существенно больший счёт за выходные токены, чем gpt-image-2.5. Похоже, это сделано исключительно для того, чтобы нельзя было делать дешёвые картинки, — множитель цены, а не алгоритм». По его оценке, low стал дороже в 4,2 раза, medium — в 3,3, high и выше — без изменений. Его замер — один промпт, но коэффициенты совпадают с теми, что зашиты в калькулятор OpenAI, так что это не случайность; сама компания замер не комментировала.

Габриэль Анайя, Go-разработчик и автор блога на DEV Community, обращает внимание на другое ограничение: страница модели 2.6 Flare не поддерживает Batch, а у 2.5 Flare батч есть с выходными токенами по $15 за миллион вместо $30. «Паритет по токенам ещё не значит паритет по картинке» и «батч-задачи пока остаются на 2.5 или gpt-image-2» (перевод редакции). Он же отмечает, что у 2.6 нет датированного снапшота: закрепить версию, как gpt-image-2.5-flare-2026-09-08, нельзя.

Что делать, если вы уже используете GPT-Image-2.5

• Не меняйте идентификатор модели в проде вслепую: если вы генерируете на low или medium, счёт вырастет в 3–4 раза при той же ставке за токен. Прогоните 20–30 своих промптов на 2.5 и 2.6 и сравните output_tokens из поля usage.
• В каждом запросе явно задавайте quality и complexity; без complexity модель планирует на high; для простой правки попробуйте low и сравните задержку и результат.
• Ночные батч-задачи оставьте на gpt-image-2.5-* или gpt-image-2: у 2.6 Batch не заявлен.
• Если вам нужны векторные иконки или короткие лупы из API, 2.6 — пока единственный способ получить SVG и GIF от OpenAI; для SVG ставьте n: 1, для GIF — frame_count не больше 16.
• Параметр user в Images API объявлен устаревшим — передавайте тот же идентификатор как safety_identifier.

Доступность: в ChatGPT и Codex Images 2.6 включена на всех тарифах на вебе, десктопе и в мобильных приложениях. Для API OpenAI может потребовать верификацию организации перед доступом к моделям GPT Image. Россия в списке поддерживаемых стран OpenAI API на 5 ноября 2026 года отсутствует, и в списке стран ChatGPT её тоже нет — официально ни API, ни ChatGPT здесь не предоставляются; из перечисленных в сравнении вендоров ситуация с доступом у каждого своя, и проверять её нужно по официальным страницам.

Контекст: Images 2.6 вышла через 57 дней после даты снапшота GPT-Image-2.5 (8 сентября 2026 года) и почти через год после GPT Image 1.5, где OpenAI сделала ставку на точное редактирование. По данным компании, через ChatGPT, Codex и API сейчас создаётся 4 млрд изображений в неделю — больше полумиллиарда в день. Конкуренты в этом году не стояли на месте: Google выпустила Nano Banana 2, а Nano Banana Pro остаётся самой дорогой моделью в нашем сравнении.

Что редакция проверит дальше: появится ли у 2.6 Batch и датированный снапшот и объяснит ли OpenAI, почему low и medium у новой версии стоят в 3–4 раза дороже при неизменной ставке за токен.

Источники: Introducing Images 2.6 — OpenAI, Image generation — OpenAI API, Pricing — OpenAI API, Supported countries — OpenAI API, Gemini API pricing — Google, Models — xAI docs, Seedream 5.0 Pro — BytePlus, Обсуждение на форуме разработчиков OpenAI, Gabriel Anhaia — DEV Community, Твит OpenAI об анонсе

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

Что такое ITSM-система

ITSM (Information Technology Service Management) — это управление ИТ-услугами, при котором техподдержка работает по сервисной модели. Система выстраивается как единое окно: заявку можно отправить в любую службу. Пользователю не нужно выяснять, кто за что отвечает и как с этим подразделением связаться. Он просто выбирает в цифровом каталоге нужный сервис и получает ответ в этом же интерфейсе. С помощью такого ПО можно заказать смену пароля, ремонт техники, диагностику программ, заказ оборудования и др.

5 ключевых ITSM-процессов

1. Управление инцидентами

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

2. Управление проблемами

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

3. Управление изменениями

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

4. Управление активами

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

5. Управление знаниями

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

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

На что обратить внимание при выборе ITSM-системы

Отечественная разработка

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

Гибкая настройка

С помощью no-code легко адаптировать систему под процессы компании. Для этого не обязательно разбираться в программировании. Изменился процесс — ответственный настраивает новую логику в визуальном редакторе, быстро тестирует и запускает в эксплуатацию буквально через пару часов.

Масштабируемость

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

Удобный интерфейс

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

Искусственный интеллект

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

Экосистемность

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

Обзор российских ITSM-систем

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

Directum ESM

Преимущества

• 100% корпоративных сервисов

Система подходит для управления ИТ-услугами и любыми другими: HR, административными, бухгалтерскими, юридическими, маркетинговыми.

• Быстрый старт

Большое количество услуг преднастроено и готово для работы сразу. Компании проводят настройку самостоятельно за 3-4 недели благодаря no-code и дружелюбному интерфейсу.

• Широкие интеграционные возможности

Directum ESM имеет открытый API и интеграционный сервис для настройки взаимодействия с ERP, MDM, CRM. Есть прямая интеграция с 1С.

• No-code-настройка

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

• Активное развитие

Новые релизы выходят каждые 3–4 месяца и с фокусом на практические задачи: контроль SLA, аналитику для руководителей, удобство для пользователей.

• Экосистемность

Входит в экосистему решений Directum и бесшовно работает с КЭДО, СЭД, супераппом для мобильного доступа.

• Гибкая установка

Доступны варианты: Cloud (SaaS) и On-premise.

Недостатки

• «свежий» продукт именно в готовом «коробочном» виде. Но вендор разрабатывает подобные решения под заказ уже много лет;
• дискаверинг и мониторинг только через интеграцию со специализированными системами;
• захват обращений только через электронную почту и портал самообслуживания. Если нужно подхватывать обращения с IP-телефонии, то необходимо интегрироваться через открытый API;
• для постройки индивидуального дашборда нужна модификация или выгрузка в BI-систему.

NAUMEN

Преимущества

• Единая платформа для управления процессами

Можно оцифровать широкий спектр процессов управления в рамках сервисного подхода. Закрывает более 15 корпоративных процессов.

• Бесплатный портал самообслуживания

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

• Широкие интеграционные возможности

Через базовые коннекторы интегрируется со всеми основными корпоративными приложениями. Функциональность REST API предполагает связку со всеми современными сервисами: Jira, Google Maps и др.

• Персонализация интерфейсов и данных

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

• Прозрачная лицензионная политика

Решение лицензируется как All-in-One, серверные и пользовательские лицензии по процессам не нужны.

• Активное развитие решения

Новые релизы выходят каждые 5–6 месяцев.

• Экосистемность

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

• Гибкая установка

Доступны варианты: Cloud (SaaS) и On-premise.

Недостатки

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

SimpleOne

Преимущества

• Настройка с низким кодом

Low-code-платформа с большими возможностями кастомизации. Можно создавать и адаптировать процессы без программирования.

• Масштабируемость на другие подразделения

Инструменты системы подходят для всех подразделений (бухгалтерия, HR и др.), есть возможность бесшовной интеграции сервисных процессов.

• Множество поставщиков услуг

Компании могут назначать исполнителями любые отделы и департаменты (бухгалтерию, HR, АХО) и управлять их портфелями услуг в единой системе.

• Оперативная аналитика и отчетность

В доступе дашборды, drill-down-отчеты и интеграция с BI-системами (Yandex DataLens). Оценка SLA и эффективности процессов с актуальной аналитикой.

• Высокая производительность

Платформа стабильно работает с большими объемами данных и тысячами одновременных пользователей.

• Экосистемность

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

• Гибкая установка

Доступны варианты: Cloud (SaaS) и On-premise.

Недостатки

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

ELMA365

Преимущества

• Быстрая поставка

Преднастроенная система включает все необходимые ITSM-процессы для быстрого внедрения.

• Надежность и производительность решения

Система успешно прошла независимый аудит ICL Services на соответствие ключевым практикам ITIL.

• No-code / Low-code-настройка

С помощью встроенного Low-code/BPM-движка можно адаптировать систему под уникальные бизнес-процессы без программирования.

• Развитие

Новые релизы выходят регулярно.

• Гибкая установка

Доступны варианты: Cloud (SaaS) и On-premises.

• Экосистемность

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

Дополнительные потребности закрываются через Low-code-настройку.

Недостатки

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

1С:ITILIUM

Преимущества

• Скорость поставки

Вендор обещает запуск системы за 14 дней. Многие клиенты это подтверждают.

• Надежность и производительность

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

• No-code / Low-code-настройка

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

• Развитие

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

• Гибкая установка

Доступны варианты: локальная установка (On-premises). Решение может работать в полностью импортозамещенной архитектуре на базе Astra Linux и СУБД Postgres.

• Экосистемность

Система помогает управлять ИТ-услугами, а также сервисами в других департаментах, например HR, АХО. Можно настроить интеграцию с другими продуктами 1С.

Недостатки

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

ITSM 365

Преимущества

•  Быстрая поставка

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

•  Low-code-настройка

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

•  Развитие

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

•  Экосистемность

Продукт бесшовно интегрируется с продуктами для подбора персонала и управления проектами.

• Гибкая установка

Доступны варианты: Cloud (SaaS) и On-premise.

Недостатки

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

Сравнение ITSM-систем

Сравнительная таблица российских ITSM-систем

Как развиваются ITSM-системы: тренды 2026-27

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

ГенИИ в поддержке

Развитие генеративного ИИ открывает дополнительные перспективы для цифровизации управления сервисами. Некоторые эксперты даже предлагают термин AISM (AI Service Management) для описания этой концепции. Применение ГенИИ меняет традиционные процессы ITSM.

Управление проблемами

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

Управление знаниями

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

Служба поддержки

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

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

Управление ИИ и контроль за безопасностью (AI Governance)

По результатам опроса, 42% компаний уже применяют искусственный интеллект в поддержке. Рост популярности таких технологий и расширение сфер их использования требуют более строгого контроля за корректностью, безопасностью и этичностью ИИ. Во многих странах формируется законодательство в этой области. Так, в 2024 году приняли Европейский акт об ИИ (EU AI Act), а в августе 2025 года его дополнили нормами для моделей ИИ общего назначения (GPAI).

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

Управление сервисами на уровне всей компании

Исследования 2025-2026 гг. показывают, что рынок ESM в 3 раза больше, чем ITSM. Тренд будет набирать обороты, и в ближайшем будущем CAGR (среднегодовой темп прироста) ESM-рынка достигнет 18-20%. Поэтому в выигрыше будут те компании, которые внедряют системы, изначально заточенные под широкий список корпоративных сервисов, а не только ИТ.

Эволюция пользовательского опыта

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

В управлении сервисами происходит смена приоритетов. Кроме технического SLA, с помощью которого фиксируют время отклика и решения обращения, эксперты предлагают измерять и XLA (Experience Level Agreement) — взаимодействие и уровень удовлетворенности. Формальное соблюдение регламентов больше не гарантирует успех. Именно глубокий анализ пользовательского опыта (XLA) помогает повысить лояльность и найти слабые места в процессах обслуживания.

Рост влияния информационной безопасности (ИБ)

Наблюдается тенденция к объединению ITSM/ESM-систем с решениями класса IAM (Identity and Access Management) для гибкого управления правами доступа. Набирает обороты модель Security-as-a-Service, при которой сервисы ИБ становятся частью общего каталога услуг.

Активно внедряется автоматическая генерация отчетности, чтобы четче соблюдать регуляторные требования. Расширяется и управление уязвимостями: запросы из систем сканирования (Tenable, Qualys) превращаются в задачи ESM с приоритетом на основе оценки риска (CVSS) и контролируются вплоть до устранения.

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

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

Так появился проект SkyPackages. За два дня я выпустил 30+ библиотек. С единым API, с тестами, с поддержкой русского языка там где это нужно.

Что внутри

Две группы пакетов.

Первая закрывает то, что мировые аналоги не решают вообще. ИНН, ОГРН, СНИЛС, КПП, БИК, расчётные счета. Производственный календарь РФ с праздниками и рабочими днями. Склонение числительных. Транслитерация по ГОСТ. Телефоны с определением оператора. Карты МИР. Всё это есть в открытом доступе по частям, но собрать в одном месте с нормальными тестами никто не удосужился.

Вторая группа это обычные утилиты, которых не хватает в стандартных библиотеках. Безопасный парсинг JSON с лимитами. Криптография на AES-256 и PBKDF2. Генерация UUID v7, ULID, NanoID. Cron с вычислением следующего запуска. Semver. Расстояние Левенштейна.

Каждый пакет существует в трёх версиях сразу. Для Python, для npm и для SkyForge.

Про автоматизацию

Обычно поддерживать три кодовые базы это боль. Три набора тестов. Три пайплайна публикации. Три раза руками заливать релизы на GitHub. Я потратил полдня и написал скрипт builder.py, который делает всё за меня.

Что делает скрипт при запуске. Генерирует файлы для всех трёх экосистем. Ставит зависимости и прогоняет тесты через pytest, vitest и SkyForge check. Собирает wheel, tgz и zip. Создаёт релизы на GitHub через API. Создаёт или обновляет репозитории для SkyForge. Правит index.html прямо в репозитории, без git. Дёргает деплой на Render.

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

Примеры

Python. Импортируем модули валидации и производственного календаря:

from sky_validate_ru import inn, snils

from sky_datetime_ru import add_working_days

from datetime import date

inn.is_valid("7707083893")

snils.format("11223344595")

add_working_days(date(2026, 12, 31), 1)

Первая строка вернёт True. Вторая вернёт строку "112-233-445 95". Третья вернёт 9 января 2026 года, потому что декабрьские праздники перескакивают.

TypeScript. Импортируем генератор ID и форматер телефонов:

import { uuidV7 } from "@skypackages/id";

import { formatPhone } from "@skypackages/phone-ru";

uuidV7();

formatPhone("+79991234567");

Первая строка вернёт UUID v7 вроде "018f4a3e-...". Вторая вернёт "+7 (999) 123-45-67".

SkyForge. Подтягиваем пакет и вызываем функцию:

пусть v = подтянуть "skyforge-validate-ru"

лог(v.инн_валиден("7707083893"))

В консоль выведется истина.

Цифры

30 уникальных библиотек. 90 релизов, по три на каждую. Три экосистемы. Покрытие тестами сто процентов. Первое место в лидерборде SkyForge. Большинство пакетов без внешних зависимостей.

Проект независимый, не принадлежит никакой компании. Всё open-source. Ставится одной командой с GitHub Releases, без регистрации в реестрах.

Что понял по ходу

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

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

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

Ссылки

GitHub: github.com/skytech-alt/SkyPackages

Сайт: skypackages.onrender.com

Буду рад фидбэку. Если знаете какая ещё библиотека нужна, пишите в комментариях или открывайте issue на GitHub.

В каталоге уже сейчас доступны для инференса Qwen3.8-27B, DeepSeek-V4-Flash-0731, Qwen3.6-35B-A3B, а также OCR и text-to-speech модели: Unlimited-OCR, PaddleOCR-VL-1.6, whisper-v3-large и другие модели. Архитектура сервиса автоматически распределяет нагрузку: компактные модели работают на ускорителях уровня A2, а тяжелые решения, такие как DeepSeek-V4-Flash-0731, запускаются на серверах со связкой до восьми GPU NVIDIA H200.

Публичные эндпоинты с оплатой за токены — это готовое решение для быстрого инференса и прямой интеграции в рабочие сервисы. Разработчики могут сразу использовать API, не отвлекаясь на поддержку собственной инфраструктуры. При этом эндпоинты остаются удобным инструментом для быстрой оценки качества генерации, проверки tool calling и сборки прототипа. Если бизнес-задача требует изолированного контура, приватности данных или запуска кастомной модели, наработанный код и промпты можно без изменений мигрировать на частный эндпоинты immers.cloud с посекундной тарификацией.

«Использование искусственного интеллекта с каждым днем становится все более повседневным и привычным. Пользователи взаимодействует с большими языковыми моделями очень по-разному. И как правило, это зависит от навыков и потребностей: для кого-то достаточно ответов модели в чате; кто-то автоматизирует рабочие процессы и разработку через популярные фреймворки или агентов; стартапам и крупным компаниям, разрабатывающим продукты на основе ИИ, часто требуется не только LLM, но и надежная инфраструктура для инференса. Нашей команде известны все эти сценарии, и развивая сервис Immers Foundation Models мы стремимся сделать так, чтобы каждый шаг на пути к фантастическим возможностям ИИ был для наших клиентов максимально простым, быстрым и доступным.» — Павел Самойлов, руководитель направления по ИИ.

immers.cloud — облачный сервис для аренды серверов с GPU NVIDIA. Платформа предоставляет инфраструктуру с посекундной тарификацией и быстрым онбордингом для обучения нейросетей, инференса LLM, 3D-рендеринга и обработки видео.

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

Функциональные флаги (feature flags, feature toggles) позволяют разработчикам включать и отключать функции приложения, но при этом не требуют повторно собирать и развёртывать код. Благодаря флагам в CI/CD можно чётко отделить друг от друга этапы «развёртывания» (доставки результатов разработки и сборки) и «релиза» (запуска новой функциональности для пользователей). Для чего и как именно это делается — разберём в этой статье.

Что такое функциональный флаг

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

Ниже приведён пример JSON, который получает приложение. Оно проверяет геотег пользователя, и если пользователь из Москвы, то значение флага возвращает true и в итоге отображается виджет погоды. Для пользователей из других городов значение флага принимает default_variant: "disabled", и виджет для них не показывается.

Функциональные флаги могут использоваться в разных сценариях — приведём основные с парой примеров:

• Повышение надёжности системы: отключение рекомендаций при высокой нагрузке, переключение на резервный платёжный шлюз при сбоях в основном.
• Обучение через продуктовые эксперименты и A/B-тестирование: сравнение двух вариантов страницы регистрации, тестирование двух видов кнопки «Купить».
• Управление доступом по тарифам и подпискам: экспорт отчётов только для пользователей Pro, расширенные настройки только для корпоративных клиентов.
• Сезонные и временные функции: промокоды на «чёрную пятницу», приём работ для конкурса.
• Аварийные выключатели (kill switches): отключение медиаплеера из-за ошибок, удаление неверно настроенного способа оплаты.

Далее рассмотрим основные типы флагов.

Типы флагов

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

По механизму работы: статические и динамические флаги

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

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

Статические флаги задаются через переменные окружения (.env), конфиг-файлы (config.json) или внешние сервисы конфигурации (Consul).

Пример в .env:

Пример в виде конфиг-файла:

Использование в коде:

Плюсы: простота, нулевые сетевые задержки, предсказуемость, безопасность (нет внешних вызовов в runtime).

Минусы: невозможность изменить поведение «на лету» — требуется пересборка/перезапуск.

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

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

В примере ниже — два флага. Первый проверяет, попадает ли пользователь в сегмент для тестирования нового способа оформления заказа: берутся только 25 % пользователей сервиса; также они должны входить в группы "beta_testers", "premium_users" и быть из России, Беларуси или Казахстана. Второй флаг показывает, что ИИ-рекомендации при заказах пока отключены для всех пользователей, но в нужный момент это можно изменить даже во время работы приложения.

Пример конфигурации:

Использование в коде:

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

Минусы: усложнение логики системы (flag debt), дополнительная задержка при запросе состояния флага и зависимость от внешних систем.

Сведём сравнение типов флагов в небольшую таблицу:

По цели применения: релизные, экспериментальные, операционные и разрешающие флаги

Релизные флаги (release flags) позволяют отделить развёртывание от релиза, то есть экспериментальная/незаконченная фича вливается в основную ветку и развёртывается вместе с остальным кодом, но остаётся выключенной до официального релиза. Если после релиза что-то пойдёт не так, флаг можно сразу же отключить, не делая новый релиз и не откатывая приложение. Когда новая функциональность начинает работать стабильно, релизный флаг удаляют.

Например, код нового платёжного шлюза уже в продакшене, но флаг пока enabled: false. Флаг включат 1 ноября, и фича станет доступной всем. Если с платежами возникнут проблемы, флаг сразу же отключат без отката деплоя.

Экспериментальные флаги (experiment flags) — это инструмент для A/B-тестов и проверки гипотез. Они позволяют показать разные новые варианты новой функции разным пользователям (или показать новую функциональность только ограниченной лояльной группе пользователей), чтобы изучить их реакцию и на её основе сделать вывод о новой фиче. По окончании A/B-теста экспериментальный код и флаг удаляют.

В примере ниже команда интернет-магазина проводит тест, чтобы выбрать подходящий цвет для кнопки «Оформить заказ» в корзине. Выборка из 30 % пользователей распределяется случайным образом: 50 % из них видят зелёную кнопку, 25 % — красную, 25 % — оранжевую. Система собирает метрики: конверсию и отказ от корзины. Через две недели становится ясно, что оранжевая кнопка даёт +15 % к конверсии, поэтому её делают основной, а флаг и экспериментальный код удаляют.

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

Операционные флаги зачастую не удаляют и оставляют в системе.

Рассмотрим следующий пример. В «чёрную пятницу» нагрузка в приложении интернет магазина растёт, утилизация CPU превышает 85 %. Из-за этого отключаются ИИ-рекомендации (на ресурсоёмкой ML-модели) и включаются обычные статические. После того как нагрузка снижается, флаг возвращается в исходное состояние.

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

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

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

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

Далее рассмотрим, какие существуют инструменты для управления функциональными флагами.

Системы управления флагами

Глобально все решения для управления флагами делятся на три категории: проприетарные, Open Source и собственные разработки.

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

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

• LaunchDarkly позволяет включать функционал для конкретных сегментов аудитории с высокой гранулярностью, то есть подходит для детального таргетинга пользователей и маркетинговых экспериментов. Платформа даёт enterprise-уровень надёжности и позволяет гибко управлять жизненным циклом флагов.
• ConfigCat обеспечивает единую точку управления, если инфраструктура состоит из разнородных технологий (веб, мобильные приложения, бэкенд на разных языках).
• Harness интегрирует управление флагами прямо в CI/CD-процессы. Предоставляет командам детальную аналитику о влиянии флагов на производительность и стабильность системы прямо в пайплайне развёртывания.

Open Source-решения дают полный контроль над кодом и данными и позволяют развёртывать систему на своих серверах (on-premise), что критично для организаций со строгими требованиями к безопасности.

Вот пара примеров Open Source-платформ для управления флагами:

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

Собственная разработка тоже возможна, но требует значительных ресурсов. На ранних этапах разработки продукта или при тестировании гипотез внедрения флагов можно использовать переменные окружения, JSON-файлы или простой API-сервис. Но по мере роста продукта поддерживать собственное решение становится всё сложнее: нужно обеспечивать отказоустойчивость, безопасность и разработку SDK для всех языков программирования в проекте. Так что переход на специализированный инструмент (Open Source или SaaS) — обычно вопрос времени.

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

Теперь посмотрим, какую роль функциональные флаги играют в CI/CD.

Функциональные флаги в CI/CD

Флаги фундаментально меняют подход к управлению исходным кодом, особенно если используется модель ветвления Trunk Based Development (TBD).

При TBD в основную ветку (main/trunk) часто вливаются изменения. Функциональные флаги позволяют разработчикам интегрировать и развёртывать фичи, которые ещё не готовы к релизу, и при этом не рисковать стабильностью всего приложения. Благодаря флагам быстрее внедряются изменения и упрощается слияние, так как весь код (и основной, и разрабатываемый) остаётся в одной ветке. Это предотвращает конфликты слияния (merge hell), которые часто случаются при долгоживущих ветках.

Флаги улучшают управление рисками, а именно:

• дают возможность выключить функциональность сразу после релиза, если она работает неправильно, — благодаря этому система быстрее восстанавливается (MTTR);
• позволяют включать фичу поэтапно, делать canary/rollout, быстро откатывать поведение через переключатель и не ждать новой сборки для исправления проблемы.

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

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

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

Отдельные наборы тестов могут быть полезны, когда состояния флагов фиксированы в разных окружениях (например, staging и production) или когда предпочтительнее запускать тесты по отдельности.

Допустим, мы готовим новую версию приложения и до того, как выпустить её в продакшен, тестируем релиз-кандидата в окружении staging. CI/CD-пайплайн собрал образ release-candidate и развернул его в staging. При запуске приложения запрашивается набор флагов из централизованной системы управления флагами. Далее при запуске автотестов подбирается набор тест-кейсов для заданного окружения. Также подбирается набор флагов для конкретного пользователя после того, как его логин и user id считаются из cookie во время запроса.

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

Ниже подробнее рассмотрим сценарий тестирования релиз-кандидата.

Сценарий тестирования релиз-кандидата с применением функциональных флагов

Сценарий состоит из следующих шагов:

1. CI/CD-пайплайн собирает образ release-candidate и деплоит в staging.
2. При запуске приложения запрашиваются флаги из Flagsmith с параметрами environment=staging, user_id, role.
3. Система флагов возвращает конфигурацию: какие флаги включены и какие тест-кейсы нужно выполнить.
4. Автотесты динамически фильтруют тесты на основе полученного ответа. Тесты, которые не относятся к активным функциям текущего окружения, не запускаются.

Все флаги хранятся в системе управления флагами Flagsmith в формате JSON.

Здесь описан флаг new_payment_flow — он управляет новой версией процесса оплаты.

В нашем примере функция включена в staging и выключена в production.

Помимо самого состояния флага, конфигурация содержит список тестов для каждого окружения. Для staging предусмотрены три проверки:

• успешная оплата;
• обработка ошибки;
• обработка тайм-аута.

Для production пока оставлен только тест успешной оплаты.

В config находятся параметры, которые тесты также могут получить из системы флагов. В нашем случае это timeout_ms 5000. Значение тайм-аута не зашито непосредственно в тесте, и его можно изменить через конфигурацию флага.

Автотесты при запуске запрашивают флаги из внешней системы с помощью следующего запроса:

Здесь тестовый раннер сообщает системе флагов контекст, в котором выполняется проверка. В параметре context указаны идентификатор release candidate и источник запроса — autotest_runner.

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

Автотесты используют функциональные флаги, чтобы динамически сформировать определённый тестовый сценарий. Для этого процесс сбора тестов перехватывается через специальную функцию (conftest.py):

Тут pytest находит все тесты, какие есть. Код узнаёт, в каком окружении запускаются тесты, подключается к Flagsmith и получает активные флаги.

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

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

В результате pytest запустит только оставшиеся тесты.

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

Здесь из конфигурации флага new_payment_flow извлекается параметр timeout_ms. В нашей конфигурации его значение было задано — 5000. Если бы оно не было указано, использовалось бы значение по умолчанию — 3000.

Таким образом, CI/CD-пайплайн остаётся универсальным и не содержит отдельной логики вроде «если это такой-то релиз, запусти такие-то тесты». Он запускает один и тот же механизм, а конкретное поведение определяется конфигурацией функциональных флагов.

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

Риски и рекомендации по использованию флагов

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

Основные риски при работе с флагами

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

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

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

Архитектурные рекомендации

Прежде всего, флаги нужно вовремя удалять: можно настроить в CI/CD автоматические уведомления на флаги, которые живут дольше установленного времени, например больше 30 дней. А релизные и экспериментальные флаги лучше удалять сразу после того, как стабилизировалась фича или закончился A/B-тест. У каждого флага должны быть владелец, дата создания и план удаления.

Как мы уже писали выше, флаги — это критическая зависимость, поэтому стоит обезопасить себя от сбоев в системе управления флагами: использовать на стороне приложения fallback-значения (default variants), внедрить локальное кеширование (чтобы пережить кратковременные падения сети), использовать автоотключение (Circuit Breaker) запросов к сервису флагов при множественных таймаутах.

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

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

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

Резюмируем ключевые принципы:

• Временность. Для флагов должен быть чёткий план удаления.
• Прозрачность. У каждого флага должны быть владелец, назначение и срок жизни.
• Отказоустойчивость. Приложение должно работать даже при недоступности сервиса управления флагами.
• Мониторинг. Состояние и использование флагов нужно постоянно отслеживать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Идемпотентность — свойство операции, при котором повторное выполнение приводит к тому же состоянию, что и однократное. Сам ответ при этом может отличаться: повторный DELETE вернёт 404 вместо 200, и метод от этого идемпотентным быть не перестаёт. У HTTP это закреплено на уровне методов: RFC 9110 относит к идемпотентным PUT, DELETE и безопасные методы, а POST идемпотентным по своей природе не является. Бизнес-операции почти всегда отправляют именно через POST.

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

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

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

Запись в базу и отправка в очередь в одну транзакцию не помещаются. Обёртывать сетевой вызов в BEGIN и COMMIT вредно вдвойне: корректности не даёт, а пул соединений выедает.

Transactional outbox решает это одной таблицей: событие пишется в той же транзакции, что и бизнес-запись, а отдельный процесс доставляет его в очередь.

Почему повтор неизбежен

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

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

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

Два способа сделать ручку идемпотентной и один в довесок

Способ первый: ключ идемпотентности

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

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

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

Способ второй: сделать операцию идемпотентной по смыслу

Иногда ключ не нужен вовсе, потому что семантику можно спроектировать идемпотентной с самого начала. Классический пример — PUT /users/42, который задаёт полное представление ресурса: отправьте его дважды, и состояние будет одним и тем же.

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

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

Довесок: оптимистичная блокировка

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

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

Где наивная реализация ключа разваливается

Гонка в проверке

Последовательность «проверить наличие ключа, потом вставить» содержит зазор, в который помещаются оба одновременных повтора: обе стороны видят, что ключа нет, и обе выполняют работу. Резервировать ключ нужно атомарно, через уникальное ограничение базы, условную запись или транзакционный compare-and-set (атомарное сравнение с записью).

Это же относится и к примеру с платежом выше: замена словаря в памяти на Redis гонку не закрывает, пока проверка и вставка остаются двумя отдельными командами. Нужен атомарный примитив резервирования, вроде SET key value NX или INSERT ... ON CONFLICT DO NOTHING.

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

Слепок запроса, а не только ключ

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

Когда тот же ключ приходит с другим слепком, это ошибка на стороне клиента, и отдавать ему старый результат нельзя. Разбор проектирования идемпотентных ручек предлагает отвечать 409 Conflict; автор практического руководства в этом случае возвращает 422. Важно, чтобы выбранный код был задокументирован и никогда не подменяется молчаливой отдачей чужого ответа.

Состояния и коды ответа

Минимальная модель состояний записи выглядит так: PROCESSING, SUCCEEDED, FAILED_RETRYABLE и FAILED_FINAL. Рядом хранятся ключ операции, слепок, отметки времени, идентификатор решения, снимок ответа и версия политики. Клиенту нужна детерминированная карта из состояния в код ответа:

• 201 или 200 — первый успешно завершённый результат.
• 200 с явной пометкой о повторе — проигрывание сохранённого ответа.
• 202 со ссылкой на статус — работу уже выполняет другой обработчик, начинать вторую не нужно.
• 409 — ключ переиспользован с другим содержимым.
• Задокументированная финальная ошибка — обработка провалилась, и автоматическое продолжение небезопасно.

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

Вторая половина задачи: база и очередь

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

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

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

Почему обернуть это в транзакцию нельзя

Соблазнительный и заведомо неверный вариант выглядит так:

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

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

Outbox: событие как строка в той же транзакции

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

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

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

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

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

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

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

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

Настройки продюсера и подтверждения брокера снижают количество повторов, но не снимают с приложения ответственность за однократность бизнес-эффекта.

Что добавить перед продакшеном

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поддержка inotify появилась в ядре и стандартной библиотеке libc. Приложения могут получать уведомления об изменениях в файловой системе, не открывая каждый отслеживаемый файл. Это упрощает перенос программ, которые используют такой API в Linux; речь о совместимости исходников, а не о гарантированном запуске готовых Linux-приложений.

Для Clang изменили выбор линкера по умолчанию: теперь используется ld.lld вместо поиска линкера по имени ld. В math.h также стали доступны тригонометрические функции стандарта C23 с множителем π, в том числе sinpi и cospi.

Изменения затронули и командную строку. Утилита pwd по умолчанию работает в режиме -L, а не -P, как требует POSIX: при выводе пути сохраняются символические ссылки. Размер истории sh по умолчанию увеличили со 100 до 128 записей. Эти и другие изменения перечислены в примечаниях к выпуску.

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

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

Пагинация — это способ отдать большую коллекцию по частям. Вариантов ровно два. Offset-пагинация просит базу пропустить N строк и вернуть следующие двадцать. Курсорная (её же называют keyset) запоминает последнюю отданную запись и просит всё, что идёт после неё.

Стоимость OFFSET растёт линейно: на таблице в 1,2 млн строк выборка со смещением в миллион занимает 2,4 с против 3 мс у курсора.

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

Курсор не поддерживает переход на произвольную страницу, поэтому для админок и таблиц с кнопкой «страница 47» offset остаётся правильным выбором.

Лимиты запросов на счётчике в памяти инстанса не работают: при десяти инстансах настроенные 100 запросов в минуту превращаются в 1000.

Скользящее окно на сортированном множестве Redis и атомарном Lua-скрипте занимает пятнадцать строк и снимает гонку без распределённых блокировок.

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

Offset ломается двумя разными способами

Про первый знают почти все, про второй вспоминают уже после инцидента.

Он линейно замедляется

PostgreSQL, MySQL и SQLite не умеют «перепрыгнуть» через строки. При OFFSET 100000 база честно читает сто тысяч строк и выбрасывает их, чтобы отдать следующие двадцать. Стоимость запроса растёт вместе со смещением.

Автор разбора замерил это на таблице в 1,2 млн строк в PostgreSQL 15 с холодным кешем и обычным btree-индексом по id:

Курсорный вариант на той же таблице держал 3 мс на любой глубине. Разница объясняется сложностью: поиск по индексу это O(log n), а большое смещение — O(offset). На пятидесятитысячной странице пользователь ждёт больше двух секунд вместо миллисекунд.

Он врёт, когда в таблицу пишут

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

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

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

Как выглядит курсор в коде

Простейшая версия работает по первичному ключу и умещается в один обработчик:

Обратите внимание на per_page + 1. Запрашивая на одну запись больше, чем собираетесь отдать, вы узнаёте о существовании следующей страницы без отдельного запроса COUNT. Лишняя запись отбрасывается, а её наличие становится флагом has_more.

Составной курсор: место, где ломается наивная версия

Курсор по одному id корректен, только пока вы сортируете по id. Как только сортировка идёт по created_at, простое условие created_at > X начинает терять записи: два заказа, созданные в одну миллисекунду, дают ничью, и одна из строк молча исчезает из выдачи.

Лечится это составным курсором — ключ сортировки плюс первичный ключ, сравниваемые как кортеж:

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

Про формат курсора:
Не отдавайте наружу голый идентификатор, если планируете менять схему. Заверните значения в маленький JSON с полем версии и закодируйте в base64: тогда через год вы поменяете состав курсора, не сломав клиентов, которые прямо сейчас держат страницу открытой.

Когда офсетную пагинацию нужно оставить

Курсор не бесплатный, и подменять им всё подряд не стоит. Есть четыре ситуации, где offset честно лучше:

• Интерфейсу нужен переход на конкретную страницу. У курсора нет номеров страниц, поэтому админки, таблицы и всё с кнопкой «перейти к странице 47» остаются на offset.
• Данных мало и они не меняются. Справочник на пять тысяч строк не выиграет ничего, зато offset проще объяснить и отладить.
• Пагинация идёт по памяти или по кешу, где смещение и так стоит O(1).
• Сортировка задаётся пользователем по произвольной колонке. Курсор тут превращается в кодирование кортежей в непрозрачные строки, и это уже заметная сложность.

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

И отдельно стоит помнить, что пагинация обычно не единственная нагрузка на базу. Кто ещё и насколько сильно её грузит, разбирали в переводе про паттерны управления трафиком к PostgreSQL.

Вторая половина задачи: кто и сколько может забрать

Правильная пагинация решает, как отдавать данные. Она не решает, сколько их заберут за минуту. Ограничение частоты запросов выглядит тривиально («считай запросы, блокируй сверх N») и превращается в задачу распределённых систем ровно в тот момент, когда серверов становится два.

Сначала ответьте, от чего защищаетесь

От выбранной цели зависит вся конструкция, и целей обычно выделяют четыре:

• Защита от перегрузки — не дать всплеску положить сервис.
• Честное распределение — не дать одному шумному клиенту вытеснить остальных.
• Защита от злоупотреблений — притупить перебор паролей, скрейпинг и подстановку учётных данных.
• Контроль расходов — ограничить дорогие ручки вроде вызова модели или построения отчёта. Тот же принцип со стороны поставщика разбирали на примере лимитов трат в OpenAI API.

Три алгоритма и один, который выбирают почти всегда

Фиксированное окно считает запросы в календарном интервале: сто в минуту со сбросом на начале минуты. Просто и дыряво: клиент отправляет сотню в 12:00:59 и ещё сотню в 12:01:00, то есть двести за одну секунду. Граница окна и есть дыра.

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

Ведро токенов обычно и оказывается верным выбором по умолчанию. В ведре лежит до N токенов, оно пополняется с постоянной скоростью, каждый запрос тратит один токен. Такая схема разрешает контролируемые всплески (молчавший клиент накопил токены и может потратить их разом), но держит среднюю нагрузку в рамках. Родственное «дырявое ведро» выдаёт идеально ровный поток и нужно там, где принимающая сторона всплесков не переносит.

Фиксированное окно пишут первым и потом жалеют. На ведро токенов мигрируют.

Ловушка, из-за которой лимит не работает вообще

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

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

Скользящее окно на Redis: пятнадцать строк Lua

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

Скользящее окно они собрали на сортированном множестве Redis. Скор записи — временная метка в миллисекундах, а весь алгоритм умещается в один Lua-скрипт, который Redis выполняет атомарно:

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

Две детали, на которых легко ошибиться

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

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

Обошлось это в два часа работы вместе с тестами. Одна запись в сортированном множестве занимает около 50 байт, на пользователя их пять, и даже при десяти тысячах активных пользователей всё хранилище лимитов весит порядка 2,5 МБ. Настроенный лимит составил пять запросов за шестьдесят секунд на пользователя. Первым же уловом стал автоматизированный скрипт, бивший в ручку больше двухсот раз в час.

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

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

• Отдавать 429 Too Many Requests, а не общий 400 или 503. По коду клиент понимает, что делать.
• Присылать заголовок Retry-After, чтобы клиент знал момент следующей попытки, а не подбирал его перебором.
• Показывать остаток бюджета в заголовках вида X-RateLimit-Remaining и X-RateLimit-Reset.

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

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

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

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

Разборы, на которых основан материал: переход с offset на курсор с замерами, паттерны и алгоритмы ограничения частоты и скользящее окно на Redis и Lua.

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

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

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

• Два агента, три способа запуска (Messages API, Claude Agent SDK, Managed Agents (beta)), четыре вертикали и восемь веб-приложений в одном репозитории под Apache 2.0.
• Не оформляет заказ, не списывает деньги и не меняет живые листинги: checkout только рисует корзину, каждая запись мерчанта ждёт одобрения человека.
• Проверки provenance, лимиты, ограждение стороннего текста и валидация памяти работают внутри вызова инструмента и держатся на всех трёх путях запуска.
• Своя интеграция сводится к реализации StorefrontBackend или MerchantBackend; отсутствующие системы выключаются переключателями enable_*.
• Модели по умолчанию: claude-sonnet-5 у покупательского агента, claude-opus-5 у мерчантского, claude-haiku-4-5-20251001 для памяти; рантаймы работают через Vertex AI, Bedrock, Microsoft Foundry и шлюзы.
• Требования: Python 3.11 и новее, Node 22. Демо поднимается шестью командами из README.

Один агент описан один раз и работает на трёх рантаймах

Главная архитектурная идея репозитория, как её формулирует README: каждый агент определён один раз (промпт, скиллы, контракты инструментов, гейты) и запускается на Messages API, на Claude Agent SDK и на Managed Agents. Четыре вертикали работают поверх одних библиотек и различаются бэкендом и доменными расширениями интерфейса.

Покупательский агент ищет и сравнивает товары, собирает планы покупок, наполняет корзину, отвечает на вопросы о заказах и правилах магазина и запоминает, что покупатель о себе рассказал. Его пять сценариев лежат как skills в каталоге shopping-agent/skills. Мерчантский агент объясняет показатели, правит листинги, реагирует на алерты по остаткам и заказам, назначает цены и промо, готовит кампании. Его пять сценариев лежат в merchant-agent/skills. Любая запись мерчанта становится staged change, которую применяет уже интерфейс одобрения на стороне хоста.

Nothing places an order, charges a card, or changes a live listing: checkout renders the cart for the host to complete, and every merchant write is staged until a person approves it.

Код разложен на семь pip-пакетов. Общее для обеих ролей вынесено в commerce-common: конфиг, ограждение стороннего текста, память, скиллы, grounding, презентационные компоненты, исполнитель инструментов и события. У каждой роли три пакета: core с типами, интерфейсом бэкенда, промптом, контрактами инструментов и гейтами; runtime с циклом ходов на Messages API; sdk с тем же агентом на Agent SDK и консолью. CI проверяет, что имена семи пакетов остаются незарегистрированными в публичном индексе, а pin-файлы ставят их из каталогов репозитория.

Эталонный путь запуска, вокруг которого построены примеры, это Messages API. Хост создаёт объект агента с бэкендом, каталогом скиллов и конфигом и стримит события хода; извлечение памяти вызывается отдельно после хода, и только на этом пути. Код из README:

На Agent SDK тот же промпт, скиллы и инструменты, но цикл ведёт SDK: хост заранее подгружает данные для grounding, после хода ничего не выполняется. На Managed Agents агент размещён у Anthropic и ходит за данными в ваш MCP-сервер; деплой делает скрипт scripts/deploy_managed_agent.sh, без флага --live это сухой прогон. Различия трёх путей по docs/safety.md:

• Messages API. Все правила grounding включаются принудительно через tool_choice; работают извлечение памяти после хода, сжатие истории и бюджеты аналитического делегата мерчанта.
• Agent SDK. Grounding только для правил с формой предварительной загрузки; цикл ограничен max_turns; аналитика мерчанта идёт субагентом без SQL-инструмента и бюджетов; память хост извлекает сам.
• Managed Agents. Grounding отсутствует, циклом владеет платформа, память пишется только через save_memory, одобрением staged change служит промпт always_ask на apply_change.

Проверки стоят внутри вызова инструмента, поэтому переживают смену рантайма

Документ docs/safety.md делит правила на три группы: что код проверяет сам, что по-прежнему просят у модели промптом и что обязан добавить деплой. Ключевой приём: правило внутри вызова инструмента держится на всех трёх путях, потому что все три прогоняют вызовы через один исполнитель в модуле commerce_common/execution.py. Правило на уровне хода живёт в конкретном рантайме, и таблица указывает, где оно не работает.

A rule enforced inside a tool call holds on all three paths, because the Messages API runtime, the SDK toolset, and the MCP server execute tools through the same executor.

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

• Ограждение (fencing). Сторонний текст очищается, оборачивается в ограждение с фиксированной меткой и обрезается до max_fenced_chars. Очистка убирает невидимые и управляющие символы, поддельные маркеры ходов, теги транскрипта и вызовов инструментов и копии самого маркера ограждения.
• Лимиты цикла. Запрошенное моделью число результатов поиска обрезается до max_search_results; после max_tool_iterations раундов рантайм Messages API принудительно делает ход без инструментов.
• Provenance корзины. В корзину попадают только идентификаторы товаров, которые в этой сессии вернул инструмент каталога или заказов. Попытка добавить товар с опциями (размер, цвет) задерживается, и модели показывают варианты. Действует лимит на позицию и на число строк.
• Нет оплаты. У StorefrontBackend нет метода, который размещает заказ или списывает деньги. URL размещённого checkout приходит из checkout_handoff после вызова модели и не проходит через неё.
• Provenance staged-записей мерчанта. Изменение принимает только идентификаторы листингов и кампаний, возвращённые инструментом в этой сессии; правка контента требует чтения get_listing. apply_change принимает только идентификаторы изменений, которые вернули staging или get_pending_changes.
• Guardrails мерчанта. Проверяются при постановке изменения и повторно при применении: число позиций, размах изменения цены, глубина промо, размер пополнения, бюджет кампании, защищённые поля.
• Одобрение хостом. При require_host_approval (включено по умолчанию) apply_change проходит только для идентификаторов, которые хост пометил одобренными. Карточка предпросмотра ничего не одобряет, «да, применяй» в чате тоже.
• Память. Ключ факта до 64 символов, значение до 200, одна из трёх категорий; значения, похожие на идентификаторы, отбрасываются. Извлечение читает только текст последнего обмена, никогда результаты инструментов.
• Поверхность инструментов и идентичность. Список инструментов вычисляется из конфига деплоя, исполнитель отказывает любому другому имени. Идентичность держит сервер: ни один аргумент инструмента не называет пользователя или мерчанта.

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

When the model breaks one of these, the error is confined to its text. Every write, figure, and disclosure behind that text still passed the checks in the table above, so the failure is a misstatement to correct and no action needs reversing.

Третья группа целиком на стороне деплоя: аутентификация и авторизация на каждом маршруте и на MCP-серверах (примеры принимают любого вызывающего), учётные данные для вызова ваших сервисов, лимиты запросов, бизнес-правила (фрод, право на покупку, цены, остатки), оплата после checkout, обращение с памятью как с персональными данными, гигиена логов и сама поверхность одобрения. Значения guardrails в двух файлах config.py названы демонстрационными.

Своя интеграция сводится к двум интерфейсам и переключателям enable_*

Точка входа для собственных систем описана в docs/backends.md. Деплой реализует StorefrontBackend поверх каталога, корзины, заказов и политик или MerchantBackend поверх аналитики, каталога, остатков, цен и кампаний. Контрактом служат докстринги методов в backend.py и types.py каждой роли. Каждый метод вызывает ваш сервис на стороне сервера с учётными данными, которые хост хранит для сессии; модель видит только результат.

Each one calls your service server-side with the credential your host holds for the session; the model reads only the result.

Документ раскладывает интеграцию на шесть шагов. Первый: решить, кто вызывающий. Хост аутентифицирует человека и стартует сессию с принципалом; токен покупателя живёт в контексте сессии, сервисная учётка передаётся в конструктор бэкенда. Гость тоже принципал: чтение, которому нужен аккаунт, бросает исключение, которое подкласс исполнителя превращает в просьбу войти. Второй: порядок многошаговых сценариев (удержать места, затем подтвердить) хранится и проверяется в бэкенде, а нарушение маппится через domain_error в понятный модели результат. Третий: как завершается checkout. Вариантов три: ссылка на маршрут в вашем приложении, размещённый checkout платформы, для которого checkout_handoff возвращает URL, или маркетплейс с записью на каждого продавца.

Четвёртый шаг: товары с опциями. Запись бывает простой, семейством (с полем options) или вариантом (с option_values и variant_of); идентификатор варианта идёт всюду, где ждут идентификатор товара. Детали товара возвращают все варианты семейства в одном ограждении, обрезанном до max_fenced_chars (12 000 символов по умолчанию). Компактная строка варианта занимает 70–120 символов, так что в семейство помещается около шестидесяти вариантов; кроссовки в восьми цветах и четырнадцати размерах документация советует подавать как восемь семейств по четырнадцать, потому что за пределами лимита результат режется без ошибки. Пятый: записи мерчанта по семействам, где изменение цены и пополнение именуют вариант. Шестой: для цифр, которых у платформы нет, возвращать None с пометкой, а не подставной ноль.

Для пилота README предлагает начинать с малого. Покупательский пилот реализует поиск и карточку товара, а остальное заглушает: метод-заглушка возвращает результат «недоступно» и не меняет ни байта промпта. Мерчантский пилот реализует восемь методов чтения, записи отказывают. Система, которой у бизнеса нет совсем, выключается переключателем enable_*: это убирает её инструменты, строки промпта и правило grounding на всех трёх путях, а сценарии, которым она нужна, паркуются в каталоге skills/_staged/. Свой сценарий добавляется каталогом с файлом SKILL.md, доменный интерфейс расширением PresentationExtension (вертикали поставляют семь), а brand_name, assistant_name и brand_voice в конфиге задают личность ассистента.

Модели заданы строкой в конфиге, а переключение платформы сосредоточено в одном месте и зависит от рантайма

По docs/deployment.md код по умолчанию ходит в API Anthropic, но у каждого пути есть одно место, где деплой переключает платформу. Рантаймы Messages API принимают любой асинхронный клиент из пакета anthropic аргументом client=: AsyncAnthropicVertex для GCP Vertex AI, AsyncAnthropicBedrockMantle или AsyncAnthropicBedrock для AWS, AsyncAnthropicFoundry для Microsoft Foundry, AsyncAnthropic с base_url и auth_token для собственного шлюза. Пакеты требуют anthropic 0.91 и новее. Рантаймы Agent SDK HTTP-клиента не создают: платформу выбирает CLI Claude Code по переменным окружения, которые добавляются в options.env. Managed Agents работает на инфраструктуре Anthropic, поэтому у него нет варианта для Vertex, Bedrock и Foundry.

Модель задаётся строкой в конфиге: поля model и memory_model у каждой роли, у мерчанта ещё analysis_model. Значения по умолчанию, по таблице документа: claude-sonnet-5 для покупательского агента, claude-opus-5 для мерчантского, claude-haiku-4-5-20251001 для извлечения памяти. Грамматика идентификаторов у платформ разная: Vertex пишет датированные снимки через @, Bedrock через Mantle берёт идентификаторы с префиксом anthropic., а через Invoke API идентификаторы inference-профилей. Все три поля идут через один клиент, поэтому все три модели должны существовать на целевой платформе. Живого разговора с облаком в CI нет; документ просит прогнать его на своей платформе до того, как на неё полагаться.

Доступность API Anthropic и облачных платформ для конкретной страны или способа оплаты в документации репозитория не обсуждается. Для собственного шлюза документ называет требование: отдавать /v1/messages со стримингом SSE для Messages API, а для Managed Agents ещё проксировать /v1/skills, /v1/agents, /v1/environments, /v1/sessions и поток событий сессии с заголовками anthropic-beta.

Демо поднимается шестью командами, а плагин Claude Code собирает агента под ваш стек

Порядок запуска из README (нужны Python 3.11 и новее и Node 22, ключ ANTHROPIC_API_KEY в файле .env):

Флаг --merchant поднимает портал мерчанта вместо витрины, --all оба. В README каждой вертикали есть раздел Try с репликами, которые прогоняет scripts/smoke_chat.py. Розничная ACME показывает поиск, сравнение, корзину, checkout и память; ACME Travel добавляет инвентарь с датами; ACME Mobile матрицу тарифов и серверные раскрытия комиссий; ACME Tickets таймированные удержания мест, листы ожидания и карту зала.

Второй способ начать: плагин commerce-builder для Claude Code. Он читает клонированный репозиторий как эталон и собирает агента на этих пакетах против ваших систем либо проверяет уже написанного. Установка и первая команда из README:

Команда /scaffold-commerce-agent спрашивает о стеке, проговаривает план и строит проект. Дальше /add-commerce-flow добавляет сценарий, /author-commerce-evals пишет evals, /review-commerce-agent начинает с уже существующего агента. Собственных MCP-коннекторов в поставке нет: оба агента ходят в системы через интерфейсы бэкенда. Где официальный коннектор является источником истины (Snowflake, BigQuery, Stripe, Square, Slack и другие в списке README), он и становится целью интеграции. MCP-сервер торговой платформы вызывается из метода бэкенда на сервере, и гейты provenance остаются перед каждой записью.

Проверка после правок: ruff check и ruff format --check, pytest, python scripts/check.py; python scripts/verify_all.py добавляет сухие прогоны деплоя и сборку веб-приложений; python scripts/smoke_chat.py --vertical travel проводит один живой разговор и требует ключ. Чтобы убедиться, что кэширование промпта работает, README советует читать cache_read_input_tokens из события turn_complete: ноль на втором ходу означает, что префикс промпта изменился.

Что делать команде, которая пишет ассистента для магазина

1. Поднять розничное демо по шести командам выше (Python 3.11 и новее, Node 22, ключ API) и пройти реплики из раздела Try в examples/retail/ на витрине (порт 3000) и в портале мерчанта (флаг --merchant, порт 3100).
2. Сверить таблицу «Enforced in code» и список «What a deployment owns» из docs/safety.md с собственной платформой: аутентификация, учётные данные, лимиты запросов, бизнес-правила, оплата, персональные данные в памяти, логи.
3. Для пилота реализовать в StorefrontBackend только поиск и карточку товара, для MerchantBackend восемь методов чтения. Отсутствующие системы выключить через enable_*, зависимые сценарии убрать в skills/_staged/.
4. Разложить каталог по трём формам записи из docs/backends.md и проверить самое большое семейство против лимита max_fenced_chars в 12 000 символов.
5. Выбрать завершение checkout: свой маршрут, размещённый URL платформы через checkout_handoff или ссылка на продавца для маркетплейса; оплата остаётся в хосте.
6. Для Vertex AI, Bedrock, Foundry или шлюза передать клиент аргументом client= (anthropic 0.91 и новее) или переменные CLI в options.env и заменить все три идентификатора моделей.
7. Перед выкладкой прогнать ruff, pytest, scripts/check.py и scripts/verify_all.py, затем один живой разговор scripts/smoke_chat.py на своей платформе; при смене модели перегнать evals по разделу «Still asked of the model».

Репозиторий создан 1 сентября, анонс в аккаунте Claude Developers вышел 2 сентября в 19:33 UTC. На 3 сентября, 01:53 мск, по данным GitHub API у проекта 277 звёзд и 46 форков. Поддержки и приёма внешних изменений Anthropic не обещает: «This is a reference implementation; it is not maintained and does not accept contributions», говорится в README. На практике это значит, что исправления и адаптацию под свои системы команде придётся вести в собственном форке, а промпты и гейты под новые модели проверять своими evals. Цен, лимитов и сроков дальнейшего развития Anthropic в репозитории не называет.

Источники: Claude Developers в X: анонс открытия Claude Commerce Agents (2 сентября 2026), GitHub: anthropics/commerce-agents, README репозитория commerce-agents, docs/safety.md: правила, проверяемые кодом, и обязанности деплоя, docs/backends.md: подключение своих систем, docs/deployment.md: Vertex AI, Bedrock, Microsoft Foundry и шлюзы, Плагин commerce-builder для Claude Code, Скиллы покупательского агента, Скиллы мерчантского агента

Изображение на обложке: Anthropic, кадр из анонса Claude Commerce Agents

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

• Март 2026 года: API-ключ для инференса публичных моделей украден с личного EC2-инстанса исследователя, где стояло самодельное приложение за Google-аутентификацией.
• Приложение имело уязвимость fail-open: при ошибке проверки доступ открывался; инстанс был намеренно публичным за Google-аутентификацией.
• Атакующий попросил агента показать ключ, получил его и добавил на сервер собственный SSH-ключ; чужие запросы шли около трёх недель.
• Май 2026 года: сканирование сервисов, подбор паролей по утёкшим базам, попытки через OAuth-токены; в публичном просмотрщике транскриптов нашли ошибку с read-only SQL, признаков её эксплуатации нет.
• METR остановила и сняла образ инстанса, заменила учётные данные; описанные меры актуальны на 30 июля 2026 года.

Как украли ключ

Исследователь METR поднял на личном инстансе EC2 небольшое веб-приложение, написанное с помощью ИИ, и защитил его входом через Google. В коде была классическая ошибка fail-open: если проверка авторизации по какой-то причине не срабатывала, приложение считало пользователя допущенным, а не отказывало. Инстанс намеренно был публичным за входом через Google, и ошибка fail-open сняла эту защиту; этого хватило.

The vibe-coded app included a fail-open vulnerability.

Дальше атакующий, по описанию METR, попросил агента показать ключ API, и тот его раскрыл, а для постоянного доступа добавил на сервер собственный SSH-ключ. Ключ использовали для запросов к публичным моделям примерно три недели. Заметить это оказалось трудно по двум причинам: METR не платила за эти кредиты деньгами, так что счёт не рос, а внутренняя панель METR не показывала запросы, отклонённые по лимитам, для всех пользователей ключа.

Вторая волна: май

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

Правила, которые из этого следуют

• Ключи API к моделям не живут на личных серверах и ноутбуках: только в секрет-хранилище команды с выдачей по ролям и сроком жизни.
• Приложения с доступом к ключам делайте fail-closed: любая ошибка в проверке прав — отказ, а не пропуск. Это первое, что стоит проверить в коде, написанном с ИИ.
• На каждый ключ — лимит расходов и алерт на аномалию по числу запросов, а не только по деньгам: бесплатные кредиты тратятся так же незаметно.
• Отдельный ключ на каждое приложение и человека: один общий ключ означает, что после утечки ротировать придётся всё сразу.
• Инстансы «на минутку» с публичным IP считайте продом: инвентаризация, автоматическое выключение по таймеру, запрет входящих портов по умолчанию.

Контекст

METR получает от разработчиков моделей ранний доступ для оценок безопасности, поэтому её инфраструктура — заметная цель. То, что оба инцидента пришлись на периферию (личный сервер, публичный просмотрщик), а не на основные системы, говорит скорее о сегментации, чем об удаче. Но именно периферия и есть то место, где у большинства команд лежат ключи «на время». Сумму METR оценивает примерно в $600 тыс. бесплатных кредитов, которые она не оплачивала деньгами.

Источник: Security update (METR, 31 августа 2026)

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

Цифровой рубль — не криптовалюта и не «безнал на карте». Счёт открывается на платформе Банка России, а банк выступает посредником, через приложение которого клиент этим счётом управляет. Один человек или компания может иметь только один такой счёт; у ИП их два: личный и для бизнеса. Если вы делаете интернет-магазин, кассу, биллинг или сервис подписок для компании из первой волны, приём цифрового рубля становится обязательным сценарием, а не опцией.

• Счёт цифрового рубля открывается на платформе Банка России через раздел «Цифровой рубль» в приложении подключённого банка; один счёт на физлицо или компанию, у ИП два.
• Лимит пополнения для физлиц — 300 тыс. рублей в месяц, для бизнеса лимита нет; тратить накопленное можно без ограничений.
• Для граждан операции бесплатны; для бизнеса комиссии не взимаются до конца 2026 года, тарифы с 2027 года установлены отдельным решением Банка России от 28 августа.
• Принимать цифровые рубли обязаны с 1 сентября 2026 года торговые компании с выручкой свыше 120 млн рублей, у которых на 1 января 2026 года был договор с крупнейшим банком-участником; торговые точки с выручкой до 5 млн рублей освобождены.
• Все банки с универсальной лицензией подключаются к 1 сентября 2027 года, с базовой — к 1 сентября 2028 года; сроки закреплены законом 248-ФЗ.

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

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

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

Доступные операции: переводы между гражданами и компаниями, платежи в бюджет и из бюджета, оплата покупок, возвраты. Открытие и закрытие счёта бесплатны, для граждан бесплатны все платежи и переводы. Для бизнеса действует льготный период до конца 2026 года; тарифы для индивидуальных предпринимателей и компаний с 2027 года установлены отдельным решением Совета директоров Банка России от 28 августа 2026 года. По вопросам работы с цифровыми рублями регулятор советует обращаться сначала в свой банк, затем на горячую линию Банка России по цифровому рублю: 8 800 301 30 00, короткий номер 301 с мобильного или +7 499 300 3 301.

Сроки для банков и магазинов

Внедрение идёт волнами. С 1 сентября 2026 года инфраструктуру открывают крупнейшие банки, а торговые компании с выручкой свыше 120 млн рублей в год, у которых на 1 января 2026 года был договор с таким банком, обязаны принимать цифровые рубли. С 1 сентября 2027 года такую возможность должны обеспечить все банки с универсальной лицензией, с 1 сентября 2028 года — банки с базовой лицензией. Торговые точки с выручкой меньше 5 млн рублей от обязанности освобождены, как и торговые точки там, где нет интернета. Обязательные сроки для банков и продавцов закреплены федеральным законом 248-ФЗ, а решение Банка России определяет лимиты, перечень операций и порядок добровольного раннего подключения остальных банков.

Что это значит для разработчика платёжной интеграции

Технически приём идёт через банк-участник, поэтому прямой интеграции с платформой Банка России у магазина нет: интерфейс и документацию даёт ваш банк. Возвраты уходят обратно на цифровой счёт покупателя, а не на карту, и это отдельная ветка в логике рефандов и чеков. Лимит 300 тыс. рублей в месяц касается пополнения счёта физлицом; расход ограничен только остатком на счёте.

• Узнайте у своего банка, как он подключает приём цифровых рублей и какие интерфейсы даёт; для крупнейших банков это уже сентябрь 2026 года.
• Заложите в модель данных третий тип платежа рядом с картой и СБП: у него свои статусы, свой возврат и своя сверка.
• Возвраты: средства уходят обратно на цифровой счёт покупателя; учитывайте это в логике рефандов и в чеках.
• Комиссии для бизнеса появятся с 2027 года по тарифам решения от 28 августа; не зашивайте «бесплатно» в расчёт стоимости платежей.
• Торговые точки с выручкой до 5 млн рублей, точки без интернета и, до сентября 2027 года, клиенты банков вне списка крупнейших могут не спешить: для них цифровой рубль пока добровольный.

Контекст

Пилот цифрового рубля стартовал в августе 2023 года на ограниченном круге клиентов и банков. К концу сентября 2025 года в нём было открыто больше 2,5 тыс. кошельков и проведено больше 90 тыс. операций. Массовый запуск дважды переносили. Следующая проверка — сентябрь 2027 года, когда к платформе должны подключиться все банки с универсальной лицензией, и тарифы для бизнеса, которые начнут действовать с января.

Источники: Сообщение Банка России о старте с 1 сентября, Решение Совета директоров Банка России от 28.08.2026, Страница проекта «Цифровой рубль»

Изображение на обложке: Банк России

В этой статье соберём работающего RAG-бота, который отвечает на вопросы о любой веб-странице, примерно на 60 строках Python. Никаких парсеров HTML, headless-браузеров и сложных фреймворков — только requests, локальная Ollama и чистый Markdown.

Что такое RAG

RAG (retrieval-augmented generation) — это подход, при котором языковая модель не отвечает по своей памяти, а сначала ищет релевантные фрагменты во внешнем тексте, а потом генерирует ответ на их основе. Это резко снижает галлюцинации и позволяет работать с данными, которых не было в обучающей выборке.

• RAG-бот на Python укладывается в ~60 строк и работает без облачных LLM.
• Самое неприятное в RAG-пайплайне — очистка HTML; готовый Markdown API убирает эту работу.
• Текст разбивается на чанки (~1200 символов), каждый превращается в эмбеддинг и сравнивается с эмбеддингом вопроса.
• Локальные модели nomic-embed-text и llama3 через Ollama не требуют иностранных карт и VPN.
• Качество ответа зависит от качества исходного текста: сырой HTML зашумляет поиск, чистый Markdown улучшает ретривл.

Что мы соберём

Архитектура бота простая и универсальная:

1. Отправляем URL в сервис извлечения текста и получаем чистый Markdown.
2. Разбиваем Markdown на фрагменты (чанки) по границам абзацев.
3. Превращаем каждый чанк в вектор — эмбеддинг.
4. То же самое делаем с вопросом пользователя.
5. Находим чанки, ближайшие к вопросу, по косинусной близости.
6. Отдаём найденные фрагменты + вопрос языковой модели с инструкцией отвечать только по контексту.

Такая схема легко масштабируется: можно заменить локальную Ollama на OpenAI, Anthropic или российские модели, а векторы перенести в Qdrant или Chroma.

Что понадобится

• Python 3.9+
• Библиотека requests
• Локально запущенная Ollama с моделями nomic-embed-text и llama3
• Доступ к API извлечения текста (в примере — Web to Markdown/JSON API; бесплатный тариф даёт 50 запросов в сутки)

Код бота

Сохраните скрипт как rag_bot.py и подставьте свой ключ, если сервис извлечения текста требует авторизации:

На что обратить внимание:
Если вы используете RapidAPI-версию сервиса, запрос к API_URL обычно требует заголовка X-RapidAPI-Key. Без ключа бесплатный endpoint может вернуть 401.

Разбор по частям

fetch_markdown — единственный внешний вызов. Сервис сам забирает страницу, убирает навигацию, баннеры и футер и возвращает Markdown: заголовки, абзацы, списки. Это освобождает от зависимостей вроде BeautifulSoup или headless Chrome.

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

embed и cosine превращают текст в векторы и считают их близость. Модель nomic-embed-text из Ollama бесплатна, быстрая и неплохо понимает русский и английский.

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

Запуск

Установите зависимости и скачайте модели в Ollama:

Если всё в порядке, в консоли появится примерно такой результат:

Почему важен чистый Markdown

Если скормить эмбеддинг-модели сырой HTML, в векторах окажутся теги <div>, меню навигации и копирайты из футера. В результате поиск похожести выдаст «Copyright © 2026» вместо полезного ответа. Чистый Markdown — заголовки, абзацы, списки — улучшает качество ретривла почти бесплатно.

Если не хочется зависеть от внешнего API, можно заменить fetch_markdown на один из альтернативных вариантов:

• trafilatura — библиотека на Python для извлечения главного текста.
• r.jina.ai/http://URL — бесплатный сервис без ключа.
• Firecrawl — API с поддержкой сканирования сайтов целиком.
• ScrapingBee — прокси + рендеринг для сложных страниц.

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

Куда развивать

• Направьте бота на документацию, чейнджлог или блог конкурента и задавайте вопросы по ним.
• Замените Ollama на OpenAI, Anthropic, Gemini или российские модели — функция answer меняется в двух строках.
• Сохраняйте эмбеддинги в векторную БД: Chroma, Qdrant или FAISS, чтобы индексировать сразу много страниц.
• Используйте формат json вместо Markdown, если нужна структура: параграфы, заголовки, ссылки — отдельно.

Выводы

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

RAG работает ровно так хорошо, каков текст, который вы ему скармливаете. Уберите самую утомительную часть — очистку HTML, — и останется интересное: поиск и генерация.

Исходник идеи — статья «Chat With Any Website: Build a RAG Bot in ~60 Lines of Python». Попробуйте собрать бота на своей странице и посмотрите, где он справляется, а где начинает фантазировать.

У S3-совместимого объектного хранилища другая логика: приложение обращается к объектам через API, а вопросы физического размещения и масштабирования решает сама система хранения. Для бэкапов, архивов и медиаданных модель такого рода подходит хорошо, однако перед переходом на нее важно проверить, как конкретное приложение работает с объектами и что произойдет с данными при нагрузке или восстановлении.

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

В объектном хранилище данные организованы в бакеты, где у объекта три составляющие: содержимое, уникальный ключ и метаданные. Вложенных директорий в привычном смысле здесь нет — папки в интерфейсах появляются потому, что ключ объекта разбирают по разделителю. Например, backups/2026/08/db-dump.tar.gz читается человеком как путь по папкам, а для хранилища — просто одна строка-идентификатор.

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

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

Управляется модель небольшим набором предсказуемых HTTPS-операций.

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

Где подходит модель

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

Для задач с частыми синхронными изменениями нужна другая модель хранения. Например, для дисков виртуальных машин, транзакционных логов СУБД, рабочих каталогов сборки и приложений с POSIX-блокировками подходит блочное или файловое хранилище. S3 при этом можно использовать для снапшотов, регулярных выгрузок и резервных копий.

Что защищает данные внутри S3 и где заканчивается эта защита

Для критичных данных в S3 используются versioning, Object Lock и репликация. Эти функции решают разные задачи и применяются в разных сценариях.

Versioning сохраняет предыдущие версии объектов. При повторной записи по тому же ключу создаётся новая версия с собственным version ID. DELETE добавляет delete marker, поэтому предыдущие версии остаются доступными для восстановления.

Versioning увеличивает объём хранения. Приложение, которое ежедневно переписывает крупный объект, создаёт последовательность его полных версий. Lifecycle-политика позволяет определить срок хранения старых версий и правила очистки незавершённых multipart-загрузок. Versioning переводится в состояние suspended, а полностью отключить его нельзя. При создании бакета с Object Lock versioning включается автоматически.

Object Lock реализует модель WORM, Write Once, Read Many. Для объекта задаётся срок retention, в течение которого система сохраняет его в защищённом состоянии.

В режиме Governance пользователь с расширенными правами может снять защиту вручную. В режиме Compliance защищённая версия сохраняется до окончания retention, включая случаи с root-аккаунтом. Срок хранения стоит рассчитывать заранее: установленный retention нельзя сократить, поэтому версия продолжит занимать место до окончания заданного периода.

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

Репликация переносит изменения вместе с объектами. Если исходные данные уже содержат логическую ошибку, она попадёт и в реплики. Для критичных данных поэтому требуется отдельный домен отказа, регулярная проверка восстановления и схема резервного копирования 3-2-1 или 3-2-1-1-0.

Своя инфраструктура или сервис провайдера

S3-сервис можно развернуть внутри собственной инфраструктуры или использовать как управляемую услугу провайдера. На уровне приложения подключение выглядит одинаково: endpoint, access key, secret key и S3 API — разница в эксплуатации инфраструктуры.

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

Как это устроено у Linx Cloud

Если выбор сделан в пользу провайдера, вот пример конкретной реализации. В основе сервиса Объектное хранилище (S3) в Linx Cloud — Ceph: мы выбрали его из-за совместимости с S3 API (по нашему опыту, полнее её реализует разве что сам AWS), а также из-за масштабируемости и гибкости для развития продукта.

Путь запроса такой: HTTPS endpoint → сетевой периметр с WAF и NGFW → балансировщики нагрузки → Ceph Object Gateway (RGW), который уже разбирает команды S3 API и передаёт операции в backend-кластер. Сами объекты лежат на OSD-узлах с репликацией в три копии (RF3), а управляющие компоненты кластера вынесены на отдельное оборудование.

Подключиться к сервису можно по интернету или по выделенному каналу точка-точка — из виртуального ЦОД Linx Cloud, серверной стойки в дата-центре Linx или с любой внешней площадки. По документации сервис поддерживает multipart upload, versioning, Object Lock/WORM, presigned URL, репликацию бакетов и lifecycle-правила удаления. Один PUT рассчитан максимум на 5 Гбайт — для объектов крупнее нужен multipart.

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

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

Каким бы ни было решение — свой кластер или сервис вроде Linx Cloud — переводить на него прод стоит только после пилота, и строить его нужно на реальном потоке данных приложения: одна команда aws s3 cp с тестовым файлом ничего не покажет.

• Поэтому сначала измеряется профиль данных: средний и максимальный размер объектов, общее количество объектов, соотношение GET и PUT, частота LIST, пиковая нагрузка и допустимая задержка.
• Затем проверяется совместимость приложения с нужными функциями S3. В тест входят multipart, versioning, Object Lock, lifecycle, presigned URL и права доступа. Для каждого механизма важно проверить именно тот сценарий, который используется в рабочей системе.
• После этого оцениваются сеть и безопасность. Тест показывает поведение канала под нагрузкой, работу при обрыве соединения, доступные маршруты и стоимость исходящего трафика. На уровне безопасности проверяются разделение прав, хранение и ротация ключей, шифрование, аудит операций и сценарий компрометации учётной записи.
• Финальная часть пилота посвящена восстановлению и стоимости. Нужно выполнить возврат старой версии и полное восстановление данных, измерить объём накопленных неактуальных версий и рассчитать расходы на запросы, хранение и трафик с учётом ожидаемого роста данных.

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

Для data lake — скорость, с которой выбранный аналитический стек читает данные, и отсутствие «болезни мелких файлов», когда объектов становится очень много. Одна и та же платформа S3 может отлично закрывать один сценарий и требовать уже другого архитектурного решения в соседнем.

Вместо вывода

S3 подходит для бэкапов, архивов, медиаконтента и аналитических данных, которые хранятся и читаются как объекты. Для дисков ВМ, СУБД и рабочих каталогов с частыми изменениями больше подходят файловые и блочные хранилища.

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

Без маркетинга и успешного успеха. Только боль, костыли и суровый прод! Мой пет-проект - бот «Щёлк-ГДЗ». Это ИИ-помощник, который решает школьные задачки по фоткам, видео, гс, тг-кружкам и PDF. Под капотом Python 3.12.3, aiogram 3, aiosqlite, апи OpenRouter (модель Gemini 3.0 Flash) и Робокасса. Крутится всё это на дешёвом VPS в Нидерландах. Держит 2500+ пользователей и не падает.

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

Нейронка вместо джуна и Уроборос багов

Сразу признаюсь... С нуля я это не писал :) Синтаксис мне генерили LLM-ки. Начинал с Gemini 2.5 Pro, затем перешел на 3.0 Pro, а сейчас использую 3.1 Pro.

Многие думают, что нейронка сама напишет проект "под ключ", но это миф. Я никогда не доверял ИИ проектирование архитектуры и использовал его как продвинутый StackOverflow (скармливал конкретную задачу (например, написать SQL-миграцию) и получал кусок кода).

ИИ — это не архитектор, а джун на спидах.

Как только логика усложнялась - гемини ловил «Уроборос багов». Кидаешь баг А - он его фиксит, но появляется ошибка Б. Скармливаешь и её - фиксит, но возвращается баг А. Цикл замкнулся. Лечилось только созданием новых чатов, в которые я кидал код и писал запросы типа "Найди критические ошибки, логические дыры и баги".

Про продуктовую логику нейронка вообще не слышала. В первой версии рефералки был баг, где любой(если его аккаунта ещё нет в БД) мог написать в конце ссылки что любые 9 цифр (?start=1234567890) и получить бонусы.

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

Немного про архитектуру.

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

main.py - это точка входа с настройкой логгеров, коннетами aiohttp и запуском APScheduler

database.py - вся работа с БД

neiro.py - логика общения с апи OpenRouter (стриминг, сжатие фоток через Pillow, JSON-контекст)

states.py - классы состояний aiogram.fsm.state (например, PaymentProcess, GdzMode)

utils.py - легковесные утилиты. Например лок пользователей (защита от спама запросами):

Хэндлеры вынесены в отдельную папку handlers/:

handlers/common_handlers.py - главное меню с обработкой /start (рефералки, utm-метки).

handlers/gdz_handlers.py - сам процесс ИИ-решения (вход в GdzMode, прием фото, видео, кружочков).

handlers/pay_handlers.py - это логика платежей (Robokassa) и "Умная корзина".

handlers/tasks_handlers.py - квесты (выдача премиума за подписку на каналы спонсоров).

Сборку интерфейсов вынес в all_def.py. Не люблю, когда в хэндлерах генерится полотно текста с кнопками. Там же лежат функции склонения слов (1 запрос, 2 запроса, 5 запросов). А в settings.py лежат списки с рандомными ответами бота, чтоб казался живым.

Так же в settings.py я сделал кэширование картинок, тоесть при первом запуске бот грузит фото меню как BufferedInputFile, сохраняет file_id от Телеграма и дальше шлет картинки моментально по ID. Сервак говорит спасибо за сэкономленный трафик)

В handlers/common_handlers.py находится первичная маршрутизация. Вот так обрабатываются рефералки, переходы с сайта, с рекламы и другое при старте:

Диета по токенам

Хранить бесконечную историю диалогов дорого и бессмысленно. В бесплатной версии храню 10 последних сообщений (5 пар вопрос-ответ), а в преме — 30.

Но фотки весят большое кол-во токенов. Если премиум-юзер закинет 30 фоток, OpenRouter выставит мне огромный счет. В итоге я прикрутил ограничение: Из 30 сообщений ИИ видит только 10 последних картинок.

Старые фотки тупо вырезаю из JSON. Подменяю на системный промпт:

С довольно неплохой моделью (gemini 3.0 flash) это работает как часы (она честно признается, что забыла картинку, а не выдумывает что-то из воздуха).

Стриминг, FloodWait и защита баланса

Чтобы бот не выглядел тормозом, я сделал стриминг ответа от ИИ в neiro.py. Я обновляю сообщение в Телеграме чанками по мере получения их от ОпенРоутера.

Но если делать message.edit_text слишком часто, ловишь FloodWait. В итоге я выставил интервал в 0.7 секунд и обернул всё в жесткий try/except:

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

В handlers/gdz_handlers.py это выглядит так:

SQLite тащит

Почему не Postgre? Потому что для микро-SaaS с 2,5к пользователей SQLite хватает за глаза. Но в асинхронной среде она любит кидать ошибку database is locked.

Чтобы этого избежать, я включил WAL-режим при инициализации пула, разделил коннекты на db_writer и db_reader, а сложные операции доверил самому SQL.

Например, 00:00 запускается крон-таска, которая собирает огромную аналитику, начисляет всем активным юзерам +1 ежедневный запрос и сбрасывает просроченные подписки. И это всё это работает атомарно внутри database.py:

Умная корзина на APScheduler

Когда дело дошло до монетизации, всплыли две проблемы:

Первая: юзер оплатил, но забыл нажать кнопку «✅ Я оплатил» в боте. Бот ждет, юзер ждет, товар не выдается, поддержка кипит.

Вторая: юзер сформировал счёт и передумал ("брошенная корзина").

Вместе с LLM я с нуля изучил apscheduler и убил двух зайцев фоновыми задачами. Теперь в handlers/pay_handlers.py при генерации ссылки на оплату я создаю две отложенные таски:

Как это работает?

Через 5 минут срабатывает async def auto_check_payment(), которая тихо стучится в робокассу. Если статус success - бот сам начисляет запросы на баланс и радует клиента. Если статус pending - таска умирает, и в дело вступает 30-минутная таска.

Но она не шлёт спам вслепую, а лезит в БД и проверяет 3 бизнес-правила:

1. await db.has_successful_payment_recently - Не купил ли он другой товар за последние 3 часа?

2. await db.get_latest_invoice_id - А это точно самый последний сгенерированный им счет?

3. await db.can_send_agitation - Не присылали ли мы ему агитацию недавно?

Если проверки пройдены, то юзер получает сообщение: "⏳ Домашка сама себя не решит! Ты начал оформлять покупку, но оплата так и не прошла...". Это поднимает конверсию оплат.

Финал

Почему я не использую Redis для стейтов? Ответ банален: мой дешевый VPS имеет всего 1 гб оперативки. Пул aiohttp, In-Memory стейты и асинхронные таски и так жрут 70% RAM. Редис тупо не влезет.

Как говорится, работает — не трогай.

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

Готов ответить на вопросы по архитектуре и послушать советы в комментариях \(^^)/

P.s. вот ссылка на первую статью о моём проекте:

P.s. Если кто-то хочет потестить вживую(не реклама), то юз бота в тг @gdzshchelk_bot

Арендовать мощные 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 месяца). Буду рад вашему фидбеку в комментариях!

• Новая спецификация MCP 2026-07-28 делает протокол stateless: сессии и handshake больше не нужны.
• Клиент передаёт свою идентификацию и возможности в поле _meta каждого JSON-RPC-запроса.
• Балансировщик может использовать обычный round-robin, ориентируясь на заголовки Mcp-Method и Mcp-Name.
• Roots, Sampling и Logging объявлены устаревшими с минимальным окном поддержки 12 месяцев.
• Финальная спецификация ожидается 28 июля 2026 года после 10-недельного окна валидации SDK.

Model Context Protocol (MCP) — открытый протокол для подключения ИИ-агентов к внешним инструментам и данным. С момента передачи Anthropic в Linux Foundation в декабре 2025-го им управляет Agentic AI Foundation, а число production-серверов уже исчисляется сотнями тысяч. До сих пор MCP работал по модели чата: сначала handshake, потом сервер выдавал идентификатор сессии, который клиент возвращал с каждым запросом.

В релиз-кандидате эта модель заменена на stateless. Клиент кладёт имя, версию и capabilities в поле _meta прямо в тело запроса. Балансировщик читает HTTP-заголовки Mcp-Method и Mcp-Name (SEP-2243) и направляет запрос на любой свободный инстанс — общее хранилище сессий больше не требуется. Если серверу нужен ввод посреди вызова, он возвращает InputRequiredResult, а клиент переотправляет запрос с inputResponses и requestState.

Вместе с ядром обновляются и расширения. Появляется MCP Apps — серверный интерактивный UI в sandboxed iframe с заранее декларируемыми шаблонами. Переработано API долгих задач: вместо tasks/list приходят tasks/get, tasks/update и tasks/cancel. Также шесть SEPов ужесточают авторизацию по OAuth/OIDC, включая проверку issuer по RFC 9207.

Часто задаваемые вопросы

Выводы

Новая спецификация — признак того, что MCP вырос из протокола для локальных подключений в полноценную enterprise-инфраструктуру. Переход к statelessness решает главную операционную проблему масштабирования, но добавляет работы тем, кто уже внедрил stateful-реализации. Главное — помнить, что релиз пока кандидат: production-серверы продолжают работать на спецификации 2025-11-25.

Источник: awesomeagents.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

Решение выросло из собственного опыта: по словам Judson Althoff, главы коммерческого направления Microsoft, привязка оригинального Copilot исключительно к моделям OpenAI была ошибкой. Клиентам важнее не бренд модели, а результат: их данные плюс та архитектура, которая даёт лучший отклик, цену и безопасность.

Microsoft запускает подразделение Frontier Company с бюджетом $2,5 млрд для помощи enterprise-клиентам в выборе ИИ-моделей.

Компания признала: привязка Copilot только к OpenAI была ошибкой, и теперь продвигает мульти-модельную стратегию.

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

Рынок отвечает развитием ИИ-шлюзов и оркестраторов: LiteLLM, Portkey, LangGraph, MCP, Azure AI Foundry, Amazon Bedrock, Google Vertex AI.

Почему одной модели уже недостаточно

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

We made a mistake by binding it to OpenAI models only.

Что это меняет для инженеров

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

Кто ещё строит маршрутизацию

• LiteLLM и Portkey — нормализуют API разных провайдеров.
• LangChain / LangGraph — рассчитаны на много-модельные пайплайны.
• Model Context Protocol (MCP) — делает инструменты переносимыми между моделями.
• Azure AI Foundry, Amazon Bedrock, Google Vertex AI — предлагают десятки моделей за единым endpoint.

Выводы

Microsoft закладывает $2,5 млрд на то, что следующий конкурентный рубеж в enterprise ИИ — не сама модель, а умение ею управлять. Для разработчиков это означает рост спроса на инфраструктуру маршрутизации, observability и политики данных. Если облачная эра научила не привязываться к одному серверу, то ИИ-эра учит не привязываться к одной модели.

Оригинал материала: The New Stack — Enterprise AI Model Routing.

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.

SafeLine WAF — это бесплатный инструмент, который я лично тестировал.

Это полностью open-source решения, продукт с действительно бесплатной Community Edition, где ключевые функции не урезаны.

SafeLine WAF — веб-приложенийный межсетевой экран, который действительно поставляется с разумными настройками по умолчанию

Что он делает:

Защищает веб-приложения от SQL-инъекций, XSS-атак, командных инъекций, CSRF, SSRF, атак включения файлов и других угроз из списка OWASP Top 10. Также поддерживает защиту от CC/DDoS-атак, управление ботами и может работать как шлюз аутентификации.

Почему он:

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

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

Некоторые показатели, которые стоит учитыват

1. Уровень обнаружения - SafeLine (Balanced) (71.65%), ModSecurity (Level 1) (69.74%), Cloudflare (Free) (10.7%)
2. Уровень ложных срабатываний - SafeLine (Balanced) (0.07%), ModSecurity (Level 1) (17.58%), Cloudflare (Free) (0.07%)
3. Точность - SafeLine (Balanced) (99.45%), ModSecurity (Level 1) (82.20%), Cloudflare (Free) (98.40%)

Сбалансированный профиль SafeLine обнаруживает более 70% атак, при этом блокируя легитимный трафик ошибочно всего в 0.07% случаев. Это именно тот уровень настроек по умолчанию, который можно использовать в промышленной среде без постоянного ручного контроля.

Установка выполняется одной командой

После запуска он разворачивается как набор Docker-контейнеров: Tengine (форк Nginx) используется в качестве reverse proxy, отдельный сервис отвечает за семантический анализ, PostgreSQL хранит конфигурации и логи, а удобная веб-панель администратора работает на порту 9443.Community Edition поддерживает до 10 сайтов, чего достаточно для большинства личных проектов и небольших бизнес-сценариев.

Сайт: https://cyberserval.tech/landing/safeline

GitHub: github.com/chaitin/SafeLine (более 21 тыс. звёзд)

Лицензия: GPL-3.0 / MIT (Community Edition)

• 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 и сравнительный анализ дополнены редакционным контекстом.

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

С фичами всё прозрачно: написал код — увидел результат на экране. Быстрая и понятная обратная связь. Но со временем замечаешь, что проблемы повторяются. Приложение тормозит не из-за плохого кода, а потому что на один экран уходит пять-шесть сетевых вызовов. Логика на клиенте. Хочешь что-то изменить — готовь релиз, проходи 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-уровень — это определить, что сломается и кто за это отвечает, до того, как оно сломается.
• Не ждите разрешения. Путь не размечен, но он открыт. Начните с малого — и двигайтесь туда, где задачи становятся интереснее.

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

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

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

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

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

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

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

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

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

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

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

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

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

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

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

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

Главное правило: сначала повторить поведение, потом улучшать

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

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

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

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

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

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

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

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

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

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

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

Shadow testing: как проверить новую систему на реальном трафике

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

Shadow testing — это запуск новой реализации параллельно старой, но без влияния на пользователя. Пользовательский запрос по-прежнему обрабатывает старая система, а новая получает копию запроса и считает результат «в тени». Пользователю этот результат не показывается. Команда только сравнивает ответы.

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

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

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

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

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

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

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

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

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

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

Для клиента ничего не меняется. Для команды появляется управляемость.

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

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

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

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

Рабочая последовательность обычно выглядит так.

Сначала команда выбирает ограниченный участок системы. На этом этапе важно не просто назвать модуль, а описать его границы. Какие сценарии он закрывает? Кто его вызывает? Какие данные он читает и пишет? Какие внешние интеграции использует? Какие неочевидные бизнес-правила в нем есть?

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

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

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

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

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

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

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

Пример: как тот же сервис мигрировали со второй попытки

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

На первом шаге они зафиксировали поведение существующего сервиса. На самые часто используемые сценарии (создание путевого листа, подпись акта осмотра, выгрузка пакета документов за период) написали характеристические тесты на реальных продакшен-данных, обезличенных и сохранённых как фикстуры. Любое будущее изменение поведения теперь падало в CI как явное расхождение.

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

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

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

Типичные ошибки при работе с legacy

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

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

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

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

Пятая ошибка — не удалять старый код. Временное сосуществование старой и новой логики нормально. Вечное сосуществование — нет. Если legacy не удаляется, технический долг не уменьшается, а просто меняет форму.

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

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

Компромиссы, к которым нужно быть готовыми

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

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

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

Когда Strangler Fig особенно оправдан

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

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

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

Когда модернизацию лучше не делать

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

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

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

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

Что получает команда

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

Появляются понятные контракты, наблюдаемость, практика безопасных релизов, культура удаления старого кода. Разработчики перестают бояться legacy, потому что у них появляется метод, а не только желание «когда-нибудь всё переписать».

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

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

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

Если тема микросервисов для вас новая, начните с базового разбора «Что такое микросервисы», а если выбираете архитектуру для проекта — сравните варианты в материале «Монолит или микросервисы». Авторский разбор внутреннего устройства Netflix читайте в статье «Разработчик изучал систему рекомендаций Netflix месяцами».

• Netflix объединила три источника данных: eBPF-сетевые потоки, IPC-метрики и распределённые трейсы.
• Каждый источник строит свой граф; общий вид получается параллельным слиянием слоёв.
• Карта обновляется почти в реальном времени и отвечает на запросы быстрее секунды.
• Инженеры используют её для поиска причин сбоев, оценки зоны поражения и планирования изменений.
• Подход можно перенести в любую распределённую систему, где нужно понимать зависимости.

Почему обычной наблюдаемости мало

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

Инженеру в три часа ночи приходится мысленно склеивать данные из разных источников. Это медленно, чревато ошибками и добавляет стресса. Netflix проанализировала тысячи обращений в поддержку за четыре года и увидела повторяющиеся вопросы: кто мои upstream и downstream, что упадёт вместе со мной, почему сервис отображается в панели мониторинга как Unknown (неизвестный сервис). Ответы на них требовали единого представления о зависимостях.

Три источника данных Service Topology

Главный вывод Netflix: ни один источник не рассказывает всю историю. Поэтому система строит три независимых графа и объединяет их по запросу.

Сетевые потоки eBPF

На сетевом уровне Netflix собирает потоки ядра через eBPF. Это даёт полноту: сюда попадают все соединения, независимо от того, инструментирован сервис или нет. Слой показывает связи между кластерами и приложениями такими, какими они есть на самом деле. Недостаток — не хватает прикладного контекста: видно, что сервис А достучался до IP-адреса сервиса Б, но неизвестно, какой конкретно endpoint вызывался.

IPC-метрики

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

Распределённые трейсы

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

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

Как собирают Service Topology

Приём и обработка потоков

За кулисами работает конвейер, который держит миллионы событий в секунду. Потоки сетевых логов читаются из Kafka в нескольких регионах AWS. Для обработки Netflix использует Apache Pekko Streams — форк Akka, который разбивает нагрузку по группам автомасштабирования и сам управляет обратным давлением.

Восстановление прямых связей

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

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

Хранение и API

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

Что даёт инженерам

Интерфейс и API дают инженерам несколько рабочих сценариев — от ручного расследования до автоматических проверок.

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

Как перенести в свою систему

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

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

Для иллюстрации вот минимальный скрипт, который строит рёбра графа из логов балансировщика:

Часто задаваемые вопросы

Выводы

Service Topology — не просто красивая картинка для панели мониторинга. Это операционная основа, которая ускоряет расследования, снижает риск изменений и даёт автоматическим системам общую картину инфраструктуры. Netflix называет её knowledge graph foundation — фундаментом для интеллектуальной автоматизации, в том числе для автоматического поиска первопричины сбоев.

Service topology provides the knowledge graph foundation that makes this kind of intelligent automation possible.

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

Источники

• From Silos to Service Topology: Why Netflix Built a Real-Time Service Map

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

Проблема не в моделях, а в отсутствии условия остановки. В этой статье разберём, как собрать минимальный, но production-ready каркас агентного цикла: спецификацию до запуска, предохранитель по токенам и ходам, неизменяемый аудит и поверхность для человеческого согласования. Полный код и 80 тестов с 100% покрытием доступны в репозитории автора оригинала.

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

Спецификация должна отвечать на три вопроса: что делает, что не делает и что значит «готово» — в одном предложении.

Circuit breaker режет цикл по жёстким потолкам: число ходов и суммарные токены. Проверка — до вызова модели, а не после.

Ledger в SQLite фиксирует каждый ход: хеш входа, дельту токенов, время, результат. Это аудит, а не лог для отладки.

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

Что такое агентный цикл и почему он уходит в бесконечность

Агентный цикл — это конструкция вида while True, внутри которой языковая модель получает задачу, вызывает инструменты, анализирует результат и решает, продолжать или закончить. Такие циклы лежат в основе оркестраторов вроде LangGraph, CrewAI и AutoGen, а также внутри coding-агентов. Если только начинаете разбираться с LLM, полезно сначала понять, как устроены большие языковые модели, а для практики — заглянуть в основы Python.

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

Почему дорожает каждая итерация:
Агент не начинает с чистого листа. Он каждый раз перечитывает всё предыдущее окно контекста — все неудачные попытки, все промежуточные выводы. Итерация 1 стоит 100 токенов, итерация 10 — уже тысячи. Вы платите за каждый провал снова и снова.

Почему компании сначала платят за чатбота, а потом за агентный рабочий процесс

Gartner фиксирует разрыв в потреблении токенов между пилотными чатботами и production-агентными рабочими процессами в 5–30 раз. А отчёт FinOps Foundation за 2026 год говорит, что 73% компаний превысили изначальный бюджет на ИИ. Цифры взяты из оригинального туториала; полные отчёты Gartner и FinOps Foundation доступны по платным подпискам. Причина разрыва — в неправильном масштабировании: команда планировала стоимость чатбота (~0,04 USD за взаимодействие), а в прод ушёл мультиагентный оркестр (~1,20 USD за взаимодействие, до 70x на сложных задачах).

A loop that runs without an exit condition isn't autonomous. It's a billing event waiting to happen.

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

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

1. Spec writer — заставляет ответить на три вопроса до первого вызова модели.
2. Circuit breaker — режет цикл, если превышены потолки по ходам или токенам.
3. Ledger — ведёт append-only журнал каждого хода в SQLite.
4. Agent loop — связывает три компонента в единый цикл.
5. Review surface — собирает пятиэлементный фрейм и требует человеческой аттестации перед выдачей результата.

Фаза 1. Определить «готово» до первой строчки кода

Самая дорогая ошибка в разработке агентов — не выбор модели, а начало кодинга до того, как команда может одним предложением описать условие завершения. «Агент проверит сайт» — не подходит. «Агент обходит целевой URL, извлекает все теги <title> и <meta name="description">, помечает отсутствующие или слишком длинные и останавливается» — подходит.

Spec writer интерактивно запрашивает три поля, сохраняет их значения в SQLite и возвращает неизменяемый SpecResult(frozen=True). Полученный session_id связывает спецификацию, строки журнала и итоговый результат в одну трассируемую сессию.

Почему frozen=True:
Спецификация — это обязательство, а не черновик. frozen=True запрещает переприсваивать поля объекта SpecResult, поэтому код цикла не может «подвинуть» условие завершения посреди запуска.

Фаза 2. Принудить «готово» на лету

Circuit breaker задаёт два жёстких потолка: turn_limit — максимальное число обращений к модели, и token_limit — суммарное число токенов за всю сессию. Каждый потолок — «строго больше»: если лимит 5 ходов, пятый ещё разрешён, шестой выбросит исключение.

Ключевое правило: breaker.check() вызывается до запроса к модели, а не после. Постфактум проверка бессмысленна: токены уже сожжены. Исключение, а не код возврата, — чтобы нельзя было промолчать.

Как подобрать лимиты для продакшена

Демонстрационные значения 5 ходов / 15 000 токенов слишком жёсткие для реальных задач. Для продакшена автор предлагает настроить лимиты под свой бюджет; в туториале приведён пример breaker = CircuitBreaker(turn_limit=10, token_limit=50000). Если одна сессия должна стоить не дороже 1 USD, а средний ход — 0,10 USD, получается порядка 10 ходов. Конкретный token_limit выбирается исходя из прайсинга модели и среднего размера контекста: чем длиннее история диалога, тем раньше сработает потолок.

• Стартуйте с жёсткими лимитами и разрешайте рост только по метрикам, не по интуиции.
• Отдельно лимитируйте retry-политику: каждый повторный запрос увеличивает и turn_count, и объём контекста.
• Не смешивайте лимит токенов с лимитом выходных токенов модели; circuit breaker считает сумму input + output.

Фаза 3. Записывать всё, что нельзя подделать

Circuit breaker защищает бюджет. Ledger защищает понимание того, что произошло. Это не лог для отладки, а журнал аудита: каждая строка — один ход, append-only, без обновлений и удалений.

Три решения стоит взять на заметку. Во-первых, вместо исходного текста сохраняется SHA-256 хеш входа: так не утекают персональные данные, а одинаковые входы разных запусков можно сравнивать. Во-вторых, pass_fail хранится как INTEGER (1/0), потому что у SQLite нет булева типа. В-третьих, временная метка — datetime.now(timezone.utc).isoformat(), так как datetime.utcnow() объявлен устаревшим в Python 3.12.

Фаза 4. Цикл, который уважает границы

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

Анатомия одного хода простая и строгая: сначала breaker.check(), потом вызов модели, потом ledger.write(), потом проверка stop_reason. Если модель вернула end_turn — возвращаем результат. Если нет — добавляем сообщение continue и идём на следующий круг.

Этот вариант цикла — минимальный текстовый. Если агент использует инструменты, в Anthropic API stop_reason может быть tool_use: тогда нужно выполнить инструмент, вернуть его результат в messages и только потом решать, продолжать или завершать.

Системный промпт обязательно включает все три поля спецификации, а не только done_looks_like. Модели нужна негативная область — то, что агент делать не должен (what_it_does_not), — не меньше, чем позитивная: иначе она начнёт «добавлять ценность» за рамками задачи.

Фаза 5. Поверхность согласования: цикл бежит к человеку

Circuit breaker и ledger решают технические проблемы, но не отвечают на вопрос: «Соответствует ли результат тому, что обещали?» Именно здесь ошибки проходят в прод: вывод выглядит аккуратным, дашборд зелёный, ревьюер ставит галочку.

Review surface собирает пятиэлементный фрейм из SQLite и требует явной аттестации:

1. Исходное обещание — три поля спецификации.
2. Критерий приёмки — поле done_looks_like как явный бенчмарк.
3. Diff — вход первого хода, выход последнего, число ходов, токены, сработал ли breaker.
4. Доказательства — все строки ledger за сессию.
5. Неразрешённые допущения — строки с breach_reason и failed-ходами.

После согласования ревьюер вызывает attest(). Функция собирает пятиэлементный фрейм в каноническом порядке и считает от него SHA-256 — получается frame_hash. Это аудиторская квитанция: она доказывает, что ревьюер видел именно этот фрейм, а не краткое резюме.

Практический пример: SEO-аудит по расписанию

Автор приводит пример SEO-аудита. SEO-аудит имеет естественный ритм: обход, выявление проблем, исправление, ожидание переиндексации. Запускать агента 24/7 бессмысленно — он будет сжигать токены в паузах между событиями. Честная архитектура — cron-задача, которая запускает цикл по расписанию.

Пример упрощён:
В production-варианте стоит проверять URL (допустимые схемы и хосты) и оборачивать requests.get в try/except requests.RequestException, чтобы агент не падал при недоступности сайта.

Cron-строка выглядит так:

Агент выполняет работу, записывает ходы в ledger, и если circuit breaker сработал — результат уходит на человеческую проверку, а не в прод.

Провайдер-независимость через адаптер

Цикл работает с любым клиентом, удовлетворяющим протоколу LLMClient. По умолчанию используется Anthropic, но через адаптер можно подключить OpenAI, Gemini, Ollama, локальные модели или собственный сервер. В репозитории автора показан иллюстративный пример адаптера для OpenAI. Главное — привести ответ к форме, которую ожидает AgentLoop: usage.input_tokens, usage.output_tokens, content[0].text, stop_reason.

Выводы: дисциплина дороже модели

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

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

Define what done looks like before you start. That's the job, and always has been.

Полный код и 80 тестов с 100% покрытием доступны в репозитории автора оригинала: github.com/dannwaneri/production-safe-agent-loop.

Источник: How to Build a Production-Safe Agent Loop — From Exit Conditions to Audit Trails, freeCodeCamp.

Разберём минимальный, но готовый к продакшену скелет: разделение слоёв, валидацию входных данных, централизованную обработку ошибок, версионирование, ограничение частоты запросов и автоматическую документацию. Все принципы применимы и к Express, и к Fastify, и к NestJS.

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

Чистое API — это, прежде всего, разделение ответственности: роутеры, контроллеры, сервисы и валидация живут в разных слоях.

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

Централизованный обработчик ошибок — единственное место, где исключения превращаются в HTTP-ответы.

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

Fastify и NestJS дают те же архитектурные идеи из коробки, но логика слоёв от этого не меняется.

Что мы будем строить

Возьмём намеренно простой домен — каталог товаров. Нам важна не бизнес-логика, а структура. К концу у нас будет REST API с единым форматом ответов, валидацией, версионированием по пути /api/v1, ограничением частоты запросов и интерактивной документацией Swagger.

Структура проекта

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

• api/v1/ — все маршруты версионированы с первого дня. Добавить v2 позже можно новой папкой, а не рефакторингом.
• products/ — фичевая папка владеет роутером, контроллером, сервисом и схемой.
• middleware/ — сквозная функциональность: защита, логирование, лимиты.
• lib/ — утилиты без привязки к фреймворку.

Разделяем ответственность

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

Роутер знает только «куда идти»

Промежуточный обработчик валидации

Промежуточный обработчик validateRequest проверяет body, params и query до попадания в контроллер. Если данные не проходят проверку, ошибка передаётся в централизованный обработчик.

Контроллер переводит HTTP в вызовы сервиса

Контроллер не знает, где хранятся товары. Его задача — извлечь параметры из запроса, вызвать сервис и вернуть ответ. Всё остальное передаётся в централизованный обработчик ошибок через next(error).

Сервис содержит бизнес-логику

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

Валидация на границе с Zod

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

Zod даёт две вещи сразу: проверку во время выполнения и типы TypeScript, выведенные из одной схемы. Промежуточный обработчик validateRequest проверяет body, params и query до того, как запрос попадёт в контроллер. Если данные невалидны, дальше они не идут.

Единый обработчик ошибок

Разбросанная обработка ошибок — один из главных источников хаоса: где-то возвращается { error: '...' }, где-то { message: '...' }, а где-то случайно отдаётся HTML-страница. Решение — один обработчик, через который проходят все исключения.

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

Единый формат ответов

Успешный ответ всегда выглядит как { success: true, data: ... }, а ошибка — как { success: false, error: { code, message, details } }. Фронтенд или сторонний интегратор знает, чего ожидать от любого эндпоинта.

Версионирование API

Версионировать API с первого дня стоит недорого. Добавить версию позже — значит ломать существующих клиентов или городить сложную миграцию.

Новая версия — новая папка src/api/v2/ и новый префикс. Старые клиенты продолжают работать на /api/v1.

Ограничение частоты запросов

Rate limiting защищает API от случайных и намеренных перегрузок. Настроить его в Express помогает пакет express-rate-limit.

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

Документация OpenAPI и Swagger

API без документации годится только для автора. С помощью swagger-jsdoc и swagger-ui-express можно получить интерактивную документацию прямо из JSDoc-комментариев в роутерах.

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

Fastify и NestJS: альтернативы Express

Всё, что мы разобрали, работает и в Express. Но если вы начинаете проект с нуля, стоит взглянуть на альтернативы.

• Fastify — быстрее Express в бенчмарках (порой в два раза), имеет встроенный логгер Pino и валидацию по схеме. Разделение слоёв остаётся на совести разработчика.
• NestJS — популярен в крупных компаниях: слои модулей, контроллеров и сервисов навязаны архитектурой, что упрощает введение новых разработчиков в проект.
• Express — остаётся лучшим выбором, если вы присоединяетесь к существующему проекту или команда уже знает экосистему.

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

FAQ

Минимальный набор для старта

Для самостоятельного запуска понадобятся базовые зависимости и алиасы путей в tsconfig.json. Объявите @/* на папку src, и примеры заработают без ручных правок импортов.

Выводы

Чистая структура API — это не переусложнение. Это минимум, при котором бэкенд можно поддерживать нескольким людям.

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

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

Источники

Идеи и примеры в статье основаны на материале Gavin Cettolo «Clean API Design in Node.js: A Practical Guide» (dev.to).

Agent2Agent — это протокол, управляемый Linux Foundation (изначально представленный Google), который позволяет агентам на разных фреймворках и языках находить друг друга, делегировать задачи и обмениваться результатами. Для Java-экосистемы выпуск SDK версии 1.0.0 означает переход от экспериментальных сборок к инструменту, готовому к промышленной эксплуатации.

Релиз 1.0.0 появился на прошлой неделе, как сообщает InfoQ в очередном выпуске Java News Roundup. В него вошли исправления ошибок, обновление зависимостей и несколько новых возможностей: интеграционный тестовый набор на базе Quarkus для проверки совместимости разных SDK, а также расширение интерфейса A2AHttpResponse и класса A2AClientHTTPError для доступа к HTTP-заголовкам ответов.

• A2A Java SDK 1.0.0 вышел в GA — первая стабильная версия для Java.
• Реализует протокол Agent2Agent для взаимодействия ИИ-агентов.
• Появился интеграционный тестовый набор на базе Quarkus.
• Доступен в Maven Central: org.a2aproject.sdk.
• Параллельно вышел A2A Jakarta 1.0.0.CR1 для Jakarta EE серверов.

Что вошло в релиз A2A Java SDK 1.0.0

• Новый интеграционный тестовый набор (ITK) на базе Quarkus для проверки кросс-SDK совместимости.
• Возможность получать HTTP-заголовки ответов через интерфейс A2AHttpResponse и класс A2AClientHTTPError.
• Исправления ошибок и обновление зависимостей.
• Готовность к использованию в production вместе с A2A Protocol Specification 1.0.

I am pleased to announce the release of A2A Java SDK 1.0.0.Final — our first GA release. The A2A Java SDK is the official Java implementation of the Agent2Agent (A2A) Protocol, an open standard that enables AI agents to communicate and collaborate regardless of underlying framework, language, or vendor.

Параллельно команда выпустила первый релиз-кандидат A2A Jakarta 1.0.0.CR1. Эта интеграция помогает запускать A2A-агентов внутри Jakarta EE серверов, таких как WildFly. В CR1 переименованы пакеты и артефакты, обновлён набор TCK для работы с A2A Java SDK 1.0.0 и настроен запуск CI на Windows.

Зачем это Java-разработчикам

SDK позволяет строить агентные приложения на Java без привязки к Python-стеку. Агенты могут общаться с агентами на Google ADK, LangGraph, CrewAI и других фреймворках через единый протокол. Это особенно важно для команд, где основная инфраструктура уже написана на Java. Рядом с A2A развивается протокол MCP: если MCP соединяет агента с инструментами, то A2A — агента с агентом.

A2A Java SDK 1.0.0 делает Java полноценной платформой для агентных приложений: теперь можно подключить SDK из Maven Central и начать строить агентов, которые работают в одной экосистеме с Python- и TypeScript-решениями.

Источник: InfoQ — Java News Roundup: A2A Java SDK 1.0, Jakarta EE 12, JNoSQL, GraalVM, Micrometer, OpenXava, Gradle.

Мы рады анонсировать выпуск 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 к своему редактору или агенту и проверьте, насколько точнее станут ответы о веб-платформе.

Попытка №1. Путь в лоб: Классы и интерфейсы

Самый очевидный способ - создать родительский класс с переменными, а языки сделать его наследниками. Но это просто… фиаско. Даже если не писать from/toJson, процесс выглядит так:

1. Объявил переменную в родителе.
2. Прописал её в конструкторе.
3. Повторил то же самое для всех дочерних классов (всех языков).

Если бы я работал на аутсорсе в Индии и мне платили за количество строк кода - это был бы идеальный вариант. Но я хотел, чтобы одной строки при объявлении было достаточно.

Попытка №2. Стандарт (ARB/JSON)

Я поплевался, но решил попробовать - «стандарт» всё-таки. Мало ли, может чего поменялось за годы. Вроде всё завелось, но сам процесс… это боль. Бегать по разным файлам, чтобы добавить одну строчку - так себе удовольствие.

Почему я от него окончательно отказался? Когда данных становится реально много (десятки языков, тысячи строк), ты попадаешь в ловушку: тебе нужно эту махину либо целиком держать в памяти, либо постоянно подгружать и парсить. Ради смены одного слова на кнопке заставлять девайс ворочать тяжелые JSON-ы в рантайме - так себе затея для производительности.

Попытка №3. Таблицы и костыли

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

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

1. Добавляю строку в таблицу.
2. Запускаю генератор.
3. Он лепит «родительский» файл.
4. После Freezed генерит toJson, fromJson…

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

Красный флаг для программиста

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

Что происходит на практике? Когда ты пишешь код и тебе нужно добавить одну несчастную строку, тебе лень (читать: нехочется выходить из потока творения) запускать весь этот цикл с генерацией. Ты просто её хардкодишь в надежде «потом скопом всё добавлю одним махом». А «потом» наступает тогда, когда уже весь проект завален хардкодом, и вычищать его - то еще удовольствие. Даже нейросетки с такими запросами помогают не с первого раза, и с сомнительной эффективностью.

Нутром чуял - флоу неправильный. В итоге я пришел к тому, что называю идеальной локализацией.

Эволюция лени: почему Enum победил интерфейсы

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

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

Попытка №4. Рекорды (Records)

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

Идеальный костыль: Enum

В итоге я пришел к самому, казалось бы, «неправильному» способу, который оказался идеальным. Enum. Само название намекает на перечисления и цифры, но оказалось, что хранить в нем буквы и целые фразы - это лучший путь для локализации.

Знаете, мне моё решение так понравилось, что я пошел к нейросетям и проверил его со всех сторон. Все модели остались в полном восторге. Под это дело я даже подготовил монументальную «нейро-статью» на полтора часа внимательного чтения, со всеми графиками, бенчмарками и анализом производительности.

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

А здесь мы будем говорить по делу.

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

Реализация

Принцип разделения:

• enum Strings → типизированный контракт (что существует).
• translator → источник данных (откуда берётся текст).

Структура файлов - минимальная. Никаких внешних зависимостей:

Ядро - strings.dart

Весь контракт локализации в одном enum. Два режима - хардкод switch и серверный кеш - за одним и тем же

. Даже сообщения об ошибках локализации — сами локализованы:

Список языков - languages_enum.dart

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

Хотите грузить с сервера? Одна строка + loader. И

- тоже одна строка, потому что

уже является registry:

Переводчик - i18n/russian.dart

Как это выглядит в жизни (и почему я перестал хардкодить) Я намеренно не привожу здесь код оберток виджетов или конкретных стейт-менеджеров. Всё это - чистая «вкусовщина». Для работы системы нужен лишь элементарный вещатель событий (Notifier), повешенный на метод смены языка.

Но главное - это мой ежедневный флоу. Сейчас, чтобы добавить строку в UI, я просто вызываю нужный мне ключ: Strings.someKey(). Без контекста, везде.

А если ключа еще нет? Я тупо иду в Strings и добавляю одну строчку в Enum. Всё.

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

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

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

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

Claude Opus 4.8 — это топовая модель семейства Claude, ориентированная на сложные задачи: программирование, юридический анализ, глубокое исследование и многошаговые рабочие процессы. Версия 4.8 пришла на смену 4.7 и доступна уже сегодня через API и веб-интерфейс claude.ai.

Claude Opus 4.8 вышел 28 мая 2026 года и заменил версию 4.7 по той же цене.

Fast mode ускоряет работу в 2,5 раза и стоит втрое меньше, чем раньше.

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

В Claude Code появились динамические рабочие процессы с сотнями параллельных подагентов.

Opus 4.8 в 4 раза реже пропускает собственные ошибки в коде, чем предшественник.

Что улучшилось

По словам Anthropic, ключевое изменение — надёжность в агентных задачах. Ранние тестировщики отмечают, что модель задаёт правильные уточняющие вопросы, замечает неточности в планах и не пытается «продавить» заведомо слабое решение. На бенчмарке Super-Agent Opus 4.8 стал единственной моделью, которая завершила все тестовые сценарии от начала до конца, обойдя GPT-5.5 при равной стоимости.

В программировании прирост заметен на всех уровнях сложности: по данным CursorBench, вызов инструментов стал эффективнее — модель использует меньше шагов для достижения того же результата. На юридическом бенчмарке Legal Agent Benchmark модель впервые преодолела порог в 10% по стандарту all-pass — показатель, который ранее был недостижим для языковых моделей.

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

Новые функции платформы

Вместе с моделью Anthropic выпустила несколько обновлений инфраструктуры:

• Dynamic workflows в Claude Code — возможность запускать сотни параллельных подагентов в одной сессии для масштабных задач вроде миграции кодовой базы.
• Effort control в claude.ai — ползунок, который позволяет выбирать между скоростью и глубиной ответа.
• System entries в Messages API — разработчики теперь могут обновлять системные инструкции прямо в массиве сообщений, не прерывая кеш подсказок.

Цены и доступность

Обычный режим стоит прежние 5 долларов за миллион входных токенов и 25 долларов за миллион выходных. Fast mode — 10 и 50 долларов соответственно, что втрое ниже, чем у предыдущих версий. Модель доступна через Claude API под именем claude-opus-4-8.

Выводы

Основные улучшения Claude Opus 4.8 сосредоточены вокруг надёжности агентных задач и честности модели. Для разработчиков это означает, что Claude Code станет более самостоятельным инструментом, способным вести масштабные проекты с меньшим контролем со стороны человека. Снижение цен на fast mode делает флагманскую модель более доступной для задач, где важна скорость.

В ближайшие недели Anthropic планирует выпустить семейство Mythos — модели ещё более высокого интеллектуального уровня, чем Opus. Они уже проходят тестирование в рамках проекта Glasswing, но для массового запуска требуются дополнительные кибербезопасные меры.

Источник: Anthropic — Introducing Claude Opus 4.8

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

«У меня тут несколько одинаковых карт создалось. Я вроде один раз нажимал, а их штук пять висит в приложении».

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

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

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

Мы начали разбираться. Стандартный мониторинг показывал норму: дашборды зелёные, в логах тихо, метрики CPU и памяти без отклонений. При этом в базе обнаруживались дубликаты, которых быть не должно. И только тогда, когда мы внимательно посмотрели на коммунальный API Gateway, то поняли что одно изменение от другой команды поменяло идемпотентность работы endpoint-а.

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

Что произошло: хронология инцидента

Архитектура была классической: Клиент → API Gateway → микросервисы,.

Сценарий развивался почти незаметно для стандартных средств наблюдения:

1. Фронтенд: Пользователь нажимает кнопку «Выпустить карту».

2. Gateway: Запрос начинает обрабатываться в API Gateway.

3. Микросервис по созданию карт: честно выполняет работу: создаёт запись в БД и возвращает `200 OK` в Gateway.

4. Новый микросервис: API Gateway вызывает новый микросервис и получает HTTP 500 в ответ от него. Исключение возникает уже после успешного вызова нашего микросервиса, и это ключевая точка разрыва: Gateway считает весь запрос неудавшимся, а ответ нашего микросервиса теряется.

5. Клиент: получает HTTP 500

6. Реакция: Пользователь видит красную плашку ошибки и логично решает: «Не сработало, пробую снова». Более того, с точки зрения протокола HTTP - запросы, в ответ на которые пришла ошибка HTTP 500, можно пытаться отправлять опять.

7. Петля: Микросервис, ничего не зная о судьбе предыдущих ответов, послушно создавал карту за картой.

Круг замкнулся. Эпидемия началась.

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

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

Вскрылось ошибочное предположение:

«В API Gateway вызов микросервиса создания карт всегда идет последним».

Таким образом идемпотентность достигалась «формально» - ведь если создание карты завершалось с ошибкой - это точно означало что и вызов API Gateway тоже завершится с ошибкой. Сработало ложное чувство безопасности.

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

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

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

FAQ: Часто задаваемые вопросы

1. Почему нельзя просто заблокировать кнопку на фронте?

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

2. Чем идемпотентность отличается от дедупликации в БД?

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

3. Как долго хранить ключи идемпотентности?

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

4. Что делать со старыми клиентами, которые не шлют request_id?

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

5. Обязательно ли делать идемпотентность для всех методов API?

Идемпотентность требуется только для методов, которые изменяют состояние системы — POST, PUT, PATCH и иногда DELETE. Методы чтения (GET, HEAD, OPTIONS) не изменяют данные, поэтому считаются идемпотентными по умолчанию.

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

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

Если метрик ещё нет, вот три косвенных признака, которые помогут заподозрить неладное:

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

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

Итог

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

Метрик на всплески повторных запросов у нас не было. А зря — это самый дешёвый способ увидеть проблему до того, как она обрушит продакшен. Системы, спроектированные на 10% нагрузки, ломаются на 60% — и обычно это становится неожиданностью для команды.

Практический чек-лист: что проверить в своей системе уже сегодня

• Убедитесь, что все критические мутирующие эндпоинты поддерживают ключ идемпотентности.
• Настройте алерты на аномальное количество запросов на создание сущностей от одного пользователя за короткий промежуток времени.
• Проверьте, как ваш API Gateway обрабатывает ошибки — не теряет ли он ответы downstream-сервисов.
• Убедитесь, что фронтенд корректно обрабатывает не только 200, но и 500, 502, 504, не провоцируя пользователя на повторные клики без необходимости.

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

Почему ручная обработка больше не работает

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

• задержки обработки;
• ошибки операторов;
• потеря заказов;
• возвраты из-за долгого подтверждения;
• невозможность работать 24/7;
• высокий риск мошенничества.

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

Именно поэтому современные площадки переходят на автоматизированную архитектуру: платежный шлюз + API поставщика цифровых услуг + система мгновенной обработки заказов.

Почему бизнес выбирает GGPay

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

Одним из таких решений сегодня является GGPAY — сервис для пополнения Steam и других цифровых платформ с поддержкой автоматизированной обработки платежей.

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

• стабильная работа API;
• автоматическое проведение платежей;
• поддержка популярных способов оплаты;
• низкие комиссии;
• высокая скорость зачисления;
• работа 24/7;
• удобная интеграция для сайтов и Telegram-проектов.

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

Как устроена API-интеграция цифровых платежей

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

Типовой процесс выглядит следующим образом:

1. Пользователь выбирает цифровой товар или пополнение.
2. Сайт формирует заказ.
3. Платежный шлюз принимает оплату.
4. После подтверждения транзакции сервер обращается к API поставщика.
5. API выполняет пополнение или выдает цифровой ключ.
6. Клиент получает результат автоматически.

Подобная модель давно используется в международной игровой индустрии и интегрируется через REST API, callback-уведомления и защищенные webhook-системы.

Главное преимущество такой схемы — отсутствие ручной обработки. Бизнес получает возможность масштабироваться практически без увеличения штата.

Какие задачи решает API для цифровых товаров

Современные API-платформы позволяют автоматизировать практически весь цикл продажи:

• пополнение Steam;
• продажу игровых ключей;
• выдачу gift card;
• оплату подписок;
• работу с региональными балансами;
• массовую обработку заказов;
• автоматический возврат;
• мониторинг статусов транзакций;
• защиту от дублирования платежей.

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

На что обращать внимание при выборе API-партнера

Ошибка многих проектов — выбор поставщика исключительно по размеру комиссии. На практике стабильность API намного важнее разницы в 1–2%.

При выборе сервиса необходимо оценивать:

1. Скорость обработки

Для игровых сервисов критична мгновенная выдача. Пользователь не готов ждать 10–15 минут после оплаты.

2. Аптайм инфраструктуры

Если API регулярно падает во время крупных распродаж Steam — бизнес теряет деньги и репутацию.

3. Наличие webhook и callback-систем

Это основа автоматизации статусов платежей.

4. Документация

Качественная документация сокращает время интеграции в разы.

5. Поддержка популярных способов оплаты

СБП, банковские карты, криптовалюты, электронные кошельки — современный рынок требует гибкости.

6. Защита от мошенничества

Антифрод-механизмы и валидация заказов особенно важны в сегменте цифровых товаров.

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

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

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

Сегодня пользователи ожидают:

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

Именно поэтому автоматизированные сервисы показывают значительно более высокую конверсию по сравнению с полуавтоматическими решениями.

Как выглядит современная архитектура цифрового магазина

Профессиональная инфраструктура обычно включает несколько уровней:

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

Дополнительно многие проекты подключают аналитические сервисы, отслеживающие:

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

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

Какие технологии будут доминировать дальше

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

• direct top-up через Steam ID;
• мультивалютные API;
• криптовалютные расчеты;
• AI-антифрод;
• распределенные платежные системы;
• автоматические системы маршрутизации транзакций.

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

Заключение

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

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

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

Реклама. Рекламодатель: ОсОО «НОВАПЭЙ», ИНН:9909710276, erid: 2SDnjf2S7a2

REST API — это веб-сервис, удовлетворяющий шести архитектурным ограничениям, выведенным Роем Филдингом в докторской диссертации «Architectural Styles and the Design of Network-based Software Architectures» (UC Irvine, 2000 год). Начав с «нулевого стиля» — пустого набора без ограничений — Филдинг добавлял каждое из них последовательно, анализируя порождаемые ими свойства распределённых гипермедиа-систем (систем, где переходы между состояниями описаны прямо в ответах сервера). Результат получил название «Передача репрезентативного состояния» (Representational State Transfer).

Индустрия взяла название и проигнорировала большинство ограничений. «REST» теперь означает «любой API, который отправляет JSON по HTTP». Если вы строите публичный API или API для команд за пределами вашей организации — пропущенные ограничения начинают стоить денег.

REST — это шесть архитектурных ограничений, сформулированных Роем Филдингом в 2000 году, а не «любой JSON-over-HTTP API».

Большинство API выполняют лишь 2–3 ограничения из шести: клиент-сервер, stateless и частично слоистую систему.

Самое игнорируемое ограничение — HATEOAS: сервер передаёт клиенту список доступных действий прямо в ответе.

HATEOAS решает три дорогостоящие проблемы: пагинацию, версионирование API и обнаруживаемость ресурсов.

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

Шесть ограничений REST API: разбор по порядку

Ограничение 1: Клиент-сервер

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

Например, если API возвращает displayOrder: 3 и buttonColor: "#ff0000" для какого-либо действия — это нарушение. Порядок отображения должен следовать из позиции элементов в ответе. Цвет должен определяться семантическим свойством вроде class: ["danger"], которое каждый клиент интерпретирует самостоятельно.

Ограничение 2: Stateless (без состояния)

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

Если вы отправляете GET /path-1 с сессионной cookie, и сервер ищет её в памяти, чтобы получить ваш ID пользователя — это серверное состояние. Stateless-версия включает ID прямо в запрос: JWT или тело POST-запроса переносят его вместе с запросом и могут вернуть в ответе для повторного использования клиентом.

Ограничение 3: Кэшируемость

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

Большинство JSON API полностью игнорируют кэширование. Вы отправляете GET /articles/42, а в ответе нет ни Cache-Control, ни ETag, ни Last-Modified. Клиент обращается к серверу каждый раз, даже если статья не менялась неделями.

Ограничение 4: Единый интерфейс (Uniform Interface)

Это главное ограничение. Филдинг разбил его на четыре подограничения — три описываются ниже, четвёртое (HATEOAS) вынесено в отдельный раздел из-за его значимости.

4.1 URI идентифицируют ресурсы. Единообразие здесь — это сама спецификация URI: схема, authority, путь, запрос, фрагмент. Ограничение ничего не говорит о структуре сегмента пути: /articles/42, /x?id=42 и /a/b/c — всё это валидные URI. «Используйте чистые URL-пути» — популярное соглашение и хороший SEO-инструмент, но не то, что требует Филдинг.

4.2 Управление ресурсами через представления. Вы выполняете GET в /whatever, чтобы получить представление ресурса. Заголовок Content-Type сообщает серверу формат тела запроса. Заголовок Accept сообщает, какие медиатипы (форматы обмена данными) поддерживает клиент для ответа.

4.3 Самоописывающие сообщения. Ответ с Content-Type: application/vnd.collection+json сообщает клиенту, как разбирать тело, без каких-либо предположений.

Ограничение 4.4: HATEOAS — то, что пропускают почти все

HATEOAS (Hypermedia As The Engine Of Application State) — четвёртое подограничение Uniform Interface. С первыми тремя большинство API справляются. HATEOAS — место, где останавливается почти каждый.

Разница хорошо видна на примере API для списка чтения. Без HATEOAS вы получаете просто данные, похожие на запись в базе:

Клиент ничего не знает о том, что он может сделать дальше. Чтобы отметить статью как прочитанную, клиент уже должен знать endpoint: PATCH /articles/42 с {"status": "read"}. Разработчик захардкодил эти знания, прочитав документацию. Сам API их не сообщил.

С HATEOAS сервер сообщает клиенту о доступных действиях в стандартизированном виде. Вот тот же ответ с использованием Siren — одного из стандартизированных медиатипов для гипермедиа-API:

Клиент не хардкодит URL и HTTP-методы. Массив actions сообщает, что можно сделать. Навигация приходит из links. Если статья уже прочитана — сервер исключает действие mark-as-read из ответа. Кнопка исчезает в UI. Без единого условного выражения в клиентском коде.

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

Ограничение 5: Слоистая система

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

Ограничение 6: Код по требованию (необязательное)

Сервер может передавать исполняемый код клиенту. Думайте о JavaScript, подключаемом через тег <script> на веб-странице. Для API это ограничение почти не применимо. Филдинг сделал его единственным необязательным.

Что HATEOAS решает на практике

Филдинг разработал HATEOAS для решения тех самых проблем, с которыми API-команды сейчас борются вручную, многократно и каждый раз по-разному.

Пагинация

Без HATEOAS каждый API изобретает собственную схему. Один использует page и pageSize. Другой — offset и limit. Третий — токены на основе курсора. С HATEOAS сервер включает ссылку с отношением «следующая страница». Клиент следует этому отношению. Схема пагинации может измениться, не сломав ни одного клиента: клиент не знал деталей схемы и не знает формата URL.

Версионирование

Без HATEOAS команды версионируют API через URL-пути (/v1/, /v2/) или кастомные заголовки вроде X-API-Version. Поддержка нескольких версий занимает месяцы, клиенты привязываются к версии и ломаются при её выводе из эксплуатации. С HATEOAS сервер вводит новые действия, добавляя ссылки. Старые ссылки продолжают работать.

Обнаруживаемость

Без HATEOAS первый шаг разработчика — чтение Swagger-документации, второй — хардкодинг каждого endpoint в клиент. С HATEOAS корень API возвращает ссылки на все доступные ресурсы. Клиент исследует API так же, как браузер исследует веб-сайт.

Сколько ограничений выполняет ваш API

Итого шесть ограничений. Большинство API удовлетворяют двум-трём: клиент-сервер, слоистую систему и частичную безгосударственность. Большинство нарушают кэшируемость по умолчанию. Большинство полностью игнорируют HATEOAS.

• Клиент-сервер — разделение ответственности за интерфейс и данные
• Stateless — каждый запрос самодостаточен, без серверных сессий
• Кэшируемость — явные заголовки Cache-Control, ETag, Last-Modified
• Единый интерфейс — URI, представления, самоописывающие сообщения и HATEOAS
• Слоистая система — прозрачность промежуточных узлов
• Код по требованию — опционально, для API почти не применимо

Это не оценка. Это карта компромиссов, которые вы приняли — намеренно или случайно. Для небольшой команды с одним потребителем и Slack-каналом для координации пропуск HATEOAS оправдан. Публичный API с сотнями потребителей платит за каждый пропущенный раунд миграции версий. Подробнее об эволюции REST-архитектуры — в главе 5 диссертации Филдинга.

Выводы

Я разочарован тем, что многие не знакомы с 15-летними исследованиями в области гипермедиа, которые стоят за REST. Большинство так называемых REST API — это просто удалённые вызовы процедур через HTTP.

Пройдитесь по шести ограничениям и посчитайте, сколько из них выполняет ваш API. Это даст не оценку, а карту принятых компромиссов — осознанных или случайных. Упражнение отвечает на один вопрос: ваш API — это Representational State Transfer или просто HTTP-транспорт, закрытый для расширения?

Оригинальная статья: Fagner Brack — What Is a REST API, and Why Yours Probably Isn't One. Первоисточник: Глава 5 диссертации Роя Филдинга, UC Irvine.

Сделал себе инструмент, который это решает. Потом оформил в продукт. Называется CoAlly - сервер, который дает агентам общую память.

Что он делает

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

Запрос "проблемы с авторизацией" найдет запись про "token refresh rotation", хотя слова совершенно разные. Работает через эмбеддинги и косинусное расстояние, скоро выйдет фича с анализом смысловой корреляции при поиске.

Подключение

Шаг 1: регистрация

Заходим на coally.cortexally.ai, создаем аккаунт. Получаем API ключ.

Шаг 2: подключение к агенту (Claude, Cursor и др.)

Одна команда в терминале:

claude mcp add coally-nexus --transport sse https://coally.cortexally.ai/sse --header "Authorization: Bearer ВАШ_КЛЮЧ"

Перезапускаем Claude Code. В списке MCP-инструментов должен появиться coally-nexus.

Cursor, Windsurf, VSCode

Заходим в настройки Cursor -> Settings -> MCP -> Settings (значок шестеренки) или создаем/редактируем файл `.cursor/mcp.json` в корне проекта (или в домашней директории для глобального подключения):

Файл `~/.codeium/windsurf/mcp_config.json` для Windsurf или соответствующее меню для VSCode и других его форков.

Перезапускаем IDE|Agent. Готово.

Первая сессия

После подключения агент при первом взаимодействии проиндексирует проект автоматически. Если нет - попросите: "проиндексируй этот проект через CoAlly".

Что происходит при индексации: сканируется дерево проекта, находятся конфиги, важные воспоминания, memorybanks и др., все это эмбеддится и сохраняется как контекст.

Дальше агент сам начнет сохранять контекст работы после значимых изменений. Если нужно явно сохранить что-то: "сохрани контекст этой задачи в CoAlly".

Что получаем

На вопрос "что вчера делали по задаче авторизации? какой статус бага с токеном и сколько времени потребуется на доработку" Агент достает из CoAlly записи: "вчера в Cursor поправили ротацию токенов, причина была в TTL, затронули два файла. Могу сразу продолжить и на основе коммитов ... исправить точечно флоу, время на исправление — N минут."

Если работаете в команде - еще полезнее. Контекст коллеги тоже доступен. Его экспертиза и навыки также постепенно приобретают цифровую версию. Не нужно ждать стендап или писать в Slack.

Ограничения

Агенты иногда игнорируют инструкции и не сохраняют контекст. Бывает. Можно просить явно.

Семантический поиск хорош, но не идеален. Если запрос слишком общий ("что нового?"), результаты будут размытыми. Конкретные вопросы работают лучше.

Бесплатный тариф - 2 проекта. Для личного использования хватает. Для команд - тарифы Team и Enterprise.

Скилл — это markdown-файл со специальной шапкой (frontmatter — служебный блок с метаданными в начале файла), который Claude Code или Anthropic Agent SDK подгружают в контекст агента по триггеру. Не справочник, а пошаговый workflow с чекпоинтами и критерием выхода: написать падающий тест, запустить, увидеть, что он падает, написать минимальный код, увидеть, что тест прошёл.

Поведение по умолчанию у любого AI-агента — кратчайший путь к «готово». Просишь функцию — он пишет функцию. Не задаёт вопросов про спеку, не пишет тест перед реализацией, не думает про границы доверия и не смотрит, как diff будет выглядеть в ревью. Скиллы прибивают сениорский каркас обратно.

• Addy Osmani опубликовал на GitHub набор из 20 скиллов для AI-агентов — markdown-файлов, в которых процесс встроен прямо в инструкции.
• За несколько недель проект собрал 27 000 звёзд и устанавливается в Claude Code одной командой.
• Скиллы покрывают шесть этапов цикла разработки: определение, планирование, сборка, верификация, ревью и выкат, плюс сквозной режим упрощения кода.
• Главные принципы дизайна: процесс важнее текста, антирационализационные таблицы, обязательная верификация, прогрессивное раскрытие, дисциплина по объёму.
• Формат переносится: те же markdown-файлы работают в Claude Code, Cursor, Gemini CLI, Codex, Aider, OpenCode.

Что внутри: 20 скиллов на шесть этапов разработки

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

• Define — /spec: что именно мы строим.
• Plan — /plan: разбиение работы на куски.
• Build — /build: реализация вертикальными слайсами.
• Verify — /test: доказательство, что работает.
• Review — /review: что ускользнуло от автора.
• Ship — /ship: безопасный выкат.
• Cross-cutting — /code-simplify: упрощение в любой фазе.

Большая фича может активировать одиннадцать скиллов подряд, мелкий багфикс — три. Решает мета-роутер с именем using-agent-skills: он смотрит на запрос и подгружает только релевантные.

Пять принципов, на которых всё держится

1. Процесс важнее текста

Скилл — это последовательность шагов, а не эссе. Если положить в контекст агента двухтысячный текст «о лучших практиках тестирования», агент прочитает, сгенерирует правдоподобный ответ и тестов не напишет. Если положить workflow (пиши падающий тест → запусти → убедись, что упал → пиши код → убедись, что прошёл → рефактори), у агента есть, что делать, а у тебя — что проверять.

Это правило одинаково работает и для людей: справочник на 200 страниц никто не открывает в дедлайн, маленький workflow с чекпоинтами выполняется.

2. Антирационализационные таблицы

В каждом скилле есть таблица «оправданий» с заранее написанными контраргументами. Примеры:

• «Эта задача слишком простая для спеки» → критерии приёмки всё равно нужны. Пять строк подойдёт; ноль строк нет.
• «Тесты напишу позже» → «позже» — это слово-обманка. Никакого «позже» не будет: пиши падающий тест сейчас.
• «Тесты прошли — мержим» → проходящий тест — это улика, а не доказательство. Запусти приложение, проверь поведение, дай человеку посмотреть diff.

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

3. Верификация — не опция

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

4. Прогрессивное раскрытие

Все 20 скиллов в контекст не загружаются. На старте сессии активен только маленький мета-навык using-agent-skills, который выбирает релевантный скилл под текущую задачу. Каждый лишний токен в контексте где-то уменьшает качество, поэтому подгружать нужно только то, что реально применимо.

5. Дисциплина по объёму

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

ДНК Google в каждом скилле

Скиллы насыщены практиками из книги Software Engineering at Google и публичной инженерной культуры. Это сделано осознанно: большая часть того, что заставляет работать большой код, задокументирована — и именно это агент пропускает первым делом.

• api-and-interface-design — закон Хайрама: любое наблюдаемое поведение API кто-то рано или поздно начнёт использовать.
• test-driven-development — пирамида ~80/15/5 (unit / integration / e2e) и правило Бейонсе: «если функционал тебе нравится — обязательно прикрой его тестом». DAMP важнее DRY в тестах: тест должен читаться как спецификация, даже ценой дублирования.
• code-review-and-quality — пулреквесты по 100 строк и метки Critical / Nit / Optional / FYI. Большие PR не ревьюят, их штампуют.
• code-simplification — забор Честертона: не сноси, пока не понял, зачем поставили. Удалённый код имеет привычку возвращаться багом.
• git-workflow-and-versioning — trunk-based development и атомарные коммиты.
• ci-cd-and-automation — shift-left и feature-флаги: лови проблемы как можно раньше, выкат и релиз — разные операции.
• deprecation-and-migration — код как обязательство: каждая строка живёт ровно столько, сколько её обслуживают.

Любая модель видела в обучении словосочетание «закон Хайрама», но не применяет его, проектируя API в три часа ночи. Скиллы — способ сделать так, чтобы применяла.

Три режима использования

Режим 1: установка плагином в Claude Code.

Получаешь все slash-команды, скиллы активируются автоматически по контексту.

Режим 2: ручной импорт markdown в свой инструмент. Скиллы — это plain-markdown, переносится куда угодно. В Cursor — в .cursor/rules/. Gemini CLI, Codex, Aider, Windsurf, OpenCode — у каждого свой путь, но workflow одинаковый.

Режим 3: ничего не устанавливать, читать как спеку. Открыть code-review-and-quality.md и применить пятиосевую шкалу серьёзности замечаний (Critical / Nit / Optional / FYI плюс blocking-комментарий) к ревью своей команды. Открыть test-driven-development.md и закрыть следующий спор «нужно ли писать тест первым». Открыть мета-навык и взять оттуда пять non-negotiables в свой AGENTS.md.

Выводы

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

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

Репозиторий лежит на github.com/addyosmani/agent-skills под лицензией MIT, разбор подхода опубликован в блоге Addy Osmani. Те же markdown-файлы можно прочитать как описание того, как должна выглядеть инженерия с AI-агентами — и забрать оттуда пять non-negotiables в свой AGENTS.md без установки чего-либо.

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

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

Вывод простой и непопулярный: для интернет-магазина CMS — это не «движок сайта», а контур бизнеса. Если он не тянет каталог, склады, оплаты и промо — экономия на старте превращается в налог на переделку.

Почему «красивая витрина» не спасает

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

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

Где Битрикс реально оправдан

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

Был у нас запуск для стройсети: 80 000 товаров, несколько складов, отдельная математика скидок для B2B. На чистом PHP такое можно дописать, но это месяцы и жирный бюджет. На готовом контуре мы вышли в прод заметно быстрее — потому что решали задачу бизнеса, а не изобретали велосипед.

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

Kогда разумнее WooCommerce и облако

Если у вас не миллион SKU и не десять складов, а тысяча позиций и простая воронка — связка WordPress + WooCommerce часто выигрывает по скорости запуска и по цене входа. Экосистема плагинов закрывает типовые задачи без заказной разработки на каждый чих.

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

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

Самопис — не зло, но это отдельная ставка

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

Если уже понятно, что платформа не та

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

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

Что мы делаем перед выбором

• Считаем не «стоимость запуска», а стоимость трёх лет жизни: лицензии, хостинг, доработки, интеграции.
• Фиксируем сценарии: каталог, промо, B2B/B2C, обмен с учёткой, маркетплейсы.
• Закладываем буфер на рост — если через год SKU вырастет в пять раз, платформа должна выдержать без полной переделки.
• Перед подписанием уточняем у подрядчика три неудобных вещи: сколько стоит час поддержки после запуска, как закрываются интеграции «не из коробки», и что будет, если через полгода понадобится второй склад или новый тип оплаты.

Ответы без конкретики («сделаем как надо») для меня красный флаг. Нормальный исполнитель называет риски и диапазоны хотя бы порядка величины.

Если очень коротко: не экономьте на фундаменте там, где сайт — канал продаж. Экономия почти всегда вернётся чеком на миграцию.

Подробнее разобрал платформы и критерии в материале на сайте: как выбрать CMS для интернет-магазина — сравнение подходов.

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

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

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

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

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

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

Сервер знает всё. Видит каждое сообщение. Если БД утекла — утекла вся переписка. Если сервер взломали — читай что хочешь. Если завтра компания решит продать данные — технически ничего не мешает.

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

Представь что Алиса хочет написать Бобу. Вместо того чтобы положить письмо на стол и надеяться что никто не прочитает — она кладёт его в запечатанный конверт. Конверт может открыть только Боб своим ключом. Сервер просто передаёт конверт не заглядывая внутрь.

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

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

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

Когда пользователь регистрирует устройство, он загружает на сервер пакет публичных ключей:

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

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

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

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

Ключевой момент: backend всё равно не получает приватные ключи и не может расшифровать сохранённые ciphertext-конверты. Но защита ключей на клиенте — отдельная задача, и её нельзя честно замалчивать.

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

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

. Математика симметрична.

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

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

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

Визуально это выглядит так:

используется для шифрования одного сообщения через AES-GCM, после чего уничтожается. Если атакующий компрометирует

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

, он не сможет откатить HMAC назад и получить старые ключи.

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

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

Мультиустройство: один пользователь, несколько конвертов

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

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

После того как пользователь открыл чат и сообщения расшифровались — кешируем последнее в памяти:

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

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

Rate limiting: дыра которую легко не заметить

Эндпоинт

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

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

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

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

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

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

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

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

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

Около семи вечера начали падать транзакции. Не все - примерно 15%. Команда сразу занялась разбором: логи, метрики, трейсы. Стандартный процесс. Проблему нашли и починили за 40 минут. По меркам платёжки - нормально.

Но пока мы разбирались, в поддержку пришло 300 тикетов. Три сотни «что происходит», «у нас не проходят платежи», «когда заработает». Саппорт ничего не знал - он ждал, пока инженеры выплывут из логов. Клиенты ждали саппорт. Всё это время тишина с нашей стороны читалась как безразличие.

Проблему починили за 40 минут. Разгребали тикеты три дня.

Почему молчание хуже, чем «мы знаем о проблеме»

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

Если транзакция не прошла, но есть страница

с записью «Повышенное время отклика платёжного шлюза. Investigating. 19:12» - большинство людей закрывают вкладку и ждут. Не все. Но большинство.

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

Что мы пробовали до этого

Расскажу честно, через что прошли, потому что это типичный путь.

Шаг первый: Telegram-канал. Завели канал «Статус сервиса». Писали туда когда что-то падало. Работало ровно до тех пор, пока кто-то не забыл написать. А потом написал через два часа когда уже всё починилось. Клиенты не понимали что происходило. Доверие к каналу упало быстро.

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

Шаг третий: Atlassian Statuspage. Это уже нормальный инструмент. Он решил проблему. Но у него есть два неудобства для русскоязычного рынка: оплата в долларах (что в 2022 стало практической проблемой) и серверы за пределами России (что для ряда клиентов принципиально с точки зрения регулирования).

Как устроен нормальный incident workflow со страницей статусов

Я говорю «нормальный» - имею в виду тот, который не требует героизма от дежурного инженера в 2 ночи.

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

Новость в том, что параллельно с уведомлением команды - автоматическое обновление публичной страницы статусов. Не «кто-то должен написать туда», а именно автоматически. Клиент видит «Degraded performance» раньше, чем успевает написать в поддержку.

Дальше инженер работает по стандартному процессу: Investigating - Identified - Monitoring - Resolved. Каждый статус обновляется на странице. Клиенты, подписавшиеся на уведомления, получают апдейты в Telegram или email. Поддержка может в один клик скопировать ссылку на инцидент и отправить клиенту вместо объяснений.

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

Что важно при выборе инструмента

Несколько технических вещей, на которые стоит обратить внимание.

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

Собственный домен.

вместо

. Это доверие и брендинг.

Telegram-уведомления. Для российской аудитории это важнее email. Люди читают Telegram, а не почту, когда ищут статус сервиса в панике.

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

Мы в Flaree делаем страницу статусов именно для таких случаев - серверы в России, Telegram из коробки, оплата в рублях. Сейчас открыт ранний доступ, первые 50 команд получают 3 месяца Pro бесплатно: flaree.ru

Что в итоге

Страница статусов - это не инструмент для больших команд. Это инструмент для любого сервиса, у которого есть клиенты и бывают инциденты. То есть для всех.

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

P.S. Если у вас уже есть страница статусов - напишите в комментариях какой инструмент используете. Интересно что прижилось у разных команд.

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

Кроме того, росту рынка способствует развитие омниканальных решений связи, в которых также очень часто задействованы сервисы для анализа коммуникаций. Российский рынок речевой аналитики, по ранее опубликованному прогнозу TelecomDaily, растет схожими с мировым темпами: в 2025 году он должен был увеличиться на 16% и составить 1,56 млрд руб.

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

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

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

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

Речевая аналитика и предубеждения

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

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

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

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

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

LLM становятся доступнее

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

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

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

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

Принцип работы моделей

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

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

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

14 апреля 2026 года OpenSSL Project выпустил OpenSSL 4.0 — первый мажорный релиз со времён 3.0 (сентябрь 2021). За четыре с половиной года накопилось много удалений и чуть поменьше новых возможностей. Разбираем, что именно сломается при апгрейде и ради чего всё это затевалось.

• OpenSSL 4.0 — первый мажор с 2021 года. Релиз 14 апреля 2026.
• Engine-интерфейс удалён полностью. Ломает gost-engine, старые PKCS#11- и TPM-адаптеры — мигрируйте на providers.
• Поддержка SSLv3 вырезана из кода (выключена по умолчанию была с 2016 года).
• ASN1_STRING стал непрозрачным — прямой доступ к полям через -> больше не компилируется.
• Появилась поддержка ECH (RFC 9849) — TLS прячет SNI от провайдера.
• Добавлен гибридный постквантовый обмен SM2+ML-KEM-768 и подпись ML-DSA-MU.

Что выпилили: список для миграции

OpenSSL 3.0 в 2021 году ввёл архитектуру providers и одновременно объявил engine-интерфейс устаревшим. Четыре года переходного периода закончились: engines больше нет в коде, опция сборки no-engine всегда включена, макрос OPENSSL_NO_ENGINE — всегда определён. Это самое болезненное для тех, кто держал кастомный крипто-плагин: GOST, аппаратные HSM, PKCS#11-токены со старым драйвером.

Из публичных API в 4.0 пропали или стали непрозрачными:

• Engine-интерфейс целиком — providers теперь единственный способ подключить внешнюю криптографию.
• Поддержка SSLv2 Client Hello и SSLv3. SSLv3 деприкейтнули ещё в 2015 году (RFC 7568), в 1.1.0 выключили по умолчанию в 2016-м, теперь удалили из кода.
• Структура ASN1_STRING стала непрозрачной. Прямой доступ к полям — через функции-аксессоры.
• ERR_get_state(), ERR_remove_state(), ERR_remove_thread_state() — объект ERR_STATE теперь непрозрачный.
• Кастомные методы EVP_CIPHER, EVP_MD, EVP_PKEY, EVP_PKEY_ASN1 — устаревшие API удалены.
• X509_cmp_time() и семейство деприкейтнуты в пользу X509_check_certificate_times().
• Скрипт c_rehash — использовать openssl rehash.
• BIO_f_reliable() — был сломан с 3.0 и без жалоб прожил все эти годы.
• Опция msie-hack в команде openssl ca.
• Таргеты сборки darwin-i386 и darwin-ppc.
• Устаревшие эллиптические кривые в TLS (RFC 8422) выключены в сборке по умолчанию — включаются флагом enable-tls-deprecated-ec.
• Explicit EC curves — аналогично, флаг enable-ec_explicit_curves.

Отдельно изменилось поведение глобальной очистки. libcrypto больше не ставит обработчик на atexit(); OPENSSL_cleanup() теперь вызывается как глобальный деструктор при выходе процесса — значит, освобождение памяти по умолчанию происходит позже и в непредсказуемом порядке относительно других деструкторов. Если вам нужна детерминированная очистка до завершения процесса (например, чтобы выявлять утечки под valgrind), вызывайте OPENSSL_cleanup() явно.

Что это значит для ГОСТ-криптографии

gost-engine — основной проект, который даёт OpenSSL понимание российских алгоритмов (ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012, «Кузнечик» и «Магма» по ГОСТ Р 34.12-2015). Как понятно из названия, он реализован именно как engine и без engine-слоя собраться и загрузиться в OpenSSL 4.0 не сможет.

Альтернатива — gostprov, провайдер от того же сообщества на новом API. На 15 апреля 2026 года gostprov покрывает базовые примитивы — ГОСТ Р 34.10-2012 (подпись), ГОСТ Р 34.11-2012 (хеш «Стрибог») и блочный шифр «Магма»/«Кузнечик» (ГОСТ Р 34.12-2015). Что ещё не закрыто по сравнению с gost-engine: часть схем шифрования CMS (ГОСТ-обёртки ключей), VKO KEK-2012 и ряд нишевых TLS-свитов. Если ваш продукт сертифицирован по требованиям ФСБ или продаётся в госсектор — апгрейд на 4.0 нужно планировать заранее, с пересертификацией.

Ветки 3.x продолжают поддерживаться: 3.5 — LTS до апреля 2030 года, 3.4/3.3 — обычные релизы с обновлениями безопасности. Если с 4.0 спешить некуда — остановитесь на 3.5 и дождитесь, пока gostprov покроет нужные вам примитивы.

Что добавили

Encrypted Client Hello (ECH)

ECH — это RFC 9849, принятый в марте 2026 года. В обычном TLS-рукопожатии первый Client Hello содержит SNI — имя сайта, к которому вы подключаетесь — в открытом виде. Провайдер видит его и по нему можно фильтровать трафик или собирать метаданные. ECH делит Client Hello на две части: ClientHelloOuter с именем фронтового домена идёт в открытую, а ClientHelloInner с настоящим SNI шифруется публичным ключом, опубликованным через DNS (HTTPS-запись).

OpenSSL 4.0 — первая мажорная версия с ECH в основной ветке. Серверная и клиентская стороны поддерживают draft-final в полном объёме. Документация проекта — doc/designs/ech-api.md.

Гибридный постквант: SM2+ML-KEM-768

OpenSSL поддерживает ML-KEM (Module-Lattice Key Encapsulation Mechanism, FIPS 203 — постквантовый обмен ключами) и гибриды с ним с версии 3.5. В 4.0 добавили ещё один гибридный обмен — curveSM2MLKEM768: китайский SM2 (RFC 8998) плюс ML-KEM-768 в качестве постквантовой части. Комбинация адресная — она нужна прежде всего для рынка КНР, где SM2 обязателен по национальному стандарту. Плюс новый алгоритм цифровой подписи ML-DSA-MU — вариант ML-DSA с внешним префиксом (prehash) для больших сообщений.

Для остального мира в релизе также появился cSHAKE (SP 800-185 — customizable SHAKE, версия SHAKE с доменным разделением). cSHAKE используется как строительный блок в новых стандартах NIST — именно на нём построен KMAC, а также часть постквантовых подписей. Плюс KDF для SNMP и SRTP — узкие штуки, но их в OpenSSL долго не было.

FFDHE в TLS 1.2 и прочие мелочи

FFDHE (finite-field Diffie-Hellman) по RFC 7919 — способ согласовывать группы для классического DH из фиксированного списка, а не из того, что сервер пришлёт. В TLS 1.3 это сделали сразу, в TLS 1.2 OpenSSL годами поддерживал только «пришли мне параметры». 4.0 закрыл этот пробел.

• FIPS self tests теперь можно откладывать до реального использования — флаг -defer_tests в openssl fipsinstall.
• На Windows можно выбирать статическую или динамическую линковку VC Runtime.
• Нижние границы параметров PKCS5_PBKDF2_HMAC теперь проверяются при работе в FIPS-провайдере.
• Проверка AKID добавлена при установленном X509_V_FLAG_X509_STRICT.
• CRL-верификация получила несколько дополнительных проверок корректности.

Как мигрировать на OpenSSL 4.0

1. Не обновляйтесь в лоб. Сначала прогоните вашу сборку с 3.5 и флагами -Wdeprecated-declarations и OPENSSL_NO_DEPRECATED_3_0, чтобы увидеть, где висит engine-API или структурный доступ к ASN1_STRING.
2. Составьте карту зависимостей: какие ваши библиотеки линкуются с OpenSSL и какие из них делают что-то нестандартное. Особое внимание — ко всему, где в коде встречается ENGINE_*.
3. Если используете ГОСТ — ставьте параллельно gostprov на 3.x, проверьте, что покрываются все ваши примитивы, и только после этого двигайтесь к 4.0.
4. Проверьте, как ваше приложение освобождает ресурсы OpenSSL. Если вы полагались на atexit()-финализацию или ранний OPENSSL_cleanup() в середине работы — добавьте явный вызов в точку, где очистка действительно нужна.
5. Пересоберите статические пакеты. OpenSSL 4.0 несовместим по ABI с 3.x — пакетные менеджеры дистрибутивов ближайшие месяцы будут подтягивать зависимости.

Выводы

OpenSSL 4.0 — релиз не столько про новые фичи, сколько про дочистку хвостов. За четыре с половиной года команда вывела из эксплуатации несколько слоёв устаревшего API и зафиксировала архитектуру providers как единственный способ подключать внешнюю криптографию. Цена — несовместимость по исходникам и ABI. На 15 апреля 2026 года крупные пакеты Debian, Ubuntu, RHEL и Fedora ещё линкуются с 3.x; пересборка экосистемы займёт месяцы, а для продуктов на engines (HSM-адаптеры, gost-engine, старые PKCS#11-драйверы) — ещё дольше.

Практический совет: если у вас нет конкретной нужды в ECH или SM2+ML-KEM-768, ближайший год можно спокойно сидеть на 3.5 LTS и следить за тем, как пересобираются ваши зависимости. Когда пакетные менеджеры дистрибутивов начнут подтягивать 4.0 автоматически — это и будет момент серьёзной миграции.

Полный changelog, downloadable tarballs и ключи для проверки подписи — на странице релиза на GitHub. Сам файл CHANGES.md — хорошее чтение на вечер для всех, кто хоть раз линковал с OpenSSL.

• requestIdleCallback — запустить фоновую задачу, когда браузер простаивает
• :focus-within — стилизовать родителя, внутри которого есть элемент в фокусе
• navigator.onLine + события offline/online — детектировать пропажу интернета
• requestAnimationFrame — плавная анимация без рывков
• Container queries — адаптив относительно размеров контейнера, а не viewport
• crypto.getRandomValues — криптографически стойкие случайные ID без коллизий
• <dialog> — нативный модал с доступностью из коробки
• Web Speech API — распознавание речи без библиотек (только Chromium)
• @supports — CSS feature detection без костылей

1. «Запустим это потом» → requestIdleCallback

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

Поддержка: современные браузеры. В Safari исторически отсутствовал, так что fallback на setTimeout всё ещё полезен.

2. «Почему мой input не подсвечивается?» → :focus-within

Стилизовать элемент с фокусом — просто. А как стилизовать родителя, внутри которого какой-то элемент получил фокус, — задача, которую обычно решают сорока строками JavaScript со слушателями focus и blur. Всё это не нужно: :focus-within делает то же самое одной CSS-строкой.

Поддержка: везде, где это хоть сколько-нибудь важно.

3. «Покажем офлайн-режим» → navigator.onLine

Вечная боль любого PWA — что делать, когда у пользователя пропал интернет (он уехал в лес или зашёл в лифт). Можно писать сложные if-ы — а можно просто слушать события offline и online. На offline складываем данные в IndexedDB, на online отправляем на сервер.

Поддержка: широкая. Одна оговорка: «онлайн» не равно «ваш бэкенд доступен». Это проверка уровня сетевого соединения, а не доступности конкретного сервиса.

4. «Плавная анимация, но проклятая» → requestAnimationFrame

Хотите, чтобы анимация не дёргалась на слабых ноутбуках, а батарея садилась медленнее? Привычка «60 fps = setInterval каждые 16 мс» — плохая идея, и вот почему. Классика, которую все видели:

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

Поддержка: везде.

5. «Карточка должна адаптироваться, но только здесь» → container queries

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

Поддержка: современные браузеры. Если целитесь в старые — добавьте fallback через обычные media queries.

6. «Случайный ID, что может пойти не так?» → crypto.getRandomValues

Именно так рождаются баги:

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

К счастью, есть нативное решение. Не серебряная пуля, но crypto.getRandomValues заметно лучше: больше энтропии, нет странных паттернов, вероятность коллизий резко снижается. Браузер просто делает это правильно. А если вам нужен не произвольный набор байтов, а именно UUID, в современных браузерах есть ещё короче: crypto.randomUUID() выдаёт готовый UUID v4 одной строкой — тоже криптографически стойко и без ручной возни с байтами.

Поддержка: широкая.

7. «Нам нужен модал» → dialog

Больше не нужно ставить 12-килобайтную библиотеку ради модального окна, которое так любят пользователи. Нативный <dialog> даёт клавиатурную навигацию, фокус-трап и корректную работу со скринридерами прямо из коробки — всё то, что в самописных модалах обычно забывают или делают криво.

Поддержка: современные браузеры.

8. «Голосовой ввод был бы крутой фичей» → Web Speech API

Собирались ставить transformers.js, потому что понадобилось распознавание речи? У браузера для этого уже есть Web Speech API. Chromium-браузеры поддерживают его напрямую, Safari — через префиксную версию webkitSpeechRecognition (код ниже как раз это учитывает), в Firefox поддержки нет. Для демо и ассистивных фич — отлично, в проде лучше иметь запасной план на случай Firefox.

Поддержка: Chromium и Safari (через webkit-префикс), в Firefox до сих пор нет.

9. «Не сломает ли это CSS?» → @supports

Хотите выкатить backdrop-filter или :has() и при этом не сломать вёрстку в браузере, где фича ещё не поддерживается? Оборачиваем в @supports — и спокойны: браузер, который знает фичу, получит красивую версию, остальные — дефолтный fallback.

Поддержка: очень хорошая.

Когда всё-таки нужна библиотека

Библиотеки — это отлично, и иногда они действительно необходимы. Но иногда вы ставите зависимость на то, что браузер решил годы назад. Перед npm install полезно спросить себя (или поискать в MDN): «А браузер не умнее меня в этом вопросе?» Иногда ответ — да. И это нормально.

Источник: Sylwia Łask — 9 things you're overengineering: the browser already solved them.

Это перевод статьи WerWolv — введение в USB для разработчиков, которые не работали с железом. Концепции объясняются через аналогию с сетевым программированием, а практический пример — реализация протокола Android Fastboot.

• USB-драйвер можно написать целиком в userspace через libusb — без кода ядра
• Endpoint в USB — аналог порта в TCP: устройство сообщает, какие «порты» открыты и какой протокол используют
• 4 типа передачи: Control (конфигурация), Bulk (большие данные), Interrupt (низкая задержка), Isochronous (аудио/видео)
• USB — master-slave: хост всегда инициирует обмен, устройство только отвечает
• Практический пример: полноценный Fastboot-клиент на C++ за ~50 строк кода

USB — это как сеть

Ключевая мысль статьи: USB можно понимать через аналогию с сетевым программированием. Endpoint — это порт, на который устройство принимает данные. Дескриптор устройства — аналог DNS, который говорит, кто это и какие «сервисы» доступны. Вам не нужно быть инженером встраиваемых систем, чтобы работать с USB — как не нужно быть сетевым специалистом, чтобы работать с сокетами.

Шаг 1: узнаём, что за устройство

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

Здесь 18d1 — Vendor ID (Google), 4ee0 — Product ID (загрузчик Pixel). Это уникальные идентификаторы, по которым хост находит нужный драйвер. VID выдаётся организацией USB-IF компаниям за деньги, PID назначает сам производитель.

Более подробный вывод:

Driver=[none] означает, что ОС не загрузила драйвер — именно то, что нужно для написания своего.

Шаг 2: общаемся через libusb

Библиотека libusb позволяет общаться с USB-устройствами из пользовательского пространства. Она предоставляет универсальный драйвер и API для отправки запросов — без написания кода ядра.

Пример: обнаружение устройства по VID:PID и получение дескриптора через Control endpoint:

Каждое USB-устройство имеет Control endpoint на адресе 0x00 — это стандартизированная «точка входа», через которую хост получает дескрипторы (кто устройство, какие интерфейсы, какие endpoint'ы). Аналогия: это как DNS-запрос перед подключением.

Endpoint'ы: порты USB-устройства

Endpoint'ы — аналог портов на сетевом устройстве. Устройство описывает в дескрипторе, какие endpoint'ы доступны и какой протокол каждый из них использует. Четыре типа:

• Control — один на устройство, адрес 0x00. Для конфигурации и запроса информации. Решает проблему курицы и яйца: чтобы узнать endpoint'ы, нужен endpoint — и это он
• Bulk — большие объёмы данных, низкий приоритет. Используется в Mass Storage (флешки), CDC-ACM (Serial over USB), RNDIS (Ethernet over USB)
• Interrupt — маленькие данные, минимальная задержка. Клавиатуры и мыши опрашиваются 1000+ раз в секунду через HID. Название обманчивое: реальных прерываний нет, хост просто очень часто опрашивает
• Isochronous — потоковые данные с гарантией тайминга. Аудио и видео, где задержка означает заикание

IN и OUT: USB — master-slave протокол, устройство никогда не говорит первым. IN = хост просит данные «к себе», OUT = хост отправляет данные «от себя». Направление кодируется в старшем бите адреса endpoint'а.

Практика: Fastboot-клиент за 50 строк

Протокол Fastboot (документация) предельно прост: хост отправляет строковую команду, устройство отвечает 4-символьным статусом + данные:

Реализация через libusb — отправляем команду на OUT Bulk endpoint, читаем ответ с IN Bulk endpoint:

Это всё. Два вызова libusb — и мы общаемся с загрузчиком Android без единой строки кода ядра.

Полный текст с исходным кодом: USB for Software Developers, WerWolv.

Мне эта модель быстро наскучила.

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

Сразу зафиксируем рамки, чтобы не плодить фантомные ожидания:

- это не убийца Telegram;

- это не презентация для инвестора с KPI и growth loops;

- это не проповедь о том, как всем теперь жить.

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

И вот здесь началось смешное.

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

Что это вообще такое

На текущем этапе это PWA-мессенджер.

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

«настоящие пацаны пишут только натив». Можете не разогреваться, я это всё уже сам себе рассказал.

Почему все равно PWA:

- мне нужен был короткий путь от идеи до живого клиента;

- мне нужен был быстрый цикл выката без ритуальных танцев с

магазинами приложений;

- мне нужен был клиент, который можно быстро ломать, чинить,

пересобирать и снова кидать в бой;

- мне нужно было что заработает на разных платформах;

- мне нравится, что PWA живет в браузерной песочнице, а не лезет в телефон как хозяин квартиры.

У PWA есть реальные потолки:

- нет такой свободы по платформенным API, как у нативного клиента;

- фон, пуши и некоторые сценарии мобильной жизни работают хуже, чем

хотелось бы;

- нет нормальных VoIP-пушей (звонки работают только когда приложение

открыто), нет нормальной интеграции со списком вызовов телефона;

- по голой производительности натив его обгоняет.

И, да, Service Workers иногда ведут себя как подростки в пубертате, а iOS местами режет фоновую жизнь PWA так, будто лично обиделась на идею веб-клиента. Я в курсе. Выживаем с тем, что есть.

Но для моей задачи PWA дал главное: скорость эволюции. А в экспериментальном проекте это иногда важнее, чем стерильная идеология.

И да, работает эта штука подозрительно хорошо. Лучше, чем я ожидал, если честно.

Зачем вообще писать еще один мессенджер, когда мир и так ими забит

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

Потому что я люблю контролировать инфраструктуру, а не молиться на чужую.

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

Потому что мне скучно.

Да, это тоже важная часть правды. На обычной работе мозг периодически начинает зевать от предсказуемости. А когда ты в одиночку пытаешься собрать живой real-time-сервис, где есть сессии, доставка сообщений, поиск, синхронизация состояния, очереди и weird cases мобильной сети —

то зевота быстро заканчивается.

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

Где начинаются не разговоры про highload, а настоящая инженерная жизнь

Пока не собираешь такое сам, кажется, что мессенджер — это просто чатик.

Ну текстик, ну websocket, ну кнопка «отправить», господи. А потом начинается взрослая часть спектакля.

1. Сообщение должно не просто уйти, а дойти правильно

Самая скучная и самая дорогая ошибка — считать, что «отправил» значит

«доставил».

Нет. В реальной жизни между клиентом, сетью, сервером и хранилищем полно мест, где всё может стать интересно:

- клиент послал пакет, но сеть моргнула;

- сервер принял, но клиент не получил подтверждение;

- клиент решил, что ничего не дошло, и отправил повторно;

- внезапно у тебя уже не просто доставка, а идемпотентность,

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

дублями.

И это только один кусок.

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

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

Инженерная реальность куда веселее:

- локальный optimistic update на offline-first клиенте хочет быть

быстрым;

- серверная истина хочет быть правильной;

- база хочет жить в своей временной линии;

- несколько устройств одного пользователя могут в это время смотреть на

мир разными глазами.

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

3. Race condition — это когда баг уже произошел, но ты еще не знаешь, где именно тебя унизили

Race conditions — мой любимый жанр инженерного фольклора. Это когда всё прекрасно, пока ты смотришь. И ломается ровно в тот момент, когда отвлекся налить кофе.

Условно:

- один поток думает, что пользователь в онлайне;

- второй уже считает, что он отвалился;

- третий в это время честно пишет новое состояние;

- четвертый с невинным лицом отдает клиенту вчерашнюю правду.

А потом ты сидишь и объясняешь себе, почему в 99.7% случаев всё идеально, а в оставшихся 0.3% система внезапно начинает разговаривать голосами. А когда еще и пытаешься заставить работать реалтайм систему еще в кластере, то все сложности возводятся в квадрат.

4. Любая «маленькая фича» очень быстро приходит за твоей архитектурой с ножом

Захотел новую механику? Например, необычную резервацию UIN еще до регистрации? На бумаге выглядит забавно. На бэкенде начинается вечеринка:

- появляется состояние для еще не существующего пользователя;

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

- нужно думать о TTL, освобождении, гонках, повторных запросах и кривом клиентском поведении;

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

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

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

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

И тут выясняется, что в реальном мессенджере мало просто «хранить сообщения». Нужно еще:

- быстро искать;

- не ломать горячий путь доставки;

- не превращать сервер в печку под нагрузкой;

- думать наперед, где потом начнется горизонтальное масштабирование, а

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

Чтобы это не выглядело как очередная литература про «сложности highload», вот живой пример. Это кусок поиска по групповым сообщениям в моем бекенде: с проверкой доступа, выборкой только текстовых сообщений и сортировкой по релевантности.

Под этот запрос у меня лежит не молитва, а вполне конкретная опора: partial GIN index по выражению`(content->>'text') gin_trgm_ops`.Иначе такая красота очень быстро превращает сервер в отопление стойки за счет тупого перебора JSONB.

А вот так тот же самый функционал очень часто пишут новички — вроде работает, пока данных смешно мало:

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

На реальном объеме истории в проде разница здесь может быть уже не в процентах, а на порядок и выше. То есть это очень быстро превращается не в «чуть-чуть быстрее», а в 10x+, а дальше всё зависит от размера истории, доли текстовых сообщений, партиций и того, насколько сильно вы любите мучить PostgreSQL.

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

6. Очереди, ретраи и backpressure — это не украшения, а повод спать чуть спокойнее

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

То есть нужны:

- очереди (Kafka, или что вы там предпочитаете);

- повторные попытки (retry-логика);

- backpressure;

- вменяемая реакция на временную деградацию (graceful degradation);

- circuit breaker чтобы какой-нибудь маленький и вроде бы некритичный сервис не мог каскадно положить бы всю инфраструктуру;

- архитектура, которая умеет признавать, что мир не идеален.

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

Интерфейс я подсматривал у Telegram. И да, специально

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

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

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

Моя любимая инженерная шалость: UIN-рулетка до регистрации

Тут я, конечно, немного похулиганил.

Я сделал резервацию UIN еще до этапа регистрации. То есть можно зайти, поймать красивый номер, а уже потом решить, нужен тебе вообще этот зоопарк или нет.

С человеческой стороны это фан, ностальгия и немного ICQ-вайба.

С серверной стороны это пачка вопросов:

- как хранить состояние для «почти-пользователя»;

- как не раздать красивые номера слишком щедро;

- как не дать мимо проходящему ботнету выгрести пул;

- как освобождать резервы и не плодить мусор;

- как не застрелить логическую целостность ради красивой игрушки.

С практической точки зрения миру, возможно, и не нужна эта фича. С инженерной — она просто слишком вкусная, чтобы я прошел мимо.

Про безопасность — без дешевой магии и без сказок для инвестора

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

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

- транспорт закрыт современным TLS 1.3 (который на текущий момент, март 2026, взломать прямым криптографическим методом практически невозможно);

- клиент живет как PWA в браузерной песочнице, какая уже сама по себе имеет ряд уровней защиты;

- поверх этого я стараюсь не творить откровенной дичи;

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

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

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

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

Почему я вообще тащу это именно на TProger

Потому что TProger — это место, где тексту мало быть наглым. Здесь за дерзость прощают только одно: если под ней есть мясо.

А у меня как раз тот случай, когда мне интереснее не «собрать лайки», а получить нормальную техническую реакцию:

- где архитектура выглядит спорно;

- где логика доставки сообщений может начать чудить;

- где PWA упрется в реальные ограничения платформы;

- где резервация UIN создает лишнюю поверхность атаки;

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

- где в протоколе, порядке событий, ретраях или кешировании я недооценил крайний случай.

Мне не нужен хор в духе «вау, круто».

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

Вот ему я и пишу.

Что я от вас хочу

По сути — честной драки, но умной.

- Хотите проверить, как это переживает плохую сеть — отлично.

- Хотите посмотреть, как выглядит поведение в edge-cases — вообще прекрасно.

- Хотите понять, насколько легко читается логика протокола — давайте.

- Хотите найти баг в порядке сообщений, в кеше, в подтверждениях, в резервации UIN, в клиентском поведении — тем более.

Только давайте без детского жанра «я что-то молча сломал и ушел сиять в закат». Если найдете слабое место, баг, странность, дыру, подозрительный сценарий или красивый способ заставить систему вести себя не так, как я планировал, — пишите.

Мне это полезнее, чем аплодисменты.

И да: я не заявляю, что построил новый и единственно верный мессенджер.

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

Что можно делать прямо сейчас

- Если вы параноик или устали от мейнстрима и навязанных решений — держите это как запасной канал связи.

- Если вы соскучились по временам красивых UIN — приходите ловить UIN-номер.

- Если вы любите sniff, разбор трафика и сетевые игры — смотрите что идет по проводу.

- Если у вас профессиональная привычка первым делом искать edge-cases — вот, собственно, ради вас всё это и принесено.

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

Что дальше

Планы без корпоративной шелухи, но вполне понятные:

- дальше допиливаю PWA-версию;

- нативные Android и iOS-клиенты — в планах, но пока не в приоритете;

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

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

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

Итог

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

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

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

Если хотите просто еще один канал связи — пожалуйста.

Если хотите посмотреть и проверить, насколько крепок мой цифровой эксперимент, — тем более пожалуйста.

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

Добро пожаловать.

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

PS:

Меня там можно найти по нику IGRYM или по UIN 10001. Также есть внутренняя группа для первых пользователей (Early Birds, доступна на экране списка чатов через «+» вверху экрана)

Ссылки:

- Приложение: https://beta.plumb-app.ru/

- Телеграм-канал с новостями проекта: https://t.me/plumb_channel

- Телеграм-группа обсуждения: https://t.me/plumb_group

Разработчик Nahuel Nucera решил эту проблему: MiniStack — полностью бесплатная замена LocalStack с открытым исходным кодом, которая эмулирует 33 AWS-сервиса на одном порте. И, в отличие от LocalStack, запускает настоящие базы данных и контейнеры вместо мок-заглушек.

MiniStack — бесплатная open-source замена LocalStack (MIT-лицензия)

33 AWS-сервиса на одном порте — S3, SQS, DynamoDB, Lambda, IAM, RDS, ElastiCache, ECS и другие

Реальная инфраструктура: RDS поднимает настоящий Postgres, ElastiCache — настоящий Redis, ECS — Docker-контейнеры

Запуск за 2 секунды, 30 МБ RAM в простое (vs 30 секунд и 500 МБ у LocalStack)

Drop-in совместимость с boto3, AWS CLI, Terraform, CDK, Pulumi

Почему LocalStack стал платным

LocalStack сменил лицензию с Apache 2.0 на Business Source License (BSL) и перенёс ключевые сервисы — S3, SQS, Lambda, IAM, Cognito, EC2 — в платный тир. Бесплатная версия LocalStack Community фактически перестала покрывать базовые сценарии локальной разработки.

Для коммерческих команд LocalStack Pro стоит от $35/мес на разработчика. Для опенсорс-проектов и индивидуальных разработчиков это создало вакуум — и MiniStack его заполнил.

Что умеет MiniStack

MiniStack — это один Python ASGI-сервер, который эмулирует AWS API на порте 4566. Ваши существующие boto3-клиенты, Terraform-провайдеры, CDK-стеки и AWS CLI работают без изменений — достаточно указать endpoint.

33 поддерживаемых сервиса

• Хранилище: S3 (с версионированием, Object Lock, CORS, lifecycle), EBS, EFS
• Очереди и события: SQS (FIFO + DLQ), SNS (fanout в SQS и Lambda), EventBridge, Kinesis, Firehose
• Базы данных: DynamoDB (TTL, транзакции), RDS (реальный Postgres/MySQL), ElastiCache (реальный Redis), Athena (реальный SQL через DuckDB)
• Вычисления: Lambda (реальное исполнение Python, warm pool), ECS (реальные Docker-контейнеры), Step Functions, EMR
• Сеть и безопасность: EC2 (instances, VPC, subnets, security groups), ALB/ELBv2, Route53, Cognito, IAM, STS
• Конфигурация: SSM Parameter Store, Secrets Manager, CloudFormation, Glue Catalog

Реальная инфраструктура, а не заглушки

Главное отличие MiniStack — он поднимает настоящие сервисы там, где это важнее всего:

• RDS — вызов CreateDBInstance с engine=postgres запускает реальный PostgreSQL-контейнер и возвращает настоящий host:port
• ElastiCache — реальный Redis-контейнер, а не in-memory имитация
• ECS — реальные Docker-контейнеры
• Athena — реальный SQL через DuckDB (при наличии)

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

Сравнение с LocalStack

Ключевые метрики рядом:

• Запуск: MiniStack ~2 сек vs LocalStack ~15–30 сек
• RAM в простое: MiniStack ~30 МБ vs LocalStack ~500 МБ
• Docker-образ: MiniStack 150 МБ vs LocalStack ~1 ГБ
• Лицензия: MiniStack MIT vs LocalStack BSL (ограниченная) / Proprietary ($35+/мес)
• RDS, ElastiCache, ECS: MiniStack — реальные контейнеры бесплатно vs LocalStack — только в Pro

При этом MiniStack совместим с тем же API: endpoint-url, boto3, Terraform, CDK — всё работает без изменения кода.

Как начать

Три способа установки:

Проверка работы:

Для Python-проектов:

Выводы

MiniStack не претендует на полное покрытие всех AWS-сервисов — это задача LocalStack Pro. Но для типичной локальной разработки (S3 + SQS + DynamoDB + Lambda + IAM + RDS) он закрывает 90% потребностей при нулевой стоимости, мгновенном запуске и MIT-лицензии.

Проект активно развивается (947 звёзд на GitHub, версия 1.0.7) и уже привлёк внимание на Hacker News (227+ баллов). Если вы искали замену LocalStack после перехода на платную модель — попробуйте.

Ссылки: GitHub | Сайт | PyPI | Docker Hub