Tokenomics

AI has a new currency. It’s time we learned how to spend it.

I recently discovered something interesting about my AI usage.

I’ve consumed approximately 560.1 million tokens.

Yes. Million.

At first, I wasn’t entirely sure what to make of that number.

I knew I used AI extensively. Between coding projects, experimenting with local language models, building applications, researching technology, and working with various AI agents, I’ve become a fairly heavy user.

But 560 million?

That seemed like a lot.

So naturally, I did what any reasonable person would do.

I asked AI how much AI I’d been using.

And the answer was interesting.

Using the common approximation of 0.75 English words per token, 560.1 million tokens would represent approximately 420 million words.

That’s the equivalent of roughly 4,200 to 5,250 full-length novels.

Of course, I haven’t personally written the equivalent of five thousand books. That usage includes prompts, responses, conversation history, code, tool outputs, and potentially other tokens repeatedly processed by models.

But it illustrates something important.

We are entering an era where people can consume hundreds of millions of units of computational language without ever really understanding what they’re consuming.

And increasingly, those units have a price.

I think we need a better way to talk about this.

I’m calling it Tokenomics.

Welcome to Tokenomics

The term tokenomics is already familiar in cryptocurrency, where it describes the economics of digital tokens.

I’m borrowing the word for something different.

AI Tokenomics is the discipline of understanding and optimizing the cost, performance, and useful value of tokens consumed by artificial intelligence systems.

Not simply how many tokens you use.

Not simply how cheaply you can purchase them.

But how effectively those tokens produce something valuable.

Think about it.

We measure computing resources in familiar units.

CPU utilization.

Memory consumption.

Storage capacity.

Network bandwidth.

Electricity usage.

And now, increasingly, tokens.

Tokens are becoming one of the fundamental units of AI consumption.

If you’re building applications with AI, you need to understand them just as you would understand CPU, RAM, or storage when designing traditional infrastructure.

Because tokens aren’t free.

And more importantly, they’re not all equally valuable.

What Exactly Is a Token?

Let’s start with the basics.

A token is a unit of information processed by a language model.

It’s not necessarily a word.

Depending on the model and tokenizer, a token might represent an entire word, part of a word, punctuation, whitespace, or another piece of text.

For example, a common English word might fit into one token.

A longer or unusual word might require several.

Code, JSON, numbers, and non-English languages can behave differently.

The commonly quoted approximation is that one token equals about three-quarters of an English word.

It’s useful for estimating scale.

It’s not a universal conversion formula.

And modern multimodal models complicate things further.

Images, audio, and video can also consume tokens or other metered units, depending on the provider and model.

The important distinction is that tokens represent what the model processes, not simply what appears in your chat window.

That includes information you may never see.

You’re Paying for More Than the Answer

When someone asks an AI model a question, they generally think about two things.

The question.

And the answer.

But the actual transaction can involve considerably more.

First, there are input tokens.

These include your prompt, instructions, conversation history, retrieved documents, code, and tool results.

Then there are output tokens.

These are the tokens generated by the model.

And depending on the model, there may also be reasoning tokens.

Some reasoning models perform additional internal computation before producing their final response.

Those reasoning tokens can count toward usage and billing even though you don’t see the underlying reasoning.

Then there’s cached input.

Some providers offer substantial discounts when a model reuses previously processed prompt content.

And finally, there’s the context window.

This determines how much information a model can consider during an interaction.

All of these influence the economics of an AI application.

And this is where things become interesting.

Because the answer you receive might be only a small fraction of the total work the model performed.

My 560 Million Token Experiment

Let’s return to my usage.

560.1 million tokens.

What would that cost if I purchased the same volume through an API?

It depends enormously on the model.

Illustrative blended price	Cost for 560.1M tokens
$0.30 per million	$168
$1 per million	$560
$5 per million	$2,801
$15 per million	$8,402
$30 per million	$16,803

These are hypothetical blended rates, not quotations for any particular provider.

Actual billing depends on input versus output, caching, reasoning, model selection, and other factors.

My lifetime token count doesn’t tell us exactly how much I paid—or how much equivalent API usage would have cost.

But it shows how dramatically model economics can change the equation.

The same number of tokens might represent a few hundred dollars or many thousands.

And here’s the uncomfortable part.

A token count doesn’t tell me whether any of those tokens were well spent.

That’s the question I think we should be asking.

The Cheapest Token Isn’t Always the Cheapest Answer

Recently, I’ve been experimenting with a different approach to AI-assisted development.

Instead of relying entirely on premium cloud models for every coding task, I’ve been exploring local language models to handle more routine work.

The idea is straightforward.

