Наверное, всем уже очевидно, что ИИ крайне полезен, мир поменялся, нас всех заменят роботы и вообще ИИ уже нас во всём превзошёл :)

Всё так или почти так, "но есть одно но" как поётся в одной известной песне. ИИ стоит денег, и весьма немалых при текущих ценах. А про локальные модели для большинства пользователей и компаний в РФ можно забыть. Ну и в целом кажется локальные модели - это не сценарий ИИ будущего.

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

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

1. Используйте бесплатные модели

"Спасибо КЭП". Кажется шутка, но "в каждой шутке есть доля шутки". Модели выходят каждый день, и если это не очень известный китайский или даже не китайский вендор, то способ загнать людей себе в модель - дать промо период. А уровень даже современных noname моделей может быть достаточно высок.

Осталось дело за малым - находить и использовать модели с промо периодом.

Как их обнаружить? Элементарно - идём https://openrouter.ai/rankings и смотрим самые популярные модели:

На текущий момент они такие. Как думаете, какова причина такой популярности некой Hy3 preview :)? Если видите в топ-10 какую-нибудь noname модель, которая внезапно набрала популярность - это оно. Берите любого агента, который поддерживает OpenRouter и/или китайские модели (лучше - OpenCode или KiloCode) и используйте. Качество не гарантировано, но о нём мы поговорим дальше. в целом, если у вас хорошо сформулированы правила\skills, подключены MCP, качественно написаны спеки, либо у вас исследовательская задача - вполне допустимый вариант.

В KiloCode есть ещё более простой способ поиска бесплатных моделей:

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

2. Используйте китайские модели

Идём на https://arena.ai/leaderboard/code/webdev а в случае 1С (на которую я буду ориентироваться в силу специфики своей деятельности) - https://vibecoding1c.ru/bench

И смотрим:

Всех "китайцев" в ТОП-10 можно (и нужно) использовать. Если у вас подключены правила\skills\MCP и выстроен нормальный Workflow есть ненулевая вероятность что разницы в качестве вы не заметите, а разница в цене может быть x10 и более.

3. Используйте разные модели для разных задач

В большинстве случаев кодировать чем-то вроде OPUS extra high уже непозволительная роскошь.

Мой текущий Workflow выглядит следующим образом:

• Спецификации - OPUS 4.8 high

• Кодирование - DeepSeek v4

• Review - GPT 5.5 high

• Тестирование - Composer 2.5

• Ресёрч - Composer 2.5

Итого на OPUS приходится не более 15-20% потраченных токенов. При этом он выполняет наиболее важные задачи планирования архитектуры.

Качество разработки при этом фактически не меняется. Но у меня конечно есть специфика - MCP с проверками на каждый чих и строгие правила\skills. То же самое с одним OPUS обойдётся x5-x7 по стоимости.

4. Используйте SDD или хотя бы Plan mode и память проекта

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

Если вдруг не пробовали - попробуйте хотя бы OpenSpec: https://github.com/Fission-AI/OpenSpec/ - как наиболее простой и лаконичный SDD фреймворк, прекрасно подходящий и для инди разработки.

5. Регулярно очищайте контекстное окно

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

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

SDD же у вас уже есть (см. пункт 4) - правильно написанная спека позволяет сбрасывать контекстное окно как и когда вам удобно

6. Пишите на английском

В таблице разница в использовании токенов для разных моделей и разных языков. Английский взят за 1.

Конечно если у вас с английским плохо - экономия не стоит того, чтобы вы не поняли спеку или потратили на её чтение x2 своего времени. Ваше время всегда дороже. Но хотя бы rules, skills и memory фиксировать на английском кажется правильной идеей. Экономия в деньгах не будет ровно такая же как в этой табличке - cache read никто не отменял. Но всё равно при долгой и активной работе это очень заметная экономия.

7. Используйте подписки вместо оплаты за токены в API

При использовании Codex и Claude Code подписки имеют очевидное ценовое преимущество перед "оплатой за токены".

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

Ну и с подписками надо понимать - они имеют свойство заканчиваться, тогда работа останавливается от слова "совсем". Это конечно беда.

Есть конечно способы "покупки нескольких подписок со скидкой", "с промо периодом". что-то вроде https://plati.market/games/chatgpt/1267/ (не рекламы ради а примера для), и потом использования подписки не в штатных инструментах вендора (у которых есть свои нюансы). Правда в современных реалиях разница в цене между этими учетками и честной оплатой уже не такая существенная. В этом случае имеет смысл организовать ротацию подписок.

