Як я заробив 50 000 безкоштовних токенів
Одна річ стала для мене очевидною лише після того, як я певний час попрацював з AI-агентами.
Як і в багатьох командах, у мене є набір обов’язкових перевірок, які мають успішно пройти перед комітом коду:
- Prettier
- ESLint
- Type checking
- Unit tests
Також у мене є правило для coding agent: щоразу, коли він вносить зміни до виконуваного коду, перед тим як рухатися далі, він автоматично запускає всі ці перевірки.
Звучить очевидно, правда?
Проблема була в тому, що всі ці інструменти були налаштовані для людей, а не для AI.
Наприклад:
- Prettier виводив кожен файл, який перевіряв, навіть якщо нічого не змінило.
- Type checker генерував детальний output навіть після успішної перевірки.
- Test runner перераховував кожен виконаний тестовий файл.
- ESLint виводив купу інформаційних повідомлень навіть тоді, коли все було добре.
І тут до мене дійшло:
Кожен рядок цього виводу стає частиною робочого контексту агента.
Сотні рядків логів не є безкоштовними. Вони займають контекст, збільшують витрати токенів і заважають моделі концентруватися на інформації, яка справді має значення.
Тому я змінив стандартні налаштування:
- Prettier нічого не виводить, якщо немає проблем із форматуванням.
- ESLint повідомляє лише про warnings та errors.
- Тести використовують dot reporter і виводять детальну інформацію лише у випадку падіння.
- Успішні перевірки повертають лише короткий підсумок.
Результат?
Точно ті самі гарантії надійності, але з радикально меншим рівнем шуму.
Для людини великі логи здебільшого нешкідливі.
Для AI-агента це забруднення контексту.
А контекст не безкоштовний.
Кожен зайвий токен — це токен, який модель могла б витратити на аналіз вашого коду.
Іноді найкраща оптимізація — це не швидша модель.
Іноді достатньо просто дати моделі менше нерелевантної інформації, яку їй доводиться читати.
Додаток для тих, хто віддає перевагу цифрам, а не теорії
Я відкотив репозиторій до попереднього стану та виміряв сирий вивід за допомогою токенайзера.
- Prettier: приблизно 15 000 токенів
- Test runner: приблизно 35 000 токенів
Після переходу на silent output та компактний репортінг:
- Prettier: приблизно 500 токенів
- Test runner: приблизно 1 500 токенів
Тобто лише за один цикл валідації вдалося прибрати приблизно 48 000 токенів — не видаливши жодної перевірки й не послабивши пайплайн.
Ті самі гарантії. Значно менше забруднення контексту.
15 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівПоради доречні, за це плюсую.
А тайтл — клікбейт, за це мінус
Вітаю! Дякую за коментар. Справедливо щодо тайтлу 🙂
Якщо будете впроваджувати цей підхід, маю невелике прохання: заміряйте, будь ласка, через `tiktoken`, скільки токенів генерував output до і скільки після оптимізації, та киньте результат сюди. Дуже цікаво побачити різницю на іншому проєкті.
Отличная идея! Надо свои логи тестов тоже из INFO переключить в WARN — они огромные, там 1500 тестов, а смысла в них нету: что упало — и так понятно из ошибки.
Вітаю! Дякую за коментар — дуже радий, що ідея стала вам у пригоді.
Я не дуже добре орієнтуюся в Python-екосистемі, але сам принцип я б застосував той самий: formatter зробити максимально silent — в ідеалі, щоб він лише повертав статус успіху або помилки; linter нехай виводить тільки warnings та errors; а для тестів я б використав максимально компактний reporter, на кшталт dot reporter, щоб успішний прогін створював якомога менше тексту.
І мені було б дуже цікаво побачити, скільки токенів це зекономить саме у вашому випадку. Якщо не складно, заміряйте, будь ласка, output до і після. У Python є бібліотека `tiktoken`, яка дозволяє досить просто оцінити розмір тексту в токенах. Було б цікаво порівняти цифри.
Попробую, как сделаю
До речі, зверніть увагу: у коментарях під цією статтею є фаундер, який розробляє testinel.dev — сервіс для покращеного root cause analysis падінь E2E-автотестів. Можливо, вам буде цікаво протестувати його або поспілкуватися з автором.
Ага, мы общались, спасибо )
правильніше написати «як я став мамкиним клікбейтером»
Вітаю! Дякую за коммент!
А що робити, — в такому світі живемо.
До того-ж, це правда.
gpt-5.6-sol коштує $5.00 за 1M input tokens.
“Як я заробив 25 центів”. :)
Але як вправа на оптимізацію — дуже гарно!
Для тих, хто не хоче робити усе це руками — Rust Token Killer:
github.com/rtk-ai/rtk
CLI proxy that reduces LLM token consumption by60-90% on common dev commands. Single Rust binary, zero dependencies
Вітаю, дякую за коментар!
Дозвольте уточнити декілька моментів.
Щодо використання сторонніх бібліотек. Тут я бачу дві проблеми.
- На великих проєктах додавання нової залежності не завжди є тривіальним рішенням. Наприклад, будь-який новий пакет може проходити окремий ревью: чи справді він потрібен, які має секʼюрні-ризики, як впливає на білд, підтримку тощо. Тому додавати залежність заради відносно простої задачі не завжди виправдано.
- Використання готового пакета саме по собі не покращує розуміння того, що відбувається під капотом. Я зовсім не проти сторонніх бібліотек, коли вони доречні, але в цьому конкретному випадку свідомо пішов іншим шляхом.
Тепер щодо $0.25. У самій математиці ви абсолютно праві. Але тут є важливий нюанс: я оптимізував не одноразову операцію, а перевірки, які виконуються багато разів протягом кожної AI-сесії.Припустимо, за одну сесію я 20 разів проходжу цикл «запит → зміна коду → автоматичні перевірки». Це означає, що ці скрипти запускаються приблизно 20 разів і 20 разів генерують зайвий output.
У день активної роботи я можу використати4–6 таких сесій, іноді більше. Візьмемо середні 5:
5 сесій × 20 циклів = ~100 запусків перевірок на день.
Тобто умовні $0.25 за один такий обсяг зайвого контексту вже починають множитися. Потім множимо на робочі дні. Потім — на кількість розробників у команді.
А якщо це не мій воркфлоу, де я контролюю кожну ітерацію, а повністю автоматизований пайплайн, який може самостійно проходити десятки-сотні таких циклів, масштаб стає ще цікавішим.
Саме тому мені й сподобалася ця оптимізація: потенційна економія накопичується на кожній ітерації, а вартість впровадження майже нульова. У найпростішому випадку достатньо буквально змінити параметри запуску кількох скриптів.
Одна така оптимізація навряд чи когось збагатить. Але якщо системно прибирати непотрібний контекст із десятків повторюваних операцій AI-агента, математика вже стає зовсім іншою.
Було би круто, щоб для вау-ефекту ви одразу прорахували, наприклад, щомісячне заощадження, та одразу написали це в назві топіку. Я так розумію мова о 0,25с * 100 * 20 = $500 — а це вже дві клауд макс підписки!
За це вам великий плюс! Я сам такий.
До речі, я розробляю сервіс testinel.dev, який допомагає робити root cause analysis падінь e2e-автотестів (Selenium, Playwright), і для типових помилок розробив парсери, щоб прибирати зайве з айтпуту, щоб ЛЛМці було «простіше це парсити».
Ось приклад сміття в помилці:
А ось оброблений саммарі:
Економію токенів я не рахував (поки що не має такого обмеження), але ми тут з вами на одній хвилі. :)
Мені приємно було читати ваш пост.
UPD. Порахував.
Зі сміттям: 339 токенів.
Без сміття: 26 токенів (я не рахував посилання «More info» — воно інформаційне та завжди однакове).
Тобто егономія 339-26=313 токенів на одному виняткі. До ваших 50 000 мені ще далеко, але і винятків буває десятки на одному запуску автоестів. ;)
Круто :) Радий, якщо мій пост допоміг подивитися на ваш процес трохи під іншим кутом.
І 339 → 26 токенів — це вже дуже хороший результат, фактично 11× на рівному місці.
До речі, тут можна піти ще далі й розділити output для людини та для AI. У Jest, наприклад, є різні reporters. Аналогічно можна мати умовний human reporter з усім корисним для розробника і AI reporter, який залишає лише інформацію, необхідну агенту.
Наприклад, постійне посилання на документацію Selenium для конкретної помилки AI, швидше за все, взагалі не потрібне — сама інформація про цю помилку вже є в його базових знаннях. А це мінус 14 токенів (так, порахував:-).
І те, що у вашому кейсі не набігають одразу десятки тисяч токенів, — абсолютно нормально. Не всюди можна знайти одну фундаментальну оптимізацію, яка дасть величезний виграш.
Але, на мою думку, саме тут і проходить межа між AI-ентузіастом та AI-інженером: інженер вміє збирати десятки таких мікрооптимізацій у систему, де на масштабі вони вже перетворюються на дуже відчутну економію часу, контексту та грошей.
Умовні $0.25 зайвих витрат в одному місці виглядають смішно — доки не починають множитися на кількість запусків, агентів і робочих днів.
Так що так — схоже, ми справді на одній хвилі :)
Очікував якісь tips&tricks щодо акційних пропозицій або llm proxy з різних безкоштовних акаунтів або промокоди , в тут таке ’ а ля капитан Очевидко’ .Дякую😆
Вітаю! Дякую за коммент!
Згоден, вам може бути ця порада КО. Мені, якщо чесно, також.
Але це я такий розумний став після того як кілька місяців палив нещадно токени на тупі логи.
Певен, є і інші такі розумники)