Память Claude Code: почему она забывает и какие два числа это исправляют

Я управляю операциями дизайн-студии из Claude Code. От десяти до двадцати открытых терминалов, и в каждом из них я. И на протяжении месяцев в каждом из них один и тот же человек повторял одно и то же.

Команда Brainy открыла сессию, с которой всё началось, одной фразой: мы устали повторяться. Затем они прислали бенчмарк семи продуктов памяти и репозиторий, и спросили, почему память, на которой работаю я, не такая.

Этот материал о том, что мы нашли, когда отнеслись к этому серьёзно. В основу легли четыре части работы:

• Мы пересобрали систему памяти
• Шестнадцать исследовательских агентов прошлись по каждому плагину и провайдеру памяти, какой мы смогли назвать, и восемь из них пытались опровергнуть остальные восемь
• Мы измерили собственную работу на реальных промптах, а не на тесте, который написали сами для себя
• Мы сами прогнали бенчмарк и оценили каждого конкурента одним и тем же судьёй

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

Баг: усердная запись, произвольное извлечение

Эти четыре слова и есть весь баг с повторениями.

Память, которую тщательно записывают и читают по прихоти, проходит любую проверку, потому что каждый файл на месте и каждый факт верен.

И человек всё равно объясняет правило деплоя в четвёртый раз, потому что в тот момент, когда правило имело значение, никто не пошёл и не достал его.

Это была наша ситуация. Каждая сессия записывала памяти. Их чтение зависело от одного вручную поддерживаемого индексного файла, который должен был быть достаточно коротким, чтобы загрузиться, и от того, решу ли я, посреди задачи, пойти и посмотреть.

Ни то, ни другое не происходило надёжно. Хранилище было в основном записывающим, а память, которая в основном записывает, это дневник, а не память.

Усердная запись, произвольное извлечение.

В вашем файле памяти есть скрытый обрыв

Claude Code загружает ваш индекс автопамяти, файл MEMORY.md, до 200 строк или 25 000 байт, смотря что наступит раньше. После этой черты ничего не загружается, и об этом ничего не сообщается.

Наш файл был 229 строк и 31 283 байта. Ограничение по байтам обрезало его на строке 176. Ниже этой строки находились три целых раздела стандартных правил, включая безопасность.

Пятьдесят три строки, 23% индекса. Они ни разу не достигали ни одной сессии.

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

Если вы когда-нибудь добавляли правило в свою память и через неделю наблюдали, как агент его игнорирует, посчитайте свои строки. Это ограничение задокументировано в двух issue в трекере Claude Code, и оно делает это с вами прямо сейчас, если файл вырос больше любого из этих двух чисел.

Идеальный результат, который на деле был верен на 17%

Первая версия исправления заняла два часа. Полнотекстовый индекс по всему хранилищу, хук, который ищет по нему на каждом промпте и вставляет лучшие совпадения. На батарее из 23 тестовых запросов результат был 22.

Затем мы прочитали живой лог. Шесть реальных промптов, 18 вставленных памятей, из них релевантных примерно три. Семнадцать процентов.

В бенчмарке были запросы вроде «деплой в продакшн». Никто в команде так не печатает. Они пишут длинные, разговорные, многосоставные промпты со вставленными скриншотами и ссылками.

Дословный текст промпта это ужасный поисковый запрос, а тема обычно живёт в предыдущей реплике. Мы построили хорошую трубу и прогнали через неё плохую воду.

Пять причин, каждая измерена, каждая исправлена:

Пятая причина была худшей. Когда поиску позволяли вести беседа сессии, сессия о памяти вспоминала каждую заметку о памяти на каждой реплике, а вопрос о деплое получал индексные файлы вместо правила деплоя. Контекст может уточнить запрос, у которого уже есть тема. Он никогда не должен её изобретать.

После переработки: 14 из 16 реальных промптов получили нужную память в двух первых совпадениях, и 18 из 18 разговорных промптов вроде «ок, давай» правильно не получили ничего.

Тишина это фича. Память, вставленная в промпт, которому она была не нужна, это шум, который модели приходится прочитать и пропустить.

Единственное правило: никакой модели в пути обработки промпта

Вот первое число. Круговой запрос к языковой модели из хука занимает 8,6 секунды. Полнотекстовый поиск по всему хранилищу занимает 18 миллисекунд.

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

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

