Token Economics: нова одиниця вартості софту — і новий борг у вашому коді

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

За майже двадцять п’ять років у розробці я бачив, як змінювалася економіка софту: ми платили за сервери, потім — за обчислення, далі — за запити й дані. У 2020 році після запуску API GPT-3 ми почали платити за токен, який став одиницею білінгу. А у 2026 році він отримав ще одну роль — став одиницею вимірювання складності та продуктивності AI-систем. Так в економіці софту з’явилась нова дисципліна — token economics (токеноміка) — з власним визначенням, метриками й дослідницьким полем.

Два факти показують масштаб. Тижневе споживання токенів на OpenRouter зросло майже у 68 разів за п’ятнадцять місяців [1]. А низка компаній, за звітом Goldman Sachs (червень 2026), уже враховує вартість токенів у своїх фінансових планах і встановлює ліміти токенних витрат для співробітників [2]. Тобто токен перетворився на окрему статтю корпоративного бюджету.

Тут напрошується заперечення: токени ж дешевшають. І справді — за останні роки токени подешевшали в рази. Але споживання зростає ще швидше. Це класичний парадокс Джевонса: що дешевший ресурс, то більше його витрачають. Економія на ціні токена не рятує, якщо не керувати кількістю токенів. Дисципліни, яка вчить нею керувати, ще рік тому не існувало. А сама ідея поєднати токен з економікою виникла задовго до ери штучного інтелекту — і навіть крипти.

Три життя одного терміна

Поєднання «токен + економіка» пережило три життя — щоразу зі зміною значення самого токена.

Перше почалося в поведінковій психології. У 1960-х Теодоро Айллон і Натан Азрін запропонували token economy як систему терапії, де пацієнти отримували жетони за бажану поведінку й обмінювали їх на привілеї. У 1968 році автори закріпили цей підхід у книзі «The Token Economy: A Motivational System for Therapy and Rehabilitation» [3].

Друге життя термін отримав у криптоіндустрії 2010-х. Токен тут — цифровий актив, а tokenomics — сукупність проектних рішень щодо створення, розподілу та управління такими токенами. Це емісія (minting) і спалювання (burning), стейкінг (staking) та голосування через governance-токени [4].

Третє життя розпочалося з розвитком штучного інтелекту. З 2020 року AI-моделі читають і пишуть не словами, а токенами. Токенізатор ріже текст на дрібніші фрагменти — тому однакова за змістом логіка може коштувати по-різному.

У 2026-му починається формування наукової дисципліни — тобто не тоді, коли за токени почали платити, а тоді, коли рахунок довелося планувати. У січні команда Університету Конкордія ввела термін tokenomics — вивчення операційної ефективності та споживання ресурсів у мультиагентних LLM-системах [5]. А вже у травні Чжецзянський університет і Alibaba Cloud опублікували один із перших систематичних оглядів теми — Token Economics for LLM Agents [1].

У червневому звіті Goldman Sachs про AI та ринок праці автори використовують термін token economics без жодного пояснення — тобто він уже став частиною професійної мови [2].

Відтепер token economics — це дисципліна, що вивчає LLM-токени як економічний ресурс. Огляд Чжецзянського університету формулює це через потрійну економічну природу токена: він одночасно фактор виробництва інтелекту, засіб обміну та одиниця обліку [1].

Той самий термін. Три різні значення токена. Три різні економіки.

Як AI-агенти зламали лінійну модель

Класичне використання LLM було лінійним: один промпт на вхід, одна відповідь на вихід, один рахунок. Агентні системи зруйнували цю модель.

Агент не відповідає один раз. Він працює циклами: завантажує контекст, міркує, викликає інструменти, спостерігає результати, рефлексує над помилками та повторює спробу. Кожна ітерація споживає токени — мислення тут вимірюється в них.

У мультиагентних системах складніше. Там агенти витрачають токени на розмови між собою: синхронізація стану, повторна передача контексту, узгодження форматів.

Ці накладні витрати вже виміряли. Бенчмарк AgentTaxo (воркшоп ICLR 2025) описує communication tax — витрати на комунікацію між агентами. У популярних мультиагентних фреймворках вхідних токенів у 2–3 рази більше, ніж вихідних, а частка токенів, що повторюються щонайменше у двох викликах моделі, сягає 86% [6].

