Є зустріч, яка вбиває більше агентних проєктів, ніж будь-який баг будь-коли. Вона трапляється приблизно через два місяці після запуску, і веде її не інжиніринг. Фінанси відкривають дашборд, показують на рядок, який виріс у 8 разів при зростанні використання у 2 рази, і ставлять питання, на яке ніхто в кімнаті не може відповісти: «За що саме ми платимо?»
Інженери не некомпетентні — система працює. Але ніхто не проєктував її вартісну поведінку, тому вартісна поведінка спроєктувала себе сама. Цей пост називає дисципліну, яка запобігає тій зустрічі: token economics. Це шоста опора в арці, яку я пишу, — після контекст-інжинірингу, spec-driven development, evals, OpenSpec і durable execution — і саме вона вирішує, чи продовжать інші п’ять працювати в продакшені.
Що таке token economics?
Token economics — це інженерна дисципліна ставлення до вартості LLM як до спроєктованої властивості системи, а не виявленої. Вона покриває чотири рішення: скільки кожному запиту дозволено коштувати (бюджетування), за яку роботу ви відмовляєтеся платити двічі (кешування), яка робота може почекати дешевшої обробки (батчинг) і яка модель заслуговує кожен запит (routing). Команди, що ухвалюють ці рішення явно, відвантажують агентів із передбачуваним unit cost; команди, які ні, дізнаються свої unit costs з інвойсу.
Слово «economics» у цьому визначенні робить реальну роботу. Це не урізання витрат — це їхнє моделювання: знати маржинальну вартість ще одного користувача, ще однієї фічі, ще одного кроку агента до того, як спитають фінанси.
Ніхто не проєктував її вартісну поведінку, тому вартісна поведінка спроєктувала себе сама. Ця фраза описує майже будь-яку агентну систему, яку вимикають на другому кварталі.
Важелів шість, і їх варто знати як набір, бо в кожного є режим відмови, що проявляється як сюрприз по витратах, а не як помилка:
| Важіль | Що він робить | Типовий ефект | Як він обертається проти вас |
|---|---|---|---|
| Бюджет на запит | Обмежує, скільки може витратити один прогін, із примусом у рантаймі | Перетворює «можемо додати крок верифікації?» з дебату на арифметику | Розмірений за середніми, тому прогони з довгого хвоста вмирають біля стелі замість того, щоб дійти до кінця |
| Prompt caching | Припиняє перекуповувати стабільний prefix на кожному кроці | Великий зріз оплачуваних вхідних токенів, узагалі без розміну якості | Промпт, зібраний у мінливому порядку, промахується мовчки — повна ціна, жодної помилки |
| Batch-обробка | Переносить роботу, на яку ніхто не чекає, у дисконтований async | Крута знижка на evals, бекфіли та сумаризацію | Застосована до того, на що користувач чекає, і тепер фіча здається зламаною |
| Routing моделей | Відправляє кожен крок найдешевшій моделі, чий вихід ви можете перевірити | Більшість кроків дешевшає; токени концентруються там, де зв’язує якість | Зроблений без evals, тому ви оптимізуєте наосліп і відвантажуєте регресію якості |
| Checkpointing | Дозволяє прогону, що впав, відновитися замість рестарту | Ретраї припиняють перекуповувати всю історію розмови | Checkpoint’и надто грубі, тому ви все одно переграєте більшу частину прогону |
| Витіснення контексту | Викидає те, що наступному кроку доказово не потрібне | Припиняє квадратичне зростання витрат із довжиною прогону | Витісняє те єдине обмеження, якого агенту треба було продовжувати дотримуватися |
Чому витрати агентів вибухають, коли витрати запитів — ні?
Тому що агенти множать. Чат-фіча коштує приблизно один виклик моделі на дію користувача — лінійно, нудно, безпечно. Агент робить кроки, і кожен крок може нести накопичений контекст усіх кроків до нього. Вартість прогону — це не вартість-кроку × кроки; це ближче до вартість-кроку × кроки², бо контекстне вікно росте в міру подовження прогону. Додайте ретраї, tool-результати, вивалені в контекст дослівно, і планувальник, який «подумає про це ще разок», — і 8-кратний сюрприз по витратах при 2-кратному використанні перестає бути загадкою.
Ось чому token economics невіддільна від контекст-інжинірингу. Кожне контекст-інженерне рішення — що ретривити, що сумаризувати, що витісняти — це ще й рішення про покупку. Неохайна контекст-стратегія — не просто проблема якості; це постійне доручення купувати ті самі токени знову і знову.
Зв’язок із durable execution настільки ж прямий: агент, який уміє відновлюватися замість рестарту, не перекуповує власну історію після кожного збою. У термінах витрат checkpointing — це дисконтна програма. Архітектури retry-from-zero платять повну ціну за ту саму роботу N разів і називають це надійністю.
Як насправді має виглядати токен-бюджет?
Справжній токен-бюджет — це стеля на запит із власником і точкою примусу, а не місячний підсумок на дашборді. Робоча форма: кожна фіча декларує очікувану вартість на запит і жорсткий максимум, система примушує максимум у рантаймі (агент, що вперся у стелю, зупиняється і репортить — точно як таймаут), і в числа є названий власник. Місячні підсумки виявляють проблеми; стелі на запит їм запобігають.
Бюджети змінюють інженерні розмови так, як дашборди не змінюють ніколи. «Можемо додати агенту крок верифікації?» перестає бути філософським дебатом про якість і стає арифметикою: крок коштує ~4k токенів на прогін, у бюджеті 3k запасу, отже або крок стає дешевшим, або щось інше. Це продуктивна суперечка. Команди ведуть її до відвантаження, а не після інвойсу.
Бюджет також має бути видимим там само, де живе спека. Якщо ви практикуєте spec-driven development, стеля вартості належить спеці поруч із поведінковими вимогами — «відповідає за 30 секунд, коштує менше X за прогін» — бо вимога, яку ніхто не записав, — це вимога, якої в системи немає.
Що насправді купує кешування?
Prompt caching — найвисоковажільний інструмент витрат у стеку, бо агентні навантаження екстраординарно повторювані: системний промпт, схеми інструментів і довгоживучий контекст ідентичні між кроками і часто між користувачами. Кеш-свідомий дизайн запитів — стабільний префікс спочатку, волатильний контент у кінці — рутинно зрізає оплачуваний обсяг токенів агентної системи вдвічі й більше, узагалі без розміну якості. Це найближче до безкоштовних грошей в AI-інжинірингу.
Але кешування окупається, лише якщо запити побудовані кешованими, а це архітектурне рішення, не прапорець. Промпт, що збирається в різному порядку на кожен запит, тихо перемагає кеш — ви платите повну ціну, і ніщо не падає з помилкою. Це місце, де різниця між «одного разу прочитав API-доки» і «реально знає платформу» проявляється прямо в інвойсі; механіка (cache breakpoints, дизайн префікса, TTL і те, як верифікувати, що ви отримуєте cache-хіти) — рівно те, що дрилить курс із Claude API, бо верифікована економія б’є припущену.
Як спроєктувати запит, який реально кешується
Правило легко сформулювати і легко порушити: усе стабільне йде першим, усе волатильне — останнім. Системні інструкції, tool schemas і довгоживучий проєктний контекст утворюють prefix; поточне повідомлення користувача, відритривлені чанки для цього запиту і стан конкретного кроку йдуть після. У момент, коли один мінливий токен з’являється рано, усе після нього стає некешованим — кеш матчиться за префіксами, а не за контентом, який він упізнає пізніше.
Самостріл, який я бачив найчастіше, — timestamp. Хтось додає корисний рядок Current time: … ближче до верху системного промпта, і весь prefix змінюється на кожному одиничному виклику. Промпт усе ще працює. Evals усе ще проходять. Рахунок тихо подвоюється, і ніде немає падіння, яке можна було б розслідувати. Те саме стосується імені користувача, request ID або випадково впорядкованого набору tool-визначень, зібраного з хеш-мапи, — усе, що змінюється від виклику до виклику, належить місцю після стабільного блоку або не належить ніде.
Час життя кешу теж важливий. Кешовані префікси спливають, тому низькотрафікова фіча може заплатити за запис кешу і жодного разу не прочитати його до спливання; високотрафікова амортизує запис по тисячах викликів. Ось чому кешування виграє так рішуче саме на агентних циклах — один прогін робить багато викликів у швидкій послідовності проти майже ідентичного prefix.
Як верифікувати економію замість того, щоб її припускати
Логуйте кешовані та некешовані вхідні токени як окремі поля, завжди. Дашборд, що показує одне злите число «вхідні токени», не може сказати вам, чи працює кешування, і команди рутинно вірять, що отримують знижку, яку перестали отримувати тижні тому. Коли розділення записане, похідна метрика, яка вам реально потрібна, — cache-hit ratio на фічу, а алерт, який вам потрібен, — падіння цього відношення, бо ламає кешування ніколи не деплой із підписом «зламати кеш», а безневинний рефакторинг, що змінив порядок збирання промпта. Цей алерт — різниця між «дізнатися за один вечір» і «дізнатися на квартальному рев’ю».
Батчинг — тихий сиблінг кешування: будь-яка робота, якій не потрібна відповідь за секунди — нічна сумаризація, бекфіли, eval-сьюти, — може йти через batch-обробку з крутою знижкою. Проєктне питання просте: які з ваших навантажень таємно асинхронні. За моїм досвідом, їх більше, ніж визнає архітектура, і evals — канонічний приклад: комплексний сьют, що ганяється вночі за batch-цінами, коштує дешевше за тонкий, що ганяється синхронно в паніці після інциденту.
Коли запит має брати модель поменше?
Роутьте за верифіковністю, а не за вайбами: використовуйте найменшу модель, чий вихід ви можете перевірити, і бережіть фронтирну модель для кроків, де помилятися дорого, а перевіряти важко. Класифікація, екстракція, форматування, сумаризація-для-зберігання — у них верифіковні виходи, і вони терплять дешевшу модель, підперту валідацією. Планування, вибір інструмента у відкритих ситуаціях і фінальний користувацький синтез зазвичай заслуговують велику модель. Добре зроучений агент часто жене більшість своїх кроків на малих моделях, витрачаючи більшість своїх токенів там, де якість реально зв’язує.
Routing — це ще й місце, де evals перестають бути опціональними. Без регресійного сьюта кожна зміна роутингу — стрибок віри, і команди або ніколи не оптимізують (дорого), або оптимізують наосліп (гірше). Зі справжнім eval-харнесом «перенести екстракцію на малу модель» — це експеримент на пів дня з pass/fail-відповіддю. Eval-сьют — те, що робить оптимізацію витрат безпечною; це знову та сама трійця: спека каже, що має триматися, evals верифікують, що все ще тримається, а token economics вирішує, скільки це може коштувати.
Патерн, який б’є обидві крайності, — ескалація замість призначення: женіть крок на малій моделі, валідуйте вихід механічно і ретрайте на фронтирній моделі лише тоді, коли validation падає. Якщо дешева модель права у вісімдесяти відсотках випадків, а validation надійна, ви платите ціни малої моделі чотири рази з п’яти і все одно отримуєте коректність фронтирної моделі — економіка краща, ніж роутити все вниз, і якість краща, ніж роутити все вгору.
Конкретна форма, зі support-triage агента, над яким я працював: класифікувати вхідний запит (мала модель, вихід — одна з фіксованого набору міток, тривіально перевірювано), відритривити релевантну історію (взагалі без моделі — це запит до бази, який команди рутинно віддають LLM без жодної причини), скласти чернетку відповіді (mid-tier), потім фінально перевірити політику й тон до того, як це дійде до людини (фронтирна). Чотири кроки, три різні моделі, один крок узагалі без моделі. Більшість кроків ідуть дешево; більшість токенів сідає на ті два, які важливі.
Антипатерн, який варто назвати: routing за тарифом клієнта замість routing за задачею. Платним клієнтам не потрібна модель побільше, їм потрібна коректна відповідь — і дешева модель із validation часто видає її надійніше, ніж дорога модель без неї. Роутьте за верифіковністю, дайте evals вирішувати і тримайте сторінку з цінами поза архітектурою.
Для мультиагентних систем додайте одне правило: суб-агенти не наслідують модель оркестратора за замовчуванням. Кожна роль отримує найдешевшу модель, яка проходить evals цієї ролі, — різниця між флотом, який масштабується, і флотом, який вимикають, — зазвичай саме це правило, застосоване рано. Будувати агентів із пер-рольовим вибором моделі та інструментуванням витрат із першого дня — базовий патерн курсу з Agent SDK, рівно з цієї причини.
Як зробити витрати видимими раніше, ніж це зроблять фінанси?
Інструментуйте вартість на запит, на фічу і на крок агента з першого деплою — так само, як ви ставитеся до latency. Логуйте токени на вході й виході (кешовані та некешовані окремо, інакше обдурите самих себе), тегуйте за фічею і кроком, алертіть на викиди за окремими запитами, а не на місячні підсумки. Один повільний запит не чекає місячного інфраструктурного рев’ю; один агентний прогін із 50-кратною вартістю теж не повинен.
П’яти полів на виклик моделі достатньо, щоб відповісти майже на будь-яке питання, яке вам потім поставлять: фіча, крок, модель, вхідні токени, розділені на кешовані та некешовані, і вихідні токени. Усе корисне виводиться з них — вартість на прогін, вартість на фічу, cache-hit ratio, розподіл, який каже вам, чи розмірена ваша бюджетна стеля під середнє чи під хвіст. Команди, що пропускають тег кроку, — це ті, хто знає, що їхній агент дорогий, але не може сказати, який із його восьми кроків за це відповідає, а це перетворює фікс на пів дня на тиждень здогадок.
Далі два алерти, і втримайтеся від додавання нових. Перший — викид за вартістю окремого запиту: один прогін, що перейшов якесь кратне свого бюджету, бо саме так ззовні виглядає цикл, що розбігся. Другий — падіння cache-hit ratio на фічу, бо саме так тихе подвоєння про себе оголошує. Алерти на місячні підсумки відчуваються відповідально і майже марні: до моменту, коли місячне число стає тривожним, гроші витрачені, а причина — чотири деплої тому.
Репортинговий артефакт, який змінює політику, — крива unit cost: вартість на успішну задачу в часі. Вона перефреймлює фінансову зустріч із «чому росте рахунок» (загроза) у «unit cost упав на 40%, поки використання подвоїлося» (коло пошани). Ті самі числа, протилежна зустріч — і команда, яка володіє своїми unit costs, отримує право продовжувати експериментувати, бо керівництво довіряє: за лічильником стежать.
Дисципліна, стиснена
Дайте кожному запиту бюджет із власником. Будуйте промпти кешованими і верифікуйте хіти. Батчте все, що таємно асинхронне. Роутьте за верифіковністю з evals як страхувальною сіткою. Робіть checkpoint’и, щоб ретраї не перекуповували історію. Інструментуйте unit cost із першого дня і репортьте його до того, як спитають. Ніщо з цього не екзотика — це та сама крива зрілості, яку інфраструктурні витрати пройшли декаду тому, стиснена в один рік. Команди, які її інтерналізують, отримують право ганяти амбітні агентні системи; команди, які ні, отримують ту зустріч. Архітектурні патерни RAG-і-агентів усі передбачають цю дисципліну під собою — а якщо хочете версію всієї арки як операційної моделі, основи spec-driven development — те місце, де шість дисциплін збираються в один воркфлоу.