Решения для ротации: https://github.com/decolua/9router или https://github.com/diegosouzapw/OmniRoute

Но предельно АККУРАТНО! ВОЗМОЖЕН БАН СО СТОРОНЫ ВЕНДОРА. Не подключайте к роутеру свою основную подписку без острой необходимости.

8. Замените grep на семантический поиск

Один из самых сложных пунктов, пожалуй. Смысл в том, что когда вы задаёте какой-то вопрос, особенно на этапе анализа, то агент проводит поиск по репозиторию где данная фича реализована и не всегда получается найти, по крайней мере с первого раза, что-то похожее по синтаксису. Как самый простой пример - вы пишите "исправь функцию авторизации", агент ищет что-то похожее с "*auth*" а у вас в коде она называется "*login*". Понятно, что умная модель сразу произведёт поиск всех вариантов вроде \/(auth|login|signin|register) (ну и получит кучу мусора, связанного с этими вариантами). Рано или поздно то, что вам нужно, будет найдено, но чаще всего именно здесь бывает большой расход токенов. Более того, даже после того, как grep нашёл релевантный кусок, модели чаще всего приходится вычитывать весь модуль где находится нужная ей процедура. А это ещё один лютый расход токенов.

Что даёт семантический поиск:

• Ищет код "по смыслу", а не по совпадениям слов - быстрее и проще находит то что нужно

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

• Сразу отсекает весь "мусор" который модели видеть не обязательно

• Не имеет формата grep - когда нужно возвращать много сторонней информации

• Может вернуть сразу всю нужную процедуру без необходимости вычитывания всего модуля

• В силу использования индексов, а не скана всех файлов - работает крайне быстро

Чаще всего в основе лежит векторный поиск, чуть реже - что-то подобное LLM-wiki. Иногда совмещают эти подходы. Вообще семантический поиск чаще всего совмещает в одном решении несколько технологий. Даже обычный полнотекстовый поиск по индексу будет существенно эффективнее, чем grep.

Но, очевидно, семантический поиск несёт и ряд проблем:

• Нужна индексация - это некоторые накладные расходы

• Для векторной индексации нужна какая-нибудь embedding модель

• Изменения конечно тоже нужно индексировать - индекс нужно поддерживать в актуальном состоянии

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

Некоторые популярные решения делают свои бенчмарки:

https://github.com/colbymchenry/codegraph - сейчас в тренде репозиторий 44 тыс. звёзд

https://github.com/zilliztech/claude-context - 12 тысяч звёзд

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

Но опять же, по мне семантический поиск даёт большую эффективность не за счёт более точных результатов на простых запросах, а за счёт обработки сложных запросов, на которых с обычным grep может улететь весь ваш лимит токенов или бюджет подписки если агента вовремя не остановить. Я правда говорю чаще всего о больших репозиториях (от 500MB и выше), потому что в основном работаю с 1С, где репозиторий традиционно содержит множество кода. Для небольших репозиториев выигрыш от семантического поиска может оказаться не таким существенным.

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

Вот так в Kilo Code:

В Claude Code семантического поиска из коробки нет, как многие могли заметить. Почему же самый популярный инструмент обходится без него?

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

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

• Мой кейс чаще всего связан с 1С - большие репозитории это норма для нас. В "классическом ИТ" размер репозитория редко достигает таких размеров. Если достигает - его, как правило, разделяют. Поэтому семантика не так актуальна для репозиториев, которые почти вмещаются в контекст современной модели.

Не могу тут не упомянуть в этом контексте мои MCP серверы, но рассчитанные именно на 1С специфику. Семантический поиск (не только по коду, но и по метаданным) - это, конечно, одна из основных фишек. В случае с 1С это не только экономия контекста - без них в 1С с ИИ работать очень проблематично.

В конце концов, если вы ничего не хотите индексировать, хотите минимум накладухи, но осознали что grep - это путь к разорению, можно использовать что-то вроде RLM-tools:

Для больших репозиториев вполне нормальное решение. Представлена экономия относительно grep. А семантика уже сильно экономит относительно RLM + добавляет качество и скорость.

Стоит ещё упомянуть https://github.com/oraios/serena - ещё один прекрасный инструмент семантического поиска на 25 тысяч звёзд,

И https://github.com/MinishLab/semble - простой векторный поиск без лишних заморочек.

9. Подключите caveman

Вот и добрались до специализированных средств.

https://github.com/JuliusBrussee/caveman - 70 тысяч звёзд. Одно из самых простых и беспроблемных средств. В мои правила для 1С, кстати, уже включено. Потому как всем рекомендую его использовать практически всегда.

