Как не слить все токены за один вечер: полный гайд по экономии для ИИ-агентов

Привет, меня зовут Луми, я создатель канала Valency Labs

Бывало ли у вас такое, что агент вроде бы сделал всего пару действий, а лимит уже тает на глазах? Открыл папку, прочитал полрепозитория, три раза запустил тесты, вывел логи на полэкрана и ещё зачем-то начал думать там, где можно было просто ответить в две строки

В этой статье я покажу самые рабочие способы экономить токены при работе с Claude Code, Codex, OpenCode и тд, и своими агентами через API

Что будет внутри:
1. Как убрать мусор из контекста
2. Как заставить агента читать только нужное
3. Как экономить на модели, не теряя качество
4. Как использовать prompt caching и batch-режим
5. Какой стек я бы собрал сам, если бы начинал с нуля

Поехали!

Почему токены улетают так быстро

Для новичка объясню максимально просто

Токены это кусочки текста, которыми ты кормишь модель и которые она возвращает тебе в ответ

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

Главная идея очень простая: чем меньше мусора видит агент, тем дешевле он работает

И тут важно понять одну вещь: иногда мы экономим именно токены, а иногда экономим деньги на тех же токенах. Оба варианта полезны

Способ 1. Режем шум из терминала: RTK

Если вы работаете через CLI-агентов, это один из самых сильных способов экономии

RTK это прокси для shell-команд, который сжимает вывод терминала до сути ещё до того, как этот вывод попадёт в контекст модели.
Ссылка: https://github.com/rtk-ai/rtk/releases

В чём прикол?
git status превращается из длинного полотна в короткую выжимку
cargo test, pytest, npm test перестают спамить сотнями строк ok
ls, grep, diff, git log и другие команды становятся в разы компактнее

Пример:
Без фильтра агент видит длинный вывод тестов
С RTK он видит короткую суть вроде "48 passed, 0 failed"
Для модели это почти одна и та же польза, а по токенам разница огромная

Установка

macOS:

brew install rtk
Linux / macOS:

curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh
Cargo:

cargo install --git https://github.com/rtk-ai/rtk

Windows + добавление RTK в PATH:
Переходим по ссылке и скачиваем rtk-x86_64-pc-windows-msvc.zip и распаковываем. Далее Win + R — sysdm.cpl — Advanced — Environment Variables

Двойной клик по PATH — New — путь к rtk.exe что вы распаковали

Готово! Вы - умничка!

Подключение

Что важно помнить

RTK работает только там, где агент реально идёт в shell. Если агент использует встроенные Read, Glob, Grep и похожие инструменты, RTK их не сжимает. Поэтому иногда выгоднее явно просить агента работать через shell-команды или вызывать rtk read, rtk grep, rtk find напрямую

Мой вывод

Если вы много кодите с агентом, RTK ставится одним из первых. Это не "приятная мелочь", а реальная экономия

Способ 2. Даём агенту короткую память о проекте

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

Лечится это просто:
CLAUDE.md для Claude Code
AGENTS.md для Codex и похожих агентов
Проектные инструкции для OpenCode и других тулов

Идея такая: один раз пишете короткую памятку о проекте, командах и запретах. Это не экономит токены напрямую как RTK, но заметно уменьшает лишние чтения, переспросы и бесполезные обходы по проекту

Ещё полезно добавить ignore-файлы, чтобы агент не индексировал мусор. Туда обычно прячут node_modules, dist, .next, coverage, логи, lock-файлы, кэши

Способ 3. Не суём в контекст весь проект

Очень частая ошибка новичка: "Сейчас я дам агенту весь репозиторий, и он точно всё поймёт"

Нет. Он не станет умнее. Он просто станет дороже

Если задача касается одного модуля, одной функции или одной папки, давайте именно её

Плохой подход: "Посмотри весь проект и исправь баг"
Нормальный подход: "Исправь баг в auth.ts. Если понадобится, посмотри только middleware и tests/auth.test.ts"

Золотое правило: сначала сужаем область задачи, потом даём контекст. Не наоборот

Способ 4. Пишем промпты короче и жёстче

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

Хорошая практика: сразу задавать ограничения
Ограничение области: "Правь только processPayment() в payment.ts. Другие файлы не трогай"
Ограничение формата: "Выводи только diff. Без объяснений. Коротко"
Ограничение инструментов: если ваш агент это поддерживает, отключайте то, что не нужно (например веб-поиск) и оставляйте только минимальный набор

Способ 5. Чистим длинные сессии

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

