Стратегия чтения больших файлов в pi: варианты A/B/C против стока

Этот док отвечает на пять вопросов из запроса: сравнить варианты A (снизить лимит до 1000 строк / 10k символов), B (не отдавать текст по большим файлам, отдавать предупреждение с числом строк и требованием читать сегментно) и C (гард с локальной картой) между собой и против стокового pi; проверить, не воспроизводят ли они эффект дробления («caveman/RTK» из формулировки запроса); найти выигрывающий вариант и способы его улучшить; развести «предупредить» и «заблокировать»; дать вердикт по внедрению. Данные: pi-механика проверена верификатором прямо по исходникам установленного пакета v0.84.1 (клеймы P-01..P-15 — VERIFIED), внешние находки из критической коллекции (C-01..C-15) большей частью перепроверены по первоисточникам; непроверенное помечено в тексте. По требованию запроса личный опыт владельца сетапа («кап срабатывает редко, но когда срабатывает — 30–70k сожрано, и чтение часто уходит вникуда из-за перечитывания») принят как установленный факт и не оспаривается.

Limitations and Risks

Сначала о том, чего в этой картине нет, потому что от этого зависит вес всех выводов ниже.

Главное ограничение: вся токеновая арифметика в доке — качественная, а не измеренная. Ни один найденный источник не квантифицирует ни частоту попадания сессий в стоковый кап (это подтвердили независимо оба коллектора и верификатор — C-14, а также coverage-заметки предыдущей итерации), ни чистый эффект дробления чтений на суммарный расход (C-14 — целевой поиск по четырём формулировкам не дал ни подтверждения, ни опровержения). Единственные внешние цифры об экономии на обрезке чтений — самозаявленные: Hermes-плагин заявляет до 60% экономии без репликации (C-09), репортер Claude Code #20223 замерил 1.7-кратную цену нумерации строк без внешней проверки (C-12). Все расчёты по сценариям ниже — арифметика над verified-механикой pi и правдоподобными допущениями, а не замеры.

Числа из практик — ориентиры, не факты. Заявки вида «~90% токенов уходит на exploration» (C-07) и «grep-first тоже жжёт токены» (C-13) — изолированные позиционные репорты без методологии; C-07 вдобавок частично не проверен (один из URL не открылся). Направление у них согласное, но пользоваться ими как числами нельзя.

Поведенческие данные перенесены из других харнесов. Почти вся критическая коллекция — это Claude Code, Gemini CLI, Cline и aider. В pi сигнал об обрезке устроен лучше, чем в большинстве из них (см. раздел 1), поэтому прямое перенесение их багов на pi некорректно; перенесено только то, что касается поведения моделей, а оно по наблюдениям проявляется в разных харнесах (C-10 — Claude и Gemini, разные семейства). Про pi публичных ишью по read-капу не найдено ни одного.

Одна техническая мелочь про доступ к источникам: коллектор primary пометил Anthropic cookbook как «регион-заблокированный для прямого fetch» (P-18), но верификатор скачал эту же страницу без проблем. Это расхождение — ограничение поисковой инфраструктуры, а не блокировка сайта; сам клейм подтверждён, и здесь нечему противоречить.

Про вариант C — главная непроверенная ставка не закрылась. Идея «модель пойдёт по приложенной карте делать точечные следующие чтения» не подтверждена ни одним источником в конфигурации «карта в тул-результате» (унаследовано из прошлого дока, статус не изменился), и появились косвенные контр-данные: aider в официальной документации сообщает, что слабых моделей карта скорее подавляет, чем помогает (C-11 — VERIFIED). Корректность номеров строк в модель-карте по-прежнему ничем не валидируется. Любая оценка C ниже несёт эту оговорку.

И одна ясность по страховке: документированных случаев «модель боится читать» из-за маленьких лимитов не найдено ни одного — ближайшее, что есть, это жалобы на слишком много повторных запросов после обрезки (C-10) и на невнятные сигналы обрезки (C-01, C-04). Риск «модель боится» остаётся гипотезой без единого подтверждения — его нельзя использовать ни за, ни против какого-то варианта, только помнить, что он не измерен.