Згадане січневе дослідження «Tokenomics» [5] розклало споживання по фазах розробки: 30 завдань у фреймворку ChatDev, повний цикл. Витрати розподілені вкрай нерівномірно: 59,4% усіх токенів припадає на рев’ю коду, а вхідні токени становлять 53,9% споживання. Фази верифікації непропорційно споживають саме вхідні токени. Найдорожчою виявилася не генерація коду, а його перевірка. Токенна вартість виявляється архітектурною властивістю системи, а не метрикою використання, яку аналізують постфактум.

У цьому напрямі досліджень є й неочевидний висновок: координація стає збитковою, коли продуктивність одиночного агента вже висока [1]. Другий і третій агенти не покращують результат — вони лише додають витрати на перемовини між собою. Тому рішення на рівні обв’язки — скільки агентів запустити, де встановити ліміт циклів, коли доручати міркування, а коли викликати інструмент — тепер часто важить більше, ніж вибір самої моделі.

Для розробника це означає одне: витрати ростуть разом з архітектурою, а не з трафіком. Рахунок може зрости без жодного нового користувача.

Token debt: ваш код уже платить

А ось питання, яке поки що майже не досліджене: вхідна сторона AI-систем — сам код.

Оптимізація, про яку говорить індустрія, стосується рантайму. Але коли AI-агент читає, пише й рефакторить вашу кодову базу, кожен вибір у ній — мова, фреймворк, багатослівність розмітки — стає витратою на кожному циклі. Раніше ми оптимізували код для виконання. Тепер його доводиться оптимізувати ще й для читання — машинами.

Я називаю це token debt — токенним боргом. Уперше я побачив його не в моделях, а в цифрах: та сама логіка, написана різними фреймворками, коштувала по-різному.

Token debt — це прихована повторювана вартість коду. Технічний борг накопичує складність для розробників — token debt накопичує витрати для AI-агентів: кожна зайва конструкція, дублювання чи надмірна багатослівність коштують токенів. І це не гіпотеза. У травні я прогнав jscpd по 49 vibe-coded проектах на GitHub: 7,2 мільйона рядків, 25 612 клонів, у середньому 7,98% дублювання — чистими виявилися чотири проекти з сорока дев’яти. Борг накопичує той самий агент, який потім за нього платить. Він так само зростає непомітно, з кожним рішенням «так простіше», і так само стягує відсотки — лише виставляє їх API-рахунок.

У дослідженнях техборгу LLM-застосунків уже описані сусідні категорії: prompt debt — борг у дизайні промптів, cost debt — борг у споживанні токенів і виборі моделі, а також борги в налаштуванні гіперпараметрів та в інтеграції з LLM-фреймворками [7]. Усі вони — про те, як ви налаштовуєте систему й розмовляєте з моделлю. Token debt відрізняється адресою: він у самій кодовій базі, яку агент читає як вхід. Prompt debt лікується рефакторингом промптів, token debt — рефакторингом коду.

Технічний борг ми давно звикли рахувати. Token debt компілятор читає — і мовчить. Показує його тільки API-рахунок.

Як виміряти token debt: перші емпіричні дані

Щоб перевірити, як це працює на реальному коді, я провів серію вимірювань у межах дослідження «Tokenomics of Web Development»: 22 веб-технології, 115 ідіоматичних сніпетів, один токенізатор — tiktoken (cl100k_base). На іншому токенізаторі абсолютні числа будуть іншими, відносні розриви зберігаються.

Мова: синтаксис має ціну

На п’яти однакових задачах, реалізованих ідіоматично кожною з п’яти мов, TypeScript вийшов на 31% дорожчим за чистий JavaScript [8]. Логіка в обох випадках однакова — різниця лише у формі запису: двокрапки, анотації, дужки параметрів. Звідси перший висновок: для агента вартість коду визначає не те, що код робить, а те, як він записаний. У зібраному коді цієї різниці немає — вона проявляється лише в рахунку за токени.

Це не аргумент проти TypeScript: 31% — плата за типобезпеку, а не дефект мови. Це прогалина на ринку — системи типів, спроектованої з урахуванням токенізатора, ще не існує.

Другий результат виявився для мене несподіванкою. Я очікував, що серед мов у тесті переможе старий знайомий CoffeeScript, але найкращий результат показав ZeroLang — експериментальна системна мова від Vercel Labs зі ще крихітною спільнотою та ранньою специфікацією, спроектована так, щоб її основним читачем був агент, а не людина.

