Token Economics in AI: from cost per token to real cost per task

Token Economics in AI is the approach that makes it possible to measure and govern how much it really costs to use artificial intelligence models and agents. 

In agentic systems, understanding the real cost of a task also requires adding the APIs and tools, retries, fallbacks and infrastructure used during execution.

This discipline connects token metering, FinOps for AI, AI Gateways, observability and cost attribution. 

The FinOps Foundation defines Token Economics as the practice of linking token consumption to the cost and value generated by AI. 

Meanwhile, the Tokenomics Foundation, launched by the Linux Foundation on August 4, 2026, is working on open, neutral standards to measure the total cost, value and ROI of AI.

 

What is Token Economics in AI?

Token Economics studies how the token consumption generated by artificial intelligence applications and systems is measured, attributed, governed and linked to business value.

A token is the basic unit models use to process information. Depending on the provider and model, different types of consumption may exist:

• input tokens,
• output tokens,
• cached input tokens,
• reasoning tokens,
• consumption associated with additional tools or capabilities.

But Token Economics goes beyond calculating: number of tokens × price per token.

In a simple application, that calculation may be a fairly good approximation of the cost of an interaction. In an agentic system, it is not.

An agent may use a model to reason, query a vector database, call an external API, query the model again, make several attempts and finally execute an action in a corporate system.

 

Explore all our solutions: Agentic Enterprise Architecture: how to govern autonomous integrations without slowing down autonomy

 

For all these reasons, a mature Token Economics practice should answer two different questions:

• How much AI resource have we consumed?
• What business outcome have we obtained from that consumption, and how much did it cost to produce it?

The FinOps Foundation itself presents Token Economics as an extension of FinOps to a new type of variable consumption: intelligence capacity.

It also warns that a view focused only on tokens leaves out compute, storage, networking, vector databases and other costs involved in an AI workload.

 

Why token cost does not reflect the real cost of an agent

The model bill represents only part of the cost of an agentic workflow.

Imagine a payments company that uses agents to automate the onboarding of new customers.

A single task may follow this sequence: LLM → KYC → scoring → fraud prevention → LLM → core banking

Each layer generates consumption:

The LLM provider knows its tokens. The KYC provider knows its calls. The cloud provider knows CPU, GPU and traffic.

But none of them necessarily knows the cost of completing the onboarding. And there is an effect the bill does not show: accumulated context is resent at every step, so the cost of a workflow grows with the square of the number of steps rather than linearly.

Gartner predicts that inference cost per agentic workflow will increase more than fivefold through 2028 (September 2026), calling it the inference paradox: the price per token falls, but the cost of the task rises because it includes more reasoning, tools and iterations.

The difficulty is already visible. In Harness’s State of AI in FinOps 2026 study (700 engineering leaders across five countries),

• only 20% can identify the source of a cost spike within hours, while 8% never manage to do so,
• 52% said there is no clear owner of AI spend,
• and organizations estimated that approximately 26% of that spend is wasted. 

The problem is that the unit used to measure it does not match the unit that matters to the business.

 

How can advanced quota policies and token metering be configured to map LLM tokens and API calls at task level?

The key is to change the attribution unit.

Instead of measuring only cost by model, API or provider, each execution should have a common identifier that accompanies all operations belonging to the same task.

We can call it: task_run_id

The relationship would be:

Business process

        ↓

Workflow / agent

        ↓

task_run_id

        │

        ├── LLM call

        ├── KYC API

        ├── fraud prevention API

        ├── vector DB query

        ├── retry

        ├── model fallback

        └── core system update

With this identifier, we stop asking: How much have we spent on model X? and can start asking: How much did it cost us to complete task X?

That change may seem small, but it completely transforms the governance model.

task_run_id and trace_id are not exactly the same thing

• A trace_id is designed primarily for technical observability: reconstructing the path of a request across distributed components.
• The task_run_id represents the economic and business unit over which we want to consolidate cost.

They may coincide in certain architectures, but they should not be conceptually confused.

A business process may require several technical traces and still be a single task from an economic perspective.

 

What data should each invocation record?

To reconstruct cost later, each billable event must preserve both technical context and business context.

A minimum schema could include:

For an LLM invocation, we may need:

task_run_id

agent_id

provider

model

input_tokens

cached_input_tokens

reasoning_tokens

output_tokens

pricing_version

This schema makes it possible to build a cost ledger, or economic record, independent of each provider’s console.

The principle is similar to what AWS recommends for request-level granularity: its Application Inference Profiles allow aggregate spend to be attributed by application or workload, but AWS clarifies that cost per request requires additional invocation metadata and logs. Bedrock supports per-request metadata (up to 16 key-value pairs) to propagate the task_run_id, but these appear only in logs: reconciliation with the bill is performed by joining logs and CUR using requestId.

How to calculate the real cost of an agentic task