1. Что именно происходит в стоке и где горят 30–70k

Механика стокового pi на v0.84.1 вся подтверждена по исходникам. У read-тула два независимых лимита — 2000 строк и 50KB, срабатывает тот, что достигнут первым (P-01); те же лимиты режут bash и grep (P-01, P-08). Важная деталь, которая часто теряется: кап применяется к выбранной порции, а не к размеру файла. Если модель запросила диапазон с limit, трюкация вообще не включается; если порция кончилась раньше файла, к результату прикладывается пометка «ещё N строк, используй offset» (P-02). Файл в 300 или 1500 строк сток отдаёт целиком и без каких-либо ограничений — кап физически не может на нём сработать.

Когда модель просит файл целиком и он длиннее капа, происходит вот что: она получает первые 2000 строк (или 50KB) с машинным notice вида «[Showing lines 1-2000 of 50000. Use offset=2001 to continue.]» (P-03). Заметьте — этот notice уже содержит и общее число строк файла, и следующий offset. Данные для «предупреждения с количеством строк», о котором говорит интуиция владельца, в стоке уже вычисляются и уже передаются модели; это подтверждено дважды — кодом и независимым разбором четырёх харнесов (P-03, C-05).

Тогда откуда 30–70k впустую? Двигатель горения находится не в тул-резалте, а в системном промпте: описание read прямо инструктирует — «When you need the full file, continue with offset until complete» (P-04). Модель, получив notice «в файле 50000 строк, читай дальше», следует этой инструкции и пейджит файл до конца по 2000 строк за ход. Для файла на 15k строк это ~7 чтений по 10–12k токенов каждый (50KB — это порядка 10k токенов, см. доку трюкации, P-10) — как раз порядка 70k. А если модель после этого ещё и перечитывает файл сегментами с нуля — что владелец наблюдает регулярно — то первый слепой кусок на 2000 строк оказывается оплачен дважды и не использован ни разу. То есть цифра владельца раскладывается на стоковые слагаемые без всякой мистики: один ход в кап ≈ 10–12k токенов, а 30–70k — это несколько таких ходов, из которых часть продублирована перечитыванием.

Для полноты картины — что бывает без капа. Cline какое-то время жил без трюкации read_file: файл на 100k+ символов уходил в контекст целиком, окно забивалось, и дальше следовало «prompt too long» без механизма восстановления — только новая задача и потеря всего прогресса (C-08 — VERIFIED). Это прямое доказательство того, что кап сам по себе не враг: отсутствие капа ломает сессию необратимо. И ещё один штрих, полезный для сравнения качества сигналов: у Claude Code документирован класс регрессий, где модель принимает неоднозначное превью обрезки за полный файл и работает по частичному содержимому, не замечая пропажи (C-01, C-02 — VERIFIED). В pi такого класса отказа нет именно потому, что notice однозначен: «показаны строки X–Y из Z» нельзя перепутать с концом файла (P-03). Это важно как точка отсчёта: проблема pi не в качестве сигнала — сигнал хороший, — а в том, что сигнал приходит вместе с 10–12k токенов текста, который часто не нужен.

Есть и обходные пути, о которых стоит помнить при любом варианте. Bash-тул режется теми же лимитами, но полный вывод сохраняется во временный файл, путь к которому отдаётся модели (P-07) — то есть осознанная модель может достать весь файл и в обход read, а «потерянного» контента при обрезке не существует в принципе. Grep в стоке возвращает до 100 матчей с урезанием строк до 500 символов (P-08), и связка «сначала точечный grep, потом узкий read по найденному диапазону» — рабочий стоковый паттерн для ситуации «нужна не вся простыня» (C-13 предупреждает и про его цену — см. раздел 4).

2. Три варианта по отдельности

Вариант A: просто снизить лимит до 1000 строк / 10k символов

