pi-dcp (Dynamic Context Pruning): принцип действия, методики и подводные камни использования

Глубокий анализ расширения PSU3D0/pi-dcp для Pi Coding Agent · собрано и верифицировано 2026-10-03

Резюме

pi-dcp решает реальную проблему — раздувание контекста длинной сессии за счёт гигантских и устаревших выводов инструментов — элегантным архитектурным ходом: не мутировать историю, а строить к каждому запросу LLM «проекцию» истории, из которой чистыми детерминированными функциями вырезан мусор. Инварианты (неприкосновенность user-сообщений, финальных ответов, недавних ходов и локального JSONL) подтверждены чтением исходников [P-03, P-10].

Однако ядро принципа действия — «переписывать середину истории практически каждый ход» — вступает в прямое противоречие с экономикой prompt caching современных провайдеров. Все 33 утверждения двух коллекций прошли верификацию; ключевой вывод: на Anthropic-протоколе pi-dcp в дефолтной конфигурации может увеличивать стоимость сессии, одновременно показывая в футере «экономию» (механизм подтверждён кодом, issue #1, документацией провайдеров и бенчмарком сестринского расширения; чистый денежный исход не измерен никем [C-01, C-02, C-04, P-20]). Дополнительно: peer-dependency расширения фактически несовместима с текущим Pi 1.0 [C-07], проекту 7 месяцев, у него 9 коммитов, один репорт от одного пользователя и ноль независимых отзывов [C-01, C-12], а имя «pi-dcp» носят ещё минимум три посторонних пакета — риск установить не то [верификатор, дополнительная находка].

Ограничения и риски (читать до принятия решения)

Критические находки вынесены вперёд, потому что они определяют профиль риска инструмента сильнее, чем его фичи.

1. Дефолтная конфигурация ломает prompt cache практически каждый ход — главный экономический риск [C-01, P-06, P-02]. Уверенность механизма: ВЫСОКАЯ (код + issue + экономика провайдеров); уверенность чистого денежного исхода: НЕИЗМЕРЕНА.
Три «безопасные» стратегии (deduplicate, purgeErrors, outputBodyReplace) имеют минимальную полосу давления low — они срабатывают при любом заполнении контекста, даже нулевом, причём если Pi не смог измерить usage, band unknown тоже деградирует до low. Пороги прунинга привязаны к возрасту хода, поэтому каждый новый ход «состаривает» очередные payload'ы за пределы защитного окна: середина префикса меняется почти в каждом запросе. Единственный зарегистрированный issue проекта (#1, 2026-06, без ответа мейнтейнера) описывает ровно это: «unpressured outputBodyReplace triggers basically every turn, meaning that I lose the cache advantage». Предложенное в issue лекарство (гистерезис) не реализовано.

2. Экономика кэша делает «серединные» переписывания самой дорогой формой мутации [C-02, P-15, P-16, C-06]. Уверенность: ВЫСОКАЯ (мульти-источник: AWS Bedrock, certsafari с цитатами заблокированных регионально офици­альных доков Anthropic, независимо измеренный mempko-блог).
Кэш Anthropic — префиксный, побайтово точный: «изменение на одном уровне инвалидирует этот уровень и всё после него». Кэш-чтение стоит ~0.1× базовой цены input, кэш-запись — 1.25×, TTL — 5 минут (1-часовая опция 2×). Когда DCP заменяет tool-вывод на ход N плейсхолдером, весь хвост после N перетарифицируется: то, что читалось бы по 0.1×, перечитывается по 1.25× (или 1×). Формально футер «✂️ DCP: ~Nk tokens saved» на закэшированных участках завышает денежную экономию до ~12.5×. Критично: это провайдерно-асимметрично — на OpenAI (кэш автоматический, скидка 50%, нет премии за запись) и особенно Gemini (чтение ~0.25×, кэш липкий) штраф за мутацию много мягче, а на DeepSeek соотношение hit/miss 30–50× делает потерю кэша самой дорогой в относительном выражении [P-17, P-18, P-19, C-06].

3. Единственный количественный бенчмарк этого же класса стратегий показывает: при агрессивном кэшировании экономия — «копейки» [C-04]. Уверенность: СРЕДНЯЯ (самостоятельный, не реплицированный бенчмарк сестринского расширения — но другого измерения стратегии-класса не существует).
Расширение pi-dynamic-context-pruning (diegopetrucci, v0.1.11) реализует те же детерминированные стратегии, но за cache-aware гейтом чистой выгоды. Его корпус из 1390 сессий (556 кандидатов на прунинг) даёт суммарную реализованную выгоду ~20.6k token-units при r=0.1 (типичный Anthropic) — «economically marginal, on the order of pennies»; выгода становится материальной только при r≥0.25 (Gemini, слабое кэширование). Его же вывод: «deterministic strategies cannot beat cache-bust penalty at aggressive caching». pi-dcp работает без такого гейта вообще.

4. Peer-dependency расширения сломана относительно текущего Pi [C-07]. Уверенность: ВЫСОКАЯ (проверено живым запросом в npm).
Заявленный диапазон @mariozechner/pi-coding-agent >=0.54.0 <1 указывает на мёртвый скоуп (последняя публикация 0.73.1, 2026-05) и верхней границей <1 исключает каждую текущую версию активного пакета @earendil-works/pi-coding-agent (1.0.x от 2026-10-01, с секциями breaking changes в changelog). Расширение может продолжать грузиться, если поверхность API не разъехалась, но формальный контракт совместимости нарушен, и проект (последний коммит 2026-03-06, предшествует issue #1) на это не реагировал.

5. Зрелость и отсутствие полевых данных [C-12, P-01]. Уверенность: ВЫСОКАЯ (двойно подтверждённый отрицательный результат).
7 месяцев, 25 звёзд, 9 коммитов, один автор, один issue от одного пользователя, ноль закрытых, нет лицензионного файла в репо (MIT — только словами в README). Никаких сторонних обзоров, обсуждений на HN/Reddit, независимых бенчмарков. Регрессионные тесты — на фикстурах, не на реальных сессиях. «Безопасность» в проекте определена структурно (что не трогается), а не по исходу (не измерялась успешность задач ни разу). При этом поле не пустое: три независимых потомка/реимплантации той же идеи независимо встроили защиту ровно от поведения pi-dcp — cache-aware гейт, «byte-stable prefix-cache-friendly placeholders» (плейсхолдер появляется один раз и далее не меняется), агентное LLM-сжатие [C-13]. Схождение трёх проектировщиков вокруг одного и того же обхода — сильное косвенное свидетельство, что поведение pi-dcp считается в этой нише дефектом, а не фичей.

6. Риск «установить не то» [дополнительная находка верификатора].
Имя pi-dcp занято минимум тремя посторонними пакетами: hypernewbie/pi-dcp (GitHub), @snowy117/pi-dcp и @edmundmiller/pi-dcp (npm), плюс страница pi.dev/packages/pi-dcp. Это одновременно и объяснение, почему по PSU3D0/pi-dcp не находится обсуждений (сигнал утоплен в омонимах), и практическая ловушка при поиске и установке. Ставить нужно строго из git:github.com/PSU3D0/pi-dcp.

7. Конфликт с двумя механизмами самого Pi [C-08, C-09, P-11, P-12, P-13]. Уверенность механизма: ВЫСОКАЯ (официальные доки); последствия — вывод из документированного поведения, не измерены.
(a) Pi оценивает порог авто-компакции по проекции после context-хука, т.е. по уже пруненной DCP-истории: прунинг откладывает/подавляет штатную компакцию, а когда та всё же срабатывает, LLM-суммаризатор читает уже усечённую проекцию — плейсхолдеры вместо данных попадают в постоянное резюме (двойная потеря: DCP-усечение, затем суммаризация усечённого). Координационный хук session_before_compact документирован, но pi-dcp его не использует; надпись README «compaction preferred» в critical-полосе — ярлык без механизма. (b) Pi в простое сам греет prompt cache (событие cache_warming_decision), а постоянные переписывания середины DCP обесценивают этот прогрев по построению; DCP событие не обрабатывает.

Технические замечания по данным. Коллекционеры сообщили официальные доки Anthropic (platform.claude.com) как «недоступные» — это ограничение фетчера/региона, а не отсутствие данных: содержание присутствует во вторичной цитате (certsafari, с постраничными сносками) и независимо подтверждено первичными доками AWS Bedrock. Расхождений между локальными снимками и живыми источниками не выявлено. Две калибровки верификатора учтены ниже: (1) направление ошибки chars/4 для не-английского инвертировано в критической коллекции — правильно так: для кириллицы/CJK chars/4 занижает и объём, и «экономию» (см. раздел про оценки); (2) ярлык «the riskiest strategy» для supersedeWrites — редакторский вывод пред-собранного анализа, а не текст репо; собственный сигнал проекта — «off by default + держать выключенной, пока не уверены» [P-04].

Принцип действия: философия инструмента

Концептуально pi-dcp — это проекционный фильтр между историей сессии и запросом к LLM. Он не редактирует разговор и не «сжимает память»; он решает, какая версия истории достаточно хороша для данного конкретного запроса. Из этой архитектуры следуют все главные свойства:

Разделение истины и представления. Локальный JSONL сессии — неприкосновенный «прошлый факт» (переживает /undo и ветвление /tree); то, что видит модель, — одноразовая проекция, пересобираемая перед каждым запросом из чистых функций [P-03, P-10]. Pi сам даёт для этого контракт: хук context даёт расширению глубокую копию сообщений, которую можно мутировать без последствий, и «Pi restores that state afterward». Философия: модель не обязана видеть всё, что происходило, — только то, что релевантно сейчас.

Детерминизм вместо интеллекта. В пайплайне нет ни одного LLM-вызова и ни одной семантической суммаризации: одна и та же история всегда даёт одну и ту же проекцию, за ~2 мс [P-03, P-09]. Агентные ручки (distillTool, compressTool, llmAutonomy) зарезервированы в конфиге, но выключены; mode: safe|advanced сегодня «mainly descriptive» — описателен, не управляет политикой [P-09]. Следствие: предсказуемость, нулевая добавленная стоимость и латентность — но и принципиальная неспособность понять, что именно из «старого» важно.

«Каузальная память» вместо контента. Вырезая payload, DCP оставляет скелет: факт вызова, имя файла, тип ошибки. Модель знает, что происходило, но не что именно было увидено/сделано, с плейсхолдером-инструкцией «перезапусти инструмент, если данные снова нужны» [P-03, P-04]. Это честная, но радикальная ставка: инструмент считает, что свежесть факта важнее его содержания — что модель всегда может «перепрочитать мир», но не может «дешевле вспомнить его».

Давление как регулятор агрессии. usageRatio = токены/окно контекста делится на полосы: low (<0.7), medium (≥0.7), high (≥0.8), critical (≥0.9); стратегии гейтятся полосой [P-06, P-09]. Но здесь и начинается главный изъян принципа: автор разместил «безопасные» стратегии в полосе low — т.е. агрессия не зависит от давления вообще. Философия «прунить только под давлением» декларирована механизмами полос, но дефолтная таблица полос обнуляет её для трёх стратегий из четырёх.

«Безопасность» — структурная, не исходовая. README говорит «aggressively yet safely prunes» — но «safely» определено как набор инвариантов (не трогаем user-сообщения, финальные ответы, недавние ходы, JSONL), а не как измеренный исход. Это риторическое усиление, а не фактическое утверждение: в измеримом измерении — экономика кэша — результат «безопасности» как раз отрицательный (см. выше), а в измерении успешности задач не измерялся никем и нигде [P-03, калибровка верификатора; C-12]. Существенно также: полоса давления сэмплируется до прунинга, поэтому реальное пост-прунинг давление ниже расчётного — оценка давления систематически завышена (второстепенная, но идеологически показательная асимметрия: система считает себя более зажатой, чем есть).

Методики: четыре стратегии и защитные слои

1. Exact Deduplicate (вкл, с low-полосы)

Принцип. Если тот же инструмент вызывался с теми же аргументами (SHA-256 от отсортированных JSON-аргументов), payload всех вызовов, кроме последнего, заменяется пометкой «точный дубликат более позднего вызова» [P-04, P-03]. README считает её «always safe».

Последствия. Сила: дубли — реальный мусор (повторные ls, повторные чтения), выгода безобидна по смыслу. Подводный камень — в самой посылке «те же аргументы → тот же результат»: между вызовами мир менялся. Повторный bash cat file после редактирования файла возвращает уже другой контент; старый вывод мог быть единственным свидетельством промежуточного состояния (именно так ловятся «а раньше тут было X»). С дедупликацией модель видит только последнее состояние и теряет доказательство эволюции. Граница между «дубликатом» и «хронологией мира» инструментом не проводится — она просто положена несуществующей. Отдельно: раз эта стратегия тоже живёт в low-полосе, даже она участвует в ежеходном переписывании префикса (замена дублей «оседает» по мере старения) — и в леме кэша соучаствует наравне с остальными [C-01].

2. Purge Errors (вкл, с low-полосы, minTurnAge=3)

Принцип. Стек-трейсы ошибок старше 3 ходов сжимаются до первых 150 символов — «сохраняя каузальную память о типе ошибки» [P-04].

Последствия. Идея разумна для типовых AGENT-циклов: старые трейсы редко нужны. Два подводных камня. Первый — тривиальный: первые 150 символов трейса — это почти всегда шапка (пути bun/TS, версия, заголовок), а диагноз живёт в хвосте; «идентичность» ошибки сохраняется, диагноз — нет. Второй — глубже: цикл «фикс → тест → фикс» и регрессии того же бага делают старую ошибку снова релевантной, и модель, помнящая только «что-то типа TypeError было», будет заново диагностировать то, что уже знала. Плейсхолдер «перезапусти инструмент» здесь вообще слаб: перезапуск воспроизводит состояние сейчас, а не падение тогда (ошибка могла быть исправлена или, наоборот, замаскирована). Число «3 хода» — фиксированная эвристика без связи с реальной релевантностью.

3. Supersede Writes (ВЫКЛ по умолчанию; активна только с high-полосы)

Принцип. Если write/edit крупного файла позже был перечитан через read — содержимое в аргументах write/edit (content, text, oldText, newText) заменяется пометкой «контент superseded более поздким read», потому что «read уже содержит новое состояние» [P-04, P-05].

Последствия. Это самая глубокая семантическая хирургия из четырёх — единственная стратегия, мутирующая собственные действия ассистента, а не результаты инструментов (что подтверждено исходниками: перезаписываются именно block.arguments.*) [P-05]. Подводные камни: (a) теряется diff-семантика — oldText/newText это и есть «что менялось и почему»; после прунинга история правок превращается в «файл читался, файл менялся» без содержания правок; (b) «read содержит новое состояние» верно только если read — полного файла и после последней правки; частичное чтение или правка после чтения ломают посылку; (c) в high-полосе стратегия активна ровно тогда, когда модель больше всего нуждается в понимании, как она пришла к текущему состоянию кода. Показательно, что собственный README проекта просит «держать supersedeWrites выключенной, пока нет уверенности в своём workflow» [P-04] — это сильнейший внутренний сигнал риска, доступный без всяких внешних данных (замечание: ярлык «самая рискованная стратегия» — редакторская характеристика пред-собранного анализа, репо таких слов не содержит).

4. Output Replace (вкл, с low-полосы, minChars=1200)

Принцип. Любой toolResult старше защитных окон и тяжелее 1200 символов (изображения считаются тяжёлыми всегда) заменяется плейсхолдером: «Large output from X(...) pruned due to age. If you need this data again, re-run the tool» [P-04, C-01].

Последствия. Это рабочая лошадка экономии и одновременно главный источник рисков. Три уровня проблем:

• Экономический — ключевой: стратегия активна при любом давлении, включая нулевое; возрастные пороги сдвигаются с каждым ходом, поэтому плейсхолдеры появляются в середине префикса почти каждый ход → кэш-промах на всём хвосте (см. Ограничения, п. 1–2) [C-01, P-06].
• Семантический — «перезапусти инструмент» возвращает состояние сейчас: файл мог быть отредактирован или удалён с тех пор, и модель, доверившись старому прочтению, может не осознать, что ей нужны данные, пока не поздно. Re-run стоит реальных денег и времени — т.е. «экономия» конвертируется в отложенные расходы ровно в тот момент, когда данные оказались нужны.
• Пороговый — 1200 символов (~300 токенов по их же chars/4) — очень низкая планка: уже один экран лога или средний файл qualifies. Порог настраивается, но дефолт делает стратегию тотальной.

Защитные слои (общие для стратегий)

• turnProtection = 8 ходов: последние 8 user-ходов неприкосновенны [P-09]. Принцип: свежее дороже старого. Следствие для практики: в длинных автономных задачах (50+ шагов внутри одного turn) главное давление — внутри turn, где turnProtection бессилен.
• stepProtection = 2 шага: при глубине текущего хода >8 защищает 2 последние пары assistant+toolResult [P-09]. Покрывает «фронт» автономии, но середина длинного автономного хода прунится при high/critical агрессивно — система на лету лишает модель данных, которые она сама собрала 10 минут назад, порождая эффект «иллюзии знания» (факт есть, содержания нет).
• protectedTools: todo, subagent, send_to_session, plan_enter, plan_exit — их выводы не прунятся никогда [P-09]. Принцип: координационные артефакты важнее данных.
• protectedFilePatterns: /CHANGELOG.md, /.plan.md, */progress.md [P-09].
• frontier pinning: эвристики «всегда держать видимыми» — последний read каждого изменённого файла, план/прогресс-артефакты, последний вывод упавшей и последний прошедшей «верификационной команды» [P-08]. Подводный камень — сама эвристика: классификация верификационных команд — regex-белый список экосистемы JS/Rust/Python ((bun|npm|pnpm|yarn) run test, pytest, cargo test/check/clippy и т.п.); make check, python -m pytest, кастомные скрипты не распознаются и не закрепляются; pass/fail определяется по первой строке вывода — хрупко [P-08]. Т.е. frontier «пришит» к определённым стекам; вне них защита молчит, и это не диагностируется.
• Управление: /dcp status|detail|manual on|off; конфиг ~/.pi/agent/dcp.json(c) → .pi/dcp.json(c), поздние перекрывают ранние [P-03, P-09].

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

Сгруппировано по механизму, не по симптому.

Экономические.

1. Ежеходный кэш-бастинг в дефолте [C-01, P-06]: спасение — понимать, что «включённый DCP» по умолчанию означает «переписываю префикс каждый ход». Диагностика конкретной сессии: доля cache_read из общего input; ориентир от Anthropic (вторичная цитата, СРЕДНЯЯ уверенность): у агентных лупов медиана 84% input из кэша, топ-дециль ≥94%; ниже ~80% — что-то ломает кэш [C-03]. Одноранговое подтверждение масштаба штрафа: аудит-инструмент Replay Doctor зафиксировал случай, когда одно изменение tool-листа посреди сессии перетарифицировало 157 080 токенов по цене записи; 98.8% перебиллинга в корпусе из 123 сессий — из одной причины [C-05, СРЕДНЯЯ уверенность — один оператор, чужие агенты].
2. Асимметрия провайдеров [C-06, P-17–P-19]: худший режим — Anthropic-протокол (0.1× чтение, 1.25× запись, жёсткий 5-минутный TTL: 0/48 сэмплов тёплые через 10 минут); мягче — OpenAI (50%, кэш липкий, без премии за запись), Gemini (~0.25× чтение, implicit caching по умолчанию); DeepSeek — hit/miss 30–50×, потеря кэша в относительном выражении максимальна. Практически: один и тот же DCP может быть нетто-выгоден в Gemini-сессии и нетто-вреден в Claude-сессии.
3. Футер — не деньги [C-11, P-07, калибровка]: «~Nk tokens saved» — оценка объёма вырезанных символов (chars/4), а не счета. Она игнорирует разницу кэш-чтение/запись (денежное завышение на закэшированных участках до ~12.5×) и, для не-английского контента, сама chars/4 занижает и объём, и величину вырезанного (кириллица ≈1–2 символа/токен, CJK ≈1 — реальные токены в 2–4 раза выше chars/4; это исправление инвертированной формулировки критической коллекции [Cross-Contradiction 1]). Для русскоязычных сессий оба искажения действуют одновременно в разные стороны — футер ни о чём не свидетельствует.
4. Противодействие прогреву кэша Pi [C-09]: Pi в простое тратится на поддержание кэша тёплым; DCP делает прогретый префикс устаревшим по построению.

Семантические.

5. Плейсхолдер ≠ память: замена контента отсутствием контента необратима внутри запроса; «re-run» возвращает настоящее, а не прошлое (файл мог измениться/исчезнуть), стоит денег и времени, и модель может не почувствовать потребность в данных до момента ошибки.
6. Двойная потеря с компакцией [C-08]: DCP оттягивает штатную компакцию (порог считается по пруненной проекции), а когда та срабатывает — LLM-суммаризатор строит постоянное резюме из плейсхолдеров, т.е. теряет смысл дважды: сначала жёстко (DCP), потом семантически (компакция). Сравнение по существу: компакция Pi — сжимает, сохраняя смысл (LLM-резюме с полем Goal/Constraints/Progress/Decisions, временно выключая кэш-записи для one-off промпта, что само по себе показывает, что платформа считает кэш-экономику first-class); DCP — выбрасывает, сохраняя скелет. В critical-полосе README сам признаёт «compaction preferred» — но координация не реализована [P-11, P-12, P-13].
7. Ослепление в глубокой автономии: turnProtection=8/stepProtection=2 не покрывают середину длинного автономного хода; при high/critical модель работает на скелете собственных недавних исследований [P-09, вывод из механизма — НЕВЕРИФИЦИРОВАНО полемыми данными].
8. Хрупкость эвристик: regex-классификация верификационных команд привязана к JS/Rust/Python-стекам; нестандартные (make check, кастом) теряют frontier-защиту; pass/fail по первой строке вывода хрупок [P-08]. Родословная риска реальна: в апстрим-линиage (opencode-плагин, чьё имя носит идея) задокументирован баг «Bug 39» — защищённые tool-вызовы всё равно сворачивались в компрессию; аналогичный сбой по упущению возможен и в pi-dcp, чья единственная защита — фикстурные тесты [C-10, СРЕДНЯЯ уверенность — кросс-доменное свидетельство по аналогии, НЕ баг pi-dcp].

Инфраструктурные.

9. Сломанный peer-dependency [C-07]: контракт совместимости с Pi 1.0 нарушен; функциональный разрыв зависит от дрейфа API 0.54→1.0 и может произойти невидимо при любом обновлении Pi.
10. Загрязнённое имя: минимум три посторонних pi-dcp-пакета; установка строго из git-источника PSU3D0 [верификатор].
11. Прочие мелкие, из пред-собранного анализа, не подтверждённые внешними данными (НЕВЕРИФИЦИРОВАНО): manual off не персистится между сессиями; возможный edge с Object.assign конфига на session_start.

Плюсы и преимущества (вытекающие из принципа)

• Необратимость исключена на уровне архитектуры: оригинал истории нетронут (JSONL, /undo, /tree) — худший исход DCP-эксперимента: «модель временно видела меньше», а не «сессия испорчена» [P-03, P-10]. Это самое честное преимущество, и оно проверяемо структурно.
• Детерминизм и дешевизна: ноль LLM-вызовов, ~2 мс, одинаковая история → одинаковая проекция; никакой добавленной латентности и стоимости на прунинг-вычисления [P-03].
• Реальная проблема решается по-настоящему: дубли вызовов, мёртвые трейсы и гигантские чтения — доминирующий мусор длинных сессий; при слабом кэшировании провайдера (Gemini; OpenAI отчасти) или длинном TTL-режиме выгода материальна — бенчмарк класса стратегий даёт материальную экономию при r≥0.25 и оптимальные пороги T=29–54 хода [C-04].
• Управляемость на лету: /dcp manual off, /dcp detail (полный разбор что и когда вырезано), конфиг с перекрытием по слоям [P-03, P-09].
• Скелет сохраняется: модель не «забывает», что файл читался и ошибка была; frontier-пиннинг удерживает план/прогресс и последние верификации видимыми — для supported-стеков [P-08, P-09].

Практический вывод

Кому и когда DCP, вероятно, оправдан (СРЕДНЯЯ уверенность — построено на механизмах, а не на измерениях pi-dcp):

1. Провайдер решает всё. На Gemini (чтение 0.25×, implicit caching) детерминированный прунинг может быть нетто-положительным; на Anthropic-протоколе дефолт (три стратегии с low-полосы) несёт механизм ежеходной инвалидации кэша, и по единственному количественному свидетельству класса экономия при агрессивном кэше — «порядка центов» [C-02, C-04, C-06].
2. Если используете на Anthropic — отключайте outputBodyReplace (и, вероятно, purgeErrors), оставляя deduplicate; supersedeWrites держите выключенной (это дефолт и рекомендация самого README) [P-04, P-06]. Это смягчает, но не устраняет churn (возрастные пороги всех стратегий сдвигаются с ходами).
3. Мониторьте cache_read / total_input: ниже ~80% — кэш ломается, и это дороже любых «saved» в футере [C-03].
4. Проверяйте совместимость с текущей версией Pi руками после каждого обновления: заявленный диапазон peer-dependency мёртв [C-07].
5. Альтернатива в том же проблемном поле существует: сестринское расширение с cache-aware гейтом (и режимом gate off) прямо решает экономическую ловушку, которую pi-dcp игнорирует [C-04]. Конвергентные реимплантации (гейт, byte-stable плейсхолдеры, tiktoken) показывают, что ниша движется в сторону cache-информированного прунинга [C-13].

Сам по себе принцип «проекции без мутации» — архитектурно чист и безопасен в смысле сохранности данных; его уязвимость — в агностичности к экономике кэша провайдеров и в подмене сжатия выбрасыванием. Пока нет ни одного измерения pi-dcp на реальных сессиях (нет вообще — ни авторского, ни стороннего [C-12]), любые заявления о его денежной пользе следует считать маркетинговыми, а решение — принимать по типу провайдера и значению cache-read доли собственной сессии.

Уровни уверенности и источники

• ВЫСОКАЯ (мульти-источник или авторитетный первоисточник, дословные доказательства): P-01…P-19; C-01, C-02, C-06, C-07, C-08, C-09, C-12, C-13; кодовое ядро C-11. Внутри: экономический исход pi-dcp (нетто-рост/снижение стоимости) — механизм ВЫСОКОЙ уверенности, величина НЕИЗМЕРЕНА никем [P-20].
• СРЕДНЯЯ (один вторичный/самоотчётный источник): C-03 (порог 80% кэш-чтений — цитата официалов через сторонний курс); C-04 (бенчмарк сестринского пакета, не реплицирован — но единственное количественное свидетельство класса); C-05 (аудит-инструмент, один оператор, чужие агенты); C-10 (lineage-баг по аналогии, не дефект pi-dcp).
• Исправления, внесённые в этот документ: направление ошибки chars/4 для не-английского (инверсия в C-11 исправлена — занижает); ярлык «riskiest strategy» атрибутирован как редакторский; «safely» из README представлен как структурный инвариант, а не исходовая гарантия.
• Пробелы (честное отсутствие данных): нет ни одного измерения pi-dcp на реальных сессиях (стоимость, успех задач, точность эвристик frontier); нет прямых измерений мутационного (vs TTL) кэш-вытеснения; академическая литература о деградации задач от lossy-компрессии не покрывалась поиском; число «157 080 токенов» относится к чужим агентам (Claude Code/Codex), не к pi; официальный Anthropic-минимум кэшируемого префикса не публиковался per-model (существование порогов подтверждено, числа — нет).

Источники по claim-ID прослеживаются до: GitHub API/issue tracker PSU3D0/pi-dcp; локальная копия исходников pi-dcp; установленные официальные доки Pi (extensions.md, compaction.md, CHANGELOG, v1.0.x); npm registry (оба скоупа); AWS Bedrock (prompt-caching, pricing); OpenAI prompt-caching blog/docs; DeepSeek pricing; Google Gemini caching docs; certsafari (цитаты platform.claude.com); pi.dev (пакет diegopetrucci); acp-kernel README; replay.doctor; blog.mempko.com; HN Algolia (отрицательный результат).