Вендор обещает примерно вот такое:

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

10. Перепишите правила правильно

На самом деле со временем в правилах (для упрощения будем считать что это AGENTS.md) накапливается достаточно много лишнего. В разных IDE\Агентах есть нотации описания правил которые подгружаются по требованию модели. Я рекомендую универсальное решение, которое работает везде: просто в основном файле ссылка на дополнительный и краткое описание зачем он нужен.

К примеру, это делается как-то так:

Agents.md должен быть максимально кратким - только с инструкциями, которые нужны всегда и на каждый диалог с агентом. Внимательно изучите его и сократите как можете, посоветовавшись с ИИ конечно... В качестве примера не самых идеальных правил и скиллов, но активно используемых, могу только предложить свои: https://github.com/comol/ai_rules_1c (контекст 1С).

11. Используйте сжатие вывода

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

Как думаете, нужно ли это модели ИИ? Конечно нет!

Как и полный вывод команды, как длинная командная строка с grep. А в современных агентских сценариях вызов инструментов командной строки это чуть ли не половина работы агента. Идея в том, чтобы заменить все инструменты командной строки на какой-нибудь один MCP, который будет их выполнять и при этом возвращать только необходимый минимум.

Пожалуй самый популярный инструмент с этим функционалом - это RTK (Rust Token Killer):

https://github.com/rtk-ai/rtk (60 тысяч звёзд)

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

Какая самая затратная? Правильно - grep (по процентам экономии конечно уступает git status, но в абсолютных значениях - конечно топ). Уступает только cat\read, но их я бы не считал командами. Вычитывание всего файла - это почти всегда зло в вайбкодинге. Семантический поиск скорее всего нивелирует проблемы и grep и cat самостоятельно, но это не умаляет достоинств RTK.

Более плотно на проблеме вычитывания всего файла сконцентрировались разработчики популярного MCP https://github.com/mksglu/context-mode (16 тысяч звёзд). Тут принцип работы несколько другой - если модель хочет прочитать весь файл, инструмент отдаёт ей кусок файла где есть то что она запрашивала. Если нужен ещё кусок - даёт его. Вычитывание полных файлов конечно зло. Это пожалуй самая затратная операция агентов. Заявления у ребят конечно громкие:

Вряд ли получим такой результат, но эффективность в любом случае достаточно существенная.

Ещё один инструмент, который бьёт все рекорды роста популярности на github - https://github.com/chopratejas/headroom - 17 тысяч звёзд. Проксирует через себя всё, что приходит от LLM и уходит к LLM и сжимает всё, что-только можно. В отличие от остальных инструментов, выглядит достаточно доработанным. Даже вот такой дашборд есть:

Вот такая статистика по экономии:

Неплохой инструмент. Вероятно имеет смысл начинать разбираться с инструментами сжатия контекста именно с него.

Если вы активно используете MCP есть ещё вот такой инструмент: https://github.com/metatool-ai/metamcp

Смысл примерно в том, что если у вас много MCP серверов с множеством инструментов - их описание тоже занимает контекст. Каждый инструмент должен содержать инструкции по его вызову. Metamcp объединяет их в один и по запросу от LLM вызывает нужный tool или спрашивает дополнительные параметры, которые ему нужны, а потом вызывает. Тут не только экономия токенов но и централизованное логирование и мониторинг. В итоге получится некоторое такое Enterprise ready решение.

С учетом Cache Read для большинства вряд ли будет очень уж большая экономия, но она, несомненно, будет.

Ещё одно решение подобного класса: https://github.com/yvgude/lean-ctx - 2.5 тысяч звёзд на github. Сжатие контекста без лишних заморочек.

12. Вообще откажитесь от текстовых файлов

Ну и если вы уже исчерпали прочие возможности, а экономия ещё недостаточная - https://github.com/volcengine/OpenViking. Данное решение предлагает в принципе отказаться от хранения и чтения текстовых файлов, заменив их на обращение к СУБД с семантическим поиском. Не факт, что это лучшее решение (но других гибких и адаптированных именно под этот кейс я не видел). Авторы обещают не только экономию токенов а ещё более быструю работу и лучшее качество поиска (что очевидно, если на коде от семантики есть прирост, почему его не должно быть и на правилах). Вот что обещают авторы в плане экономии:

Мои личные ощущения заключаются в том, что за подобными решениями (СУБД вместо текстовых файлов) будущее, но я могу ошибаться.

Итого

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

Ну и да - подписывайтесь на мой канал https://t.me/comol_it_does_matter - всё про вайбкодинг, в основном применительно к 1С.