Let a smaller or locally hosted model do the initial implementation.

Then use a more capable cloud model to review the work, identify problems, and make corrections.

In theory, this should reduce expensive cloud usage.

And sometimes it does.

But I quickly realized something.

A cheap model can become expensive if it keeps making mistakes.

Imagine Model A costs $0.50 to complete a task.

Model B costs $2.

At first glance, Model A looks like the obvious choice.

But what happens if Model A fails repeatedly?

Maybe it misunderstands the requirements.

Maybe it introduces bugs.

Maybe it modifies files it shouldn’t touch.

Maybe it produces code that technically runs but doesn’t actually solve the problem.

Now you need another attempt.

And another.

Then you spend twenty minutes figuring out what went wrong.

Eventually you ask the premium model to fix everything anyway.

Congratulations.

You saved $1.50 on the first attempt and spent considerably more getting the job done.

This is why I think the most important metric in Tokenomics isn’t cost per million tokens.

It’s cost per successful outcome.

The Metric That Actually Matters

Let’s define it.

Effective cost per successful outcome = Total AI inference cost + infrastructure cost + human correction cost, divided by successful outcomes.

For API-based applications, the inference cost includes the input, output, reasoning, and other billable usage across all attempts.

For local models, it may include electricity, hardware depreciation, hosting, and the time spent maintaining the system.

For agent workflows, it includes retries, failed tool calls, unnecessary loops, and duplicated work.

And then there’s human time.

Which is often the most expensive part.

If I spend an additional hour fixing something a cheaper model generated, did I really save money?

Maybe.

But probably not if my time is worth more than the API cost I avoided.

This is the difference between optimizing token prices and optimizing Tokenomics.

Cheap tokens are not necessarily efficient tokens.

AI Agents Are Where Token Consumption Gets Interesting

A normal AI conversation is relatively straightforward.

You ask a question.

The model responds.

But an AI agent is different.

It may read files.

Search documentation.

Execute commands.

Inspect results.

Modify code.

Run tests.

Encounter an error.

Read the error.

Try again.

Every one of those steps can require another model interaction.

And depending on the architecture, each interaction may include a growing amount of previous context.

Let’s say an agent starts with 10,000 tokens of context.

It performs an action and adds 5,000 tokens of results.

The next request may contain 15,000 tokens.

Then 20,000.

Then 25,000.

If the application repeatedly resends the full conversation, token consumption can grow much faster than the number of steps suggests.

That’s before the agent starts making mistakes.

I’ve seen AI coding workflows where an agent spends an enormous amount of effort reading files, generating explanations, re-reading files, and explaining what it plans to do.

Meanwhile, the actual task might require changing fifteen lines of code.

At some point, you have to ask:

Are we paying for useful work?

Or are we paying for the model to talk about doing useful work?

Context Is Not Free

One of the biggest misconceptions about AI is that more context is always better.

It isn’t.

Models need enough information to understand the task.

But giving a model an entire repository when it only needs three files isn’t necessarily helpful.

You’re paying to process information that may be irrelevant.

You’re also introducing noise.

The model has more opportunities to focus on the wrong details.

And even when a model technically supports a massive context window, that doesn’t mean every token inside that window receives equal practical attention.

Context-window capacity and effective reasoning quality are different things.

Think of it like hiring an engineer to fix a network problem.

You could give them the relevant topology, configuration, and error logs.

Or you could hand them every network configuration your company has ever produced.

The second option contains more information.

It isn’t necessarily more useful.

This is why retrieval, summarization, and context management matter.

Give the model what it needs.

Not everything you happen to have.

Stop Using a Ferrari to Deliver Pizza

Another major principle of Tokenomics is model selection.

Not every task needs the most expensive model available.

If I need an AI to classify a support ticket, extract an invoice number, format a response, or identify a product category, I probably don’t need the most sophisticated reasoning model on the market.

A smaller model may handle that work perfectly well.

Save the premium model for problems that actually require its capabilities.

Complex architecture.

Difficult debugging.

Ambiguous requirements.

Multi-step reasoning.

High-consequence decisions.

This is where model routing becomes valuable.

Instead of sending every request to one model, an application can select models based on task complexity.

Simple task?

Small model.

Complex task?

More capable model.

Uncertain result?

Escalate.

And here’s the important part.

The router itself must be reliable.

If it sends difficult tasks to weak models and creates endless retries, you’ve simply moved the inefficiency somewhere else.

The goal isn’t to use the smallest model possible.

It’s to use the least expensive model that reliably produces an acceptable result.

Cache What Doesn’t Change

Here’s another optimization that developers should pay more attention to.