Практика простая:
Если закончил один крупный блок работы, сжимай контекст (compact).
Если переходишь на совсем другую задачу, начинай сессию заново (clear).

Ещё очень важная штука: ограничивайте количество шагов агента, чтобы не улететь в бесконечные циклы

Что такое max-turns простыми словами
Это “предохранитель”, который ограничивает сколько раз агент может сделать шагов в стиле “подумал -> вызвал инструменты -> получил результат -> продолжил”
Без лимита агент иногда начинает ходить по кругу: читать лишние файлы, снова запускать тесты, снова проверять одно и то же, и так пока не сгорит контекст или бюджет

Что нужно делать новичку на практике
1. Если задача маленькая и понятная, сразу ставь max-turns 5
Примеры таких задач: поправить один файл, исправить 1-2 ошибки, добавить одну проверку, переписать небольшой кусок текста

2. Если задача средняя, ставь max-turns 10
Примеры: небольшой рефакторинг в одном модуле, починить тесты, сделать 2-3 связанных изменения

3. Если лимит закончился и агент “остановился”, не паникуй
Ты делаешь одно из трёх:
а) повышаешь лимит и запускаешь ещё раз
б) просишь продолжить с того места, где остановился, но с более узким scope
в) делишь задачу на два захода и начинаешь новую чистую сессию

Как выглядит в команде
Если у твоего CLI есть такой флаг, он обычно выглядит как --max-turns 5 или --max-turns 10
Смысл один: ты заранее говоришь агенту “делай не больше N шагов, потом остановись”

Лайфхак
Ставь max-turns всегда, кроме реально больших задач, и ты перестанешь ловить ситуации, где токены улетают “в никуда”

Способ 6. Маршрутизируем задачи на дешёвые модели

Это уже не про уменьшение числа токенов, а про уменьшение цены этих токенов

Ошибка: использовать дорогую модель вообще для всего подряд

В реальности задачи у агента разные. Архитектура и сложный рефакторинг действительно могут требовать сильную модель. А классификация, извлечение полей, мелкие правки и короткие сабтаски почти всегда можно отдать более дешёвой mini/nano/haiku-модели

Если у вас пайплайн из 10 шагов, и только 2 из них реально сложные, нет смысла платить за все 10 как за премиум reasoning

Что нужно делать правильно
Шаг 1. Раздели работу агента на “мозг” и “руки”
Мозг это планирование и финальная сборка результата
Руки это простые операции: классификация, извлечение полей, поиск по тексту, форматирование, черновики, мелкие правки

Шаг 2. Дорогую модель оставь для мозга
Где дорогая модель реально нужна:
архитектура и план
сложный рефакторинг с рисками
финальный текст “в люди”
код-ревью, где важны смыслы и безопасность

Шаг 3. Дешёвую модель используй для рук
Где дешёвая модель обычно справляется отлично:
классификация “что это за кейс”
извлечь поля в JSON
сделать краткое summary
переименовать и поправить мелочи
нагенерить варианты заголовка и первых абзацев

Шаг 4. Сделай каскад, если сомневаешься
Правило каскада простое:
сначала пробуем дешёвой моделью
если ответ низкого качества или “не уверен”, эскалируем на более сильную модель
Так ты платишь дорого только за сложные случаи, а не за весь поток

Шаг 5. Не пихай весь контекст в дешёвую модель
Лучше так:
дешёвая модель делает выжимку или вытаскивает факты
дорогая модель принимает решение и пишет финал по короткой выжимке
Это очень часто даёт лучший результат и дешевле по деньгам

Способ 7. Включаем prompt caching

Одна из самых мощных оптимизаций для тех, кто строит агентов через API.

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

Обычно повторяется: system prompt, длинные инструкции, описания инструментов, схемы ответов, постоянная часть контекста по проекту.

Чтобы caching реально работал:
Держите стабильный префикс запроса.
Не меняйте порядок инструментов и схем без причины.
Переменные и динамику выносите в конец.
Не вставляйте timestamp и случайный мусор в начало промпта.

Правило одно: всё стабильное в начало, всё меняющееся в конец.

Как это делать правильно:
Шаг 1. Найди что у тебя повторяется из запроса в запрос
Обычно это:
инструкции “как отвечать”
описание роли агента
описание инструментов и схемы JSON-ответов
примеры формата
кусок постоянного контекста о проекте

Шаг 2. Собери из этого “шапку” и не трогай её
Важная идея: шапка должна быть одинаковой байт в байт, без случайных изменений
Если ты каждый раз меняешь хотя бы одно слово в начале, кеш будет ломаться

