Complete Guide по токенам в ИИ: как работают и как экономить

Я впервые задумался, что трачу слишком много токенов, в тот день, когда посмотрел в ccusage (консольная утилита — показывает расход токенов в Claude Code по дням, сессиям и моделям с оценкой в долларах) и увидел $399 за сутки.

Задачи были обычные. Рефакторинг пары модулей, написание коммитов, объяснения чужого кода. Ничего, что могло бы стоить как командировка. Я открыл разбивку по проектам, прошёлся по сессиям — и нашёл корень. Один большой JSON-файл, который я несколько раз кидал в контекст целиком. Модель прочитала его пять раз за два дня, и каждое чтение стоило мне денег.

После этого я решил разобраться, как на самом деле работает с токенами. Не на уровне «токен — это примерно слово», а глубже: что именно грузится в контекст, когда, почему дорожает каждый следующий ответ, от чего реально зависит качество. И поменял 12 вещей — одни за пять минут, другие за неделю.

В статье — всё это по порядку. Теория, чтобы оптимизации не выглядели магией. И конкретные действия с инструментами, настройками и привычками.

Сразу уточнение. Большую часть примеров я разбираю на Claude Code, потому что им пользуюсь сам. Но статья не про Claude. Токены, контекст, tokenization и context rot — это общая механика всех современных LLM. Где есть различия между Claude и GPT — отмечаю отдельно.

Чтобы не спотыкаться дальше по тексту:

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

Правило грубое, но работает. Английское слово — примерно один токен. Русское слово — 2–5 токенов. «Usage» — один токен. «Использование» — четыре.

Почему такая разница? Токенайзер — это BPE (Byte-Pair Encoding), алгоритм, который учится резать текст на куски на основе частот в обучающих данных. Все популярные модели обучались преимущественно на английском тексте и коде. В Llama-2, например, 89.7% обучающих данных — английский и 8.38% — код. На все остальные языки мира вместе взятые остаётся 2%.

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

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

Токены делятся на два типа, и разница в цене — пятикратная.

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

Выходные токены — то, что модель пишет в ответ.

Смотрите сами на цены Claude Sonnet: входные — $3 за миллион, выходные — $15 за миллион. У Opus пропорция та же: $5 и $25. У Haiku: $0.80 и $4. Везде output в пять раз дороже input.

Почему? Чтение — дешёвая операция. Модель пропускает входной текст через свои слои один раз и получает представление. Генерация — дорогая. Каждый выходной токен модель вычисляет отдельно, учитывая всё, что уже сгенерировала. Это последовательная операция, её сложно распараллелить.

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

Контекстное окно — это всё, что модель держит в «памяти» одновременно при одном запросе. У Claude 4.6 — до 1 миллиона токенов. У GPT-5 и Gemini — тоже около 1 миллиона. Звучит много.

Есть нюанс. В контекст попадает не только ваш чат. Туда каждый раз загружается:

Активная разработческая сессия на Claude Code сжигает 50 000–100 000 токенов в час. Для ориентира: это примерно 80–160 страниц обычного текста, которые модель «перечитывает» каждый turn. Длинная сессия с большими файлами и множеством MCP — намного больше.

Тут ключевой момент, о котором все забывают.

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

Почему?

Архитектура transformer устроена так, что (упрощённо говоря) каждый токен сравнивается с каждым другим — это квадратичная сложность. На 10 000 токенах модель делает 100 миллионов сравнений. На 100 000 — 10 миллиардов. Сигнал не становится сильнее с ростом контекста, а вот шум — да. Softmax, который распределяет «внимание» модели, размазывает его всё тоньше.

Плюс есть эффект, который называют «lost in the middle». Модель хорошо помнит, что было в начале контекста и что в конце. А то, что в середине длинного контекста — значительно хуже. Точность падает на 30% и больше по данным Stanford.

Что это значит на практике.

Долгий чат без сброса контекста — не просто дорогой, а плохой. Модель начинает путать детали, размывать формулировки, забывать, о чём говорили час назад. И платите за это именно в эти моменты вдвойне: за длинный контекст и за то, что результат хуже.