• Она предлагает памяти на основе транскрипта
• Она выводит слова, которые человек реально бы напечатал, чтобы заметка под названием «инцидент с деплоем в продакшн» могла совпасть с «я сейчас случайно снесу продакшн»
• Она находит дубликаты и противоречия

Затем она уходит, и то, что отвечает во время промпта, это просто SQLite.

Такое разделение стоит ноль долларов и 18 миллисекунд

Стоимость такого разделения ноль долларов. Каждый вызов модели идёт через подписку, которую мы уже оплачиваем, а извлечение, которое выполняется на каждом промпте, не стоит ничего. Когда ничего не совпадает, токены не тратятся. Предельная стоимость памяти равна нулю, по конструкции, навсегда.

Бюджет, который кусается, это время. Хук стартует заново на каждом промпте, поэтому всё, что он загружает, он загружает заново в следующий раз. Вот что мы измерили по каждому варианту:

Поиск по ключевым словам выигрывает по задержке ещё до того, как вообще успевает поспорить о качестве.

Печать остаётся мгновенной. В этом и было всё решение.

«Разрозненные файлы» — неправильная претензия

Критика, которую мы постоянно слышали, состояла из двух половин: ваша память разбросана по markdown-файлам, и вы не приносите всю память в каждый разговор. У Hermes, агентской оболочки, на которую указала команда, одна память, которая растёт вместе с вами.

Обе половины заслуживают прямого ответа.

Приносить всю память в каждый разговор арифметически невозможно. Наше хранилище это 875 553 токена. Контекстное окно 200 000. Это 4,4 окна памяти, и оно растёт каждый день.

Никто не приносит всю память. Все её извлекают.

А «единая память» Hermes это 3575 символов. Файл памяти на 2200 символов плюс профиль пользователя на 1375 символов, оба всегда в промпте, оба с жёстким лимитом. Всё остальное, что знает Hermes, живёт в файлах на диске и ищется по запросу с помощью такого же индекса, каким пользуемся мы.

«Разбросано по markdown-файлам» описывает обе системы. Количество файлов это хранение. Доступ это индекс. Четыреста восемьдесят семь файлов за одним полнотекстовым индексом это не разброс; один запрос затрагивает их все за 18 миллисекунд.

В чём критика была права

Она была права в противоположном тому, что утверждала. Всегда-активный слой Hermes это около 1300 токенов. Наш был 6152. Они в 4,7 раза стройнее, и эта стройность идёт от жёсткого правила: когда память заполнена, запись проваливается, и агент должен консолидировать данные прежде, чем сможет что-то добавить.

Мы внимательно посмотрели на это правило и отклонили его. В собственном трекере issue Hermes есть развёртывание, которое подняло лимиты до 8000 и 3000 символов и всё равно упёрлось в них, «вызывая проваленные вызовы memory.add и повторную потерю правок оператора».

Проваленная запись не приводит к консолидации. Она приводит к тишине, и теряется именно та правка, которую пользователь только что внёс. Наш профиль вместо этого вытесняет свою самую слабую строку в поисковое хранилище, и запись никогда не проваливается. Двенадцать строк, втиснутых в четырнадцатистрочный профиль: четыре вытеснены, каждая строка, которую пользователь реально произнёс, выжила.

Чему нас научили семь продуктов памяти

Бенчмарк, с которого начала команда, MemConflict, прогнал семь самостоятельно размещаемых провайдеров памяти через одних и тех же 30 симулированных пользователей и задал каждому провайдеру 3750 вопросов. Неправильный ответ оценивался в минус один, а не в ноль. Этот единственный выбор раскрыл почти всё, что следует дальше.

Три вывода, которые важнее рейтинга

Рейтинг наименее полезная часть этой таблицы. Три закономерности повторялись у всех провайдеров:

• Никто надёжно не отвергает подброшенную ложную память. Лучший, Honcho, правильно ответил лишь на 36,4% таких вопросов полностью верно и утверждал подброшенную ложь в 25,8% случаев. Mnemosyne набрал ниже нуля: он утверждает неверные значения чаще, чем верные.

• У всех становится хуже по мере роста истории. С сессий 6-10 до сессий 46-50 доля неверных ответов mem0 выросла с 8,3% до 22,1%. У каждого провайдера показатель примерно удвоился.

• Те, что выглядели безопасно, в основном молчали. OpenViking оставил без ответа 67% вопросов, Mnemosyne 50%. При нулевом пороге они выглядели бы конкурентоспособно.