CoffeeScript залишився другим — і підтвердив те, чого я й чекав: у верхівці рейтингу опинилися дві мови, де структуру задають відступи. Кожна дужка — це токен, кожна крапка з комою — токен, а відступ для токенізатора безкоштовний. Лаконічність, яка досі була лише питанням стилю, отримала ціну.

А найкорисніший результат дав Civet — мова з тим самим лаконічним синтаксисом, що й CoffeeScript, але з типами. За рядками вона компактніша за JavaScript: 34 проти 41. За токенами програє: 320 проти 287. Різниця не в синтаксисі, а в тому, що в нього дописано, — анотації в стилі TypeScript з’їдають усю економію на відступах. Отже, платить не форма запису, а те, що ви в неї додали. Приберіть типи — і Civet опуститься приблизно до рівня CoffeeScript.

Фреймворк: код, який пише компілятор, дешевший

На еквівалентних компонентах Angular коштує на 38% більше токенів, ніж Svelte [8]. Але цікавий тут не сам переможець, а механіка: вартість коду для LLM складається з двох незалежних величин — наскільки щільно він токенізується і скільки коду загалом довелося написати. У цьому вимірюванні перемогла друга. Фреймворк, який найгірше токенізується в групі, все одно вийшов найдешевшим, оскільки реактивність за розробника розгортає компілятор. Універсального переможця при цьому немає: на окремих завданнях уперед виходять інші фреймворки.

Практичний наслідок такий: найдешевший токен — той, який компілятор створив сам. Усе, що ви записали вручну, агент буде перечитувати й оплачувати; усе, що згенерувала збірка, для нього просто не існує.

І ось чому це борг, а не просто витрата. Мову та фреймворк обирають один раз — на старті проекту, коли про токени ще ніхто не думає. Утім рахунок за це рішення приходить щодня, під час кожного проходу агента, і зростає разом із кодовою базою. Разове рішення, яке створює витрати на кожному проході, — це і є борг.

Обидва заміри стосуються того, як написаний код. Але агент читає не лише код — він читає й те, що видають ваші інструменти. Саме тут token debt проявляється найгостріше: звіт лінтера чи аналізатора потрапляє в контекст повністю і повторно при кожному запуску. Це й привело мене до наступного вимірювання.

Тулінг: найдорожчий рядок у рахунку

У власному бенчмарку jscpd я порівняв, скільки токенів різні CPD-інструменти віддають агенту на одному й тому самому корпусі — 547 файлів, 21 645 рядків, понад 150 форматів. Компактний формат jscpd — 2 800 токенів. JSON від Duplo — 158 000.

Це не два звіти про одні й ті самі дублікати. Кожен інструмент рахує клони по-своєму: jscpd знаходить 212, Duplo — 518, бо працює чистим текстовим збігом без токенізації й роздуває результат хибними спрацюваннями. Але агенту байдуже, скільки з них справжні. Він читає й оплачує все, що йому подали.

Чистий замір виходить на одному інструменті. Той самий jscpd на тому самому корпусі: 2 800 токенів у компактному форматі проти 23 000 у консольному. Ті самі 212 клонів, той самий код — різниця у вісім разів лише в тому, як їх подано агенту.

Сирі дані та методика вимірювання лежать у репозиторії jscpd — їх можна перевірити й відтворити.

Найдорожчий рядок у рахунку опинився там, куди ніхто не дивиться. Причина в тому, що вихід інструментів рідко переглядають і майже не оптимізують: історично він призначався не для читання, а для парсингу.

Із цього випливає третій висновок — прикладний. Мову проекту так просто не змінити, як і фреймворк; а формат звіту змінюється одним прапорцем у конфігурації. Найдешевший спосіб скоротити token debt — не переписувати код, а подивитися, що саме ваші інструменти передають агенту. Саме тому в jscpd з’явився компактний формат звіту для AI-пайплайнів.

Дублікати я рахую роками — і тепер у них з’явився ще один вимір: ціна в токенах. Головне, що змінилося в моєму підході, — я перестав довіряти метрикам інструментів на слово: спершу вимірюю, потім довіряю. Метрика без контексту — це просто число.

Усі три потрапляють в один контекст агента. Token debt накопичується з кількох боків одночасно.

У підсумку найбільше з вашого API-бюджету з’їдають не ваші рядки, а службові поля чужого звіту.

Що показує реальне використання AI-агентів