Поэтому дисциплина сессий — не просто экономия. Это гигиена работы с агентом.

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

Экономия: до 95% на документо-ориентированных задачах.

Если у вас большая база знаний — корпоративная документация, база по продукту, конкурентный анализ, регламенты — и вы кидаете весь файл в контекст каждый раз, вы платите за 200 000 токенов, из которых реально релевантны 5–10 тысяч.

RAG (Retrieval-Augmented Generation) решает это архитектурно. Вместо «весь файл в контекст» — embeddings и vector database. Документы заранее режутся на чанки по 500–1000 токенов. Каждый чанк превращается в числовой вектор через отдельную модель эмбеддингов. При запросе вопрос тоже превращается в вектор, и база находит 5–20 ближайших по смыслу чанков. В контекст летят только они.

Ключевая деталь: поиск идёт не по ключевым словам, а по семантике. Вопрос «сколько платит команда за облако» найдёт чанк со словами «AWS спенд за квартал», даже если ни одно слово из запроса там не встречается.

Инструменты: pgvector (расширение PostgreSQL, удобно если уже используете Postgres), Chroma (проще для старта, работает локально), Pinecone (облачный вариант). Backend обычно делают на FastAPI или Next.js API routes с pipeline для ингестии новых документов.

Честно про сложность. RAG — это полноценное отдельное приложение. Нужен backend, vector DB, pipeline ингестии, интерфейс для запросов, процесс обновления базы. Это не настройка за вечер.

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

