Это выборка: всего в таблице проекта двадцать две строки. За пределами показанного - Objective-C с 91.6%, Scala с 91.2%, Svelte со стопроцентным покрытием, Vue, Astro, Lua, Luau. И там же лежит нижний край, которого нет в выборке выше: Liquid на магазине Shopify даёт 73.8%, Pascal и Delphi - 77.4%.
Остаток проект не прячет и объясняет: динамическая диспетчеризация во время выполнения, рефлексия, контейнеры внедрения зависимостей, точки входа по соглашению фреймворка, вендорный код. То есть честная граница статического анализа, а не подкрученный знаменатель.
Смотреть в этой таблице надо на свой язык, а не на среднее - разброс от 73 до 100 процентов слишком велик, чтобы среднее что-то значило.
Индекс, который не отстаёт
У любого предпосчитанного индекса есть врождённая болезнь: он устаревает. Правка есть, а карта старая, и агент уверенно отвечает по вчерашнему коду.
Здесь наблюдатель за файлами ловит изменения через родные события операционной системы и синхронизирует ровно изменившееся. На проекте в четыре тысячи четыреста файлов это около трети секунды работы, на репозитории компилятора Swift в двадцать семь тысяч файлов - около четырёх десятых. Дерево не пересканируется никогда.
С задержкой перед синхронизацией у проекта путаница, и лучше знать код, а не README. В одном месте README обещает срабатывание через триста миллисекунд после одиночного сохранения, а в другом называет окно ожидания в две секунды. Верно второе: в исходнике наблюдателя стоит именно две тысячи миллисекунд, переменной окружения значение переопределяется в пределах от ста миллисекунд до минуты. Серия быстрых правок при этом схлопывается в одну синхронизацию.
Разница с обычным подходом принципиальная: стоимость растёт от размера правки, а не от размера репозитория. Проект приводит сравнение с самым быстрым конкурирующим индексатором на тридцати одном репозитории и тридцати языках - от двух до семи раз быстрее на средних и крупных, и разрыв увеличивается с ростом проекта.
Есть и окно между сохранением и синхронизацией. В нём ответ помечает файл как ожидающий обновления и отправляет агента прочитать живой файл напрямую.
Что показывают замеры
Цифры из README: восемьдесят восемь процентов меньше вызовов инструментов, пятьдесят три процента быстрее, шестьдесят два процента меньше обработанных токенов, сорок четыре процента дешевле. Семь открытых репозиториев, повторный замер в августе 2026.
Это собственные замеры проекта, не независимая оценка. Но методика описана честнее, чем принято: в контрольной группе командная строка заблокирована, чтобы агент "без CodeGraph" случайно не нашёл установленный CodeGraph через оболочку.
Гораздо полезнее среднего - разброс. Экономия оказалась привязана не к размеру репозитория, а к тому, сколько разведки требует вопрос. Там, где агент без графа тратил от двадцати восьми до сорока трёх вызовов, экономия составила от пятидесяти семи до семидесяти восьми процентов. Там, где он справлялся за семь вызовов, разница почти исчезла.
Отсюда практический вывод: польза считается по вашим вопросам, а не по чужому среднему.
Цифра, которую проект публикует против себя
А теперь то, ради чего этот проект стоит уважать отдельно.
Все проценты выше меряют пропускную способность: сколько токенов обработано, сколько инструментов вызвано, сколько денег ушло на один ответ. Они ничего не говорят о том, сколько контекста осталось лежать в окне после ответа. И по этой оси CodeGraph не выигрывает, а проигрывает.
На тех же семи репозиториях в многоходовых сессиях его ответы оставляют примерно на восемьдесят процентов больше остаточного контекста, чем у агента, который читает файлы. На репозитории VS Code это шестьдесят семь тысяч токенов против восемнадцати.
Механизм тот же самый, что даёт скорость. CodeGraph возвращает один плотный дословный ответ, который закрывает вопрос - и остаётся в окне. Агент с grep и чтением файлов перебирает много мелких результатов, и они вытесняются.
Меньше обработанных токенов и больший постоянный след - это два одновременно верных факта, а не противоречие. Если вы работаете длинными сессиями в небольшом окне, это надо закладывать заранее.
Проект мог бы про это промолчать. Он не только не промолчал, но и выложил помодульный замер отдельным документом.
Условие, без которого экономии не будет
Есть требование, которое легко пропустить, а без него всё вышеописанное не работает.
Граф помогает, только когда агент обращается к нему напрямую. Если модель по привычке отправляет разведку подагенту, а тот идёт читать файлы, CodeGraph превращается в дополнительный слой поверх той же самой работы - и становится накладным расходом, а не заменой.
Поэтому в инструкциях интеграции агента прямо направляют отвечать самому, а не делегировать исследование читающим подагентам.
Проверять это стоит на своей настройке: посмотреть, обращается ли агент к графу или продолжает жить старыми привычками.
Установка и три шага, которые нельзя перепутать
