Сколько токенов в длинном запросе: как разделить его на 6 этапов в 2026 году

Что такое токены в нейросети простыми словами?

Когда ты отправляешь сообщение, Claude работает не с ним целиком. Текст превращается в последовательность токенов. Ответ тоже состоит из токенов. Внутренний контекст, который модель учитывает во время работы, измеряется в них же.

Отсюда две практические вещи.

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

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

Не смешивай это значение с другими.

В этой статье токен всегда означает единицу обработки текста нейросетью.

Как нейросеть делит слова на токены?

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

Поэтому не стоит рассуждать так: «В сообщении 20 слов, значит, токенов тоже 20». Это разные единицы подсчёта.

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

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

Если агент несколько раз перечитывает одни и те же файлы, он снова обрабатывает их содержимое, что отмечают в пользовательском отчёте о расходе контекста 19 days, 245 sessions, 123M tokens in Claude Code. Поэтому длинная сессия может расходовать токены даже тогда, когда новое сообщение короткое.

Сколько текста помещает 1 токен?

Запрос «1 токен» часто заставляет искать простую конвертацию: один токен равен какому-то фиксированному числу символов или слов. Такой формулы для всех моделей нет.

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

У меня нет проверенного диапазона для русского языка и примера токенизации одного запроса в конкретной модели, поэтому правило вроде «один токен - это четыре символа» я не пишу.

Есть только ориентир от Anthropic. При описании контекстного окна в 100 000 токенов компания сопоставила такой объём примерно с 75 000 словами. Это оценка для большого объёма. Она не служит переводчиком каждого отдельного токена.

Практический вывод простой: не пытайся оценивать длинную задачу только по числу слов. Смотри на весь контекст, который агент получает в работе, и оставляй запас для ответа.

От чего зависит количество токенов в запросе?

Запрос «количество токенов» обычно считают слишком узко. Человек смотрит на своё сообщение и не видит остальную часть рабочего контекста.

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

Дальше я добавляю к этому ещё несколько источников расхода:

• сообщения текущей и предыдущей переписки;
• файлы, которые прочитал агент;
• результаты команд;
• системные инструкции;
• подключённые инструменты;
• skills;
• MCP;
• файлы проекта.

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

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

Я бы проверял лимиты и расход контекста до начала сложной работы. Если в твоей версии интерфейса доступна команда /context, введи её:

/context

Команда не превращает длинную сессию в короткую. Она помогает увидеть, что уже заняло место.

На этом месте я останавливаюсь с обещанием «сэкономить токены одной командой». Универсального счётчика для конкретного интерфейса в фактуре нет. Рабочее правило надёжнее: передавай только материалы, которые нужны для текущего действия.

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

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

Почему есть лимит токенов?

Запрос «лимит токенов» может означать две разные границы.

Первая - сколько материала модель способна учитывать в одном контексте. Вторая - какой объём она способна выдать одним ответом. Они связаны, но это не одно и то же.

Anthropic сообщила о росте контекстного окна Claude с 9K до 100K токенов. В том же описании 100K токенов сопоставлены примерно с 75 000 слов.

Для Claude Opus 4.6 Anthropic также описала автоматическое сжатие старого контекста и окно 1M, то есть миллион токенов, в бета-режиме. Сжатие помогает продолжать длинную задачу, заменяя старую историю кратким представлением.

Но compaction не отменяет значение токенов. В обсуждении compaction в Claude Code на Hacker News пользователи описывают случаи, когда детали, оставшиеся на диске, не попадали в сжатое резюме. Технические лимиты при этом не исчезают.

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

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

Как разделить длинный запрос на этапы?

1. Определи одну цель.

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

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

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

2. Составь план до кода.

   Попроси агента перечислить файлы, границы этапа и способ проверки. До реализации сначала зафиксируй границы текущей фазы и задачи, которые останутся на потом.

   План текущего этапаСкопировать промпт

   Мы делаем внутренний инструмент для обработки заявок.
   
   Это этап 1 из 3.
   На этом этапе не пиши код приложения.
   
   Сделай только:
   - изучи структуру проекта;
   - перечисли файлы, связанные с формой заявки;
   - составь план изменения формы;
   - укажи, что не входит в этот этап;
   - предложи проверку результата.
   
   Сохрани план в файл 01-plan.md.
   
   В конце напиши:
   1. что выяснено;
   2. какие решения нужны;
   3. какие файлы потребуется изменить;
   4. что останется на следующих этапах;
   5. как проверить план.
   
   Не перечитывай и не пересказывай всю историю разговора.
   Используй только нужные файлы.

3. Выполни одну часть.

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

   Агенту нужен конкретный вход: файл плана, список решений и существующие файлы, которые относятся к текущей задаче. В Anthropic это называют prompt chaining: каждый вызов получает результат предыдущего.

   Anthropic описывает prompt chaining как разбиение задачи на последовательность шагов, где каждый вызов языковой модели обрабатывает результат предыдущего. Building Effective Agents

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

4. Сохрани решения и файлы.

   После завершения этапа запиши, что сделано, какие решения приняты, какие файлы изменены, что не сделано и как проходила проверка.

   Удобная структура папки:

   Скопировать

   project/
     00-goal.md
     01-plan.md
     02-decisions.md
     03-phase-1-result.md
     04-phase-2-result.md
     05-checks.md
     handoff-next.md

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

5. Создай handoff.

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

   Handoff для следующей сессииСкопировать промпт

   Мы закончили этап с формой заявки.
   
   Сделано:
   - изменена форма создания заявки;
   - добавлена проверка обязательных полей.
   
   Изменены файлы:
   - src/components/RequestForm.tsx
   - src/lib/validation.ts
   
   Принятые решения:
   - пустое поле показывает ошибку под формой;
   - отправка блокируется до исправления ошибки.
   
   Проверки:
   - запущена проверка сборки;
   - результат запиши в 05-checks.md.
   
   Не сделано:
   - не изменена страница списка заявок;
   - не добавлены уведомления после отправки.
   
   Следующая фаза:
   - подключить сохранение заявки;
   - проверить успешную отправку.
   
   Ограничения для следующей фазы:
   - не переделывать завершённую форму;
   - не менять названия полей без отдельного подтверждения.
   
   Сначала прочитай:
   - 00-goal.md
   - 01-plan.md
   - 02-decisions.md
   - 03-phase-1-result.md
   - handoff-next.md
   
   Не пересказывай всю переписку.
   Не переделывай завершённый этап без отдельного подтверждения.

6. Начни новую сессию.

   Открой следующий этап с handoff и нужными файлами. Передай только итог предыдущей работы, а не весь старый чат.

   Не рассчитывай на автоматический перенос всей истории в новую сессию. Передай нужные решения и файлы вручную, чтобы новый контекст получил материалы текущего этапа, а не накопленные ошибки, лишние команды и нерелевантные файлы.

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

Что ломается в длинной сессии?

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

Вот основные поломки.

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

• Потеря памяти. Новая сессия получает ограниченный набор материалов. Если не передать решения и ограничения, агент начнёт угадывать.

• Цена handoff. Передача контекста между отдельными агентами тоже расходует токены. Изоляция облегчает работу основной сессии, но не гарантирует меньший общий расход.

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

• Скрытый стартовый расход. Новая сессия не начинается с пустого места. В неё уже входят системные инструкции, инструменты, skills, MCP и файлы проекта.

Я бы держал простое правило: одна сессия - одна цель и один проверяемый результат. Когда цель закрыта, сохрани результат и реши, нужен ли продолженный контекст.

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

Вопросы и ответы