Claude Opus 4.7: правда о чтении всего repo за один раз

Почему 1M context не равен «берём весь repo и вставляем в prompt»

Главная ловушка — считать только исходники. В лимит контекста входит всё, что модель должна «видеть» при генерации ответа: инструкции, файлы, вывод инструментов, ошибки тестов, промежуточные результаты и сам формат будущего ответа. Если вы просите полный security audit, список рисков, diff-патч и план миграции, модель должна не только прочитать входные данные, но и иметь пространство, чтобы всё это написать.

Вторая проблема — шум. В крупных проектах часто есть node_modules, vendor, сгенерированные файлы, артефакты сборки, кэши, минифицированный код, большие JSON, CSV, дампы и логи. Формально их можно попытаться «скормить» модели, но полезности от этого мало: они съедят контекст и ухудшат соотношение сигнала к шуму.

Третья проблема — токенизатор. Anthropic отдельно предупреждает, что у Opus 4.7 новый tokenizer: один и тот же текст может занимать примерно от 1x до 1,35x токенов по сравнению с предыдущими моделями. Для кода это важно: нельзя уверенно сказать «у нас 700 тыс. токенов по старому счётчику, значит всё поместится».

Когда один проход по всему репозиторию реалистичен

Сценарий выглядит правдоподобно, если:

• репозиторий небольшой или средний;
• исключены зависимости, build artifacts, generated files, кэши и большие логи;
• в контекст добавлены только нужные README, конфиги, тесты и ключевые файлы;
• подсчёт сделан через механизм для Opus 4.7, а не «на глаз»;
• оставлен запас под ответ, особенно если нужны отчёт, patch или пошаговый план;
• задача сформулирована так, чтобы модель указала, какие файлы она реально учитывала.

В таком режиме 1M context — мощная возможность: модель может держать перед собой архитектурную картину проекта, связи между модулями и больше контекста, чем коротко-контекстные системы.

Когда лучше не пытаться «всё за раз»

Для большого monorepo, проекта с десятками пакетов, объёмной документацией, автогенерацией, внешними зависимостями и длинной историей логов надёжнее идти поэтапно. Anthropic позиционирует Opus 4.7 для сложных агентных workflows и larger codebases, но это скорее аргумент в пользу инструментального процесса, а не против него.

Практичнее сначала дать модели карту проекта: дерево директорий, manifest-файлы, точки входа, тесты, конфиги CI/CD. Затем — попросить выбрать релевантные зоны, выполнить поиск по символам и зависимостям, прочитать ключевые файлы, проанализировать ошибки тестов и только после этого формировать вывод. Такой подход снижает риск, что модель потратит контекст на мусорные или вторичные файлы.

Как организовать анализ repo без самообмана

1. Начните с инвентаризации. Сформируйте список директорий, языков, пакетов, entry points, тестов, конфигов и последних изменений.
2. Сразу исключите шум. Обычно не стоит включать зависимости, артефакты сборки, автогенерированный код, кэши, большие логи и дубликаты.
3. Пересчитайте токены для Opus 4.7. Оценки от Opus 4.6 или других моделей могут не совпасть из-за нового tokenizer.
4. Не забивайте контекст до последнего токена. Максимальный вывод в 128k tokens звучит много, но большие отчёты и patch-и быстро его расходуют.
5. Просите отчёт о покрытии. В финальном ответе полезно требовать список прочитанных файлов, пропущенных зон, допущений, рисков и проверок, которые нужно запустить человеку или CI.

Итог

Claude Opus 4.7 действительно открывает более реалистичный путь к анализу крупных репозиториев: 1M context window и до 128k output tokens — это серьёзный запас. Anthropic также прямо относит модель к сценариям long-running work, complex agentic workflows и larger codebases.

Но «может один раз прочитать весь repo» — это не универсальное свойство, а условие. Если весь полезный репозиторий плюс prompt, история, результаты инструментов и запас под ответ помещаются в лимит, один проход возможен. Если перед вами большой monorepo или проект с большим количеством шума, разумнее фильтровать, разбивать работу на этапы и проверять результат тестами.