Паттерн экономии токенов в Claude Code на правке файлов

[sanchesfree]

READ выполняется чтоб понять — может файл уже отредачил другой агент или ещё кто... Будто 1 строку читать в данном случае — опасно

[Regsorm]

Согласен, но это при коллективном редактировании(или многопоточном) Я же редактирую один. Я же пишу - в одной сессии клод. В нескольких сессиях... Там можно разрулить, но более сложно.

[aamonster]

А у него нет операции типа CAS (compare-and-swap) для таких дел?

[Regsorm]

Нет

[alex-khv]

Есть. Diff называется

[schekinfs]

кажется, вам есть еще чего полезного рассказать :). давайте еще

[StudyQA]

Хороший хак. Мы тоже столкнулись с этой проблемой, когда стали гонять ~100 сессий Claude Code в день по разным проектам — контекст забивался чтениями файлов моментально.

Ещё один паттерн, который хорошо работает в дополнение: CHECKPOINT.md в корне проекта. Каждая сессия при завершении пишет туда своё состояние (что сделала, что дальше, какие файлы трогала). Когда контекст компактится или сессия перезапускается — Claude читает один файл вместо того, чтобы заново сканировать полпроекта.

По сути это тот же принцип — держать контекст чистым. Только Read(1-1) экономит на уровне отдельных правок, а чекпоинт-файл — на уровне всей сессии.

А code-index — это свой MCP-сервер для индексации? Или что-то другое?

[Regsorm]

Да, MCP. https://habr.com/ru/articles/1042686/

[dkeiz]

а ещё можно читать/писать исключительно сабагентом с младшей моделью.
Это все весело, пока кросс контекст в коде не понадобится, или не окажется, что модель не прочитала комментарии строкой выше, в которых указано что этот кусок кода менять не надо, менять надо другой
А ещё для любого суперрида из файлов можно устраивать автокомпакт прошлого функционального вызова с записью только результата, тогда контекст всегда будет свеж, правда и кэш придется каждый раз обновлять.
Короче проблема одна - модель в целом не знает какой контекст ей нужен. Если начнет гадать - может прогадать. Если начнет слишком детерминировано искать - так может и не нужны ей лишние риды, пусть пишет в столбик на бэйсике?
Очень хотелось бы узнать на каком стэке такой детерменированный рид реально работает.

[Regsorm]

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

[dkeiz]

это понятно, но хотелось бы объективных бенчмарков. Мой скепсис: если модель не знает, она может начать гадать. Это из очевидного. Но другое - модель может знать половину, а вторую половину придумывать в режиме thinking x(super-ultra)high, и экономии ни по токенам ни по времени не получится. Ваш поиск быстрее, но поиск и так самая быстрая операция из всего инференса.
Я тут без претензий, у меня любопытство. Ведь если есть гарантированно хороший паттерн - о нем стоит знать побольше.

Если же вы за счет индексации добились изоляции (частей) проекта, так может сразу на микросервисы попилить? Шутка конечно, но раз уж отвечают, хочется задать вопросов.

[nidalee]

Все эти костыли, к сожалению, малополезны - модель постоянно спотыкается о кастрированную выдачу того же ртк - "дай проведу тесты rtk npm run tests - ой, что-то не все видно, дай еще раз с грепом проведу - ой, опять не все, щас без ртк сделаю..." в итоге по ощущениям на ту же операцию с третьей попытки уходит только больше токенов, чем на обычную. Так и тут, будет читать и не видеть то, что ожидал - дай по-другому прочитаю, итд итп. Очень и очень не универсально.

[Regsorm]

Если перехватывать все запросы чтения grep/glob/read/bash c целью Read в индексированном каталоге и пропускать все на неиндексированные файлы(тип, размер) - нормально.