Как увеличить лимит вывода Claude Code

Коротко: как увеличить лимит вывода Claude Code

Обе настройки появились в Claude Code 2.1.261 4 сентября 2026 года. Они решают вполне конкретную проблему: команда выполнилась и нужные данные есть, но до модели дошла лишь малая часть вывода.

Это лимиты символов, а не токенов. Представьте окно выдачи: чем шире его открыть, тем больше строк лога Claude увидит за один раз, но каждая дополнительная строка займёт место в контексте сессии.

Сначала восстановите недостающий вывод

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

При успешном выполнении команды Claude Code по умолчанию передаёт в сессию примерно 30,000 символов. Если вывод длиннее, Claude получает короткий фрагмент из начала и путь к сохранённому файлу вывода в каталоге сессии. Попросите Claude прочитать этот файл или выполнить по нему поиск. Обычно такой подход расходует меньше контекста, чем отправка полного лога при каждом похожем запросе.

С ошибками всё устроено иначе. Если вывод слишком велик, Claude получает фрагменты из начала и конца общим объёмом примерно 10,000 символов, а путь к сохранённому файлу в результате не указывается. Если нужная трассировка стека оказалась в середине, перезапустите команду и запишите весь вывод в заранее известный файл:

# Baseline: run the command normally and observe where its inline result stops
npm test

# Recovery for a failing run: keep the whole log at a path Claude can inspect
mkdir -p .claude/logs
test_status=0
npm test > .claude/logs/test-full.log 2>&1 || test_status=$?
wc -c .claude/logs/test-full.log
tail -n 120 .claude/logs/test-full.log
printf 'test exit code: %s\n' "$test_status"

Теперь файл .claude/logs/test-full.log — основной источник данных. Вместо вставки всего файла в чат попросите Claude найти в нём названия упавших тестов, исключения и трассировки стека. Такой способ также сохраняет исходный код завершения как видимое подтверждение результата.

Когда команда переходит в фоновый режим, Claude Code уже сообщает, в какой файл она пишет вывод. Anthropic теперь помечает TaskOutput как устаревший инструмент и рекомендует применять Read к этому файлу — зачастую это более аккуратный способ восстановить данные.

Измените только необходимый параметр

Если одна и та же успешно выполняемая команда постоянно выходит за стандартное окно, увеличьте только bashOutputMaxChars. Начальное значение 60,000 примерно вдвое расширяет стандартный объём вывода в сессии, не поднимая его сразу до максимума в 128,000 символов:

{
  "bashOutputMaxChars": 60000
}

Поместите этот объект в файл, область действия которого соответствует задаче:

Выполните /status, чтобы убедиться, какой файл загрузил Claude Code. Затем снова запустите ту же команду и сопоставьте результат wc -c с выбранным значением. Если лог по-прежнему окажется длиннее, для успешной команды Claude Code снова должен показать фрагмент вывода и путь к сохранённому файлу.

Для фоновой задачи вместо этого используйте taskOutputMaxChars. Здесь действует тот же диапазон — от 4,000 до 128,000 символов. Если вывод завершённой фоновой задачи всё равно превышает лимит, Claude получает последние символы, поэтому полную историю надёжнее смотреть в файле вывода.

Обе настройки имеют приоритет над прежними переменными окружения. При наличии bashOutputMaxChars Claude Code игнорирует BASH_MAX_OUTPUT_LENGTH, а при наличии taskOutputMaxChars — TASK_MAX_OUTPUT_LENGTH. Одновременное использование обоих способов усложняет диагностику, поэтому источник значения должен быть один.

Расход контекста не исчезает, а перемещается

Если увеличить стандартный лимит успешной команды примерно с 30,000 до 60,000 символов, можно обойтись без отдельного чтения файла — при условии, что результат помещается целиком. Но одновременно в сессию может попасть примерно на 30,000 символов больше. Максимальное окно в 128,000 символов чуть более чем в четыре раза превышает стандартное.

Универсального и честного способа пересчитать эти дополнительные символы в токены или деньги нет. Исходный код, JSON, обычный текст и Unicode разбиваются на токены по-разному, а стоимость или квота зависят от модели и типа аккаунта. На практике достаточно следовать простым правилам:

• Повышайте лимит, если в пропущенной середине постоянно остаются данные, нужные Claude.
• Оставляйте стандартное значение, если ответ даёт один точечный поиск по сохранённому файлу.
• Убирайте проектное исключение после завершения работы с особенно шумным выводом.
• Не повышайте оба лимита только потому, что одна команда однажды была обрезана.

Это дополняет подход к снижению расхода контекста навыками Claude Code. Метаданные навыков занимают контекст ещё до начала работы, а вывод инструментов поступает уже в процессе. Решение одной проблемы не устраняет другую.

Семь сценариев, где увеличение лимита особенно полезно

1. Сводки тестов в монорепозитории

При запуске большого набора тестов инженер по релизам может получить успешный результат, в котором сводки по пакетам и предупреждения не помещаются в стандартное окно. Увеличение bashOutputMaxChars для этого репозитория позволит сразу увидеть сводку целиком. Если вывод укладывается в выбранный лимит, при каждой проверке релиза потребуется меньше дополнительных чтений.

2. Фоновые среды для интеграционного тестирования

Платформенная команда может оставить локальный сервер, эмулятор или интеграционную среду работать в фоне, пока Claude занимается другими задачами. Повышенный taskOutputMaxChars позволит Claude получить больше свежих данных при следующей проверке задачи. При этом полный файл задачи остаётся важным: после переполнения настройка отдаёт предпочтение последним символам.

3. Массовая проверка предупреждений компилятора и линтера

