Когда я открыл свой публичный профиль Cursor и увидел там примерно 1,1 миллиарда токенов, цифра выглядела впечатляюще даже для меня. Я действительно использую Cursor много, иногда по несколько часов подряд, но миллиард за месяц всё равно заставил задуматься: это нормальный объём для активной работы с AI или я просто бессмысленно таскаю через модель гигантский контекст?
Чтобы разобраться, я выгрузил Usage CSV и посмотрел на структуру потребления. И здесь оказалось гораздо интереснее, чем просто большая цифра в профиле. Сам по себе миллиард токенов почти ничего не говорит об эффективности работы: важно понимать, какие это токены, какие модели их использовали, сколько из них было новым контекстом и сколько Cursor просто повторно читал из кэша.
Что находится внутри миллиарда токенов
В моей выгрузке оказалось 725 отдельных usage events и суммарно 1 064 143 356 токенов. Из них примерно 989,8 млн, или 93%, — Cache Read. Обычного Input было около 63,1 млн, Cache Write — 4,6 млн, а непосредственно Output модели — всего 6,6 млн токенов.
Получается довольно необычная пропорция. На поверхности видно больше миллиарда токенов, но только около 6% приходится на новый input, а непосредственно сгенерированный моделями текст и код занимает меньше одного процента общего объёма. Основная масса — это контекст, который Cursor уже видел раньше и повторно отдавал модели через кэш.
Именно здесь становится понятно, откуда взялась такая большая цифра. Я часто использую длинные Agent-сессии, в которых модель работает с одним проектом несколько часов: изучает файлы, меняет код, запускает приложение, исправляет ошибки и снова возвращается к уже известным частям проекта. Контекст при этом постоянно путешествует вместе с сессией, даже если значительная его часть уже закэширована.
Какие модели использовали больше всего
Главным потребителем оказался Grok 4.6 High — около 595,7 млн токенов, то есть больше половины всего моего usage. Следом идёт Composer 2.5 с 264,7 млн, затем Claude Fable 5 Thinking — около 151 млн. На остальные модели приходится относительно небольшая часть.
Были и отдельные дни с очень высокой нагрузкой. 14 августа — 185,3 млн токенов, 13 августа — 184,8 млн, 18 августа — 144,6 млн. Только за 13 и 14 августа через Cursor прошло примерно 370 миллионов токенов.
При этом в CSV было всего 17 активных дней, поэтому среднее потребление в день, когда я действительно работал в Cursor, составило около 62,6 млн токенов. На этом уровне Cursor уже трудно воспринимать просто как редактор кода с интеллектуальным автокомплитом. В моём случае он всё больше становится рабочей средой, внутри которой несколько AI-моделей фактически выполняют значительную часть инженерной работы.
Миллиард токенов и $20 сверху
Самая неожиданная часть анализа — стоимость. На Cursor Dashboard за тот же период отображается около 948,9 млн Total Tokens, из которых 946,2 млн проходят как Included и только 2,7 млн — как On-demand.
В CSV я нашёл всего пять платных On-demand events, которые суммарно дали примерно $20,43 дополнительного расхода. То есть я действительно использовал Cursor очень интенсивно, но почти весь этот огромный объём оказался внутри included или free usage.
После этого вопрос «как уменьшить количество токенов?» стал для меня значительно менее интересным. Если система позволяет прогонять сотни миллионов токенов без пропорционального роста расходов, имеет смысл оптимизировать не сам счётчик. Намного важнее другое: не начинает ли длинный контекст со временем ухудшать качество работы Agent.
Когда длинная сессия полезна
Самая длинная моя Agent-сессия продолжалась около девяти часов, но сама по себе эта цифра меня теперь не пугает. Если Agent всё это время работает над одной большой задачей, накопленный контекст скорее помогает ему. Он знает архитектуру, помнит предыдущие решения, уже видел ошибки и понимает, почему некоторые варианты реализации были отвергнуты.
Например, если я полностью переделываю homepage, вполне логично провести внутри одного чата весь цикл: изучить существующую реализацию, предложить новую структуру, написать компоненты, адаптировать mobile, запустить проект, проверить страницу в браузере, найти проблемы и закончить финальную доводку. Создавать новый чат после каждого небольшого изменения здесь только мешало бы.
Проблема начинается не тогда, когда сессия становится длинной, а тогда, когда задача меняется, а старый контекст продолжает ехать вместе с ней. Если после homepage я начинаю делать listings, затем переключаюсь на SEO, потом на Cloudflare и в том же разговоре внезапно начинаю подключать Telegram, Agent получает огромное количество информации, которая формально относится к проекту, но уже почти не относится к текущей задаче.
Один чат — одна законченная задача
Отсюда мой главный вывод: не один prompt — один чат и не один проект — один чат. Один законченный блок работы — один чат.
Homepage может иметь собственную Agent-сессию. Раздел brokers — следующую. Listings — ещё одну. Миграция инфраструктуры, SEO, интеграция Telegram или отдельная большая проблема с API тоже получают собственный разговор. При этом внутри каждой такой сессии совершенно нормально делать десятки итераций и оставаться там несколько часов.
Граница проходит не между сообщениями и даже не между файлами, а между смысловыми задачами. Если Agent сделал карточку объекта и нужно немного поправить mobile layout, hover или отступ — это всё ещё одна задача. Если после этой карточки я решил полностью менять архитектуру фильтрации каталога, стоит уже подумать о новой сессии.
Для себя я сформулировал простой индикатор. Если следующий запрос начинается примерно с «а теперь ещё давай…», стоит проверить, действительно ли это продолжение текущей задачи или уже начало следующей.
Новый чат не должен означать потерю памяти
Возникает естественный вопрос: если регулярно начинать свежие сессии, как не объяснять Cursor каждый раз заново устройство проекта, правила дизайна и технические ограничения?
Ответ заключается в том, что постоянные знания вообще не должны храниться исключительно в истории чата. Для этого существуют Project Rules, User Rules и AGENTS.md. Именно туда логично вынести архитектуру проекта, используемый стек, naming, структуру директорий, правила дизайна, ограничения, команды запуска, требования к responsive и всё остальное, что Agent должен знать независимо от конкретной задачи.
Тогда новый чат становится не перезапуском проекта, а всего лишь очисткой рабочей памяти. Фундаментальные знания остаются на месте, но десятки старых промежуточных решений, ошибок и обсуждений больше не занимают текущий контекст.
Мне кажется, именно это различие особенно важно при интенсивной работе с AI: есть долгосрочная память проекта, а есть оперативная память конкретной задачи. Смешивать их в одном бесконечном разговоре не обязательно.
Большую задачу сначала стоит спланировать
Для небольших изменений я обычно сразу запускаю Agent в работу, но большие задачи имеет смысл начинать с Plan Mode. Если изменение затрагивает много файлов, несколько частей системы или требует архитектурных решений, несколько минут предварительного исследования могут сильно упростить дальнейшую реализацию.
Например, вместо команды «переделай систему listings» лучше сначала дать Agent изучить существующую архитектуру, данные, routing и зависимости, а затем попросить сформировать конкретный план. После проверки этого плана уже можно переходить к реализации.
Это снижает риск характерного сценария, когда AI очень быстро пишет первые 30–40% решения, а затем обнаруживает архитектурное ограничение и начинает переписывать собственную работу. Чем крупнее feature, тем полезнее разделить этапы понимания задачи и написания кода.
Subagents как маленькая команда
Для действительно больших задач появляется ещё один уровень — Subagents. Основной Agent может оставить за собой общую задачу, а отдельные исследования передавать специализированным агентам с собственным контекстом.
Например, главный Agent отвечает за новую систему listings. Один subagent изучает существующую архитектуру, другой проверяет API и данные, третий делает code review, четвёртый отдельно ищет проблемы в mobile и accessibility. Основному Agent не обязательно хранить каждое промежуточное действие этих исследований — ему нужен их итог.
В результате модель работы немного меняется. Вместо одного огромного AI-чата появляется структура, похожая на небольшую команду, где основной Agent выполняет роль координатора и собирает результаты отдельных специалистов.
Код — ещё не результат
Ещё один вывод касается окончания сессии. Я всё меньше считаю задачу выполненной в тот момент, когда Agent сообщил, что написал код.
Нормальный рабочий цикл должен продолжаться дальше: реализовать, запустить, проверить результат, найти ошибки, исправить их и проверить повторно. Особенно это важно для интерфейсов, где изменение может выглядеть правильным в коде, но развалиться в браузере или на определённой ширине экрана.
Если Agent имеет доступ к браузеру, console logs и network traffic, логично заставлять его использовать эти инструменты самостоятельно. Генерация кода — только промежуточный этап. Итогом должна быть работающая и проверенная feature.
Как понять, что старый чат пора закрывать
Я не вижу смысла вводить искусственный лимит вроде «новый чат каждый час» или «после определённого количества токенов обязательно reset». Продолжительность сессии сама по себе ничего не говорит о качестве контекста.
Но признаки его деградации обычно заметны. Agent начинает забывать уже оговорённые ограничения, повторно задаёт вопросы, на которые уже получил ответы, затрагивает не относящиеся к задаче файлы, возвращает исправленные ранее ошибки или начинает противоречить собственным решениям. Иногда причина ещё проще: текущая работа просто слишком далеко ушла от исходной задачи.
В этот момент новый чат — не потеря накопленных знаний, если долгосрочный контекст нормально вынесен в правила проекта. Это всего лишь возможность снова дать модели чистое пространство для решения следующей проблемы.
Мой рабочий цикл с Cursor
В итоге я пришёл к достаточно простой последовательности:
TASK → PLAN → BUILD → VERIFY → COMMIT → NEW CHAT
Сначала одна чётко сформулированная задача. Если она большая — отдельный этап планирования. Затем Agent исследует проект и реализует решение, после чего самостоятельно проверяет результат и исправляет найденные проблемы. Когда законченный кусок работы проверен, его можно зафиксировать commit и перейти к следующей задаче уже в свежей сессии.
Постоянные знания при этом остаются в Rules и AGENTS.md, а отдельные большие исследования при необходимости передаются Subagents. Таким образом появляется архитектура не только у самого программного проекта, но и у процесса взаимодействия с AI.
Чему меня научил первый миллиард
Первоначально 1 064 143 356 токенов выглядели как доказательство того, что я совершенно неэффективно использую Cursor. После разбора usage вывод получился почти противоположным: около 93% объёма составил Cache Read, реальный Output оказался меньше одного процента, а дополнительный On-demand расход за период — всего около $20.
Поэтому моей целью точно не будет попытка любой ценой уменьшить usage. Если большой объём вычислений позволяет за несколько дней сделать работу, на которую раньше требовались недели, сам по себе счётчик токенов не является проблемой.
Оптимизировать нужно качество контекста, границы задач и способность Agent самостоятельно доводить работу до проверенного результата. И, возможно, в этом сейчас происходит более важный сдвиг, чем очередное улучшение prompt engineering: мы постепенно перестаём учиться разговаривать с одной моделью и начинаем учиться управлять AI-агентами как полноценной рабочей системой.
Обсуждение