Once execution is instrumented, the cost can be represented with a simple model:

TASK_COST =

      LLM_COST

    + API_AND_TOOL_COST

    + RETRY_COST

    + FALLBACK_COST

    + DIRECT_INFRASTRUCTURE

    + ALLOCATED_SHARED_COST

In turn:

LLM_COST =

      (input_tokens − cached_read) × input_rate

    + cached_read  × cache_read_rate      (discount)

    + cached_write × cache_write_rate     (surcharge)

    + output_tokens × output_rate         (includes reasoning tokens)

 

Cached tokens are a subset of input, and reasoning tokens are billed as output: adding them separately charges them twice. Not all platforms bill exactly the same categories or in the same way, so the model must be able to adapt to each provider. Batch discounts, committed capacity and volume tiers break the simple price-per-token model and turn part of the cost into period cost.

For this reason, rates should be stored in a versioned pricing table associated with an effective date.

This makes it possible to reconstruct a historical task correctly even when the price, provider, routing, model or consumption mode changes, or when a contractual discount is introduced.

The pricing version forms part of the economic evidence.

 

How to allocate retries and fallbacks

A retry or fallback should not become a new task from an economic perspective.

If a KYC query fails three times before completing, all attempts should remain linked to the same task_run_id.

We can distinguish them using:

execution_type = retry

attempt = 2

parent_event_id = …

The same applies when an agent starts with one model and later uses another as a fallback.

The second model generates a new cost event, but it belongs to the same task.

This distinction makes it possible to calculate especially useful metrics:

• Retry Cost Ratio

retry_cost / total_task_cost

• Fallback Cost Ratio

fallback_cost / total_task_cost

If a workflow starts to systematically increase either of these metrics, the problem may not be the model price.

It may be caused by:

• unreliable prompts,
• timeouts,
• integration with external APIs,
• routing,
• model selection,
• the design of the agent itself.

Here, Token Economics becomes not only a financial discipline but also an architectural diagnostic tool.

 

How to allocate shared costs

Not all costs can be directly associated with a task.

A reserved GPU, an AI Gateway or a vector database may simultaneously serve hundreds of processes without being directly associated with a task. 

The solution is not to ignore them, but to establish an explicit allocation rule.

The order should be:

1. Direct attribution, when consumption can be technically associated with the task_run_id.
2. Allocation by measurable usage, for example time, tokens, queries or capacity used.
3. Documented allocation rule, when no more precise signal exists.

Before allocating costs, it is useful to separate capacity from consumption: a reserved GPU costs the same whether it serves one task or ten thousand, and allocating it by usage makes the same task look more expensive in a quiet month.

For example:

Shared GPU → execution time

Vector DB → number of queries / volume

Gateway → number of operations processed

Storage → stored volume

The rule should include at least: owner + version + criterion + effective date.

Without these four elements, the allocation may vary from one report to another and is no longer defensible to finance leadership.

 

Budget per agent: controlling spend before it happens

Measuring spend after the fact is observability; governing it means deciding before execution whether the next action fits within the available budget.

A policy can combine, at the same time:

• cost,
• tokens,
• API calls,
• steps,
• execution time.

For example:

agent: onboarding-agent

budget:

  max_cost_per_task: 0.60

  currency: EUR

  max_tokens: 150000

  max_api_calls: 25

soft_limit:

  at: 70%

  actions: [alert_owner, forecast_overrun]

degrade:

  at: 85%

  actions: [use_lower_cost_model, reduce_output_budget, disable_optional_tools]

hard_limit:

  at: 100%

  actions:

    – require_approval

    – deny_next_action

This is a vendor-agnostic example.

The policy could use a pre-flight budget reservation model:

actual_spend

+ reservations_for_in_progress_operations

+ estimated_cost_of_next_operation

≤ available_budget

The cost of the next step is reserved against max_tokens, turning it from a technical parameter into an economic control. When the call finishes, the reservation is replaced by actual consumption, and it expires if the call never completes.

This is especially important when several agents execute actions simultaneously. Without reservations, each may see that budget is still available and collectively generate an overrun. The check and the reservation must be a single atomic operation.

 

Soft limit, controlled degradation and hard limit

Not every limit should automatically stop a task. We can distinguish three levels: 

Soft limit

Execution continues, but a signal is generated:

• alert,
• overrun forecast,
• owner notification.

Controlled degradation

Before blocking, the architecture can reduce expected cost:

• use a lower-cost model,
• reduce context,
• reduce output,
• avoid an optional tool,
• make use of cache,
• limit new steps.

Hard limit

The next action is not executed without an explicit exception. It may:

• stop the task,
• require approval,
• cancel a workflow branch.

The decision should be part of company policy rather than scattered across individual agents.

 

Token Economics and AI Gateway: what role does each play?

The AI Gateway can act as a measurement and enforcement point, but Token Economics is a broader model.

