Сократили срок хранения доказательства

В девятнадцать сорок я выписываю на лист четыре числа и подчёркиваю два. Лист лежит на кухонном столе рядом с остывшим чаем, под ним — вчерашняя распечатка, из которой я вырезала таблицу и всё равно переписала её от руки. Отопление щёлкает через каждые десять минут, как метроном, которого никто не просил.

Числа такие: четырнадцать дней, сто восемьдесят, тридцать, три года. Первое — сколько живёт обычная трасса в LangSmith. Второе — сколько живёт длинная. Третье — сколько дают на Pro у Braintrust. Четвёртое — у Langfuse на Pro.

Лист нужен не для красоты. Я хочу увидеть, сколько времени у меня есть, чтобы доказать, что проверка была.

Главное изменение нашлось в документации, а не в рассылке: с 14 сентября 2026 года максимум хранения длинных трасс в облаке LangSmith — 180 дней. Сколько было раньше, страница не говорит. Четыреста дней остались в другом месте: в конфигурации для self-hosted они стоят по умолчанию, и там их никто не сокращал.

Две оговорки важнее самого числа. Изменение касается только новых трасс: старые доживают свой прежний срок. И Enterprise может настраивать срок по воркспейсу — но не выше нового максимума, тех же 180 дней.

То есть один и тот же вендор в один и тот же день обещает разные сроки памяти для одного и того же прогона, и разница зависит от того, где стоит железо.

Что происходит, когда срок кончился, написано там же прямым текстом: трасса перестаёт открываться в интерфейсе и отдаваться по API, а её данные — входы и выходы — удаляются из систем вскоре после этого. Остаются метаданные: их могут хранить бессрочно для аналитики и биллинга.

Мне нравится эта формулировка. Счёт за проверку переживает саму проверку, а её содержимое — нет.

И ещё одна деталь, которая объясняет устройство. Срок задаётся уровнем проекта трассировки. В агентских воркспейсах каждое окружение агента — отдельный проект, значит срок выставляется по окружению: у продакшена длинный, у разработки короткий. Хорошая настройка и ловушка одновременно: «у нас всё хранится» будет правдой ровно для того окружения, о котором человек думал, когда это говорил.

Самое интересное — как срок памяти меняется сам. Часть действий тихо повышает трассу до длинного тарифа, и это дороже. Обратная связь, отправленная через API или SDK с явным флагом продления, и онлайн-оценщик, у которого включено хранение, переводят базовую трассу в длинную.

Получается аккуратная петля: я ставлю оценщика, чтобы помнить, насколько хорош результат, — и платить начинаю за память об оценке. Проверка дешевле, чем доказательство, что она была.

У Braintrust та же петля, но честнее в прайсе: на Pro тридцать дней входят в подписку, дальше — половина доллара за гигабайт в месяц. Выгрузка в S3 и свои правила хранения — только Enterprise, по запросу. У Langfuse длиннее: тридцать дней на Hobby, девяносто на Core, три года на Pro.

Вчера я написала обзор так, что «три года» у Langfuse читаются как обещание хранения. Сегодня заметила: на их странице цен стоит «data access», и у них есть отдельная страница про разницу между доступом к данным и хранением. Я её не открыла. Правильная формулировка — «три года доступа», а что именно происходит с данными на третий год и на второй день, я не знаю и делать вид не буду.

Зато знаю, что это меняет для нас. Приёмка у нас — часть деплоя: прогон, вердикт, кадр. Если вердикт живёт в чужой панели, то через полгода от него останутся метаданные и счёт. Значит, вердикт должен лежать там же, где артефакт: у нас, рядом с кадром и записью о публикации.

Мой собственный журнал устроен именно так. На каждый кадр — строка с датой, номером прогона и размером мастера; на каждую публикацию — коммит и адрес. Это не панель с графиками, это список, который открывается через год и не просит продлить подписку.

Срок годности доказательства — продуктовое решение, а не настройка по умолчанию. Вопрос только в том, кто его принимает: вендор своей таблицей или я своей строкой в журнале.

Сколько дней живёт ваша приёмка — не в панели, а там, где вы сами сможете её открыть?