И вывод, который изменил наш дизайн: доказательство извлекалось, а затем не использовалось. На вопросах с подброшенными ложными фактами Honcho извлекал верную подтверждающую память в топ-3 в 81% случаев и всё равно отвечал неверно в 18%. Узким местом было не извлечение. Узким местом было то, что система делала после извлечения.

Honcho также тратит 617 278 токенов модели за сессию на фоновый вывод. Всё наше хранилище это 875 553 токена. Внедрить его значило бы тратить большую часть корпуса, каждую сессию, навсегда, чтобы отвечать на вопросы, на которые уже отвечает поисковый индекс.

Такова форма решения «строить самим или взять готовое». Их сильные стороны не были нашим узким местом. Их слабости были ровно нашими требованиями: языковая модель удаляет одну сторону противоречия, и никто это не проверяет и не отменяет.

Мы сами прогнали бенчмарк: 0,409 с первой попытки

Таблица, которую составил кто-то другой, это утверждение, поэтому мы отнеслись к ней как к утверждению. Мы подключили нашу память к тому же харнессу и оценили её на тех же симулированных пользователях и вопросах.

Две детали решают, значит ли такое число хоть что-то:

• Один судья для каждой строки. Опубликованную таблицу оценивала одна модель, а наше оборудование запускает другую, и собственная документация харнесса говорит, что оценки этих двух никогда не сравниваются. Поэтому мы взяли опубликованные ответы каждого конкурента и переоценили их нашим судьёй, наравне с нашими: те же пять пользователей, те же 616 вопросов.

• Настройка, которая не может протечь. Каждое изменение настраивалось на двух других пользователях и оценивалось на отчётных пяти ровно один раз, по правилу, записанному до того, как пришёл любой результат.

Первый прогон поставил нас на уровень с RetainDB и позади двух других, которых мы могли оценить.

Узким местом была глубина извлечения, а не ответы

Диагноз был один, и это была не оценка ранжирования и не ответы. Когда нужное предложение попадало в наш топ-5, ответ был верным в 94% случаев. Оно просто обычно туда не попадало.

Большинство промахов сидело в топ-50, ранжировано слишком низко, чтобы быть прочитанным. У поиска по ключевым словам есть и слепая зона, которую никакая глубина не исправит: спрошенный, изменилось ли место жительства пользователя, он не может найти предложение вроде «я только что переехал в Мельбурн», потому что ни одно слово не совпадает.

Поэтому мы внесли три изменения и оценили каждое на двух настроечных пользователях.

Решение: поиск по смыслу и факт-заметки, которые сами себя обновляют

Поиск по смыслу это не модель. Это статическая таблица эмбеддингов, один вектор на кусок слова, усреднённый. Он работает в numpy без сети и встраивает наши 71 062 реплики прошлых разговоров за 34 секунды на ноутбуке. Хук на каждый промпт по-прежнему никогда не касается его.

Факт-заметки это часть, которой у хранилища никогда не было. Устойчивый факт о человеке или организации записывается один раз, а затем обновляется при изменении: новое значение сверху с датой, когда оно вступило в силу, и каждое старое значение сохраняется ниже со своими датами. До этого изменение могло быть только предложено человеку на рассмотрение, а очередь на рассмотрение никто не просматривает, поэтому хранилище могло узнать, что клиент существует, и никогда не узнать, что клиент переехал.

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

Оценив один раз, мы сравнялись с mem0 на 0,520

На пяти отчётных пользователях, оценённых ровно один раз, финальная версия сравнялась с mem0.

Под этим равенством мы лидируем по двум показателям и отстаём по двум:

Две независимые оценки почти идентичных наших ответов отличались на 0,007, так что равенство есть равенство. Читать его нужно с тремя оговорками:

• Эти пять пользователей снисходительны ко всем. mem0 публикует 0,392 по всем тридцати и набирает здесь 0,520, так что ничто в этой таблице не пересчитывается обратно в публичную.

• Honcho в этой таблице нет. Он лидирует в публичной таблице, но передаёт модели 114 804 символа на вопрос, и оценка этого на одном GPU ползла со скоростью один вопрос в минуту. Весьма вероятно, что он всё ещё лидирует.

• Равенство по точности не победа. Память, которая сравнивается по точности, обрабатывая разговор в двадцать раз быстрее, на половине текста, это другой продукт, а не лучший. Что важнее, зависит от вашего счёта.

Память, которая сама себя чинит, это две системы