An AI Gateway can:

• measure tokens,
• apply rate limits and policies,
• select models,
• log requests.

Token Economics answers a different question: How do we link that consumption to the task, its total cost and the value it generates?

This is why an AI Gateway guide should not be confused with a Token Economics model.

The gateway is one component of the control architecture.

Token Economics defines what we want to measure, how we attribute it and which economic unit we use to evaluate the outcome.

 

Who should govern the AI cost model?

There is no single valid organizational structure. Depending on the organization, responsibility may sit with:

• FinOps,
• Platform Engineering,
• Cloud CoE,
• AI CoE,
• architecture,
• a joint Technology-Finance function.

What matters is that someone has explicit responsibility for:

Without clear ownership, Token Economics risks becoming just another dashboard that no one maintains.

 

From cost per token to cost per task

This is the most important shift.

• For the technical team, it is useful to know: Tokens consumed: 120,000.
• For FinOps: Model cost: €0.18.
• For the CFO: Cost to complete an onboarding: €0.52.

These are three different levels of information. It is the same onboarding: the model represents 35% of the task cost.

The final metric makes it possible to start building real unit economics. Some especially useful indicators would be:

A €0.60 task that generates €20 of value may be economically better than a €0.15 task that produces no useful outcome.

For this reason, Token Economics must connect consumption and value.

The FinOps Foundation itself defines this discipline precisely as the connection between token consumption and business outcomes. 

 

From Token Economics to the ROI of an AI process

When the outcome can be expressed economically, we can move from cost to ROI:

ROI =

(value generated – total process cost)

/

total process cost

The value will depend on the use case:

• incremental revenue,
• reduction in operating cost,
• shorter process time,
• fraud reduction,
• higher conversion,
• lower cost per case.

That figure must come from the business; it should not be invented from technical consumption.

This is why task_run_id is so important: it makes it possible to link a technical execution to a business outcome.

The Tokenomics Foundation is working precisely to promote neutral frameworks and metrics that help link AI spend to its value and economic return.

 

How to avoid vendor lock-in in the cost model

The organization should use each provider’s attribution capabilities, but it should not allow them to be the only place where its economic model exists. The open FOCUS specification exists precisely to normalize cost data across providers.

The pattern would be: provider or cloud → native telemetry → normalization → task_run_id → cost ledger → showback, chargeback and ROI.

This makes it possible to change models, providers, clouds, gateways or partners without losing the method used to calculate how much a task costs.

 

What an organization should be able to answer before scaling its agents

An architecture with Token Economics properly implemented should be able to answer fairly specific questions:

1. How much does it cost to complete each type of task?
2. What percentage belongs to the LLM and what percentage to APIs and infrastructure?
3. How much are we spending on retries and fallbacks?
4. Which agents are exceeding their reference cost per task?
5. Which tasks have the greatest cost variability?
6. How much spend can we not attribute?
7. Can we prevent a new operation before exceeding the budget?
8. What business value does each process generate?

If all we can answer is, “This month we used 400 million tokens,” we are still measuring consumption, not governing the economics of AI.

At Chakray, we help organizations address this challenge through integration architecture, API Management and AI systems governance, connecting model consumption with the APIs, tools and systems that actually execute each process. 

If your organization can already measure tokens but still cannot explain how much an end-to-end task costs, we can help you define the attribution model, instrument the control points and turn that consumption into cost and value metrics that both Technology and Finance can use.

 

Frequently asked questions about Token Economics

What is Token Economics in artificial intelligence?

Token Economics is the discipline that measures, attributes and links the token consumption of AI systems to their cost and the business value generated. 

In agentic architectures, it should also include the APIs, tools, retries and infrastructure involved in execution.

What is the difference between token metering and Token Economics?

Token metering measures how many tokens an application consumes. 

Token Economics uses that data, together with other technical and business costs, to calculate how much it costs to produce an outcome and assess whether that consumption generates enough value.

How is token cost related to the APIs called by an agent?

By propagating a common identifier such as task_run_id across all workflow operations. 

Each LLM call, API call, retry or fallback records its consumption under that identifier, making it possible to reconstruct the total cost of the task later.

How can an agent’s budget be limited?

Through policies that combine maximum cost, tokens, API calls and other limits. 

Before each action, the estimated cost can be reserved and compared with the remaining budget to allow it, degrade it, request approval or block it.

What is cost per completed task?

It is the sum of all the resources required to obtain a business outcome: LLM tokens, tools, downstream APIs, retries, fallbacks, direct infrastructure and the corresponding share of shared costs.

Is Token Economics only useful for reducing costs?

No. Its purpose is to connect cost and value. A more expensive workflow may be a better investment if it produces more revenue, reduces more costs or significantly improves a process. 

The relevant metric is not consuming the fewest possible tokens, but obtaining the best economic outcome per unit of consumption.