Prompt caching.

Imagine you’re building an application that repeatedly sends the same system instructions, documentation, and reference material to a model.

Maybe the first 20,000 tokens are identical across hundreds of requests.

Without caching, you may repeatedly pay to process that same information at normal input rates.

With provider-supported prompt caching, reusable content can often be processed at a discounted rate.

The exact mechanism and discount depend on the provider.

But the principle is simple.

Don’t repeatedly pay full price for work the system can reuse.

This also changes how prompts should be structured.

Stable instructions and reference materials should generally appear before changing user-specific content when the provider’s caching implementation benefits from shared prefixes.

That’s not merely a prompt-writing preference.

It’s an architectural cost decision.

Output Tokens Are Expensive Too

We tend to focus on input tokens because large context windows look intimidating.

But output tokens often cost more per token than input.

And reasoning tokens can make the calculation more complicated.

This means a model that generates three pages of explanation when you only needed a JSON object may be wasting money.

For a human conversation, detailed explanations can be useful.

For an automated workflow, they can be unnecessary overhead.

If another application needs five fields, ask for five fields.

If a coding agent needs to modify a function, it may not need to rewrite an entire file.

If a system needs a classification, it probably doesn’t need a philosophical essay explaining the classification.

Constrain the output to the useful deliverable.

But don’t take that too far.

Sometimes a detailed explanation prevents a costly misunderstanding.

Again, Tokenomics isn’t about minimizing tokens at all costs.

It’s about understanding which tokens create value.

Reasoning Is a Resource

Modern reasoning models introduce another interesting consideration.

Thinking takes computation.

Some models expose settings that let developers adjust reasoning effort.

For a difficult engineering problem, additional reasoning can improve the result.

For a simple formatting task, it may accomplish very little.

I encountered this while experimenting with local reasoning models.

A model could consume its entire generation budget on internal reasoning and produce no useful final answer.

Technically, the model was working.

Practically, I received nothing.

That taught me something important.

A model’s token budget needs to match the task.

Too little reasoning and you risk poor answers.

Too much reasoning and you waste resources.

And if the output limit is too restrictive, the model may never finish.

This is another reason token caps shouldn’t be confused with context windows.

One determines how much information can be considered.

Another constrains how much the model can generate.

They’re related, but they aren’t interchangeable.

The Hidden Cost of Bad Prompts

There’s a tendency to treat prompt engineering as a creative skill.

I think it should also be treated as an efficiency discipline.

A vague prompt can produce a vague result.

Then you clarify.

Then you correct.

Then you explain what you meant.

Then the model tries again.

Every round consumes additional tokens.

Sometimes a little more effort up front saves several expensive iterations later.

This doesn’t mean every prompt needs to be enormous.

In fact, unnecessarily complicated prompts can create their own problems.

But clear requirements matter.

Define the objective.

Provide relevant context.

Specify constraints.

Explain what success looks like.

For coding agents, that might mean identifying the files they should modify, the tests they should run, and the behavior that must remain unchanged.

A well-defined task can be far cheaper than an open-ended instruction to “figure everything out.”

The Local AI Trade-Off

Now let’s talk about local AI.

Because this is something I’ve been exploring personally.

Running a model on your own hardware can reduce or eliminate per-token API charges.

That sounds attractive when you’re consuming hundreds of millions of tokens.

But local AI isn’t free.

You need hardware.

GPUs.

Memory.

Electricity.

Cooling.

Storage.

And time.

You also need to consider throughput.

A model that generates tokens slowly may save API fees while costing you productivity.

If a cloud model finishes a task in two minutes and your local model takes twenty, the economics depend on what you’re doing.

For unattended batch processing, twenty minutes might be perfectly acceptable.

For interactive development, it could be frustrating.

And local models vary significantly in quality.

A smaller model may be excellent at routine coding tasks but struggle with complex architectural decisions.

That’s why I find hybrid workflows interesting.

Use local compute for the work it handles well.

Use cloud models where their capabilities justify the cost.

And evaluate the total workflow, not just the token bill.

The best AI infrastructure is not necessarily entirely local or entirely cloud.

Sometimes it’s a combination of both.

When Efficiency Becomes False Economy

There’s another side to this conversation.

You can optimize too aggressively.

Imagine an application that sends a tiny prompt to a cheap model with almost no context.

It returns an answer quickly.

The token bill looks fantastic.

Unfortunately, the answer is wrong.

Now your application makes a bad decision.

Or your customer receives incorrect information.

Or your coding agent introduces a security vulnerability.

Suddenly those token savings don’t look very impressive.

This is especially important for business applications.

