Модель gpt-5-6-sol, провайдера не раскрываю. Я развиваю API сервис доступа к моделям, поэтому здесь как раз упёрся в экономику маршрута KV кеш у поставщика работает, cached tokens мы видим, но скидки за cache hit в закупочном списании нет. Повтор с 91% попаданием стоил практически столько же, сколько холодный запрос. Передать клиенту скидку, которой сам не получил, я не могу поэтому уменьшаю именно физически отправляемый контекст: на шлюзе и локально рядом с агентом.
Небольшое уточнение: изменение контекста не всегда сбрасывает кеш целиком обычно сохраняется неизменный префикс, а промах начинается после первой изменённой части. Но при удалении старой истории из начала действительно можно потерять почти весь hit. Поэтому сейчас проверяю cache-aware правило: когда выгоднее ничего не трогать, а когда физическое сокращение уже окупает потерю префикса.
А ваши 95% подтверждались одновременно полями usage и фактическим списанием баланса?
Спасибо, это полезная деталь. Забрал себе как отдельную гипотезу: handover на границе пункта плана против сжатия по порогу и нового чистого окна Прогоню A / B по стоимости, cache hit и потере фактов.
А handover у вас свободным текстом пишется или есть фиксированная структура - цель, сделанное, решения, открытые вопросы и следующие шаги?
Вы предлагаете смотреть, остался ли плагин на седьмой день, но в опубликованном server.js есть только Map с TTL 120 секунд, а pingd отправляет id, streak, state и night. Ни first_seen, ни возраста установки нет, причём streak относится к Claude, а не к плагину. Получается, D7 retention в текущей реализации технически не измеряется или прод-сервер отличается от репозитория?
Да. И качество обычно начинает деградировать раньше, чем приходит страшный счёт: нужный факт просто тонет в старых логах, повторных чтениях и закрытых тупиках.
И уточню: миллион в статье — не предлагаемый размер кеша, а как раз антипример. До чего способна раздуться сессия, если позволить ей жить без границ.
Живой тест показал ещё неприятнее: универсальный архив тоже не решение. На короткой сессии служебный слой съел больше, чем сэкономил. Поэтому сейчас логика ближе к вашей: закончился смысловой этап — старое сворачиваем; понадобилась конкретная деталь — агент дочитывает локальный оригинал.
А по какому сигналу вы сбрасываете: завершение задачи, смена ветки или порог по токенам?
Да, экономика у провайдера тут действительно забавная: чем толще мы собрали запрос, тем больше заплатили 🙂
Но я бы не перекладывал всё на модель. API обрабатывает ровно то, что в него отправил агентский рантайм. Если клиент каждый раз прикладывает старые логи, файлы и двадцать ненужных схем инструментов, провайдер честно всё это посчитает.
Поэтому контролировать мусор должен тот, кто собирает контекст. Собственно, из этой боли Trim и вырос.
Модель
gpt-5-6-sol, провайдера не раскрываю. Я развиваю API сервис доступа к моделям, поэтому здесь как раз упёрся в экономику маршрута KV кеш у поставщика работает, cached tokens мы видим, но скидки за cache hit в закупочном списании нет. Повтор с 91% попаданием стоил практически столько же, сколько холодный запрос. Передать клиенту скидку, которой сам не получил, я не могу поэтому уменьшаю именно физически отправляемый контекст: на шлюзе и локально рядом с агентом.Небольшое уточнение: изменение контекста не всегда сбрасывает кеш целиком обычно сохраняется неизменный префикс, а промах начинается после первой изменённой части. Но при удалении старой истории из начала действительно можно потерять почти весь hit. Поэтому сейчас проверяю cache-aware правило: когда выгоднее ничего не трогать, а когда физическое сокращение уже окупает потерю префикса.
А ваши 95% подтверждались одновременно полями usage и фактическим списанием баланса?
Спасибо, это полезная деталь. Забрал себе как отдельную гипотезу: handover на границе пункта плана против сжатия по порогу и нового чистого окна Прогоню A / B по стоимости, cache hit и потере фактов.
А handover у вас свободным текстом пишется или есть фиксированная структура - цель, сделанное, решения, открытые вопросы и следующие шаги?
Вы предлагаете смотреть, остался ли плагин на седьмой день, но в опубликованном server.js есть только Map с TTL 120 секунд, а pingd отправляет id, streak, state и night. Ни first_seen, ни возраста установки нет, причём streak относится к Claude, а не к плагину. Получается, D7 retention в текущей реализации технически не измеряется или прод-сервер отличается от репозитория?
Да. И качество обычно начинает деградировать раньше, чем приходит страшный счёт: нужный факт просто тонет в старых логах, повторных чтениях и закрытых тупиках.
И уточню: миллион в статье — не предлагаемый размер кеша, а как раз антипример. До чего способна раздуться сессия, если позволить ей жить без границ.
Живой тест показал ещё неприятнее: универсальный архив тоже не решение. На короткой сессии служебный слой съел больше, чем сэкономил. Поэтому сейчас логика ближе к вашей: закончился смысловой этап — старое сворачиваем; понадобилась конкретная деталь — агент дочитывает локальный оригинал.
А по какому сигналу вы сбрасываете: завершение задачи, смена ветки или порог по токенам?
Да, экономика у провайдера тут действительно забавная: чем толще мы собрали запрос, тем больше заплатили 🙂
Но я бы не перекладывал всё на модель. API обрабатывает ровно то, что в него отправил агентский рантайм. Если клиент каждый раз прикладывает старые логи, файлы и двадцать ненужных схем инструментов, провайдер честно всё это посчитает.
Поэтому контролировать мусор должен тот, кто собирает контекст. Собственно, из этой боли Trim и вырос.