Идея понятна: раз попадание в кап дорого, сделать каждый удар вдвое дешевле. Реализация тривиальна и подтверждена первоисточником: константы трюкации параметризуются и экспортированы (P-10), а экстеншен может зарегистрировать тул с именем read поверх встроенного — он перезапишет его и в реестре определений, и в реестре исполнения (P-09).

Но у A есть свойство, которое в свете данных владельца оказывается решающим: он меняет поведение в первую очередь там, где и так всё хорошо. Стоковый кап на файлы 1000–2000 строк не срабатывает вовсе — они отдаются целиком (P-02). После снижения лимита этот целый класс файлов начинает резаться: каждое чтение такого файла превращается в усечённое чтение плюс пейджинг. То есть A удваивает частоту срабатывания капа (все файлы 1000–2000 строк добавляются к тем, что и так резались), чтобы вдвое удешевить редкий удар. По принятому факту владельца кап и так редок — значит, основная нагрузка изменений ляжет на нормальный режим работы. При этом сам паттерн «первое большое чтение отдано целиком, потом перечитано» никуда не девается: модель по-прежнему получает 1000 строк текста, которые ей могут быть не нужны, и по-прежнему инструктирована промптом «читай до конца» (P-04). Дешевле — да, вдвое. Лучше по сути — нет.

Отдельный минус: дробление усиливается. Файл на 5000 строк в стоке — это 3 чтения по 2000, в варианте A — 5 чтений по 1000. Если эффект дробления на длинных сессиях существует (см. раздел 4 — измерений нет), A его проявляет сильнее всех остальных вариантов.

Вариант B: по большим файлам не отдавать текст, а отдавать предупреждение

Формулировка из запроса: когда модель просит файл больше 2000 строк, вместо текста выдать предупреждение с числом строк и требованием читать сегментно; сами сегментные чтения никак не ограничивать.

Начать стоит с того, что половина B уже реализована в стоке: предупреждение с количеством строк уже существует (P-03, C-05). Содержательное отличие B ровно одно — удержать текст. Вместо «2000 строк текста + предупреждение» модель получает только предупреждение. И вторая половина формулировки — «сегментные чтения не ограничивать» — уже выполнена стоком: порции до 2000 строк / 50KB не трюкируются (P-02). Как изменение это было бы no-op; B требует реализации только в одной точке — реакции на запрос без offset/limit к файлу длиннее капа.

Что B даёт по токенам, видно из двух сценариев. Если модель запросила файл целиком, потому что он ей действительно нужен, B почти ничего не меняет: модель прочитает его сегментами по 2000 строк — столько же, сколько сток выдал бы пейджингом по notice; суммарный расход тот же, минус только один сгоревший кусок, если бы перечитывание случилось, плюс один лишний ход на ошибку. Если же модель запросила файл вслепую — «а что там вообще» — а нужен был кусок, B экономит весь сгоревший кусок целиком: предупреждение стоит порядка сотни токенов вместо 10–12k. По принятому факту владельца второй сценарий на его кап-попаданиях доминирует — именно поэтому 30–70k «сожраны совсем уж бесполезно». B попадает точно в его интуицию: предупредить дешевле, чем выдать текст, который всё равно перечитается.

