Автоматизировать это в TeleClaude можно: ловить паттерн “auth required” в stderr, делать claude login --no-interactive и парсить URL. Но дальше всё равно нужен браузер на той же машине, чтобы подтвердить OAuth. Для headless-сервера без GUI это не решается без workaround’ов.
В моём случае TeleClaude крутится на десктопе, где есть браузер, так что в теории можно через Playwright автоматически открыть ссылку и подтвердить. Но пока это из разряда “починить то, что ломается раз в два месяца”, если руки дойдут, сделаю новый пост))
Коротко: вылетает, но редко, а даже если так, то меры борьбы с этим предусмотрены :)
Claude Code CLI сам управляет OAuth-токенами и обновляет их автоматически. Пока подписка активна (Max, Pro, Team), токен рефрешится в фоне, и 401 вы не увидите. Когда всё-таки может прилететь 401:
Подписка истекла или сменился план
Вы явно разлогинились (claude logout)
Anthropic отозвал сессию на своей стороне (бывает при обновлениях)
В моем TeleClaude процесс Claude Code CLI в этом случае просто падает с ненулевым exit code. Роутер ловит это, убивает процесс, и при следующем сообщении в топик спавнит новый. Если CLI не может авторизоваться, он сам пишет ошибку в stderr, и она прилетает в Telegram как сообщение об ошибке. Но за несколько месяцев ежедневного использования (еще когда пользовался OpenClaw) такое было однажды, исправил через claude login в терминале, а потом закрыл системно.
Да хороший вопрос, так как тут путаница в терминах.
Claude Code и так локальный. Это CLI, которая стоит на моей машине, выполняет код локально, читает файлы локально. Но сама-то модель Claude работает в облаке Anthropic, то есть к ней уходят запросы через API. Локальной модели Claude не существует, Anthropic её не раздаёт.
OpenClaw тоже работал локально. Проблема была не в том, где он крутится, а в том, как он подключался к Claude. Anthropic изменили условия, OpenClaw потерял возможность использовать Claude Code как бэкенд с авторизацией через oAuth (только через API key осталась, а это цена х5 примерно выше, чем мой текущий тариф).
TeleClaude решает ту же задачу иначе: он спавнит Claude Code CLI напрямую как дочерний процесс и общается с ним через stdin/stdout. Авторизация через OAuth самого Claude Code, без посредников. По сути, это как если бы вы открыли терминал и запустили claude руками, только вместо вас это делает бот из Telegram с доп.инструкциями (а значит не теряет контекст, работает корректно и т.п.)
Нет, не ACP. OpenClaw подключался к Claude через свой собственный протокол (по сути, обёртка над API). Anthropic не "прикрыли" конкретно ACP, но они изменили условия, при которых OpenClaw мог использовать Claude Code как бэкенд. Мой TeleClaude работает иначе: он спавнит Claude Code CLI как локальный процесс и общается с ним через stdin/stdout. Авторизация через OAuth самого Claude Code, без сторонних прослоек.
Про шаблоны в git — да, думал об этом. Сейчас шаблон фактически зашит в роутере: при создании топика он генерирует CLAUDE.md, topic-memory.md и симлинки на общие файлы (SOUL.md, main-memory.md). В принципе шаблон в отдельном репозитории мог бы быть логичным следующим шагом, особенно если хочется давать разным топикам разные "личности" или наборы инструкций. Но пока не сделал, потому что текущая схема покрывает мои задачи, тем не менее идея правильная, доделаю :)
Спасибо за вопрос и ссылку. Если коротко — 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 мл рублей в год учатся по совсем другим специальностям. Это бизнес, экономика, финансы, маркетинг, мода, дизайн и ряд других. Маловероятно, что они вдруг решат сменить специальность с бизнеса на образование или социальную сферу только, чтобы получить эти деньги от государства и потом отработать на него еще три года.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
спасибо, поправил
да, так и рабоатет :)
Автоматизировать это в TeleClaude можно: ловить паттерн “auth required” в stderr, делать claude login --no-interactive и парсить URL. Но дальше всё равно нужен браузер на той же машине, чтобы подтвердить OAuth. Для headless-сервера без GUI это не решается без workaround’ов.
В моём случае TeleClaude крутится на десктопе, где есть браузер, так что в теории можно через Playwright автоматически открыть ссылку и подтвердить. Но пока это из разряда “починить то, что ломается раз в два месяца”, если руки дойдут, сделаю новый пост))
Коротко: вылетает, но редко, а даже если так, то меры борьбы с этим предусмотрены :)
Claude Code CLI сам управляет OAuth-токенами и обновляет их автоматически. Пока подписка активна (Max, Pro, Team), токен рефрешится в фоне, и 401 вы не увидите. Когда всё-таки может прилететь 401:
Подписка истекла или сменился план
Вы явно разлогинились (claude logout)
Anthropic отозвал сессию на своей стороне (бывает при обновлениях)
В моем TeleClaude процесс Claude Code CLI в этом случае просто падает с ненулевым exit code. Роутер ловит это, убивает процесс, и при следующем сообщении в топик спавнит новый. Если CLI не может авторизоваться, он сам пишет ошибку в stderr, и она прилетает в Telegram как сообщение об ошибке. Но за несколько месяцев ежедневного использования (еще когда пользовался OpenClaw) такое было однажды, исправил через claude login в терминале, а потом закрыл системно.
Зайдите на Авито, там можно купить всё (не реклама)
Да хороший вопрос, так как тут путаница в терминах.
Claude Code и так локальный. Это CLI, которая стоит на моей машине, выполняет код локально, читает файлы локально. Но сама-то модель Claude работает в облаке Anthropic, то есть к ней уходят запросы через API. Локальной модели Claude не существует, Anthropic её не раздаёт.
OpenClaw тоже работал локально. Проблема была не в том, где он крутится, а в том, как он подключался к Claude. Anthropic изменили условия, OpenClaw потерял возможность использовать Claude Code как бэкенд с авторизацией через oAuth (только через API key осталась, а это цена х5 примерно выше, чем мой текущий тариф).
TeleClaude решает ту же задачу иначе: он спавнит Claude Code CLI напрямую как дочерний процесс и общается с ним через stdin/stdout. Авторизация через OAuth самого Claude Code, без посредников. По сути, это как если бы вы открыли терминал и запустили claude руками, только вместо вас это делает бот из Telegram с доп.инструкциями (а значит не теряет контекст, работает корректно и т.п.)
Нет, не ACP. OpenClaw подключался к Claude через свой собственный протокол (по сути, обёртка над API). Anthropic не "прикрыли" конкретно ACP, но они изменили условия, при которых OpenClaw мог использовать Claude Code как бэкенд. Мой TeleClaude работает иначе: он спавнит Claude Code CLI как локальный процесс и общается с ним через stdin/stdout. Авторизация через OAuth самого Claude Code, без сторонних прослоек.
Про шаблоны в git — да, думал об этом. Сейчас шаблон фактически зашит в роутере: при создании топика он генерирует CLAUDE.md, topic-memory.md и симлинки на общие файлы (SOUL.md, main-memory.md). В принципе шаблон в отдельном репозитории мог бы быть логичным следующим шагом, особенно если хочется давать разным топикам разные "личности" или наборы инструкций. Но пока не сделал, потому что текущая схема покрывает мои задачи, тем не менее идея правильная, доделаю :)
Так это и не пет-проект :) SpamAway.ru для проверки спама сразу во многих каналах, вполне себе бизнес-история.
Спасибо за вопрос и ссылку. Если коротко — 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 на вторую модель?