Средний путь, для разовой работы с одним большим файлом. Открываешь чат, прикладываешь документ, задаёшь все вопросы по нему в одной сессии — и закрываешь чат. Файл при этом кешируется (см. пункт 4 про prompt caching), и повторные вопросы в течение 5 минут стоят в 10 раз дешевле. По сути — это «RAG для одного файла на один вечер» без vector DB и инфраструктуры. Закончил работу — `/clear или новый чат, и документа больше нигде нет.

Экономия: до 20 раз по стоимости.

Это самый быстрый win. Не меняешь процесс, не ставишь инструменты, просто перестаёшь бить по гвоздям микроскопом.

У Claude три модели с разницей в цене до 6 раз на входных токенах и до 6 раз на выходных:

По моему ощущению, Sonnet покрывает процентов 90% моих задач. На Opus я переключаюсь в двух сценариях: архитектурные решения и code review на большом контексте.

У OpenAI логика та же, только называется иначе. GPT-5 mini для простого, GPT-5 для большинства, GPT-5 Pro для сложного. Gemini — Flash/Pro/Ultra. Механика одна везде: сильная модель дороже, слабая модель справляется со своей категорией задач.

Почему это критично для тех, кто работает через API.

Если у вас подписка Claude Pro или Max — вы платите фиксированную сумму и упираетесь в rate limits. Там выбор модели влияет на то, как быстро вы упрётесь в лимит, а не напрямую в деньги. Если работаете через API — каждый запрос стоит реальных денег. Неправильный выбор модели на больших объёмах превращается в сотни долларов в месяц впустую.

Как настроить. Добавь в глобальный дефолт:

Переключать прямо в чате: /model haiku для поиска, /model opus для архитектуры.

И ещё одна вещь, которая реально помогает. Напиши в CLAUDE.md правило: в конце каждого ответа, где предлагается следующий шаг или запускается задача, модель должна подсказывать, какая модель лучше подходит. Формата типа:

Выглядит мелочь, но на первое время дисциплинирует. Ты начинаешь автоматически думать «а какая тут нужна» и перестаёшь сидеть на Opus из инерции.

Экономия: системная. Самый важный пункт после выбора модели.

Помните про context rot? Длинный чат на 80 000 токенов не только дорогой. Он ещё и плохо работает. Модель путается в деталях, теряет нить, начинает галлюцинировать факты из середины разговора.

Правило простое: задача закончена — открывай новый чат для следующей несвязанной задачи. Не тяни за собой балласт.

Как устроено под капотом.

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

/compact работает иначе. Она просит модель сделать саммари всей истории и подменяет историю этим саммари. Полезно, когда вы в середине задачи и терять нить нельзя. Но саммари — тоже контекст, и он всё равно растёт.

По моему опыту, /clear используется в 80% случаев, /compact — в 20%.

Сразу оговорюсь: это не процесс на каждую правку опечатки. Это процесс для больших фич, где задача делится на 5–7 шагов и каждый шаг тянет за собой решения. Для «поправь типо в README» достаточно короткого чата на Haiku. Но когда работа идёт больше часа — разница становится огромной.

Допустим, у вас проект и нужно накатить новую фичу.

Шаг 1 — Brainstorm. Открываешь новый чат, подключаешь Opus. Берёшь скилл вроде product-brainstorming и прогоняешь задачу: что надо сделать, кому это надо, какие есть варианты реализации, в чём риски. Opus тут нужен, потому что он сильнее в исследовательских задачах и может предложить неочевидные решения.

Шаг 2 — Спецификация. Новый чат, переключаешься на Sonnet. Скармливаешь результаты brainstorm, просишь написать spec. Sonnet отлично справляется со структурированной работой по готовой базе.

Шаг 3 — План. Новый чат, Haiku. Просишь разбить spec на конкретные задачи с acceptance criteria. Это простая механическая работа, Haiku её делает быстро и дёшево.

Шаг 4 — Реализация. Теперь у тебя в плане 5–7 задач. Два варианта.

Вариант последовательный. Для каждой задачи — новый чат. Выбираешь модель под сложность: простая CRUD-ручка — Haiku. Новый сервис с логикой — Sonnet. Реструктуризация — Opus. Сделал, закоммитил, запушил, следующая задача — снова новый чат.

Вариант параллельный. Если работаешь с мультиагентами — например, через Superpowers или просто через Task-инструмент Claude Code — можно запустить все 7 задач одновременно, каждую изолированным агентом со своей моделью. Они идут в фоне, не мешают друг другу, не отравляют контексты друг друга. Собираешь результаты по готовности.

Итог такого подхода. Контекст каждого чата — чистый и релевантный одной задаче. Модель подобрана под сложность. Ты не платишь за Opus, когда нужен Haiku, и не тянешь полуторачасовую историю в простую правку.

Чтобы не забывать про новый чат — добавь в CLAUDE.md правило:

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

Экономия: до 10 раз на повторных запросах с одним системным промптом.

Вещь, которую пропускают почти все гайды. У Anthropic есть кеширование промпта: когда вы отправляете запрос, части промпта, помеченные как кешируемые, сохраняются на серверах Anthropic на 5 минут. Повторный запрос в этом окне — и кешированная часть стоит в 10 раз дешевле обычного чтения.

Работает это на системном промпте, документах, которые вы прикрепили к чату, описаниях инструментов. Всё, что не меняется от turn к turn.

Практически:

Вывод: в Claude Code это уже работает за вас. Но знать механику полезно — она объясняет, почему `/clear` делает сессию «свежее и дешевле»: после сброса следующий turn заново прогревает кеш, а дальше всё катится по десятипроцентной стоимости.

У OpenAI есть аналогичная функция под названием prompt caching — работает похоже, но условия и TTL отличаются.

Экономия: 60–90% на выводе консольных команд.

Когда Claude запускает git log, pytest, npm run build, docker compose up — вывод этих команд попадает в контекст целиком. Полный стектрейс со всеми строками. Весь лог сборки с прогресс-барами и предупреждениями. История коммитов за полгода. И там много мусора: дублирующиеся строки, форматирование, цветовые escape-коды, повторяющиеся пути.

RTK (Rust Token Killer) — это CLI-прокси, который перехватывает вывод команд и сжимает его до того, как он попадёт к модели. Четыре стратегии: умная фильтрация (убирает комментарии, пробелы, шаблонный код), группировка (однотипные ошибки собирает в один блок с count), усечение с сохранением контекста (длинные логи режутся с сохранением начала/конца и маркеров середины), обработка вывода больших проектов.

Цифра у меня своя — rtk gain за месяц использования показывает около 89% среднего сокращения на ~3000 командах. Понятно, что на другом проекте с другим соотношением команд результат будет другим. Но порядок — 60–90% — устойчивый. Это значит сессия живёт в 3 раза дольше до того, как упрётся в context limit или rate cap. При том же объёме работы.

Отдельно про десктоп. Многие думают «я работаю в Claude Desktop или в ChatGPT-приложении, RTK мне не нужен». На самом деле — нужен. Приложения тоже запускают команды под капотом, когда агент просит что-то сделать в терминале. Вывод этих команд так же попадает в контекст, как и в CLI. RTK ставится системно и перехватывает bash везде.

Ограничение: RTK работает только с Bash-инструментом. Встроенные Read, Grep, Glob в Claude Code через RTK не проходят — там Claude сам работает с файлами через SDK, без shell.

Установка:

После этого в `~/.claude/settings.json` появится PreToolUse hook, который автоматически перехватывает все bash-вызовы. Работает прозрачно, ничего в процессе работы не меняется.

Экономия: 40–60% на каждом использовании документа.

Сырой PDF — плохой формат для LLM. Там форматирование, метаданные, иногда дублирующиеся блоки навигации, колонтитулы на каждой странице, непарсящиеся изображения и капризные колонки. Всё это попадает в контекст и жрёт токены.

Чистый Markdown — идеальный формат для LLM. Минимум разметки, максимум содержания, структура сохраняется в заголовках и списках. Плюс есть инвестиционная логика: конвертируешь один раз — экономишь каждый раз при использовании.

Три способа решить задачу — выбирайте по ситуации.

Способ 1. Консольная утилита. MarkItDown от Microsoft — специально спроектирован для подготовки документов под LLM. Поддерживает PDF, DOCX, PPTX, XLSX, HTML, изображения. Сохраняет структуру.

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

Способ 2. Свой скилл. Написать скилл типа `/popovs:doc-to-md`, который ты кладёшь в репо, и он автоматически конвертирует документы при первой работе с ними. Плюс — интеграция с твоим воркфлоу. Минус — надо написать.

Способ 3. Кросс-модельная конвертация. Если в одной модели токены жалко, а в другой — нет, можно перегнать документ через неё. Например, конвертировать PDF в Markdown через ChatGPT, а работать потом в Claude. Или наоборот. Работает, если у вас подписка в обоих местах.

Про это часто забывают, а зря.

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

Два правила, которые это ломают.

Правило 1. При первой генерации сразу укажите стили, разметку, структуру, всё что хотите получить в финале. Не «напиши текст, потом оформим» — а «напиши текст с такими заголовками, таким списком, такой таблицей». Это экономит вам итерации.

Правило 2. Делайте PDF только один раз в самом конце. Все промежуточные этапы — в Markdown. Обсуждаете структуру в MD. Редактируете текст в MD. Показываете коллегам MD. И только когда всё согласовано — конвертируете в PDF через `pandoc`, браузерный Print to PDF или `weasyprint`.

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

Экономия: 10–30% на системном промпте.

MCP (Model Context Protocol) — это способ подключить к модели внешние сервисы: Notion, Confluence, GitHub, Slack, базы данных, платёжки. Штука очень полезная, но с ней есть коварный нюанс.

Когда вы подключаете MCP-сервер, в системный промпт каждой сессии добавляется описание всех его инструментов и схем. У Notion это примерно 15 инструментов с описаниями. У GitHub — больше. У Confluence — под три десятка. И всё это грузится в каждый ваш чат, даже если в этом проекте вы Notion не трогаете.

В итоге человек подключает пять MCP «на всякий случай», и у него системный промпт разрастается на 20–30 тысяч токенов только за счёт описаний инструментов, которыми он в конкретном проекте не пользуется.

Решение — изоляция MCP по проектам.

Подключайте MCP не через глобальные плагины Claude Code или Codex (где сервер цепляется на всё подряд), а напрямую через проектные конфиги. Это даёт контроль: в каком проекте какие серверы активны.

Если работаете в пустом проекте без внешних интеграций — никаких MCP в контексте нет вообще. В каждом токене есть смысл.

Пример с Git — он хорошо иллюстрирует общий принцип.

У вас есть два способа работать с Git через агента. Первый — плагин-MCP, подключённый к агенту: вы говорите «закоммить и запушь», агент вызывает инструменты, всё происходит. Второй — руки: `git commit`, `git push` в терминале или через GUI вроде GitHub Desktop.

Если считать в токенах, второй способ в два-три раза дешевле. Потому что плагин каждый раз тащит в контекст описание своих инструментов и диалог «какую команду вызвать». А прямой вызов через Bash-инструмент плюс RTK — это одна строка вывода.

Мораль не в том, что MCP — зло. Мораль в том, что MCP имеет смысл для того, что реально требует агентности: создать issue с кучей контекста, найти связанную страницу в Confluence и прочитать её, обновить страницу в Notion по шаблону. Для механических операций, где ты просто кликнул бы кнопку — дешевле сделать это руками или через простой Bash.

Экономия: 30–50% на системном промпте.

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

Причина снова в BPE-токенайзере. Русский текст режется на более мелкие куски, чем английский, потому что русского в обучающих данных было мало. По оценкам, то же самое содержание на русском занимает в 2–3 раза больше токенов, чем на английском.

Есть ещё одна деталь, о которой спорят. Некоторые исследования говорят, что модели, обученные в основном на английском тексте, внутренне «думают» в английском latent space — и русский ввод обрабатывается хуже не только из-за токенайзера, но и из-за самого представления. Но это гипотеза, а не установленный факт. Надёжно подтверждено одно: русский стоит в 2–3 раза больше токенов на тот же смысл. Этого уже достаточно, чтобы задуматься.

Вопрос в другом: готовы ли вы к этому.

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

Чат с моделью — другое дело. Если вам комфортнее думать на русском и формулировать задачи на русском — не надо себя ломать ради экономии. Качество вашей задачи и формулировки важнее стоимости токенов.

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

Моя текущая позиция: системный промпт — на английском. Чат с моделью — на русском. Получаю экономию на константной части без боли в рабочих задачах.

Экономия: заметная на длинных промптах, см. цифры ниже.

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

Плохо:

Хорошо:

Модель понимает обе формулировки. Но вторая короче в 5 раз.

По бенчмаркам автора открытого скилла Caveman — экономия 14–21% на структурных промптах, до 40% на длинных чат-диалогах. Это скромнее, чем заявленные в ранних обсуждениях 75%, но заметно на длинных сессиях.

Два способа применения.

Способ 1. Скилл Caveman. Есть готовый открытый репозиторий с Claude Code skill, который автоматизирует подход. Подключаете скилл, настраиваете, дальше модель сама пишет в caveman-стиле.

Способ 2. Вручную через CLAUDE.md. Просто напишите в системном промпте:

Модель начинает отвечать короче. Работает на 80% случаев без отдельного скилла.

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

Экономия: 10–30% в зависимости от текущего объёма.

Системный промпт стоит токенов в каждом turn. Если у вас там 5000 токенов, каждый ваш запрос начинается с 5000 токенов. Умножьте на 100 turn в день.

Три конкретных рычага.

skillListingMaxDescChars. По умолчанию Claude Code разрешает каждому скиллу иметь описание до 1536 символов, и все описания едут в системный промпт. Если у вас 10 скиллов, это 15000+ символов на одни описания. Выставьте 300 — этого хватает, чтобы модель понимала, когда вызвать скилл.

Load-on-demand. Редко используемые инструкции не надо держать в AGENTS.md. Выносите в отдельные файлы и подключайте при необходимости через `@./docs/ai/ml.md`. Работает в Claude Code и Cursor. Так делают с ML-гайдами, языко-специфичными инструкциями, чек-листами для специфических задач.

Ревизия. Раз в месяц — глазами пройтись по AGENTS.md и CLAUDE.md. Убрать устаревшие правила. Убрать то, чему модель всегда следует без напоминания (такие инструкции часто дублируют то, что уже заложено в её поведение). Убрать пункты, которые вы забыли, зачем добавляли.

На моём AGENTS.md такая ревизия дала ощутимый результат. Изначально было 8000+ токенов правил, которым я когда-то зачем-то научил модель. Прошёлся глазами — половину выкинул. Остались те, которые реально меняют поведение. Качество ответов — то же. Плюс теперь я знаю, что в файле, и могу объяснить каждое правило зачем. До ревизии — не мог.

Экономия: 10–25% на длинных сессиях.

Claude Code автоматически запускает компакцию, когда контекст приближается к лимиту. По умолчанию это происходит поздно — когда контекст уже большой, каждый turn дорогой, и context rot вовсю работает против вас.

Настройка autoCompactWindow позволяет выставить более ранний порог. Минимум — 100000 токенов.

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

У меня это стоит уже полгода. Один раз поставил — и всё. Раньше было ощущение, что длинная сессия под конец начинает тупить — сейчас такого нет, потому что компакция срабатывает раньше, чем контекст успевает раздуться. Настройка бесплатная: ставите один раз, работает всегда.

Экономия: 10–20% на выходных токенах.

Помните, что выходные токены стоят $15 за миллион у Sonnet? Длинный развёрнутый ответ — дороже короткого. Если в промпте нет явной инструкции быть кратким, модель по умолчанию пишет развёрнуто: вводные абзацы, «важно отметить», «стоит обратить внимание», финальные резюме.

Добавьте в CLAUDE.md блок compression:

Одна оговорка. Это правило — только для ответов модели вам в чате. Оно не должно применяться к генерируемому контенту — коммитам, PR-описаниям, постам, статьям, документации. Там нужна нормальная человеческая речь, а не caveman.

В моём репозитории это разделено через два модуля: `style.md` для чата с компрессией, `writing-voice.md` для генерируемого контента без неё.

Если я что-то и вынес из этой истории с $130 — это: сначала измерь, потом чини. Без цифр оптимизация вслепую.

Поставь ccusage. npx ccusage@latest — и увидишь свои траты по дням, сессиям и моделям. Запусти утром в понедельник, посмотри, что было за прошлую неделю — и ты уже знаешь, куда целиться.

Установи RTK один раз. rtk init -g — и вывод bash-команд автоматически сжимается на 60–90%. Работает в фоне, ничего в процессе не меняется.

Выстави дефолтную модель.

Sonnet для большинства задач, переключаешь на Haiku или Opus только когда нужно.

Добавь подсказки в CLAUDE.md. Правило, чтобы модель подсказывала, какая модель подходит для следующей задачи. И правило про «задача закрыта — открой новый чат». Дисциплинирует быстрее силы воли.

Настрой ранний autoCompact. "autoCompactWindow": 150000. Одна строка в settings.json — компакция срабатывает раньше, контекст не раздувается.

Ограничь описания скиллов. "skillListingMaxDescChars": 300. Сэкономит пару тысяч токенов в системном промпте, если у вас много скиллов.

Изолируй MCP по проектам. Подключай сервера через проектные конфиги, а не как глобальные плагины. В пустых проектах — пусто.

Для документов — markitdown. Повторно используемые PDF конвертируй в Markdown через `markitdown file.pdf > file.md`. Генерируй PDF только в самом конце, промежуточные этапы — в Markdown.

Дальше — язык промпта, Caveman, размер CLAUDE.md. Это уже про полировку, но тоже работает.

Я прошёл этот путь и собрал самое важное в публичный репозиторий с настройками для AI-агентов.

Там не всё из статьи — специально. RAG, например, не собрано, потому что это отдельный продукт, а не настройка. Но базовая гигиена — есть.

Что внутри:

Установка одной командой разворачивает всё в нужные места:

Поддерживает Claude Code, Codex CLI, Cursor, Gemini CLI.

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