An AI system that saves $100 in inference costs but creates $10,000 in operational problems is not efficient.

It’s poorly designed.

Quality matters.

Reliability matters.

Security matters.

Human oversight matters.

And sometimes the correct decision is to spend more tokens.

Not fewer.

The goal is to eliminate waste, not intelligence.

Businesses Need Token Budgets

As AI becomes integrated into business applications, I think token consumption needs to become a normal operational metric.

Just like cloud compute.

Just like storage.

Just like bandwidth.

Companies should know how many tokens their applications consume.

Which features consume the most.

Which users generate the most expensive workloads.

Which models produce the best results.

Which agent workflows require repeated attempts.

And which activities actually justify their costs.

Imagine a customer support application.

One workflow uses 5,000 tokens and resolves the customer’s issue.

Another uses 50,000 tokens, invokes six tools, retries three times, and still escalates to a human.

Which workflow is more efficient?

The answer seems obvious.

But without proper monitoring, businesses may only see a growing AI bill.

They won’t necessarily understand why it’s growing.

That’s where Tokenomics becomes an operational discipline.

Not just a pricing discussion.

Tokens Are Becoming the New Cloud Bill

There’s a parallel here with the early days of cloud computing.

When companies first moved workloads to AWS and Azure, the promise was simple.

Stop buying servers.

Pay for what you use.

And for many workloads, that was transformative.

But eventually organizations discovered that usage-based pricing requires discipline.

Idle virtual machines.

Oversized databases.

Unnecessary storage.

Excessive data transfer.

Poorly designed architectures.

All of it could produce enormous bills.

That’s why FinOps became important.

Organizations needed to understand cloud spending and connect it to business value.

I think AI is entering a similar phase.

Except the unit of consumption isn’t primarily vCPU-hours or gigabytes.

It’s tokens.

And those tokens can multiply rapidly when applications begin using autonomous agents.

We may eventually see token budgets, token efficiency metrics, and AI cost optimization become as routine as cloud infrastructure monitoring.

Some companies are already doing versions of this.

But I suspect many developers are still in the phase where they build first and look at the bill later.

I understand.

I’ve been there.

The Tokenomics Framework

If I were designing an AI application today, I’d approach token efficiency around five principles.

Match. Choose the model and reasoning effort appropriate for the task.

Minimize. Provide the relevant context without flooding the model with unnecessary information.

Cache. Reuse stable instructions and data wherever the provider supports it.

Constrain. Generate the output the application actually needs.

Measure. Track total cost per successful outcome, not simply tokens consumed.

And I would add one more.

Validate.

Because preventing a bad result is often cheaper than repairing one.

For coding agents, run tests.

For structured data, validate schemas.

For critical workflows, verify results before allowing an agent to take consequential actions.

Every unnecessary retry consumes resources.

But an undetected failure can cost considerably more.

560 Million Tokens Later

Looking back at my own usage, 560.1 million tokens is a fascinating number.

It’s a reminder of how much AI has become part of my workflow.

But it’s also a reminder that consumption and productivity aren’t the same thing.

Some of those tokens helped me build applications.

Some helped me learn unfamiliar technologies.

Some assisted with debugging.

Some saved me hours of research.

And I’m sure some were wasted.

On unnecessary explanations.

Failed attempts.

Repeated context.

Agent loops.

And models doing work that a smaller model could probably have handled just as well.

The next time I look at my AI usage, I don’t necessarily want to see a smaller number.

I want to see a more meaningful one.

How much useful work did those tokens accomplish?

How many problems did they solve?

How much time did they save?

How much did the successful outcomes actually cost?

Because 560 million tokens might be an impressive consumption statistic.

But it isn’t a productivity metric.

Welcome to the Economics of Intelligence

I think the technology industry is approaching an important transition.

For years, we measured the value of software by what it could do.

Then cloud computing taught us to measure what it cost to operate.

Now AI is forcing us to combine those questions.

How intelligent does a system need to be?

How much reasoning is enough?

How much context is useful?

When is a premium model justified?

When should work move to a smaller model?

And when does reducing cost actually make the system worse?

These aren’t just technical questions.

They’re economic ones.

AI providers will continue competing on model capability, speed, context windows, and price.

Developers will continue building increasingly sophisticated agents.

Businesses will continue integrating AI into everyday operations.

And token consumption will continue growing.

But the winners won’t necessarily be the companies consuming the most tokens.

Or the developers buying the cheapest ones.

They’ll be the ones who understand how to turn those tokens into useful outcomes.

That’s Tokenomics.

Not how many tokens you can afford to spend.

How much value you can create with the ones you do.