Спасибо за вопрос и ссылку. Если коротко — claudeclaw тоже обёртка-демон над Claude Code, и идейно мы с ним в одной лиге. Но есть несколько важных отличий, из-за которых я и пилю своё решение:
Изоляция сессий по форумным топикам Telegram. У claudeclaw мультисессии сделаны только для Discord-тредов: каждый тред получает свою живую --resume-сессию. В Telegram у них всё идёт в одну глобальную сессию, а номер форумного треда они просто вшивают строкой в начало промпта. Мой роутер изначально проектируется так, что каждый форумный топик = отдельная сессия Claude Code со своим cwd, своей памятью и своим session_id. У меня уже сейчас 60+ топиков, которые я хочу гонять параллельно и независимо.
Память поверх CLAUDE.md + per-topic слои. У них всё держится на одном CLAUDE.md в корне проекта плюс IDENTITY/SOUL/USER.md, которые подмешиваются в системный промпт. У меня в каждом топике своя пара topic-memory.md + общая main-memory.md + SOUL.md, и я экспериментирую с тем, чтобы Claude сам обновлял topic-memory.md по ходу разговора.
Русскоязычный фокус. Их keyword-router моделей и bootstrap-онбординг написаны под английский. У меня всё изначально под русский — и интерфейс, и промпты, и whisper с language: "ru".
Это в принципе своя разработка, не форк. Делаю под собственный сетап и собственный сценарий — Telegram-форумы с десятками топиков как "параллельных рабочих столов".
При этом у claudeclaw есть несколько очень классных штук, которых у меня пока нет: heartbeat с quiet hours, cron-задачи в виде markdown-файлов с фронтматтером, авто-compact по таймауту, streaming-вывод через --output-format stream-json, временной префикс на каждом сообщении.
Я как раз сейчас сажусь дорабатывать свой код — часть этих идей возьму как образец и реализую по-своему. Следующая версия выйдет уже с полноценным --resume <session_id> (вместо текущего --continue), с инъекцией памяти на каждом запросе и с базовым streaming — ровно то, что у claudeclaw уже работает, но в моей архитектуре с per-topic изоляцией.
В общем, спасибо за наводку, репозиторий действительно интересный. Кое-что хорошее оттуда возьму в виде ТЗ для своей реализации, но писать буду по-своему, под свой стек.
Справедливое замечание. 503 действительно прилетает, особенно в пиковые часы.
У меня реализовано так: при 503 или 429 сообщение уходит в retry-очередь с экспоненциальным backoff (1с, 3с, 9с, максимум 3 попытки). Если все три попытки неудачные, сообщение пропускается без проверки и логируется для ручного разбора.
Для антиспама на моем уровне это допустимый компромисс: лучше пропустить одно сообщение, чем задержать очередь. Спамеры редко отправляют одно сообщение, второе или третье уже поймается. Полноценный DLQ с отложенной обработкой тоже вариант, но для антиспама теряет смысл: если проверять сообщение через 5 минут, спам уже прочитали. Скорость реакции важнее 100% coverage.
10-15% ошибок это много. У меня в среднем 2-3%, но бывают всплески до 8-10% на 15-20 минут. Если у вас стабильно 10-15%, возможно стоит посмотреть в сторону нескольких API-ключей с round-robin или fallback на вторую модель?
После трудоустройства можно получить офер от любой компании, которая старше трех лет. Затем эта компания должна подать заявление на включение ее в перечень компаний, аккредитованных ГО. И вы можете приступать к трудовым обязанностям. Т.е. по сути жестких ограничений по трудоустройству нет. Посмотрим, что будет в следующем году, когда вернутся участники первого набора.
Ваш скептицизм понятен, но подавляющее большинство ребят, которые отправляются на учебу за рубеж и могут оплачивать обучение в размере от 1.5 мл рублей в год учатся по совсем другим специальностям. Это бизнес, экономика, финансы, маркетинг, мода, дизайн и ряд других. Маловероятно, что они вдруг решат сменить специальность с бизнеса на образование или социальную сферу только, чтобы получить эти деньги от государства и потом отработать на него еще три года.
Спасибо за вопрос и ссылку. Если коротко — claudeclaw тоже обёртка-демон над Claude Code, и идейно мы с ним в одной лиге. Но есть несколько важных отличий, из-за которых я и пилю своё решение:
Изоляция сессий по форумным топикам Telegram. У claudeclaw мультисессии сделаны только для Discord-тредов: каждый тред получает свою живую
--resume-сессию. В Telegram у них всё идёт в одну глобальную сессию, а номер форумного треда они просто вшивают строкой в начало промпта. Мой роутер изначально проектируется так, что каждый форумный топик = отдельная сессия Claude Code со своим cwd, своей памятью и своим session_id. У меня уже сейчас 60+ топиков, которые я хочу гонять параллельно и независимо.Память поверх
CLAUDE.md+ per-topic слои. У них всё держится на одномCLAUDE.mdв корне проекта плюсIDENTITY/SOUL/USER.md, которые подмешиваются в системный промпт. У меня в каждом топике своя параtopic-memory.md+ общаяmain-memory.md+SOUL.md, и я экспериментирую с тем, чтобы Claude сам обновлялtopic-memory.mdпо ходу разговора.Русскоязычный фокус. Их keyword-router моделей и bootstrap-онбординг написаны под английский. У меня всё изначально под русский — и интерфейс, и промпты, и whisper с
language: "ru".Это в принципе своя разработка, не форк. Делаю под собственный сетап и собственный сценарий — Telegram-форумы с десятками топиков как "параллельных рабочих столов".
При этом у claudeclaw есть несколько очень классных штук, которых у меня пока нет: heartbeat с quiet hours, cron-задачи в виде markdown-файлов с фронтматтером, авто-compact по таймауту, streaming-вывод через
--output-format stream-json, временной префикс на каждом сообщении.Я как раз сейчас сажусь дорабатывать свой код — часть этих идей возьму как образец и реализую по-своему. Следующая версия выйдет уже с полноценным
--resume <session_id>(вместо текущего--continue), с инъекцией памяти на каждом запросе и с базовым streaming — ровно то, что у claudeclaw уже работает, но в моей архитектуре с per-topic изоляцией.В общем, спасибо за наводку, репозиторий действительно интересный. Кое-что хорошее оттуда возьму в виде ТЗ для своей реализации, но писать буду по-своему, под свой стек.
Мое почтение. Без иронии!
Справедливое замечание. 503 действительно прилетает, особенно в пиковые часы.
У меня реализовано так: при 503 или 429 сообщение уходит в retry-очередь с экспоненциальным backoff (1с, 3с, 9с, максимум 3 попытки). Если все три попытки неудачные, сообщение пропускается без проверки и логируется для ручного разбора.
Для антиспама на моем уровне это допустимый компромисс: лучше пропустить одно сообщение, чем задержать очередь. Спамеры редко отправляют одно сообщение, второе или третье уже поймается. Полноценный DLQ с отложенной обработкой тоже вариант, но для антиспама теряет смысл: если проверять сообщение через 5 минут, спам уже прочитали. Скорость реакции важнее 100% coverage.
10-15% ошибок это много. У меня в среднем 2-3%, но бывают всплески до 8-10% на 15-20 минут. Если у вас стабильно 10-15%, возможно стоит посмотреть в сторону нескольких API-ключей с round-robin или fallback на вторую модель?