Работая
в айтишечке@workinginit
AI-агентыСтатья с интерактивом

Почему короткие ответы AI не всегда экономят лимит

Агент может прислать ответ в три строки, а до этого прочитать код, открыть логи и несколько раз проверить свою гипотезу. По длине ответа этого не видно.

Сразу попробовать на примере

Один файл, несколько входов

Допустим, просишь найти ошибку в SQL. Агент открывает запрос, читает лог, проверяет гипотезу, правит код и снова запускает проверку. Для выбора следующих действий он обращается к модели. Во вход могут попасть инструкции, переписка, прочитанный код и результаты инструментов. Например, документация Claude Code объясняет, как история и результаты инструментов снова участвуют в запросах.

Теперь условный пример. Инструмент прочитал лог на 20 тысяч токенов — фрагментов текста, которыми измеряют объём входа и ответа модели. Затем агент сделал шесть запросов, в каждом из которых был весь лог. Только этот фрагмент дал 20 000 × 6 = 120 000 входных токенов суммарно.

Инструмент прочитал файл один раз, но его содержимое попало на вход модели шесть раз.

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

Просьба «ответь в трёх предложениях» может сократить финальный ответ. Но сама по себе она не задаёт, сколько файлов агент прочитает и сколько запросов сделает до ответа. Поэтому по его длине нельзя судить обо всей работе.

Число входных токенов тоже не равно расходу лимита подписки: его правила задаёт сервис. Здесь мы не рассчитываем лимит или деньги.

Проверить на примере

В симуляторе можно менять размер фрагмента и число запросов. Сравнение показывает вход с короткой выборкой: например, 2 000 × 6 = 12 000 токенов вместо 120 000. Обе версии используют одинаковое число запросов. Хватит ли выборки для решения задачи, модель не проверяет.

Задайте свою ситуацию

Один фрагмент остаётся во входе каждого запроса.

Вход суммарно · учебная модель

120 000 токенов

Не расход лимита подписки.

От 0 до 100 000 токенов

Сколько раз модель получает этот текст

Тот же текст. Снова на входе.

Учебная модель
Полный фрагмент
  1. Запрос 1
    20 000
  2. Запрос 2
    20 000
  3. Запрос 3
    20 000
  4. Запрос 4
    20 000
  5. Запрос 5
    20 000
  6. Запрос 6
    20 000
20 000 × 6 =120 000входных токенов суммарно — только этот фрагмент

Каждая строка — отдельное обращение к модели. Полоса показывает весь фрагмент в этом запросе. Остальной контекст не показан.

Учебная модель: один фрагмент в каждом запросе, без остального контекста и кэша. Сумма входов не равна размеру контекстного окна или цене.

Открыть симулятор отдельно

Что меняет кэш

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

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

Тогда каждый раз начинать новый чат? Внутри одной задачи это может добавить работы: придётся заново объяснять, что уже выяснили, и читать нужные файлы.

Я бы продолжал отладку в том же чате. А когда ошибка найдена и нужно написать анонс релиза — открыл бы новый. Логу с падением SQL там уже делать нечего. При необходимости можно перенести короткую сводку результата.

А если отдать большой лог помощнику?

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

Но помощник тоже читает, рассуждает и делает запросы. Его обращения тоже входят в общий расход. Делегирование может ускорить работу и при этом потратить больше токенов: такой эффект описывает Anthropic на примере своей исследовательской системы. Это наблюдение об их системе, а не постоянный коэффициент для любых агентов.

Количество текста в главном чате не показывает, сколько поработала вся команда. Работу помощников наш симулятор не считает.

Что я бы поменял в своей просьбе

Вместо одного «найди ошибку, ответь коротко» добавил бы:

Начни с этого SQL-файла. Из лога сначала извлеки сообщение об ошибке и по 30 строк до и после него. Если этого не хватит, расширь фрагмент или проверь связанные файлы. После исправления повтори проверку, на которой возникала ошибка. Если две попытки не помогли, остановись и напиши, что уже проверил и чего не хватает.

Так я задаю, с чего начать и когда перестать повторять неудачные попытки. Размер фрагмента и число попыток можно подобрать под задачу.

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

Источники

Проверены 28 октября 2026 года. Числа в симуляторе — условный пример, не замеры. Практический совет в конце статьи — предложение автора, его влияние на лимит и качество ещё не измерено.