Token Debt Is the New Technical Debt

In almost twenty-five years in development I have watched the economics of software change: we paid for servers, then for compute, then for requests and data.In 2020, after the GPT-3 API launched, we started paying per token, and the token became a unit of billing. In 2026 it took on a second role — a unit for measuring the complexity and productivity of AI systems. That is how software economics gained a new discipline: token economics, with its own definition, metrics, and research field.Two facts show the scale. Weekly token consumption on OpenRouter grew almost 68-fold in fifteen months [1]. And a number of companies, according to a Goldman Sachs report (June 2026), already account for token cost in their financial plans and set token spending limits for employees [2]. The token has become a line item in the corporate budget.Prices fell; the count grew fasterThere is an obvious objection: tokens are getting cheaper. They are — prices have fallen several times over in recent years. But consumption is growing faster. This is the classic Jevons paradox: the cheaper a resource gets, the more of it we burn. Saving on the price of a token does not help if you do not manage the number of tokens. A year ago, the discipline that teaches you how to manage it did not exist. And the idea of pairing the token with economics is far older than AI — older than crypto, too.Three Lives of One TermThe pairing of “token + economics” has lived three lives — each time with a different meaning of the token itself.The first began in behavioral psychology. In the 1960s, Teodoro Ayllon and Nathan Azrin proposed the token economy as a therapy system in which patients earned tokens for desired behavior and exchanged them for privileges. In 1968 the authors formalized the approach in the book The Token Economy: A Motivational System for Therapy and Rehabilitation [3].The second life came in the crypto industry of the 2010s. Here the token is a digital asset, and tokenomics is the set of design decisions governing how such tokens are created, distributed, and managed: minting and burning, staking, and voting through governance tokens [4].The third life began with AI. Since 2020, AI models have been reading and writing not in words but in tokens. The tokenizer cuts text into smaller fragments — which is why logic that is identical in meaning can cost different amounts.In 2026 the field starts to take shape as a scientific discipline — not when we started paying for tokens, but when the bill had to be planned. In January, a team at Concordia University introduced the term tokenomics: the study of operational efficiency and resource consumption in multi-agent LLM systems [5]. By May, Zhejiang University and Alibaba Cloud had published one of the first systematic surveys of the topic — Token Economics for LLM Agents [1]. In its June report on AI and the labor market, Goldman Sachs uses the term token economics with no explanation at all — meaning it is already part of the professional vocabulary [2].From here on, token economics is the discipline that studies LLM tokens as an economic resource. The Zhejiang University survey frames this through the token’s triple economic nature: it is simultaneously a factor of production for intelligence, a medium of exchange, and a unit of account [1].The same term.Three different meanings of the token. Three different economies.How AI Agents Broke the Linear ModelClassic LLM usage was linear: one prompt in, one answer out, one bill. Agentic systems broke that model.An agent does not answer once. It works in loops: it loads context, reasons, calls tools, observes results, reflects on errors, and tries again. Every iteration consumes tokens — thinking here is measured in them.Multi-agent systems are harder. There, agents spend tokens talking to each other: state synchronization, repeated context transfer, format negotiation.That overhead has already been measured. The AgentTaxo benchmark (ICLR 2025 workshop) describes the communication tax — the cost of agent-to-agent communication. In popular multi-agent frameworks there are 2–3 times more input tokens than output tokens, and the share of tokens repeated across at least two model calls reaches 86% [6].The January “Tokenomics” study [5] broke consumption down by development phase: 30 tasks in the ChatDev framework, full cycle. The distribution is strikingly uneven: 59.4% of all tokens go to code review, and input tokens make up 53.9% of consumption. Verification phases consume input tokens disproportionately. The most expensive step turned out to be not generating code but checking it. Token cost proves to be an architectural property of the system, not a usage metric you analyze after the fact.This line of research has a counterintuitive finding as well: coordination becomes a net loss once a single agent’s performance is already high [1]. The second and third agents do not improve the result — they only add the cost of negotiating with each other. So decisions at the harness level — how many agents to run, where to cap the loops, when to delegate reasoning and when to call a tool — now often matter more than the choice of model.For a developer this means one thing: cost grows with architecture, not with traffic. Your bill can rise without a single new user.Token Debt: Your Code Is Already PayingHere is a question that is still almost unexplored: the input side of AI systems — the code itself.The optimization the industry talks about concerns runtime. But when an AI agent reads, writes, and refactors your codebase, every choice in it — language, framework, markup verbosity — becomes a cost on every loop. We used to optimize code for execution. Now it has to be optimized for reading, too — by machines.I call this token debt. I first saw it not in models but in numbers: the same logic, written in different frameworks, cost different amounts.Token debt is the hidden recurring cost of code. Technical debt accumulates complexity for developers; token debt accumulates cost for AI agents: every redundant construct, every duplicate, every bit of excess verbosity costs tokens. And this is not a hypothesis. In May I ran jscpd across 49 vibe-coded projects on GitHub: 7.2 million lines, 25,612 clones, 7.98% duplication on average — four projects out of forty-nine came back clean. The same agent that later pays for the debt is the one accumulating it. It grows just as quietly, with every “this way is easier” decision, and it charges interest the same way — it just bills you through the API.Research on technical debt in LLM applications already describes neighboring categories: prompt debt — debt in prompt design; cost debt — debt in token consumption and model choice; plus debt in hyperparameter tuning and in integration with LLM frameworks [7]. All of them are about how you configure the system and talk to the model. Token debt differs by address: it lives in the codebase itself, which the agent reads as input. Prompt debt is cured by refactoring prompts; token debt, by refactoring code.Technical debt we have long been used to counting. Token debt the compiler reads — and says nothing. Only the API bill shows it.How to Measure Token Debt: The First Empirical DataTo see how this works on real code, I ran a series of measurements as part of the study Tokenomics of Web Development: 22 web technologies, 115 idiomatic snippets, one tokenizer — tiktoken (cl100k_base). On a different tokenizer the absolute numbers will change; the relative gaps hold.Language: Syntax Has a PriceAcross five identical tasks implemented idiomatically in each of five languages, TypeScript came out 31% more expensive than plain JavaScript [8]. The logic is identical in both cases — the only difference is the form of notation: colons, annotations, parameter parentheses. Hence the first conclusion: for an agent, the cost of code is set not by what the code does but by how it is written. In the compiled output that difference is gone — it shows up only on the token bill.This is not an argument against TypeScript: the 31% is the price of type safety, not a defect of the language. It is a gap in the market — a type system designed with the tokenizer in mind does not exist yet.The second result was a surprise to me. I expected my old friend CoffeeScript to win among the languages in the test, but the best result came from ZeroLang — an experimental systems language from Vercel Labs with a still tiny community and an early spec, designed so that its primary reader is an agent, not a human.CoffeeScript came second — and confirmed what I did expect: the top of the ranking is held by two languages where indentation defines structure. Every bracket is a token, every semicolon is a token, and indentation is free for the tokenizer. Terseness, until now purely a matter of style, has acquired a price.The most useful result came from Civet — a language with the same terse syntax as CoffeeScript, but with types. By line count it is more compact than JavaScript: 34 versus 41. By tokens it loses: 320 versus 287. The difference is not in the syntax but in what has been added to it — TypeScript-style annotations eat up the entire saving from indentation. So what you pay for is not the form of notation but what you put into it. Take the types out and Civet drops to roughly CoffeeScript’s level.Framework: Code the Compiler Writes Is CheaperOn equivalent components, Angular costs 38% more tokens than Svelte [8]. But the interesting part is not the winner — it is the mechanics: the cost of code for an LLM is made up of two independent quantities — how densely it tokenizes, and how much code you had to write in the first place. In this measurement the second one won. The framework that tokenizes worst in the group still came out cheapest, because the compiler unfolds reactivity on the developer’s behalf. There is no universal winner, though: on individual tasks other frameworks come out ahead.The practical consequence: the cheapest token is the one the compiler produced itself. Everything you wrote by hand, the agent will reread and pay for; everything the build generated simply does not exist for it.And here is why this is debt rather than just cost. Language and framework are chosen once — at the start of a project, when nobody is thinking about tokens. But the bill for that decision arrives every day, on every agent pass, and grows along with the codebase. A one-time decision that creates a cost on every pass is exactly what debt is.Both measurements are about how the code is written. But an agent reads more than code — it also reads whatever your tools emit. This is where token debt bites hardest: a linter or analyzer report lands in the context in full, and again on every run. That is what led me to the next measurement.Tooling: The Most Expensive Line on the BillIn my own jscpd benchmark I compared how many tokens different CPD tools hand to an agent on one and the same corpus — 547 files, 21,645 lines, more than 150 formats. jscpd’s compact format: 2,800 tokens. Duplo’s JSON: 158,000.These are not two reports about the same duplicates. Every tool counts clones its own way: jscpd finds 212, Duplo finds 518, because it works by plain text matching without tokenization and inflates the result with false positives. But the agent does not care how many of them are real. It reads and pays for everything it is handed.A clean measurement takes one tool. The same jscpd on the same corpus: 2,800 tokens in the compact format versus 23,000 in the console one. The same 212 clones, the same code — an eight-fold difference purely in how they are presented to the agent. The raw data and the measurement methodology are in the jscpd repository — you can check and reproduce them.The most expensive line on the bill turned out to be where nobody looks. The reason is that tool output is rarely reviewed and almost never optimized: historically it was meant not for reading but for parsing.From this follows the third conclusion — the applied one. You cannot easily change your project’s language, nor its framework; but the report format can be changed with a single configuration flag. The cheapest way to cut token debt is not to rewrite the code but to look at what exactly your tools are passing to the agent. That is why jscpd now has a compact report format for AI pipelines.I have been counting duplicates for years — and now they have one more dimension: a price in tokens. The main thing that changed in my approach is that I stopped taking tool metrics on faith: measure first, trust after. A metric without context is just a number.Two you choose once; one you change with a flagAll three land in the same agent context. Token debt accumulates from several directions at once.In the end, the biggest share of your API budget goes not to your own lines but to the boilerplate fields of somebody else’s report.What Real AI Agent Usage ShowsIndependent confirmation came in May. Researchers at SonarSource built minimal pairs of repositories — identical architecture, dependencies, and external behavior, but different code cleanliness — and ran Claude Code through 660 trials on 33 tasks [9]. The result was twofold: code cleanliness did not affect the agent’s ability to complete tasks, but it did affect the operational cost of its work. On clean code the agent spent 7–8% fewer tokens and returned to files it had already edited 34% less often. The authors deliberately measure tokens, not money: converting to dollars depends on the model, the provider, and the state of the cache — things that are not properties of the code.Adjacent research shows the scale this is counted at: a single task on SWE-bench Verified consumes about 4 million tokens on average, and most of them are input [9]. That is, tokens the agent merely reads.The question of “how to pay less” already has its own literature: models are taught to stop earlier, compress context, call a tool instead of reasoning at length, and carry memory across sessions. The Token Economics for LLM Agents survey pulls these approaches into one system [1] — and all of them work on how the agent spends tokens. But none of them touches the artifact the agent reads: the codebase. That is where token debt lives — the one axis where responsibility lies with the developer, not the platform.Instead of a ConclusionSoftware has a new cost line, measured in tokens. It touches every layer of the stack — from tokenizer design to attention kernels to the choice of programming language. For the first time, code has a price not only when it runs but also when it is read.A metal token, a blockchain record, the raw material of intelligence — over six decades the token has been all three. And each time it was used to keep accounts: first of behavior, then of capital, now of the cost of code. In the coming years we will optimize not only latency, memory footprint, and cloud costs. We will have to learn to count one more resource — the token footprint of our software. And we will have to do it just as carefully for both audiences: humans and agents.Count It YourselfToken economics has the advantage of being verifiable in one evening. tiktoken is OpenAI’s library for counting the tokens of any file. The Tokenizer Playground shows exactly how your code is split into tokens.Start with your own repository: count how many tokens the largest file the agent reads every time takes up. Then count what your linter’s report costs in tokens.References 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 — a measurement series. HackerNoon: Part 1, Part 2 9. Trivedi, P., & Schmitt, O. (2026). Does Code Cleanliness Affect Coding Agents? A Controlled Minimal-Pair Study. SonarSource.