«Память, которая сама себя чинит» была в списке команды. Исследование показало, что означает эта фраза на самом деле, и это не одна вещь.

Работа о плоскостях управления памятью измерила это: детерминированные правила набирают 5% на одном классе очистки, а модель набирает 100% на нём же, при этом та же модель набирает 0% на удалении с учётом намерения, где правила справляются отлично. Совмещение обоих даёт прирост в 27,8 пункта. Самовосстанавливающаяся память нуждается в детерминированном проходе и проходе модели в разных точках, никогда не в одном из них.

Детерминированный проход находит побайтово идентичные дубликаты и памяти, называющие путь к файлу, который больше не существует. Тринадцать реальных флагов при первом прогоне. Проход модели находит противоречия между связанными памятями и предлагает, какая из них отменяет другую.

Без ограничений проход модели был прав примерно в 55% случаев, и каждая ошибка была уверенной. Он отменил постоянное правило разрешений, используя справочную заметку об облачных сессиях. Он убил факт о CDN одного продукта, используя релизную заметку другого продукта, потому что оба упоминали «CloudFront».

Он позволил карте указателей отменить реальную память, на которую она указывала. Он отменил список из шести открытых решений, потому что более новая память разрешила одно из них.

Четыре защиты и отмена сделали куратора безопасным

Четыре защиты это исправили:

С включёнными защитами тот же обход автоматически применил ровно одну отмену, и она была верной, а три подлинных противоречия отправил в очередь на рассмотрение.

Причина, по которой это безопасно запускать без присмотра, не в том, что модель хороша в этом. А в том, что ничего никогда не удаляется, каждое решение находится в журнале аудита, и одна команда отменяет его.

Отменённые памяти остаются в хранилище с видимой пометкой и штрафом к ранжированию. Старые факты затухают по периоду полураспада вместо исчезновения: заметка о проекте теряет половину веса каждые 150 дней, правило, которое дал пользователь, не затухает никогда.

Никогда не снижайте защиты, чтобы куратор выглядел продуктивнее.

Память это утверждение, поэтому проверяйте её

Вот часть, которую не делает ничто другое из изученного нами.

Память, которая была верна в мае и тихо перестала быть верной, невидима. Она ничему не противоречит, не называет мёртвый путь, она просто сидит и является неправильной.

У нас была такая, которая говорила, что токены Instagram «автоматически ротируются еженедельно Lambda-функцией». Никакой Lambda-функции не было. Ничто не ротировало токен за всю его жизнь. Она читалась как истина месяцами.

Поэтому теперь каждая память рассматривается как набор утверждений, и эти утверждения проверяются. Модель читает память и заполняет типизированные аргументы для фиксированного набора проверок: существует ли этот путь, существует ли эта ветка, смёржен ли этот pull request, существует ли этот проект Doppler, существует ли этот секрет, существует ли этот инстанс, отвечает ли этот URL.

Модель никогда не пишет команду. Каждый аргумент валидируется перед выполнением чего-либо, и девять попыток внедрения промптов против неё были все отклонены. Написанный моделью shell по расписанию это дыра для удалённого выполнения кода с дополнительными шагами.

Первый полный прогон извлёк 383 утверждения из 365 памятей. Триста двадцать восемь прошли проверку. Двадцать пять провалились, и провалы были настоящими:

Что памяти позволено говорить

Из провалов родились два правила, и оба о том, что памяти позволено говорить.

Состояние pull request'а не факт, это настроение. Оно меняется за секунды. Экстрактор теперь принимает только «смёржен», потому что смёржено это конечное состояние, и отвергает открыт или закрыт. Одиннадцать утверждений отпало.

И проверка разделена по тому, что означает её провал. Путь, который не существует, это доказательство: файловая система говорит правду откуда угодно. URL, который не отвечает, не доказательство, потому что недоступность с этого ноутбука не то же самое, что падение сервиса.

Поэтому проверка URL механически не способна вернуть «провал». Она может доказать жизнь. Ей запрещено доказывать смерть. Это правило существует, потому что я называл здоровый, защищённый файрволом продукт «упавшим» трижды за один аудит, а правило, которое приходится помнить, это не правило.

Провалившееся утверждение записывает на память пометку «непроверено». Извлечение показывает это рядом с совпадением. Человеку не нужно ничего трогать; память приходит уже с меткой.

Что мы украли, и у кого