Сборка приложения может завершиться успешно и при этом выдать тысячи предупреждений. Более широкое окно успешной команды покажет сообщения из пакетов, которые иначе остались бы за пределами фрагмента. Это оправданно, когда команда разбирает накопившиеся предупреждения и полный результат важнее экономии контекста.

4. Пробные запуски миграций базы данных

Инженер по данным может выполнить успешный пробный запуск, который выводит каждое предлагаемое изменение схемы. Если ограниченный по размеру план остаётся в сессии целиком, Claude сможет сопоставить связанные изменения в одном результате. Так сохраняется непрерывность ревью, но лишь при условии, что из лога исключены секреты и производственные идентификаторы.

5. Аудит зависимостей и лицензий

Инженер по безопасности может получить длинный успешно сформированный перечень, в котором важные находки разбросаны по средней части. Репозиторный лимит Bash позволит целиком передать ограниченный отчёт в рамках одной аудиторской сессии. Так снижается риск пропустить пакет лишь потому, что он не попал во фрагмент.

6. Поиск причин нестабильных тестов

QA-инженеру нужна точная последовательность событий вокруг непредсказуемого сбоя, но результат команды с ошибкой показывает только начало и конец вывода. Повышение лимита Bash не меняет это поведение. Если сохранить вывод повторного запуска в известный файл, а затем искать по узкому временному диапазону или названию теста, данные останутся доступны и не заполнят всю сессию.

7. Многословные генераторы кода

Разработчику может единожды понадобиться полный отчёт генератора об успешной работе — например, чтобы проверить каждый созданный или пропущенный файл. Временная локальная настройка расширит результат на время проверки, после чего её можно удалить. Это упрощает аудит сгенерированных изменений и не превращает разовое исключение в постоянное командное правило.

Если структура файлов настроек пока незнакома, в подробном руководстве по настройке Claude Code сначала объясняется место инструмента в рабочем процессе, а уже затем — тонкая настройка этого частного случая.

Что имеет смысл создать

Лучшая возможность: контекстный брокер логов

Можно создать локальную обёртку команд для команд разработки с ИИ: она всегда сохраняет исходный лог, измеряет число символов, индексирует важные диапазоны и возвращает компактный манифест с путями. Рекомендовать отдельный лимит вывода для конкретной команды ей следует лишь тогда, когда одни и те же данные приходится извлекать снова и снова.

Смежный спрос невелик, но коммерчески привлекателен. По данным о ключевых словах в США, запрос log analyzer получает около 320 поисков в месяц, имеет транзакционный интент и цену клика $60.95. Бюджеты на существующие решения для наблюдаемости подтверждают, что за работу с логами уже готовы платить: Better Stack предлагает пакет на 40 GB для логов, трассировок и метрик за $25 в месяц при годовой оплате, а также чат AI SRE по цене $5 за миллион токенов. Эти продукты решают более широкую задачу, но сами расходы показывают, что команды платят за поиск полезного сигнала в логах.

Минимальная версия, которую уже можно продавать, — кроссплатформенная обёртка, локальный каталог логов, счётчик символов, индекс сбоев и отчёт, который Claude сможет читать выборочно. Главный риск — доверие. В логах сборки могут оказаться учётные данные, сведения о клиентах и закрытые пути, поэтому локальное хранение и понятные правила маскирования чувствительных данных — основа продукта, а не финальная полировка. Это самая сильная возможность, поскольку она решает повторяющуюся задачу, стоящую за настройкой, а не просто меняет JSON.

Нишевая возможность: упаковщик данных о сбоях тестов

Можно создать адаптер, который запускает распространённые тестовые фреймворки, сохраняет неизменённый лог и выдаёт Claude краткую карту данных: названия упавших тестов, диапазоны трассировок стека и путь к файлу для более глубокого анализа. Команды QA и Developer Experience будут готовы платить, если один шумный набор тестов ежедневно создаёт одну и ту же работу по диагностике.

Запрос test failure analysis получает, по оценке, 20 поисков в США в месяц при низкой конкуренции и сложности ключевого слова 11. Для позиционирования самостоятельного универсального SaaS такого спроса мало. Однако его достаточно, чтобы оправдать узкую функцию внутри брокера логов или платный инструмент для команд с дорогостоящими наборами тестов.

Для MVP потребуются адаптеры к двум или трём средствам запуска, детерминированное хранение исходных логов и параллельное представление извлечённых данных со строками источника. Главная сложность — фрагментация: Jest, Pytest, Gradle и собственные раннеры оформляют ошибки по-разному, а слишком самоуверенный экстрактор может удалить именно ту подсказку, которая была нужна Claude. Исходный файл всегда должен оставаться доступен в одном чтении.

Где эта настройка не поможет

Этот параметр не добавляет сообщений Claude, не повышает недельную квоту, не расширяет контекстное окно модели и не обходит лимит на использование инструментов. Он меняет только обработку числа символов в сессии для двух типов локальных результатов Claude Code.

Безграничный вывод от этого тоже не становится безопасным. Сохранённый Claude Code вывод успешной команды обрезается после 64 MiB, а команда принудительно завершается, если поток её вывода превышает 5 GB. Кроме того, результат на 128,000 символов может вытеснить из контекста полезную часть диалога. Максимум — это предохранитель, а не рекомендация.

В облачных сессиях есть ещё одна ловушка, связанная с областью действия. Они читают закоммиченный .claude/settings.json, но не пользовательские и локальные файлы настроек с вашей машины. В такие сессии попадают только управляемые сервером настройки организации. Если значение будто бы игнорируется, проверьте /status, прежде чем снова его менять.

Если нужен контекстный процесс разработки с учётом особенностей ваших тестов и систем логирования, стоит начать с систем внедрения ИИ.