Что такое Calab и что именно удалось собрать за сутки
Calab - это self-hosted мессенджер для команды, который разработчик Илья Трикоз собрал примерно за сутки с помощью иерархии ИИ-агентов на моделях Claude. Первый промпт ушёл в пятницу 25 сентября в 22:35, а вечером следующего дня версия 0.3.1 уже стояла в проде: подписанные сборки под macOS, Windows и Linux, веб-версия и лендинг. Разбор кейса опубликован на Habr.
Масштаб участия человека в этой истории лучше всего описывает сам автор.
«Строчки кода я не написал. Ни одного теста не запустил. Всё остальное сделали модели».
Всего он отправил 90 сообщений, 29 из которых были скриншотами с подписью «сделай как тут». Это описание собственного проекта, а не независимое тестирование, и цифры стоит читать именно так.
Что входит в Calab: голос, чат, роли, стрим экрана
По набору функций Calab ближе всего к Discord, только разворачивается на своём сервере. В описании кейса перечислены:
- голосовые комнаты;
- чат с пузырями как в Telegram, реакции, закрепы, упоминания, превью ссылок и поиск с морфологией;
- гостевой доступ по ссылке без регистрации;
- роли и права;
- стрим экрана.
За пределами этого списка открытых данных нет, поэтому сравнивать Calab с Discord по глубине интеграций, ботов и модерации пока не на чем.
Что значит «за сутки»: таймлайн и артефакты
Сутки здесь считаются от первого промпта до рабочей версии в проде. Хронология короткая: пятница 25 сентября, 22:35 - первый промпт; вечер субботы - версия 0.3.1 в продакшене. В релиз вошли подписанные сборки под macOS, Windows и Linux, веб-версия и лендинг.
Первый промпт, по описанию, был стеной текста без запятых, где смешаны требования: продукт вроде Discord, чат как в Telegram, звук и стабильность как в Zoom, голос, роли и права, стрим экрана, PostgreSQL и отдельно «эхо не должно быть совершенно». Из 90 сообщений почти треть оказалась картинками: агент получал визуальный референс, а не текстовое описание интерфейса.
Слово «прод» здесь не преувеличение: сборки подписаны, версия опубликована. Другой вопрос, что тестового контура в схеме не было, и часть дефектов всплыла уже у пользователей.
Архитектура Calab: LiveKit, Opus с DTX, AV1 simulcast и Go-сервер
Стек собран вокруг медиасервера LiveKit. Он работает как SFU (Selective Forwarding Unit): принимает потоки от участников и раздаёт их остальным, не смешивая звук и видео на своей стороне. Нагрузка на сервер падает, обработка кодеками остаётся на клиентах.
Голос и видео: почему Opus с DTX и AV1 simulcast
Аудио идёт кодеком Opus с включённым DTX (Discontinuous Transmission). В тишине пакеты не отправляются вообще: трафик падает до 0,1 кбит/с, а на речи держится в районе 30-45 кбит/с. Для команды, которая держит голосовую комнату открытой весь день, это разница между постоянным потоком данных и почти нулевым потреблением в паузах. Автор приводит эти цифры в описании голосовой части.
Обработку звука закрывают две технологии: RNNoise, нейросетевое шумоподавление, которое работает на устройстве, и эхоподавление AEC3 из стека WebRTC.
Стрим экрана сделан в AV1 с simulcast. Отправитель кодирует картинку сразу в нескольких качествах, а зритель получает тот слой, который реально видит. Слой, на который никто не смотрит, не кодируется. Текст остаётся резким, а код или документ едут на 20-300 кбит/с. В одной комнате поддерживается до трёх стримов.
Для self-hosted решения это определяющие параметры: именно simulcast решает, сколько трафика съест демонстрация экрана в команде из десяти человек.
Сеть и обход файрволов: TURN/TLS на 443
Отдельная часть архитектуры - работа в сетях, где UDP режут. Цепочка деградации выглядит так: при блокировке UDP соединение падает на TCP, затем на TURN/TLS на порту 443, и снаружи трафик выглядит как обычный HTTPS. Автор отмечает, что проверял это из-за VPN с одного публичного IP.
Для корпоративной сети это ключевой момент. Голос и видео по UDP в офисах часто блокируют, и без запасного маршрута через 443 звонки просто не поднимаются.
Сервер и клиенты: Go, Electron и вес образа
Серверная часть написана на Go. Образ сервера весит около 20 МБ, а в простое процесс занимает около 40 МБ оперативной памяти. Клиенты сделаны на Electron, плюс есть веб-версия и мобильный веб, интерфейс переведён на четыре языка. В первом промпте среди требований упоминался PostgreSQL.
Цифры по образу и памяти важны при планировании хостинга: сервер на 40 МБ в простое можно держать на дешёвой VPS, а вот медиатрафик и TURN-релей дают совсем другую нагрузку. Electron на клиенте означает привычные для этого фреймворка требования к памяти на рабочих машинах.
Как была устроена оркестрация ИИ-агентов
Детали оркестрации приведены со слов автора кейса. В открытом тексте разбора нет построчной раскладки по агентам, поэтому читать это стоит как описание процесса, а не как проверенную методологию.
Иерархия моделей: кто за что отвечал
В схеме участвовали три модели Claude: Fable 5.1, Opus 5.5 и Sonnet 5. Логика иерархии прозрачна: сильные модели берут архитектуру и сложные решения, более дешёвые закрывают рутинные правки. Точное распределение ролей в кейсе не расписано, поэтому подставлять конкретную модель под конкретную задачу не стоит.
Про Opus 5.5 известно больше: Anthropic выпустила её 22 сентября 2026 года, у модели контекстное окно на 1 млн токенов, до 128 000 выходных токенов в стандартном режиме и профиль «текст и изображения → текст» (спецификация модели в разборе WPS). Дата выпуска объясняет тайминг кейса: до релиза собрать такой проект на этой модели было невозможно. Отдельно мы разбирали что даёт Claude Opus 5.5 для кодинга и автономных задач, включая цены за миллион токенов.
git worktree, ADR и документация раньше кода
Агенты работали в изолированных git worktree. Это штатный механизм git, который позволяет держать несколько рабочих копий одного репозитория с разными ветками одновременно. Для параллельных агентов он даёт главное: каждый правит свой файловый слепок и не перетирает чужую ветку.
Второй элемент - документация и ADR (Architecture Decision Records), созданные раньше кода. ADR фиксируют принятые решения: почему выбран LiveKit, как устроены права, где проходят границы сервисов. Когда такие записи появляются до реализации, агент получает контракт и не изобретает архитектуру заново в каждом сообщении.
Приём не уникален для Calab. Похожий оркестратор на Java с git worktree, CLI-сессиями агента и веб-дашбордом описывал другой разработчик, и изоляция рабочих копий там тоже лежит в основе схемы.
Параллелизм: около 12 агентов в пике
В пике параллельно работало около 12 агентов. Изоляция через git worktree плюс заранее зафиксированные контракты снижают число конфликтов, но не убирают их полностью: чем больше одновременных правок, тем выше шанс, что два агента решат одну задачу по-разному. Ревью и сборка в такой схеме нужны не меньше, чем в обычной команде.
Сколько стоило собрать Calab и почему 80% ушло на кэш контекста
По прайс-листу API сборка обошлась примерно в $12 400. Порядка 80% этой суммы ушло на чтение кэша контекста, а не на генерацию кода. Разбивку приводит автор кейса, независимого подтверждения расчёта нет.
Из чего складываются $12 400
Основная статья - повторное чтение. Агенты постоянно перечитывают документацию, ADR и уже написанный код: без этого они не удерживают контракты между сессиями. Генерация нового кода в этом балансе оказалась меньшей частью счёта, что плохо укладывается в привычную интуицию «платим за написанные строки».
Почему кэш контекста дороже генерации кода
Чем больше контекст и чем чаще к нему обращаются, тем выше доля чтения. Иерархия агентов и параллелизм как раз увеличивают частоту обращений: каждый агент перед правкой подтягивает документацию, спецификации и чужие изменения.
Отсюда практический вывод для тех, кто повторяет схему: расходы растут не от объёма сгенерированного кода, а от размера и структуры контекста. Помогают чистка CLAUDE.md и AGENTS.md, дробление документации на короткие файлы и отказ от лишних данных в промпте; разбор оркестрации моделей, субагентов на дешёвых моделях и работы с кодовой базой описывает эти приёмы подробнее. Про экономию на чтении кэша есть отдельный материал о Claude Fable 5.1 в AWS Bedrock.
Ещё один пункт, который редко попадает в смету: счёт за API уходит зарубежному провайдеру, и оплатить его российской картой нельзя. Часть разработчиков закрывает это виртуальной картой зарубежного банка с пополнением рублями через СБП, такие карты выпускают дистанционно и привязывают к Apple Pay, Google Pay, Alipay и WeChat. Расходы на операции стоит закладывать в бюджет рядом со счётом за токены.
Ошибки агентов: CSP, ломавший голос, Caps Lock и мобильный Safari
Автор отдельно разбирает промахи агентов. В описании кейса названы три: CSP, ломавший голос, поведение Caps Lock и мобильный Safari. Развёрнутых технических деталей по каждому в открытых материалах нет, поэтому ниже речь о механике таких сбоев, а не о точном воспроизведении.
CSP, который ломал голос
Content Security Policy ограничивает источники, с которых страница грузит скрипты, подключается по сети и открывает медиаканалы. Если в политике не разрешены домены и схемы, нужные для WebRTC (сигналинг, TURN, медиа), голосовая связь не поднимается, а консоль браузера не всегда даёт очевидную подсказку. Ошибка коварна тем, что интерфейс выглядит рабочим: сообщения отправляются, кнопки нажимаются, звука нет.
Caps Lock и мобильный Safari
Caps Lock и мобильный Safari - типовые проблемы ввода и совместимости. Первая связана с обработкой состояния клавиши в Electron-клиенте, вторая с расхождениями мобильного Safari и десктопных движков в вёрстке, фокусе и медиа. Такие дефекты плохо ловятся статикой: их видно только при живом наборе текста и запуске на конкретном телефоне.
Общий урок для агентной разработки простой: агент не видит реального окружения и не запускает тесты, если это не задано явно. В кейсе Calab тесты не запускались вообще, поэтому часть проблем всплыла уже в проде, а разбираться с ними пришлось человеку.
Что остаётся за человеком: дистрибуция, эксплуатация, железо, вкус и юридика
Вывод автора кейса сформулирован жёстко: инженерная себестоимость продукта резко упала, а дистрибуция, эксплуатация, реальное железо, вкус и юридические вопросы остались за человеком. Разберём по пунктам.
Дистрибуция и эксплуатация self-hosted продукта
Подписанные сборки под macOS, Windows и Linux, веб-версия, каналы обновлений, мониторинг, разбор инцидентов и поддержка пользователей сами не появляются. Подпись приложения требует сертификатов и нотаризации, обновления нужно доставлять, а сбои в голосовой связи искать по логам медиасервера и TURN. Агенты эти задачи автоматически не закрывают.
Железо, вкус и юридические вопросы
Железо: серверы, пропускная способность, TURN-релей, инфраструктура под медиатрафик. Вкус: продуктовые и UX-решения, которые нельзя делегировать без критериев, потому что агенту неоткуда взять представление о том, как должно ощущаться приложение. Юридика: лицензии зависимостей, обработка персональных данных, требования регуляторов.
Регулирование агентных систем движется параллельно. NIST NCCoE получил отзывы более чем от 600 комментаторов на концептуальный документ по идентичности и авторизации программных и агентных ИИ, а первый сценарий планируется показать вместе с проектом DevSecOps (материал NIST о комментариях к концепт-документу). Сигнал понятный: агентная разработка постепенно переезжает в регулируемое поле, и вопросы авторства, доступа и ответственности будут задавать не только юристы компании.
Можно ли повторить схему: практические выводы и ограничения
Чек-лист для повторения: артефакты и правила
- Документация и ADR до кода. Решения фиксируются письменно, агент получает контракт, а не свободу изобретать архитектуру.
- git worktree для изоляции. Каждый агент работает в своей копии репозитория.
- Ограничение параллелизма. Около 12 одновременных агентов уже требуют дисциплины; больше не значит быстрее.
- Структурированный контекст. Короткие файлы вместо одного раздутого, чистка CLAUDE.md и AGENTS.md.
- Проверка на реальных устройствах. Десктоп, мобильный браузер, разные сети, включая блокировку UDP.
- Контроль расходов на API. Считать не только генерацию, но и чтение кэша контекста.
Основа чек-листа - описание кейса Calab, а не независимое тестирование.
Когда подход не сработает
Схема упирается в несколько ограничений. Без тестов дефекты приходят в прод, и ловит их человек. Счёт за API может оказаться заметным: $12 400 по прайс-листу для пет-проекта или небольшой команды это серьёзная сумма. Эксплуатация, юридические вопросы и продуктовые решения остаются на людях. В регулируемых сферах добавляется соответствие требованиям, и активность NIST NCCoE показывает, куда движется эта часть.
Calab - показательный кейс, а не универсальный рецепт. Он доказывает, что собрать рабочий self-hosted мессенджер силами агентов реально за сутки, и одновременно показывает цену: неотлаженный код, четырёхзначный счёт за токены и задачи, которые всё равно упираются в человека.