Аналог у B в проде существует и живёт годами: Claude Code при чтении свыше ~25k токенов выдаёт жёсткую error-строку «File content (28375 tokens) exceeds maximum allowed tokens (25000). Please use offset and limit parameters...» (C-03 — VERIFIED). Пользователи жалуются на захардкоженный порог, на рассинхрон порогов между поверхностями (Desktop 10k против CLI 25k, #40357) и на баги самого блок-пути в отдельных версиях — но не на сам факт блока. То есть форма «отказ вместо текста с директивой внутри» — обкатанный паттерн, а не эксперимент.

Риск у B один, и он поведенческий: нет гарантии, что модель послушается. В Gemini CLI документирован случай, когда модель перестала читать файлы чанками по первой просьбе и команду приходится повторять минимум дважды (C-10 — VERIFIED); workaround против той же проблемы в Claude Code сам автор называет хрупким (C-10). Но у B есть приятное свойство: цена несоблюдения мала. Повторный слепой read по файлу длиннее капа — это повторная error-строка на ~100 токенов, на которой модель почти наверняка поправится; сравните со стоком, где тот же повторный слепой read — это ещё 10–12k токенов. Дешёвый отказ вместо дорогого — ровно та асимметрия, которую владелец и просит.

«Модель боится читать» тут теоретически возможно (модель, получив error, может постесняться вернуться), но, как сказано в ограничениях, ни одного такого репорта ни в одном харнесе не найдено — а в проде Claude Code блок в этой форме работает постоянно.

Вариант C: гард с локальной картой, line numbers, ленивая подгрузка

Вариант C — линия из прошлого дока: перехватывать каждое чтение, при возврате больше 200–600 строк урезать его и прикладывать карту регионов файла (из tree-sitter/ctags — без модель-коллов), плюс line numbers прямо в выдаче read, плюс карту выдавать не на каждое чтение, а лениво. Механически всё реализуемо в pi без форка: tool_call позволяет мутировать аргументы до исполнения (P-12), tool_result — дорастить результат после (P-13), промпт правится на ходу (P-14), block существует, но для карты бесполезен — error-строка второй канал не несёт (P-11), поэтому гард должен именно урезать, а не блокировать.

Против C, однако, играет сам масштаб проблемы, которую он решает. Гард с капом 200–600 строк срабатывает на каждом чтении исходника средней руки — то есть перестраивает всю повседневную работу с файлами ради редкого дорогого попадания в кап. На классе файлов 200–2000 строк, которые модель читает целиком, гард строго дороже стока: больше чтений, плюс карта на каждом срезе, плюс (если оставить модель-суммаризатор) модель-колл на файл с неограниченным по размеру входом. А главная навигационная ставка — «модель ходит по карте» — как было сказано в ограничениях, не подтверждена, и есть документированные контр-данные от aider (C-11). Отдельно про line numbers: польза адресации подтверждена встречными репортами (без номеров трудно однозначно указать на строку в следующем шаге — C-12), но цена измерена репортером #20223: 1.7-кратный расход к чистым токенам на файле, до 2.95× на больших, что срезает эффективное окно примерно на 40% (C-12). Claude Code платит эту цену сознательно — но и проблема у него другая: он режет на 2000 строк постоянно, у pi-владельца это редкое событие.

Прошлый док уже разбирал полную версию C и пришёл к выводу «не лучше стока; минимальная версия — собирать». Этот вывод остаётся в силе, но с уточнением контекста: минимальная версия была предложена как способ закрыть общие дыры стока (нет номеров строк, нет структурного индекса, промпт толкает в пейджинг). Для конкретно заявленной проблемы — редкое дорогое попадание в кап — минимальная версия C избыточна: она лечит каждое чтение ради лечения одного его типа. Если когда-нибудь захочется строить C целиком, данные для решения даст не анализ, а замеры на своём сетапе; для текущего вопроса он не кандидат.

3. Сравнение по сценариям

Оценки расхода — качественные, на verified-механике; «большое чтение» ≈ 10–12k токенов (50KB / 2000 строк).

По латентности: B добавляет один ход только на попаданиях в кап (редких, по факту владельца); A добавляет ходы на всём, что длиннее 1000 строк, включая нормальные файлы; C добавляет карт-токены и (при модель-суммаризаторе) ожидание модель-колла внутри хода чтения. По сложности реализации: A — копия read с другими константами, час работы (P-09, P-10); B — хук tool_call с блоком и хорошим текстом reason, тоже небольшая работа (P-11); C — экстрактор, кэш, диф-инвалидация, ленивая подгрузка — полноценный проект, и его цена уже разобрана в прошлом доке.

Перверт-риски по вариантам: «модель боится читать» — не подтверждена нигде ни для одного варианта; «слишком много мелких чтений» — риск в первую очередь A (двойное дробление) и C (кап на каждом чтении; позиционный репорт C-13 предупреждает про цену цепочек мелких чтений — направление, не числа); для B дробление ограничено тем, что сегменты остаются по 2000 строк, то есть модели не навязывается мелкость — навязывается осознанность порции. Перечитывание после уреза — механизм владельца, и он у B лечится дополнительно (см. ниже).

4. Дробление чтений: есть ли «эффект caveman/RTK»

Прямой ответ: не существует данных ни в одну сторону, и это подтверждено как пустая область дважды независимо (C-14 — VERIFIED как negative finding). Целевые поиски обоих коллекторов по формулировкам «chunked reads token overhead», «offset limit many calls», «agent re-reads same file» не нашли ни одного источника, который измерял бы, как дробление чтений влияет на суммарный расход на длинной сессии. Заодно выяснилось, что сам термин не про это: «caveman» во внешних источниках — это сжатие выходных токенов со своей собственной ценой (~1–1.5k входных токенов за ход на правила, с честным предупреждением автора, что на уже лаконичной работе можно уйти в минус, P-19), а «RTK» вообще расшифровывается как «Rust Token Killer» и означает сжатие CLI-вывода (P-20). Термин из запроса — внутренний, и его стоит в дальшейших обсуждениях называть по-русски: «дробление», без отсылки к этим проектам.

Что остаётся, когда измерений нет, — качественное рассуждение, и оно говорит вот что. Дробление стоит дорого тогда, когда каждая порция маленькая и порций много: растёт число ходов, растёт повторная отправка накопившейся истории, и на длинной сессии это складывается. Но варианты различаются радикально по тому, насколько сильно они дробят. B не меняет размер сегментов вообще — они как были, так и остаются до 2000 строк (P-02); единственное его дробление — замена одного слепого чтения на предупреждение плюс последующие сегменты, которые в стоке всё равно случились бы по notice. У A дробление удваивается механически (лимит вдвое меньше — чтений вдвое больше). У C добавляется ещё и собственный контентный налог (карты), который к дроблению не относится, но работает в ту же плохую сторону: любой добавленный в контекст токен — это расход без обратной гарантии пользы.

Из этого следует практический порядок риска: если гипотетический эффект дробления существует, первым его проявит A, следом C, а B почти не двигает количество и размер ходов. Плюс у B есть противоход ровно в зону наблюдаемой у владельца траты: перечитывание того же файла. В Claude Code существует задокументированный митигейт — при повторном чтении того же файла/диапазона вместо полного содержимого возвращается заглушка с напоминанием «File already in context» (~87 токенов) (C-06 — класс явления и митигейт VERIFIED, точная формулировка из реестра — частично непроверена). В pi этого механизма нет. Добавить его — значит бить во вторую половину проблемы владельца (перечитывание) независимо от первой (слепое большое чтение).

5. Предупреждение или блок: где проходит граница (вопрос 4)

Ответ на первую половину вопроса: вариант B и интуиция «давать предупреждение с количеством строк» — это одно и то же по сигналу и разные по тексту. Сигнальная половина (число строк + указание, как читать дальше) уже есть в стоковом notice (P-03, C-05); уникальное свойство B — не отдавать 2000 строк текста вместе с этим сигналом. Формулировка владельца «лучше предупреждение» в чистом виде соответствует стоку, а не B; его же критерий «любой вариант, где первый большой read отдаётся целиком и потом перечитывается, — худший паттерн» исключает и сток, и A. Поэтому честная формулировка такова: интуиция владельца и вариант B — одна идея с разной степенью решительности, и решительность — это как раз выбор между «предупредить» и «не отдать текст».

Вторая половина — механика границы в pi, и здесь всё проверено по исходникам. Каналов вмешательства три. Первый — блок: хук tool_call возвращает {block: true, reason}, и вызов превращается в error-результат, содержимое которого — одна строка reason, без деталей, без второго канала (P-11). Второй — тихая мутация аргументов до исполнения, например принудительный limit (P-12). Третий — патч результата после исполнения (P-13), которым можно оформить предупреждение как не-error результат с любым содержимым.

Ключевой вывод по вопросу «потеряется ли что-то, если предупреждение выглядит как error»: для варианта B — нет, и это отличие его от варианта C. У C при блоке потерялась бы карта, которую нечем передать в однострочный error (P-11) — поэтому бриф гарда принципиально требует «урезать, а не блокировать», и это его подтверждённо верное решение. У B второго канала нет по построению: предупреждение — это строка «в файле N строк, читай сегментно с offset/limit», и она целиком помещается в тот единственный канал, который блок и предоставляет. Прод Claude Code годами работает ровно в такой форме (C-03), и накопленные жалобы касаются негибкости порога и рассинхрона между поверхностями, но не формы «error с директивой».

Практическое следствие для реализации: B можно смело делать блоком, и даже желательно, потому что error-вид гарантирует, что модель не воспримет предупреждение как конец файла (тот самый класс отказа C-01/C-02, которого в pi нет именно благодаря однозначности сигнала). Единственная цена — косметическая: в UI pi ошибка выглядит как ошибка. Если это раздражает, есть обходной путь через P-13 — исполнить чтение, но не отдавать текст, а вернуть не-error результат с тем же текстом предупреждения; содержательно это тот же B, просто с другим визуальным оформлением. Оба пути механически подтверждены (P-11, P-13), выбор между ними — вопрос вкуса, а не риска.

6. Вердикт

Очевидно выигрывающий вариант есть, и это B — в форме блока с директивой, реализуемый хуком tool_call.

Логика выбора короткая. Требование владельца асимметрично: редкие, но дорогие попадания в кап, причём дорогие именно потому, что выданный текст часто не нужен и затем перечитывается. Под это требование A подходит плохо — он удешевляет удар вдвое, но удваивает частоту ударов и добавляет дробление в нормальный режим работы, не устраняя сам паттерн «текст выдан — текст сожжён». C решает другую, более широкую проблему, платя за это на каждом чтении и опираясь на непроверенную навигационную ставку (C-11). B — единственный вариант, который бьёт точно в описанный механизм: слепое большое чтение превращается из «10–12k токенов, возможно впустую» в «строку на ~100 токенов + осознанные сегментные чтения», при этом когда файл нужен целиком, B стоит ровно столько же, сколько сток (сегменты не ограничены, P-02), плюс один ход. И его худший отказ — модель один-два раза повторит слепой запрос — стоит порядка сотни токенов, тогда как худший отказ стока — те самые 30–70k владельца. В условиях, где измерений нет ни у кого (C-14), выбирать стоит вариант, у которого цена ошибки минимальна, — это B.

Что конфигурировать рядом:

1. Триггер и порог. Срабатывать там же, где сток срабатывает на трюкацию: запрос без offset/limit (или с порцией больше капа) к файлу, который превысил 2000 строк или 50KB (P-01, P-02). Порог сделать конфигурируемым — это не перестраховка: единственная устойчивая жалоба на такой блок в Claude Code — захардкоженные и рассинхронизированные пороги (C-03, #40357), и индустрия в целом уходит от капов «в строках» к бюджетам в токенах/байтах (C-15). Порог в конфиге стоит дешевле, чем потом жалеть.
2. Текст reason. Одна строка, максимально операциональная. Число строк файла, число байт, если кап по байтам, и конкретная директива с готовыми числами: «File has N lines; read in ranges, e.g. offset=1 limit=1000» (формат рабочего блока из C-03, #4002). Данные для этого уже вычисляются в read.js (P-03) — дописывать подсчёт не нужно.
3. Правка системного промпта read — обязательная пара к B. Стоковый текст «When you need the full file, continue with offset until complete» (P-04) прямо инструктирует модель делать то самое сжигание, от которого владелец хочет избавиться; без правки блок будет дерться с собственным инструктажем харнеса. Правится через before_agent_start или описание тула без форка (P-14, P-09): заменить пейджинг-до-конца на «для больших файлов читайте целевые диапазоны; слепое чтение файла целиком вернёт ошибку с числом строк».
4. Дедуп-заглушка на повторные чтения — второй этап, сильное улучшение B. Она бьёт в механизм «модель всё равно перечитывает тот же файл», на который указывает владелец и который не отсекается самим B: модель может законно прочитать сегмент, а потом запросить тот же файл заново. Паттерн из Claude Code — повторное чтение того же диапазона возвращает короткую заглушку «уже в контексте» (C-06) — реализуем тем же хуком tool_result (P-13) и стоит копейки.
5. Ничего из тяжёлого не тащить. Line numbers в выдаче read для этой проблемы не нужны: измеренная цена 1.7× (C-12) несопоставима с редкостью кап-попаданий у владельца. Карту, суммаризатор, tree-sitter — не трогать; это отдельный проект с отдельной ставкой, и для его решения нужны замеры, а не анализ.

Что измерить сразу после внедрения, чтобы перевести док из качественного в численный: логировать каждое срабатывание триггера (частота кап-попаданий — величина, которой нет ни у владельца в среднем виде, ни у кого в мире, C-14) и расход сессии до/после по футеру pi. Неделя логов закроет и главную неизвестную базу сравнения, и вопрос о дроблении для конкретной модели и конкретных код-баз — вместо гипотезы появится измерение. Если после включения B на длинных сессиях суммарный расход не упал — значит, сжигает не кап, и вот это будет видно впервые.

Уверенность вердикта: MEDIUM. Механика pi, на которой всё построено, — VERIFIED по исходникам (P-01..P-15), прецедент формы «блок с директивой» в проде — VERIFIED по Claude Code (C-03), арифметика экономии — качественная, без замеров. Она поднялась бы до HIGH после логов частоты срабатывания и суммарного расхода на своём сетапе; подняться выше в рамках только внешних источников она не может — данных об этом явлении в среднем по миру не существует (C-14).

Corrigendum к предыдущему анализу (saved/dqsfgt66-analysis.md)

• Claim: Claude Code Read имеет дефолтный кап ~250 строк (подано как прецедент «малый дефолтный кап»).
• Corrected: дефолтный кат Claude Code — 2000 строк либо токен-бюджет порядка 40KB на чтение; значение «250» не подтверждается ни одним найденным источником. Часть прецедента «line numbers + честный PARTIAL-notice» остаётся подтверждённой (P-16 — RE-CONFIRMED).
• Root cause: в предыдущей итерации значение капа не было перепроверено по первоисточникам; наложился документированный дрейф версий Claude Code, в котором семантика капа менялась со «строк» на токен-бюджет (C-15, #20223).
• Confidence change: не влияет на главный вердикт прошлого дока (о полной версии C с модель-суммаризатором), но снимает аргумент «у флагманского харнеса малый кап — и это хорошо работает»: на самом деле кап там сопоставим со стоковым pi, а не в 8–10 раз меньше.

Источники

Механика pi: локальные исходники v0.84.1 (dist/core/tools/read.js, truncate.js, bash.js, grep.js, compaction/*, pi-agent-core/dist/agent-loop.js) и docs/extensions.md — клеймы P-01..P-15, все перепроверены верификатором по дистрибутиву. Внешние: разбор харнесов на Arize (C-05, C-06), ишью Claude Code #4002/#40357 (C-03), #20223/#92979 (C-02, P-16, C-12), #28783 (C-01), Gemini CLI #19066 (C-10) и #4948 (C-04), Cline #4576 (C-08), Hermes read-summarizer (C-09), aider FAQ (C-11), Anthropic context management (P-17, P-18), репо caveman (P-19), hermesatlas (P-20). Непроверенные зоны: C-07, C-13, C-14 (область без измерений), частичная деталь C-06 (формулировка заглушки из реестра reminders).