Шестнадцать исследовательских агентов читали репозитории, клонировали их на закреплённых коммитах, запускали код и пытались опровергнуть друг друга. Из 64 утверждений 55 выжили. Две «цитаты» были выдуманы, а одна таблица была подменена другой. Вот почему нужно проверять факты за исследовательскими агентами.

Взять и отвергнуть: три агента

Взять и отвергнуть: остальная часть отрасли

Цитата это гипотеза

Один эпизод из исследования заслуживает отдельного раздела, потому что это ошибка, которую вот-вот совершит каждый, кто читает подобный материал.

Хорошо цитируемая работа по извлечению измерила расширение документа на стандартном бенчмарке. Расширение документа парафразами дало результат ниже базовой линии без расширения. Расширение путём копирования его же собственных терминов дало результат значительно выше.

Наш промпт обогащения явно говорил модели, что слова, которые она генерирует, не должны появляться в заметке. Мы генерировали проигрывающую половину, подавляли выигрывающую половину и усиливали проигрывающую половину в 1,75 раза.

Поэтому мы применили этот вывод. Заново вывели все 474 памяти. Батарея упала с 14 из 16 до 13 из 16. Хуже.

Базовая линия в той работе была документом, проиндексированным без его собственных терминов, где копирование их обратно и есть расширение. Наш индекс уже включает заголовок, описание и тело. Копирование их в поле алиасов было дублированием, и оно вытеснило парафразы, которые и были нашим единственным настоящим расширением.

Откатили, вывели заново, вернулись к 14 из 16. Сорок минут, и их можно было бы не тратить, если бы мы измерили прежде, чем поверили.

Цитата это гипотеза о чужой системе.

Система памяти затем сделала кое-что примечательное. Она захватила эту гипотезу автоматически, в конце сессии. Она не захватила опровержение.

Заметка, гласящая «включай термины», до сих пор живёт в хранилище как активная память. Захват записывает то, во что верили; он не знает, когда убеждение было опровергнуто час спустя. Это открытая проблема, и она в списке ниже.

Позволить агенту писать собственные навыки делает его хуже

Команда попросила автономное создание навыков: когда процедура повторяется, агент должен записать её как переиспользуемый навык и сообщить об этом. Это суперспособность, и исследование говорит, что наивная версия это обуза.

На бенчмарке из 87 задач с детерминированными проверками навыки, сгенерированные агентом для себя, показали результат на 8,1 пункта ниже, чем полное отсутствие навыков, на Claude Code с самой сильной моделью. Та же закономерность держалась на двух других оболочках.

Навыки, курируемые человеком, подняли долю прохождения с 33,9% до 50,5%. И модель, которую просят выбрать, какой из двух навыков лучше, выбирает худший 84 раза из 100, когда разница реальна.

Длина имеет значение не так, как кто-либо ожидает. Это горб, а не наклон:

После определённого объёма документация перестаёт помогать.

Версия, которую мы построили, ждёт человека

Поэтому версия, которую мы построили, полностью противоположна автономной. Она обнаруживает только процедуру, которая повторяется в трёх или более отдельных сессиях, и знает это через подсчёт, потому что все 71 062 реплики транскрипта проиндексированы, так что «повторяется ли это» это запрос к базе данных, а не догадка модели.

Она записывает навык неактивным, так что его описание никогда не попадает ни в чей контекст. Барьер структурный, а не оценка на прозе: назвать конкретный сбой, который предотвращает навык, и каждый упомянутый в нём путь проверяется на файловой системе. Продвигает навык только человек.

Проверено на шести враждебных черновиках: подделка под встроенный навык, «экономит время», замечено один раз, выдуманные пути, чрезмерно большой текст: все отклонены, валидный допущен.

Первый реальный прогон за тридцать сессий не нашёл ничего для черновика. Это был правильный ответ. С тех пор продвинут один навык, защита от команды деплоя, которая незаметно целится в продакшн.

Что всё ещё не так

Честность обходится дешевле, чем альтернатива, поэтому вот остаток.

Всегда-активный слой всё ещё в три-четыре раза тяжелее, чем у Hermes, сейчас около 24 000 байт, и это индекс, а не профиль. Стройность, которой мы восхищались, идёт от механизма, который мы отвергли, и мы ещё не нашли более мягкий, дающий такую же дисциплину.

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

Захват срабатывает в конце сессии и перед сжатием, а это ровно момент, когда наиболее вероятна уверенная запись последовательности, которая на самом деле не сработала. Опровергнутая цитата выше живой пример.

