Token Burn Rate (Швидкість витрати токенів)(Швидкість споживання токенів та управління витратами)

1. Огляд концепції та системна проблема

У звичайних чат-ботах споживання токенів є незначним: одне запитання та відповідь споживають кількасот токенів. Проте у вайбкодингу та автономних агентських циклах (Cursor Composer, Claude Code, OpenHands) динаміка споживання токенів радикально змінюється. Агент завантажує в контекст правила проекту, уривки кодової бази через індекс, схеми інструментів і логи терміналу, надсилаючи 50 000–150 000 токенів на кожній ітерації.

Якщо агент робить 25 кроків для виправлення бага, сумарний обсяг вхідних токенів легко сягає кількох мільйонів. Якщо інженер не розуміє метрики Token Burn Rate (швидкість спалювання токенів), проект швидко стикається з фінансовим шоком: сотні доларів за день роботи на одну робочу станцію або блокування лімітів корпоративного API-ключа в середині робочого дня.

2. Архітектурна таксономія та ментальна модель

Структура витрат токенів у сучасних агентських системах поділяється на чотири нерівнозначні категорії:

┌─────────────────────────────────────────────────────────────┐
│                 TOKEN BURN RATE COST BREAKDOWN              │
├─────────────────────────────────────────────────────────────┤
│ 1. Cached Input Tokens (Prompt Caching Hit) ➔ -90% вартості │
│    Статичні правила репозиторію, базові файли, системний промпт│
├─────────────────────────────────────────────────────────────┤
│ 2. Fresh Input Tokens (Uncached Cache Miss) ➔ 100% вартості │
│    Нові файли, логи терміналу, свіжі повідомлення інженера  │
├─────────────────────────────────────────────────────────────┤
│ 3. Generation Tokens (Output / Code Blocks) ➔ 3-5x тариф   │
│    Генерований код, виклики інструментів у форматі JSON     │
├─────────────────────────────────────────────────────────────┤
│ 4. Thinking / Reasoning Tokens (Extended CoT) ➔ Преміум     │
│    Внутрішні приховані міркування моделей Claude 3.7 / o1   │
└─────────────────────────────────────────────────────────────┘

1. Базове вхідне споживання (Context Ingestion):
   • Обсяг контексту, який модель перечитує на кожному кроці. Чим довший діалог, тим більша вага кожного наступного запиту.
2. Кешований контекст (Cached Prefix):
   • Токени, збережені у KV-кеші відеокарт провайдера. Мають знижену вартість (наприклад, $0.30 за 1M замість $3.00 у Claude Sonnet), якщо префікс запиту не змінюється протягом кількох хвилин.
3. Генераційні токени коду (Output Tokens):
   • Код, який повертає модель. Тарифікується значно дорожче за вхідні токени (у 3–5 разів), оскільки потребує послідовного авторегресивного розрахунку на GPU.
4. Токени розширеного мислення (Thinking Tokens):
   • Внутрішні ланцюжки міркувань моделей нового покоління. Складна задача може згенерувати 10 000 токенів думок ще до того, як модель напише перший рядок коду.

3. Технічний пайплайн та внутрішня механіка

Життєвий цикл моніторингу та контролю Token Burn Rate:

1. Пре-інференсний підрахунок токенів (Token Counting): Локальний токенізатор (наприклад, tiktoken або бібліотека токенізації провайдера) розраховує довжину сформованого промпту перед відправкою.
2. Перевірка лімітів (Circuit Breaker & Guardrails): Система порівнює поточні витрати з встановленим бюджетом: якщо поточна сесія перевищила поріг у $5.00, надсилається попередження інженеру.
3. Оптимізація структури промпту для збереження кешу: Архітектура запиту впорядковується так, щоб статичні дані (правила, маніфести інструментів) йшли на початку, а динамічні (свіжий вивід терміналу) — в кінці. Це запобігає інвалідації кешу провайдера.
4. Отримання телеметрії після відповіді: З заголовків відповіді API зчитуються точні показники: prompt_tokens, completion_tokens, cache_read_input_tokens, cache_creation_input_tokens.
5. Розрахунок поточної швидкості спалювання: Обчислюється швидкість витрат ($/хвилину або $/задачу) і виводиться в статусному рядку IDE або терміналу.

4. Практичні інженерні сценарії в продакшені

01. Архітектурне структурування промптів під збереження 90% знижки кешу

Інженер налаштовує роботу з Claude 3.7 Sonnet:

• Якщо помістити динамічний timestamp або мінливі логи на початок системного промпту, весь 100k контекст буде вважатися новим, спалюючи $0.30 на кожному кроці.
• Перемістивши мінливі змінні у найостанніший блок запиту, інженер забезпечує 95% попадання в кеш (Cache Hit), знижуючи вартість 20-крокового циклу з $6.00 до $0.80.

02. Корпоративний шлюз контролю бюджетів розробників

Технічний директор компанії впроваджує проксі-сервер (LiteLLM / Portkey):

• Кожен інженер отримує персональний добовий ліміт у $15.
• При досягненні 80% ліміту розробник отримує сповіщення в Slack.
• При 100% інструмент автоматично перемикає некритичні задачі на наддешеві моделі (DeepSeek V3 або Claude Haiku).

03. Виявлення аварійного циклу (Infinite Loop Detection)

Автономний агент потрапив у циклічну спробу встановити несумісну бібліотеку:

• Детектор Token Burn Rate помічає, що за останні 3 хвилини було відправлено 8 запитів без зміни результуючого коду, що спалило 1.2M токенів.
• Процес аварійно переривається, зберігаючи кошти компанії.

5. Підводні камені, типові помилки та безпека

• Випадкова інвалідація префіксного кешу: Додавання випадкових UUID або поточного часу на початку розмови руйнує весь KV-кеш, збільшуючи фінансовий рахунок у 10 разів.
• Невидимий овердрафт на моделях мислення (Thinking Budget Overflow): Якщо не обмежити параметр max_thinking_tokens, модель може міркувати протягом 30 000 токенів над тривіальною зміною назви кнопки, спалюючи кошти без доданої вартості.
• Залишені фонові сесії у терміналі: Запуск декількох CLI-агентів у різних термінальних вкладках без моніторингу може призвести до непомітного вичерпання корпоративного балансу, якщо один із процесів застрягне.
• Неправильне налаштування сповіщень провайдера: Відсутність налаштованих жорстких лімітів (Hard Limits) в кабінетах Anthropic або OpenAI створює ризик несподіваного списання тисяч доларів із прив'язаної банківської картки.