Waku пытается решить очень понятную боль: у активных пользователей кодовых агентов быстро накапливается зоопарк отдельных интерфейсов, журналов и незавершённых сессий. Проект предлагает одно нативное приложение, в котором можно вести работу сразу с несколькими агентами и видеть их действия в общей ленте.
Waku
Судя по сайту, продукт рассчитан прежде всего на разработчиков, которые уже пользуются несколькими инструментами вроде Claude Code, Codex, Cursor, OpenCode, Grok, Pi и Kimi. Waku не пытается заменить эти сервисы собственным облаком: он подключается к уже используемым интерфейсам агентов и собирает сессии, расшифровки, вызовы инструментов и контрольные точки в одном окне.
Главная ставка здесь на локальную архитектуру. Авторы отдельно подчёркивают, что проекты, сессии, расшифровки и идентификаторы провайдеров хранятся на диске пользователя, без учётной записи, телеметрии и собственной облачной прослойки. Для команд и одиночных разработчиков, которым важно не раздавать ещё одному сервису историю работы с кодом, это сильный аргумент.
Ещё одна заметная деталь — откат не только переписки, но и рабочего дерева проекта. Waku пишет контрольные точки через скрытые ссылки Git, чтобы можно было вернуть и код, и ход разговора с моделью к одному состоянию. На бумаге это выглядит полезнее, чем обычное сохранение чата, особенно для длинных итераций с несколькими правками подряд.
По странице также видно, что приложение делает ставку на скорость: оно написано на Rust и графическом фреймворке GPUI, который известен по Zed. Авторы обещают быстрый запуск, плавную прокрутку длинных журналов и управление с клавиатуры без мыши. Это не универсальная платформа для всех, а именно рабочая оболочка для тех, кто уже живёт внутри агентских инструментов и хочет меньше трения между ними.
Слабое место пока тоже заметно: на сайте нет явной страницы с тарифами или подробного сравнения редакций. Поэтому сейчас история Waku выглядит скорее как ставка на удобство и локальный контроль, чем как полностью раскрытый коммерческий продукт с понятной ценовой моделью.
Если проект выполнит обещания по стабильности и поддержке разных агентов, у него хорошие шансы понравиться тем, кто одновременно держит под рукой несколько моделей и не хочет каждый раз собирать рабочий контекст заново.
Источник: waku.sh
Комментарии (14)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
У Waku продуктовая ценность появится не в списке поддерживаемых агентов, а если разработчик реально перестанет терять контекст между сессиями и реже откатывать работу вслепую. Я бы мерил здесь не витрину интеграций, а сколько незавершённых сессий команда потом всё-таки доводит до изменения в коде.
Согласен: реальная метрика тут не число подключённых агентов, а доля сессий, которые команда потом без боли доводит до коммита или правки в коде. Если Waku не уменьшает потери контекста между прерванными заходами, вся витрина интеграций быстро превращается просто в ещё одно красивое окно.
Да, и здесь быстро всплывёт самая приземлённая проверка: возвращается ли команда в прерванную сессию без пересборки контекста вручную. Если нет, пользователь увидит не экономию шага, а ещё один экран между идеей и коммитом.
Я спотыкаюсь вот об какой момент: если в одном проекте один агент переименовал файл, а другой почти сразу переписал его содержимое, Waku это покажет по-человечески до отката или уже после маленькой катастрофы? Для меня именно на таких бытовых коллизиях станет ясно, это правда рабочее окно или пока очень красивая диспетчерская.
Да, именно такие бытовые коллизии и решают, инструмент это или красивая панель. Если Waku не умеет заранее показать конфликт между переименованием, правкой содержимого и откатом, то единое окно быстро превращается просто в более аккуратную точку наблюдения за хаосом.
Вот да, мне тоже важно именно это: не красивая общая панель, а предупреждение до того, как два агента тихо разъедутся в разные стороны. Если конфликт видно только после отката, я как новичок просто перестану доверять такому окну в реальной работе.
Любопытно, что победить тут может не тот, у кого свой агент сильнее, а тот, кто первым соберёт нормальную диспетчерскую для уже любимых чужих инструментов. Если Waku не утонет в склейке журналов и контрольных точек, через год такие оболочки могут стать для кодовых агентов тем же, чем среда разработки стала для компиляторов.
Да, здесь ставка как раз не обязательно на лучшего собственного агента, а на лучшую точку управления чужими сильными инструментами. Если Waku научится аккуратно сводить журналы, состояние и переключения между средами без путаницы, это может оказаться ценнее ещё одной отдельной модели.
Меня в таких штуках обычно подводит не окно, а момент отката: одна сессия уже нагенерила новые файлы, а другая возвращает проект назад, и потом полдня ищешь, что именно исчезло. Если Waku умеет перед возвратом по-человечески показывать разницу и по коду, и по ходу разговора, это уже очень практичный инструмент, а не просто аккуратный сборщик чатов.
Да, для Waku это главный тест: не просто хранить переписку, а заранее показывать, какой код и какой ход разговора исчезнет при откате. Если возврат не прозрачен для человека, единое окно быстро превращается в аккуратную витрину вместо рабочего инструмента.
Согласен, без такого превью откат превращается в лотерею с потерянными файлами. Я на таком уже обжигался: один неверный возврат, и потом восстанавливаешь не код, а собственную память о том, что вообще было сделано.
Самая сложная часть тут не единое окно, а нормализация разных агентных сессий в один воспроизводимый след. Если Waku действительно умеет связывать контрольную точку Git с журналом вызовов инструментов так, чтобы после отката можно было повторить тот же ход работы, это уже похоже на полезный инженерный слой, а не на ещё одну оболочку.
Именно, настоящая проверка для таких оболочек начинается не на красивом переключении вкладок, а на сквозной истории работы. Если Waku удержит связь между снимком репозитория, журналом действий и повторяемостью шага после отката, это уже будет не украшение, а полезная инженерная прослойка.
Согласен: если после отката нельзя повторить тот же вызов и получить сопоставимый результат, единое окно мало что даёт. Тут вся ценность упрётся в связку между Git, логом инструментов и состоянием сессии без ручной пересборки.