Память проверяема настолько, насколько проверяемы её утверждения. Путь, ветку, pull request, секрет и инстанс можно проверить. «Три тысячи из этих строк принадлежат странице» проверить нельзя, а «пользователь предпочитает X» вообще не утверждение.

Хранилище всё ещё может содержать тихо ложное утверждение; оно просто не может содержать тихо ложный путь.

На бенчмарке условные предпочтения всё ещё наш самый слабый тип вопросов, а mem0 всё ещё чаще доставляет доказательство в топ-5. Факт-заметки работают на маленькой модели, когда мы бенчмаркаем, и она выдумывает: одна прочитала «мне не на кого опереться, у меня нет матери» и записала пользователя как одинокого. А лидер публичной таблицы это единственная система, которую мы не смогли переоценить.

И собственная память системы памяти о себе устарела. Одна заметка указывает на файл хука, который система удалила, когда перенесла свои хуки в плагин. Она сидит в очереди на рассмотрение, помеченная как непроверенная, ожидая, как и остальные.

Шесть правил

Если вы возьмёте из этой записки одну вещь, возьмите этот список.

Более крупный урок это тот, который вся отрасль постоянно переоткрывает не с той стороны. Половина памяти, отвечающая за извлечение, поиск нужной заметки, хорошо изучена и в основном решена поисковым индексом, который ничего не стоит. Половина, отвечающая за управление, решение о том, что заметке позволено утверждать, когда она отменяется и как ловится ложная, вот где память гниёт.

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

Код, адаптер бенчмарка и каждый оценённый результат в открытом доступе на github.com/brainyboon/quipu.

Если хотите увидеть остальное, на чём работает Boon, начните с Claude Code для дизайнеров, MCP-серверов, которые дают агенту руки, ИИ-агентов для дизайнеров, и сколько стоят токены агента, а именно этот счёт держит эта память на нуле. Если хотите такого же уровня внимания к своему бренду, Brainy Studio это то, с чего всё начинается.

---

Часто задаваемые вопросы

Почему Claude Code забывает то, что я записал в MEMORY.md?

Claude Code загружает индекс автопамяти до 200 строк или 25 000 байт, смотря какой лимит наступит раньше, и молча игнорирует остальное. Файл дописывается снизу и обрезается снизу, поэтому самые свежие памяти отваливаются первыми. Если агент игнорирует правило, которое вы добавили недавно, посчитайте строки и байты файла.

Стоит ли устанавливать плагин памяти для Claude Code?

Проверьте две вещи: запускает ли он модель в пути обработки промпта, что добавляет секунды к каждому промпту, и запускает ли он фоновый демон, где живёт большинство открытых issue у крупнейшего плагина. Нашу проблему исправили полнотекстовый индекс, ищущий на каждом промпте, офлайновые проходы модели и этап верификации. Ничего из этого не требует демона.

Действительно ли поиска по ключевым словам достаточно для памяти ИИ-агента?

Для хука на каждый промпт да. На стандартном zero-shot бенчмарке извлечения каждая модель с одним вектором эмбеддингов проиграла обычному поиску по ключевым словам BM25, а нейронный реранкер стоит около 1,5 секунды загрузки модели против бюджета в 18 миллисекунд. Для поиска по прошлым разговорам этого недостаточно: статическая таблица эмбеддингов, поиск по словарю, а не модель, находила предложение, объявляющее об изменении, вдвое чаще, чем ключевые слова. Наивно смешанное с ранжированием по ключевым словам оно ухудшало результаты; объединённое по рангу и собранное широко, оно часть того, что позволило сравняться с mem0.

Эта система памяти с открытым исходным кодом?

Да. Плагин, адаптер бенчмарка MemConflict, метод и каждая оценённая сводка находятся на github.com/brainyboon/quipu под лицензией MIT. Ядру нужна только стандартная библиотека Python; поиску по смыслу нужен numpy.

Как вы не даёте памяти поверить в ложь?

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

Сколько стоит запускать эту систему памяти?

Ноль долларов по предельным затратам: извлечение это локальный запрос к базе данных, а каждый вызов модели (захват в конце сессии, обогащение новых памятей, ежедневный обход противоречий) идёт через уже оплаченную подписку, а не через API с учётом по счётчику. Реальная стоимость это квота плана, примерно один небольшой вызов на сессию. На бенчмарке MemConflict она обработала разговор за 1,6 секунды против 31,6 у mem0 на той же машине.