Шаг 3. Всё динамическое перенеси вниз
Динамика это:
сообщение пользователя
конкретная задача на сегодня
вставки из логов, файлов, базы
timestamp, случайные id, “текущее время”, и прочее
Динамика в конце, иначе ты сам себе убиваешь кеш

Шаг 4. Следи за метриками
Если платформа показывает cached_tokens или cached input, смотри растёт ли доля кеша
Если кеша нет, почти всегда причина в том, что префикс “плывёт”

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

Способ 8. Для фоновых задач используем batch

Если задача не требует мгновенного ответа, не обязательно гонять её в обычном режиме

Batch отлично подходит для массовых однотипных задач: классификация, разметка, summaries для пачки документов, обработка очереди background-задач

Не подходит: чат в реальном времени и интерактивный coding loop
Подходит идеально: nightly jobs, массовая обработка данных, фоновые пайплайны, очереди без жёсткого SLA

Как делать batch правильно
Шаг 1. Сформулируй задачу так, чтобы она была независимой
Batch любит задачи вида “на вход текст -> на выход JSON”
Например:
разметить 1000 сообщений по категориям
достать из 500 статей даты и названия проектов
сжать 300 логов до короткой выжимки “что сломалось и где”

Шаг 2. Дай фиксированный формат ответа
Чем меньше свободы у модели, тем меньше мусора она генерирует, и тем проще тебе потом это обрабатывать
Пример логики: “выводи только JSON с полями category, confidence, reason_short”

Шаг 3. Группируй задания по шаблону
Если у тебя много разных промптов, batch выгода падает
Лучше один шаблон и много входных данных, чем 100 разных шаблонов

Шаг 4. Не отправляй в batch то, что нужно прямо сейчас
Batch это про дешевле, но не мгновенно
Если нужен интерактивный диалог, оставайся в обычном режиме

Шаг 5. Делай “двухступенчатую” схему
Дешёвая модель в batch делает черновую обработку и вытаскивает факты
Дорогая модель в realtime собирает финальный ответ из этих фактов
Так у тебя и цена ниже, и качество финала выше

Способ 9. Не возвращаем модели все промежуточные данные

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

Правильнее: инструменты по возможности возвращают не сырые данные, а агрегаты, summaries, отфильтрованные результаты и нужные поля

Пример
Вместо 1000 строк логов лучше вернуть errors_count и топ ошибок

Как делать правильно, чтобы новичок понял
Шаг 1. Реши что именно модели нужно узнать из данных
Например: “какая ошибка”, “где упало”, “что делать”, “сколько раз повторилось”
Если цель понятна, ты сразу понимаешь что можно выкинуть

Шаг 2. Сжимай инструментами до того, как это увидит модель
Вместо “вот тебе весь лог” делай:
счётчики
топ ошибок
первые 10 строк вокруг места падения
уникальные сообщения без повторов

Шаг 3. Возвращай структуру, а не простыню
Если можешь, возвращай JSON с фиксированными полями
Тогда модель не будет тратить токены на “прочитать и понять полотно”, и меньше шанс что она пропустит главное

Шаг 4. Если всё же нужен сырой кусок, отдавай маленький фрагмент
Например: 30 строк вокруг ошибки, а не 5000 строк всего файла

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

Итого: что выбрать новичку

Если вы только начинаете и не хотите усложнять себе жизнь, вот практический набор:
1. Поставить RTK (если работаете через CLI-агента)
2. Сделать CLAUDE.md или AGENTS.md (коротко описать проект, команды и запреты)
3. Ограничивать область каждой задачи (не "посмотри всё", а "работай только с этим модулем")
4. Делать промпты короче (сразу писать формат ответа и границы задачи)
5. Чистить длинные сессии и ограничивать max-turns

Если вы уже строите своего агента через API, добавляйте:
1. Prompt caching
2. Model routing
3. Batch для фоновых задач
4. Сжатые tool outputs

Мой практический совет

Если лень разбираться во всём сразу, делайте в таком порядке:
1. rtk init -g
2. CLAUDE.md или AGENTS.md в проект
3. короткие промпты + max-turns
4. compact после больших блоков работы
5. потом уже caching и routing

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

Надеюсь эта статья была полезной. Если это так то прошу подписаться на мой канал и поделиться статьей

Если будут вопросы, пишите мне в личку или в чат

Обнял вас крепко, жду фидбека!