Дисклеймер
Я фронтенд-разработчик. Работаю в Bay Area, в компании, которая выдаёт всем инженерам корпоративные подписки на Claude Code и Cursor. То есть лично из кармана я за токены не плачу — счёт уходит работодателю. Это важная деталь, потому что без неё дальше непонятно: зачем человеку, который ни копейки не тратит, было пилить три месяца open-source инструмент для подсчёта чужих денег.
Если коротко — стало любопытно.
Если чуть длиннее — оказалось, что эта любопытная мысль вытащила за собой целую экосистему репозиториев, два пивота, один выкинутый в мусорку RAG-движок, плагин для JetBrains на Kotlin, расширение для VS Code на TypeScript и Rust-демон, который я бы сам, без AI, не написал никогда в жизни.
Это статья про то, как и зачем я всё это сделал. И почему фронтендер, который последний год почти не пишет код руками, всё равно может зашипить вполне серьёзный системный инструмент — если правильно собрать процесс.
Откуда вообще взялся вопрос
Поздней осенью прошлого года я заметил, что мой рабочий день изменился. Раньше он состоял из открытия VS Code, чтения тикета, гугления, написания кода, отладки, ревью. Сейчас день состоит из формулирования задач для Claude Code, чтения его диффов, тыканья в Cursor с вопросом «почему это не работает», и иногда — да, иногда — я всё ещё открываю файл и правлю руками. Но это уже исключение.
Меня это устраивает. Скорость выросла, рутина исчезла, голова занята проектными решениями, а не точкой с запятой. Но в какой-то момент я открыл /cost в Claude Code, увидел свою сессию и подумал: «А сколько я вообще трачу-то?»
Claude Code показывает текущую сессию. Всё. Никакой истории. Никакой разбивки по репозиториям. Никакого ответа на вопрос «сколько денег ушло на этот тикет».
Cursor показывает чуть больше, но в своём кабинете, и тоже без привязки к тому, что я реально делал.
И тут меня зацепило. Я работаю с несколькими репозиториями одновременно: основной продукт, пара побочных проектов, экспериментальные ветки. Какой из них съедает больше всего токенов? Какой тикет оказался самым «дорогим»? Сколько Opus я случайно сжёг там, где спокойно хватило бы Sonnet? Эти вопросы интересны не потому, что я хочу сэкономить — повторюсь, плачу не я. Они интересны потому, что без ответов я не понимаю, как именно я использую инструмент, который занимает 80% моего рабочего времени.
В индустрии это называется громко — «наблюдаемость». В моей голове это было проще: «хочу видеть, куда уходит».
Первая попытка: оптимизатор, который ничего не оптимизировал
Изначально я хотел сделать оптимизатор стоимости. План был наивным и красивым: написать прослойку, которая будет смотреть на каждый промпт перед отправкой и решать, можно ли сделать его дешевле — выкинуть лишний контекст, переключить модель, что-то закешировать.
Я начал писать. Через пару недель упёрся в очевидное: невозможно оптимизировать то, чего ты не видишь. У меня не было базовой картины — сколько уходит сейчас, на что именно, в каких разрезах. Я пытался оптимизировать чёрный ящик, причём не глядя в него.
Это был первый пивот. Я сказал себе: окей, забудем про оптимизацию. Сделаем сначала видимость. Просто покажем, куда идут токены. А оптимизация — потом, если получится.
Так появилось имя — budi. Это была шутка про «buddy», приятель-помощник, который сидит рядом и говорит, на что ты тратишь деньги. Имя прижилось.
Почему Rust, если я фронтендер
Под капотом budi — Rust. Демон, который тайлит транскрипты AI-агентов в реальном времени, парсит JSONL-файлы, обогащает каждое сообщение git-контекстом и пишет в локальный SQLite. Sub-millisecond латентность на хуках.
Если бы вы спросили меня в 2023 году, могу ли я написать такое — я бы засмеялся. Я знаю TypeScript, React, немного Node.js. Никакого Rust, никаких системных языков, никакого опыта в файловых наблюдателях и асинхронных рантаймах.
Но в 2026 году ограничение «я не умею писать на X» работает иначе. Я выбрал Rust по двум причинам: во-первых, демон должен быть лёгким (никто не захочет постоянно резидентного процесса на 200 МБ); во-вторых, я хотел проверить, насколько далеко можно уехать, если язык выбирает не разработчик, а задача.
Claude Code писал большую часть Rust-кода. Я писал требования, дизайн, архитектуру, ревьюил каждый PR, тыкал палочкой в места, где модель выдавала непонятные мне идиомы, и заставлял её объяснять. По факту я выучил Rust в процессе написания на нём продакшен-инструмента. Не идеальный путь обучения, но рабочий.
Эксперимент с RAG, который пришлось убить
Прежде чем я пришёл к нынешней архитектуре, у меня было ещё одно ответвление, на которое я угрохал несколько недель — RAG-движок для Claude Code.
Идея звучала красиво. Перед каждым промптом в Claude Code хук молча подмешивает релевантный контекст из репозитория. Tree-sitter парсит код в AST. Векторный поиск находит подходящие куски. Cross-encoder делает реранкинг. Всё это на Rust, быстро, локально. Меньше походов модели за файлами — меньше токенов — меньше денег.
Я даже довёл это до рабочего состояния. И собственный аналитический модуль budi (которого тогда ещё не было целиком, но базовые метрики уже считались) показал мне жестокую правду.
49% промптов получали инъекции контекста. Всего 2% этих инъекций были подтверждены — то есть Claude реально использовал то, что я ему подсунул. Остальные 47% — это были токены, которые я тратил на вброс контекста, который модель проигнорировала и пошла читать файлы сама.
Оптимизатор, который не оптимизирует. Инструмент, который не доказывает свою пользу. И главное — пользователь даже не видит, что эта штука вообще что-то делает.
Я выкинул весь RAG-движок. Оставил только хуки, базу и парсинг. И это был второй пивот — обратно к простой идее «просто покажем, куда идут токены». Самая ироничная часть: пивот был принят на основе данных, которые мой же собственный аналитический модуль и собрал. Иногда лучшая фича — та, которую ты выпилил.
Что в итоге
Сейчас budi выглядит так.
Демон сидит на 127.0.0.1:7878. Он смотрит, куда Claude Code, Codex CLI, Cursor, Copilot CLI и Copilot Chat (VS Code, JetBrains) сами пишут свои транскрипты. Это обычные JSONL-файлы на диске, которые агенты делают для себя — никаких хаков, никакого перехвата трафика, никакой проксирования API. Файлы уже там, я их просто читаю.
Каждое сообщение обогащается:
-
активная ветка git, репозиторий, тикет (вытащенный из имени ветки —
JIRA-1234-fix-something) -
пути к файлам, к которым агент обращался через инструменты
-
классификация сессии (багфикс, рефакторинг, фича, ревью)
-
разбивка по моделям (Opus / Sonnet / Haiku и аналоги у Codex / Cursor)
-
разделение токенов на input / output / cache / thinking
-
стоимость по актуальному прайс-листу LiteLLM
Всё это попадает в локальный SQLite. CLI — это просто HTTP-клиент к демону, который никогда не лезет в базу напрямую. На моих ~1.1 ГБ транскриптов и ~9000$ исторической стоимости запрос полной истории занимает 40 мс при пиковом потреблении 11 МБ памяти. Я специально замерял в сравнении с ccusage — отличным инструментом от другого автора, который вдохновил меня, но работает stateless и потому на тех же данных тратит 740 мс и 322 МБ.
Что вы получаете:
budi status # сегодняшние расходы и здоровье демонаbudi stats projects # репозитории, отсортированные по тратамbudi stats branches # ветки по тратамbudi stats tickets # тикеты по тратам — самое моё любимоеbudi stats files # файлы, которые «дороже» всего трогатьbudi stats models # разбивка по моделямbudi sessions latest # детали последней сессии + vitals
Плюс статус-лайн прямо в Claude Code, Cursor и JetBrains. В нижнем правом углу IDE висит маленькая строчка:
budi · $2.34 1d · $12.50 7d · $48.10 30d
Накопительные суммы за день, неделю и месяц. Не календарный сброс в полночь — именно скользящее окно. Когда я вижу там $80 за день — это сигнал, что я делаю что-то странное, и стоит остановиться и подумать. Эту строку можно настроить под любые слоты — сессия, последнее сообщение, ветка, проект, провайдер.
Экосистема — почему один репо превратился в шесть
Когда я начинал, всё было одним репозиторием на GitHub. По мере того как budi обрастал интеграциями, репозиторий рос, релизы становились нервными, а CI — медленным. Поэтому я разнёс на отдельные репозитории по принципу «одна аудитория — один артефакт»:
-
budi — ядро. Rust-демон и CLI. То самое, что вы ставите через
brew install. Здесь живёт пайплайн ингеста, схема базы, аналитика, статус-лайн и API. Это сердце продукта. -
budi-cloud — облачный дашборд на app.getbudi.dev. Next.js 16, React 19, Supabase, Tailwind. Команды могут видеть общую картину расходов по людям, репозиториям, моделям. Важно: туда уходят только агрегаты — числовые метрики, идентификаторы веток, хеши репозиториев. Никогда не уходят промпты, код или ответы AI. Никогда. Это не маркетинговая фраза, это структурно невозможно — в коде синка нет полей для этих данных.
Обзор расходов в облачном дашборде
Разбивка расходов по репозиториям -
budi-cursor — расширение для VS Code и Cursor. TypeScript. Тот самый виджет в статус-баре, но в редакторе. Опубликовано в VS Marketplace и Open VSX.
-
budi-jetbrains — плагин для JetBrains IDE. Kotlin. Опубликован в JetBrains Marketplace. Для меня это был отдельный экзистенциальный опыт — Kotlin я знаю на уровне “видел в чужих PR”, но Claude Code и здесь вытащил.
-
homebrew-budi — Homebrew tap. Просто формулы. Без него
brew install siropkin/budi/budiне работает. -
getbudi.dev — лендинг. Next.js. Лицо проекта, документация, ссылки на установку.
Все шесть репозиториев написаны мной в паре с Claude Code. Если посмотреть на git log — в коммитах сотни упоминаний «Co-Authored-By: Claude». Это не маркетинговый трюк, это честная атрибуция. Без AI я бы вытащил один репозиторий — может быть, два. Шесть — нет.
Что я понял про работу с AI-агентами на этом проекте
Самое сильное наблюдение — у AI-агента нужно стоить процесс, а не просто кидать задачи. Когда я работал в режиме «напиши мне модуль для X» — у меня получалась куча несогласованного кода, который через неделю было больно поддерживать. Когда я переключился на режим «вот SOUL. md проекта, вот его архитектура, вот контракт данных, реализуй задачу в этих рамках» — у меня стали получаться нормальные модули.
В репозитории budi сейчас лежит файл SOUL.md — единый источник правды для агента и людей. Архитектура, поток данных, контракт атрибуции, схема релизов, что нельзя трогать. Claude Code в первую очередь читает его. И уже после этого открывает любой код.
Второе наблюдение — данные о собственной работе с AI сильно меняют решения. Я выкинул RAG не потому, что мне разонравилась идея, а потому, что цифры показали, что она не работает. Я бы без этих цифр продолжал шлифовать RAG ещё месяца три и в итоге всё равно бы пришёл к тому же ответу — только позже и дороже.
Это, кстати, отдельная мета-петля: я делал инструмент для измерения работы с AI, использовал его на себе же, и его данные меняли продукт, который я с его помощью же и измерял. Когда я первый раз это заметил, было немного не по себе.
Третье — про «не плачу из своего кармана». Это была изначальная формулировка, но она оказалась неточной. Когда видишь, что один тикет съел $80 в Opus, а другой такой же — $12 в Sonnet, разница в моих привычках вылазит сразу. Я перестал по умолчанию запускать Opus на простые задачи. Не потому, что меня кто-то заставил — потому, что я просто увидел разницу. Видимость меняет поведение, даже если деньги не твои.
Куда оно идёт
Сейчас в budi 6 поддерживаемых агентов, в roadmap — Gemini CLI, Amp и Goose. Cloud-сторона уже умеет команды, разрезы по пользователям, и я потихоньку добавляю инсайты — не просто «вы потратили $X», а «вы тратите 40% на репо Y, и из них половина — Opus там, где Sonnet справится».
Параллельно с фичами я учусь продукту. И это, наверное, отдельная статья — фронтенд-разработчик, который умеет делать инструменты, но не умеет их продавать. Я смотрю на open-source-метрики (звёзды, скачивания, упоминания) и пытаюсь понять, где у меня не хватает того, что в индустрии называется storytelling. Я бы написал ещё про это, но сначала надо набить шишек.
Если хочется попробовать
brew install siropkin/budi/budi && budi init
Дальше пользуйтесь Claude Code, Cursor, Codex, как обычно, — budi сам найдёт их транскрипты и начнёт считать. Через минуту запустите budi stats и увидите свою картину. Если у вас уже есть месяцы истории — budi db import импортирует всё за один проход.
Никаких аккаунтов, никаких подписок, MIT-лицензия, 100% локально по умолчанию. Облако — опционально и только агрегаты.
GitHub: github.com/siropkin/budi Сайт: getbudi.dev
Спасибо, что дочитали. Если вы тоже фронтендер, который последний год почти не пишет код руками — мне будет интересно услышать, какие у вас вопросы про собственные расходы. И если вы их тоже не задавали — попробуйте, это неожиданно отрезвляюще.
ссылка на оригинал статьи https://habr.com/ru/articles/1042528/