Вы предлагаете смотреть, остался ли плагин на седьмой день, но в опубликованном server.js есть только Map с TTL 120 секунд, а pingd отправляет id, streak, state и night. Ни first_seen, ни возраста установки нет, причём streak относится к Claude, а не к плагину. Получается, D7 retention в текущей реализации технически не измеряется или прод-сервер отличается от репозитория?
Да. И качество обычно начинает деградировать раньше, чем приходит страшный счёт: нужный факт просто тонет в старых логах, повторных чтениях и закрытых тупиках.
И уточню: миллион в статье — не предлагаемый размер кеша, а как раз антипример. До чего способна раздуться сессия, если позволить ей жить без границ.
Живой тест показал ещё неприятнее: универсальный архив тоже не решение. На короткой сессии служебный слой съел больше, чем сэкономил. Поэтому сейчас логика ближе к вашей: закончился смысловой этап — старое сворачиваем; понадобилась конкретная деталь — агент дочитывает локальный оригинал.
А по какому сигналу вы сбрасываете: завершение задачи, смена ветки или порог по токенам?
Да, экономика у провайдера тут действительно забавная: чем толще мы собрали запрос, тем больше заплатили 🙂
Но я бы не перекладывал всё на модель. API обрабатывает ровно то, что в него отправил агентский рантайм. Если клиент каждый раз прикладывает старые логи, файлы и двадцать ненужных схем инструментов, провайдер честно всё это посчитает.
Поэтому контролировать мусор должен тот, кто собирает контекст. Собственно, из этой боли Trim и вырос.
Вы предлагаете смотреть, остался ли плагин на седьмой день, но в опубликованном server.js есть только Map с TTL 120 секунд, а pingd отправляет id, streak, state и night. Ни first_seen, ни возраста установки нет, причём streak относится к Claude, а не к плагину. Получается, D7 retention в текущей реализации технически не измеряется или прод-сервер отличается от репозитория?
Да. И качество обычно начинает деградировать раньше, чем приходит страшный счёт: нужный факт просто тонет в старых логах, повторных чтениях и закрытых тупиках.
И уточню: миллион в статье — не предлагаемый размер кеша, а как раз антипример. До чего способна раздуться сессия, если позволить ей жить без границ.
Живой тест показал ещё неприятнее: универсальный архив тоже не решение. На короткой сессии служебный слой съел больше, чем сэкономил. Поэтому сейчас логика ближе к вашей: закончился смысловой этап — старое сворачиваем; понадобилась конкретная деталь — агент дочитывает локальный оригинал.
А по какому сигналу вы сбрасываете: завершение задачи, смена ветки или порог по токенам?
Да, экономика у провайдера тут действительно забавная: чем толще мы собрали запрос, тем больше заплатили 🙂
Но я бы не перекладывал всё на модель. API обрабатывает ровно то, что в него отправил агентский рантайм. Если клиент каждый раз прикладывает старые логи, файлы и двадцать ненужных схем инструментов, провайдер честно всё это посчитает.
Поэтому контролировать мусор должен тот, кто собирает контекст. Собственно, из этой боли Trim и вырос.