Незалежне підтвердження з’явилося у травні. Дослідники SonarSource побудували мінімальні пари репозиторіїв — з однаковою архітектурою, залежностями та зовнішньою поведінкою, але різною чистотою коду — і прогнали Claude Code через 660 випробувань на 33 задачах [9]. Результат виявився подвійним: чистота коду не вплинула на здатність агента завершувати завдання, але вплинула на операційну вартість його роботи. На чистому коді агент витрачав на 7–8% менше токенів і на 34% рідше повертався до файлів, які вже редагував. Автори свідомо міряють токени, а не гроші: переведення в долари залежить від моделі, провайдера й стану кешу, тобто від речей, які не є властивостями коду.

Масштаб, у якому це рахується, показують суміжні дослідження: одна задача на SWE-bench Verified у середньому споживає близько 4 мільйонів токенів, і більшість із них — вхідні [9]. Тобто токени, які агент просто читає.

Питання «як платити менше» вже має власну літературу: моделі вчать зупинятися раніше, стискати контекст, викликати інструмент замість довгих міркувань і накопичувати пам’ять між сесіями. Огляд Token Economics for LLM Agents зводить ці підходи в одну систему [1] — і всі вони працюють із тим, як агент витрачає токени. Але жоден із них не чіпає самого артефакту, який агент читає, — кодової бази. Тут і живе token debt: єдина вісь, де відповідальність лежить на розробнику, а не на платформі.

Замість висновку

Софт отримав нову статтю витрат, вимірювану в токенах. Вона стосується кожного шару стека — від дизайну токенізатора до attention-ядер і вибору мови програмування. Код уперше отримав ціну не лише під час виконання, а й під час читання.

Жетон, запис у блокчейні, сировина інтелекту — за шість десятиліть токен встиг побувати всіма трьома. І щоразу в ньому вели облік: спершу поведінки, потім капіталу, тепер — вартості коду. У найближчі роки ми будемо оптимізувати не лише latency, memory footprint і cloud costs. Доведеться навчитися рахувати ще один ресурс — token footprint нашого софту. І робити це доведеться однаково уважно — і людям, і агентам.

Порахуйте самі

Токеноміка зручна тим, що її можна перевірити за один вечір. tiktoken — бібліотека від OpenAI, якою можна порахувати токени будь-якого файлу. Tokenizer Playground показує, як саме ваш код розбивається на токени.

Почніть із власного репозиторію: порахуйте, скільки токенів займає найбільший файл, який агент читає щоразу. А потім — скільки коштує в токенах звіт вашого лінтера.

P.S. Якщо тема відгукнулась — у Telegram-каналі Math.random() я продовжую розбирати token economics, агентні інструменти, реальні вимірювання й експерименти, які не завжди стають окремими статтями. Саме там першими з’являються нові заміри, спостереження та інженерні висновки.

Література

1. Chen, Y., Chen, J., He, C., Li, Y., Ji, Y., Wu, Y., Yang, D., Diao, L., Shou, L., Zhang, H., Li, H., & Chen, G. (2026). Token Economics for LLM Agents: A Dual-View Study from Computing and Economics. Zhejiang University & Alibaba Cloud.
2. Goldman Sachs Global Investment Research (2026). An AI Job Apocalypse? Top of Mind, Issue 149, June 25, 2026.
3. Ayllon, T., & Azrin, N. H. (1968). The Token Economy: A Motivational System for Therapy and Rehabilitation. New York: Appleton-Century-Crofts.
4. Gregory, R., & Mini, T. (2025). Token Economics. In R. Beck (Ed.), Elgar Encyclopedia of Cryptocurrencies, Blockchain, and DLT. Edward Elgar.
5. Salim, M., Latendresse, J., Khatoonabadi, S., & Shihab, E. (2026). Tokenomics: Quantifying Where Tokens Are Used in Agentic Software Engineering. MSR ’26, Rio de Janeiro.
6. Wang, Q., Tang, Z., Jiang, Z., Chen, N., Wang, T., & He, B. (2025). AgentTaxo: Dissecting and Benchmarking Token Distribution of LLM Multi-Agent Systems. ICLR 2025 Workshop on Foundation Models in the Wild.
7. Aljohani, A., & Do, H. (2025). PromptDebt: A Comprehensive Study of Technical Debt Across LLM Projects. EASE 2025.
8. Kucherenko, A. (2026). Tokenomics of Web Development — серія вимірювань. HackerNoon: Частина 1, Частина 2
9. Trivedi, P., & Schmitt, O. (2026). Does Code Cleanliness Affect Coding Agents? A Controlled Minimal-Pair Study. SonarSource.