Dashboard illustrating organizational, repository, developer, agent, and outcome economics for GitHub Copilot

Tokenomics for AI Development: From AI Spend to Business Value

AI-assisted software development is becoming a standard part of how engineering teams work.

Developers use AI to write code, generate tests, explain unfamiliar systems, review pull requests, investigate bugs, and automate repetitive tasks. Agents can now go further by searching repositories, editing files, running tests, and iterating on their own changes.

That creates a new question for technology leaders:

Are we actually getting value from our AI investment?

It is tempting to answer that question by looking at a few simple metrics:

Those metrics are useful, but they are not enough.

A high prompt count does not necessarily mean high productivity. A low prompt count does not necessarily mean low value. More generated code can even create more review and maintenance work.

To understand the real economics of AI-assisted development, we need to connect four separate layers:

  1. Organizational economics
  2. Repository economics
  3. Developer and agent economics
  4. Outcome economics

The goal is to connect these layers into one end-to-end view of AI value.

The main question becomes:

Are customers getting value from their AI investment, from billing and repository design through to developer behavior and business outcomes?

What does "tokenomics" mean here?

In this article, tokenomics does not mean cryptocurrency economics.

Here, tokenomics means the study of how AI resources are consumed and converted into useful engineering work.

That includes:

A useful high-level formula is:

AI value = business outcome value - total AI cost

The total cost is broader than the subscription price:

Total AI cost =
    subscription cost
  + runtime consumption cost
  + platform and operational cost
  + review and correction cost
  + quality and risk cost

That last category matters.

If an AI-generated change creates extra bugs, security reviews, or maintenance work, those costs are part of the economic picture too.

The four-layer framework

The framework is easier to understand as a flow:

Organizational investment
          |
          v
Repository configuration
          |
          v
Developer and agent behavior
          |
          v
Engineering and business outcomes

Each layer answers a different question.

Layer Question
Organizational economics What are we buying, and where is the money going?
Repository economics What have we configured or built to support AI-assisted development?
Developer and agent economics How are people and agents using AI at runtime?
Outcome economics What measurable value is being created?

The important part is not just measuring each layer separately.

The important part is joining them together.

For example:

Organization spending
    -> Repository configuration
        -> Developer and agent usage
            -> Pull request behavior
                -> Business outcomes

Without those connections, we end up with a collection of dashboards that report activity but do not explain value.

Layer one: Organizational economics

Measuring the investment

The first layer starts with the customer’s investment.

At this level, we want to understand:

This is the financial baseline.

A basic seat utilization formula looks like this:

Seat utilization =
    active assigned seats
    ---------------------
    purchased seats

In Python:

from dataclasses import dataclass
from datetime import date
from decimal import Decimal


@dataclass
class OrganizationSpend:
    """Stores AI investment and usage for one billing period."""

    organization_id: str
    billing_period: date
    purchased_seats: int
    assigned_seats: int
    active_seats: int
    subscription_cost: Decimal
    estimated_runtime_cost: Decimal

    @property
    def total_cost(self) -> Decimal:
        """Return subscription cost plus estimated runtime cost."""
        return self.subscription_cost + self.estimated_runtime_cost

    @property
    def seat_utilization(self) -> Decimal:
        """Return active seats as a percentage of purchased seats."""
        # Avoid division by zero for organizations with no purchased seats.
        if self.purchased_seats == 0:
            return Decimal("0")

        return (
            Decimal(self.active_seats)
            / Decimal(self.purchased_seats)
            * Decimal("100")
        )

What this code is doing

This model separates two types of cost:

That distinction is useful because the subscription may be relatively fixed, while runtime usage can vary depending on prompts, models, context size, and agent activity.

The example uses Decimal instead of float because this is financial data. Binary floating-point values can introduce small rounding errors that become awkward when aggregated across thousands of transactions.

An interesting detail

High seat utilization is not the same as high economic value.

An organization may have 95 percent active seats, but if developers are not completing work faster or producing better outcomes, the investment may still need attention.

Adoption is a prerequisite for value. It is not proof of value.

Cost allocation

Organizational economics becomes more useful when costs can be allocated to meaningful dimensions:

A simplified cost model might look like this:

Team AI cost =
    allocated subscription cost
  + estimated runtime cost
  + platform allocation

Estimated runtime cost could be calculated as:

Runtime cost =
    input tokens * input token price
  + output tokens * output token price
  + agent actions * agent action price

In mathematical form:

\[ \text{Runtime Cost} = \sum_{i=1}^{n} \left( T_i \times C_T + O_i \times C_O + A_i \times C_A \right) \]

Where:

The actual pricing model will depend on the product and contract, so prices should be stored separately from usage records.

That way, the organization can update pricing without rewriting historical usage data.

Layer two: Repository economics

Repositories are economic assets

The repository layer focuses on what has been built and configured around AI-assisted development.

This is more of a static view than a runtime view.

It can include:

These assets represent investment.

A repository with clear instructions, reusable prompts, strong tests, and carefully designed agents may produce more reliable AI output than a repository with no guidance.

The repository layer asks:

What have we built to make AI usage more effective, consistent, and safe?

Static configuration versus runtime usage

A repository scan can tell us that a security-review agent exists.

It cannot tell us whether developers actually use it or whether it improves outcomes.

That distinction is important:

Static presence:
The repository contains a security-review agent.

Runtime behavior:
Developers invoke the agent during pull request preparation.

Outcome:
The agent helps identify security issues without increasing review time.

Each statement belongs to a different layer.

A repository inventory might look like this:

Repository Asset type Asset name Complexity Last modified Owner
payments-api Agent security-reviewer High 2026-07-28 Platform
web-client Prompt test-generator Medium 2026-07-30 Web
data-pipeline Instructions coding-standards High 2026-08-01 Data

Repository maturity

Organizations may want a way to compare repository readiness.

One possible maturity score is:

\[ \text{Repository Maturity} = w_1I + w_2A + w_3P + w_4T + w_5S \]

Where:

Here is a simple implementation:

from dataclasses import dataclass


@dataclass
class RepositoryMaturity:
    """Stores normalized repository readiness scores from zero to one."""

    instructions: float
    agents: float
    prompts: float
    testing: float
    security: float

    def score(self) -> float:
        """
        Calculate a weighted repository maturity score.

        The values should already be normalized between zero and one.
        """
        # These weights are examples and should be adjusted to match
        # the organization's priorities.
        weights = {
            "instructions": 0.25,
            "agents": 0.20,
            "prompts": 0.15,
            "testing": 0.25,
            "security": 0.15,
        }

        values = {
            "instructions": self.instructions,
            "agents": self.agents,
            "prompts": self.prompts,
            "testing": self.testing,
            "security": self.security,
        }

        # Multiply each score by its weight and add the results together.
        return sum(values[key] * weights[key] for key in weights)

What this code is doing

The score is normalized between zero and one, which makes it easier to compare repositories of different sizes.

The weights are also explicit. That matters because different organizations will have different priorities.

For example:

An interesting detail

Repository configuration often acts as a multiplier.

A good instruction file may influence thousands of future interactions. That means the economic value of the file may not appear in a single prompt or pull request.

Beware of maturity theater

Static assets can create the appearance of maturity.

A repository might contain:

That is why repository maturity should eventually be joined to runtime and outcome data.

A more complete formula could be:

Effective repository value =
    repository maturity
  * runtime adoption
  * outcome correlation

If any one of those factors is close to zero, the effective value is limited.

Layer three: Developer and agent economics

Measuring real usage

The developer and agent layer measures what happens while work is actually being performed.

Useful signals include:

This is the layer most people think of when they hear "AI usage analytics."

It is also where many measurement mistakes happen.

Token volume is not productivity

A token is a unit of model processing.

It is not a unit of business value.

High token consumption may indicate:

Low token consumption may indicate:

So token counts need context.

A useful metric is productive interaction rate:

Productive interaction rate =
    interactions producing accepted output
    --------------------------------------
    total interactions

"Accepted output" needs a clear definition.

It might mean:

Prompt efficiency

Prompt efficiency estimates how much useful progress is created from a given amount of AI consumption.

One possible formula is:

\[ \text{Prompt Efficiency} = \frac{\text{Accepted Changes}} {\text{Input Tokens} + \alpha \times \text{Output Tokens}} \]

The coefficient \(\alpha\) represents the relative importance or cost of output tokens.

A simpler operational metric might be:

Change efficiency =
    accepted changes
    ----------------
    prompt count

Lines of code can also be used, but they are a weak proxy.

Ten lines that fix a serious production issue may be more valuable than one thousand generated lines that are never merged.

Better denominators include:

Agent economics

Agents add another level of complexity.

A typical agent task may look like this:

1. Read repository files
2. Search for relevant code
3. Call tools
4. Modify files
5. Run tests
6. Inspect failures
7. Retry changes
8. Produce a final patch

The cost of the task is therefore more than the prompt and completion.

A simplified model is:

Agent task cost =
    model token cost
  + tool invocation cost
  + compute cost
  + human review cost

Human review cost is particularly important.

An agent that creates a patch quickly but requires a long review may not create net value.

A practical formula is:

\[ \text{Agent Net Benefit} = \text{Estimated Developer Time Saved} - \text{Review Time} - \text{Correction Time} - \text{Runtime Cost} \]

Detecting inefficient interactions

A tokenomics system should be able to identify patterns such as:

Here is a simple aggregation example:

from collections import defaultdict
from dataclasses import dataclass


@dataclass
class Interaction:
    """Represents one AI interaction during a development task."""

    developer_id: str
    repository_id: str
    input_tokens: int
    output_tokens: int
    accepted: bool
    duration_seconds: int


def summarize_interactions(
    interactions: list[Interaction],
) -> dict[str, dict[str, float]]:
    """
    Aggregate interaction metrics by developer.

    The results can later be joined with billing, repository,
    pull request, and outcome data.
    """
    summary = defaultdict(
        lambda: {
            "interactions": 0,
            "accepted_interactions": 0,
            "input_tokens": 0,
            "output_tokens": 0,
            "duration_seconds": 0,
        }
    )

    for interaction in interactions:
        # Retrieve the running totals for the current developer.
        metrics = summary[interaction.developer_id]

        # Add the current interaction to the developer's totals.
        metrics["interactions"] += 1
        metrics["accepted_interactions"] += int(interaction.accepted)
        metrics["input_tokens"] += interaction.input_tokens
        metrics["output_tokens"] += interaction.output_tokens
        metrics["duration_seconds"] += interaction.duration_seconds

    for metrics in summary.values():
        # Use the interaction count as the denominator for rate metrics.
        total = metrics["interactions"]

        metrics["acceptance_rate"] = (
            metrics["accepted_interactions"] / total if total else 0.0
        )

        metrics["tokens_per_interaction"] = (
            (metrics["input_tokens"] + metrics["output_tokens"]) / total
            if total
            else 0.0
        )

    return dict(summary)

What this code is doing

This function calculates both usage intensity and acceptance rate.

That combination is more useful than token volume by itself.

For production use, the output should be stored with additional dimensions such as:

An interesting detail

A developer with a low acceptance rate is not necessarily less productive.

They may be using AI for exploration, architecture, debugging, or learning. In those situations, rejecting several suggestions may be completely normal.

Metrics should always be interpreted within the context of the task.

Layer four: Outcome economics

Connecting AI usage to value

Outcome economics is the most important layer and probably the hardest one to get right.

This layer asks whether AI-assisted development changes meaningful engineering or business results.

Potential outcome metrics include:

The key word is meaningful.

A high number of prompts is an activity metric. A shorter pull request cycle time is much closer to an outcome.

Cohort analysis

Cohorts help us compare similar groups over time.

Possible cohorts include:

A simple before-and-after calculation is:

Change in pull request cycle time =
    post-adoption cycle time
  - pre-adoption cycle time

This is useful, but it is not enough on its own.

The team may have improved because:

A stronger approach is difference-in-differences:

\[ \text{Estimated AI Effect} = (\text{Treated}_{post} - \text{Treated}_{pre}) - (\text{Control}_{post} - \text{Control}_{pre}) \]

In plain English:

  1. Measure the change for the team that adopted AI.
  2. Measure the change for a similar team that did not.
  3. Subtract the control group's change from the treated group's change.

This does not prove causation, but it gives us a better estimate.

Outcome attribution is probabilistic

It is rarely possible to prove that one AI interaction directly caused a business result.

Instead, we should estimate contribution using multiple variables:

\[ P(\text{Outcome Improved} \mid \text{AI Adoption}, \text{Repository Maturity}, \text{Task Type}, \text{Team}, \text{Time}) \]

This is a conditional relationship.

It is not a guarantee.

A responsible analysis should explain:

A practical outcome score

Some organizations may want a summary score.

One example is:

\[ \text{Outcome Score} = w_1V + w_2C + w_3Q + w_4D + w_5A \]

Where:

Here is a simple implementation:

def outcome_score(
    velocity_change: float,
    cycle_time_change: float,
    quality_change: float,
    developer_experience_change: float,
    adoption_change: float,
) -> float:
    """
    Calculate a balanced outcome score.

    Each input should be normalized to the same scale, such as
    -1.0 for significant decline and 1.0 for significant improvement.
    """
    # These weights are examples. Organizations should tune them
    # according to their own goals and risk tolerance.
    weights = {
        "velocity": 0.25,
        "cycle_time": 0.25,
        "quality": 0.25,
        "developer_experience": 0.15,
        "adoption": 0.10,
    }

    values = {
        "velocity": velocity_change,
        "cycle_time": cycle_time_change,
        "quality": quality_change,
        "developer_experience": developer_experience_change,
        "adoption": adoption_change,
    }

    # Combine the normalized metrics into one transparent summary score.
    return sum(values[name] * weights[name] for name in weights)

What this code is doing

The function assumes all inputs have already been normalized to the same scale.

That is necessary because the original metrics probably use different units:

Normalization also needs to account for direction.

A reduction in cycle time is usually positive. An increase in escaped defects is negative.

An important warning

A composite score should not hide individual metrics.

For example, a large increase in velocity should not be allowed to mask a serious increase in defects.

Quality and security should be treated as guardrails.

Connecting all four layers

The real value of the framework comes from joining the layers together.

A simplified data model might look like this:

organizations
  organization_id
  billing_period
  subscription_cost
  purchased_seats
  assigned_seats
  active_seats

repositories
  repository_id
  organization_id
  repository_maturity_score
  instruction_count
  agent_count
  prompt_count

interactions
  interaction_id
  developer_id
  repository_id
  model_id
  input_tokens
  output_tokens
  accepted
  timestamp

pull_requests
  pull_request_id
  repository_id
  author_id
  created_at
  merged_at
  review_duration
  changed_files
  defect_followup

outcomes
  organization_id
  team_id
  period
  adoption_rate
  cycle_time
  deployment_frequency
  defect_rate
  developer_experience_score

The relationships might look like this:

Organization
    |
    +-- Repositories
            |
            +-- Interactions
            |       |
            |       +-- Developers
            |
            +-- Pull requests
                    |
                    +-- Outcomes

With those relationships in place, we can ask better questions:

These are much more useful questions than simply asking how many prompts were sent.

A reference tokenomics pipeline

1. Ingestion

The pipeline can collect data from:

Each source has different timing and reliability characteristics.

For example:

The data model should preserve two timestamps:

That distinction is important when events arrive late.

2. Normalization

Raw events should be converted into a canonical schema.

from dataclasses import dataclass
from datetime import datetime


@dataclass
class CanonicalInteraction:
    """Normalized interaction record for downstream analytics."""

    interaction_id: str
    organization_id: str
    repository_id: str
    developer_id: str
    model_id: str
    input_tokens: int
    output_tokens: int
    accepted: bool
    started_at: datetime
    completed_at: datetime
    source_system: str

    @property
    def duration_seconds(self) -> float:
        """Return the interaction duration in seconds."""
        # Datetime subtraction produces a duration object.
        return (self.completed_at - self.started_at).total_seconds()

What this code is doing

A canonical model gives every downstream system the same vocabulary.

Without one, different teams may define the same metric in different ways.

For example, one system might define an active developer as someone who sent one prompt in a month. Another might require five interactions in a week.

Both calculations could be technically correct while still producing incompatible dashboards.

An interesting detail

Many analytics disagreements are caused by semantic drift rather than arithmetic mistakes.

The number may be calculated correctly, but the definition behind the number has changed.

Metric definitions should therefore be documented, versioned, and reviewed.

3. Feature engineering

Useful derived features include:

Definitions should be versioned.

Changing the definition of "accepted output" can invalidate comparisons with previous periods.

4. Aggregation

A typical analytics hierarchy looks like this:

Interaction
    -> Developer
        -> Repository
            -> Team
                -> Organization
                    -> Enterprise

Every aggregation should preserve enough detail for drill-down.

Business leaders may want organizational ROI. Engineering enablement teams may need to inspect the exact repositories and agents associated with that result.

Both views should come from the same underlying data.

5. Serving

The resulting metrics could be served through:

The architecture should separate:

  1. Raw events
  2. Cleaned events
  3. Derived facts
  4. Metric definitions
  5. Dashboard views

This separation makes debugging much easier.

Data quality and privacy

Data quality risks

Tokenomics systems are exposed to several common data quality problems:

A reliable system should include:

Privacy boundaries

Developer analytics need careful governance.

The goal should be to measure economic behavior without turning the system into unnecessary surveillance.

Good principles include:

The safest default is to use the smallest identity level required for the question.

For example:

Common analytical mistakes

Mistake one: Treating adoption as ROI

Adoption means people are using the system.

It does not prove that they are faster, more effective, or producing better outcomes.

Mistake two: Optimizing for token volume

Token volume can increase because of productive complex work or unproductive retries.

The objective should be useful outcomes, not maximum consumption.

Mistake three: Counting generated lines of code

Generated lines are easy to count, but they are weakly connected to value.

Code that is never merged or maintained should not be treated as economic output.

Mistake four: Ignoring repository context

Two developers may send the same number of prompts.

One may work in a mature repository with reliable tests and reusable agents. The other may work in an unstructured codebase with poor documentation.

Their usage is not economically equivalent.

Mistake five: Ignoring quality

Faster delivery with more defects may reduce value rather than increase it.

Quality metrics should be treated as guardrails.

Mistake six: Confusing correlation with causation

A team may improve after adopting AI because it also received:

Attribution requires controls, experiments, or carefully designed longitudinal analysis.

Mistake seven: Building dashboards before defining metrics

A beautiful dashboard with ambiguous metric definitions creates false confidence.

Definitions should come before visualization.

A practical value model

A complete tokenomics model can estimate value at several levels.

Organization-level value

\[ \text{Organization ROI} = \frac{ \text{Estimated Business Value} - \text{Total AI Cost} }{ \text{Total AI Cost} } \]

Estimated business value may include:

The important part is to document how each estimate was created.

Repository-level value

\[ \text{Repository Efficiency} = \frac{ \text{Merged Delivery Value} }{ \text{Subscription Allocation} + \text{Runtime Cost} + \text{Review Cost} } \]

Repository output is affected by team size, project scope, and work complexity, so this metric should be used for comparison carefully.

Interaction-level value

\[ \text{Interaction Value} = \text{Estimated Time Saved} - \text{Correction Time} - \text{Runtime Cost} \]

Interaction-level estimates are noisy.

They become more useful when aggregated across similar task categories, such as:

Outcome-level value

For metrics where lower is better, such as cycle time:

\[ \text{Outcome Improvement} = \text{Baseline Cycle Time} - \text{Observed Cycle Time} \]

For metrics where higher is better, such as deployment frequency:

\[ \text{Outcome Improvement} = \text{Observed Deployment Frequency} - \text{Baseline Deployment Frequency} \]

Every calculation should state:

Using a pilot to validate the framework

This type of initiative is a natural candidate for a focused pilot before a broader rollout.

The pilot should not try to measure everything.

Its purpose should be to test whether the four layers can be connected reliably and whether the resulting analysis is useful to customers and internal teams.

Recommended pilot questions

A pilot could answer:

  1. Can billing data be joined to repositories?
  2. Can repository assets be scanned consistently?
  3. Can runtime interactions be attributed to teams and repositories?
  4. Can pull request and adoption metrics be connected to usage?
  5. Can the system calculate cost per active developer?
  6. Can it identify high-usage, low-outcome segments?
  7. Can it identify repositories where configuration improves runtime efficiency?
  8. Can customers understand the results?
  9. Can teams act on the recommendations?

Choosing pilot participants

A representative pilot should include:

If the pilot includes only highly mature teams, the results may be too optimistic.

Pilot success criteria

Success should be measured across three dimensions.

Technical success

Analytical success

Customer success

From reporting to recommendations

A tokenomics system should not stop at reporting.

It should help teams decide what to do next.

Billing recommendations

Repository recommendations

Runtime recommendations

Outcome recommendations

Every recommendation should include:

For example:

{
  "recommendation_type": "repository_configuration",
  "repository_id": "payments-api",
  "recommendation": "Add standardized security-review instructions",
  "evidence": {
    "repository_maturity": 0.31,
    "security_agent_usage": 0.04,
    "defect_followup_rate": 0.12
  },
  "expected_benefit": "Improve consistency of security-focused review tasks",
  "confidence": 0.68,
  "measurement_plan": "Compare security-related pull request findings over two release cycles"
}

What this example is doing

The recommendation is not just a sentence.

It contains:

That last part is essential.

A recommendation without a measurement plan is just an opinion with better formatting.

Why connecting all four layers matters

The four-layer model changes the conversation from:

How much are developers using AI?

to:

How does organizational investment become measurable engineering and business value?

That is a much more useful question.

The organizational layer explains allocation.

The repository layer explains enablement.

The developer and agent layer explains behavior.

The outcome layer explains impact.

Individually, each layer is incomplete.

Together, they create an investigation path:

Investment:
Are we allocating resources effectively?

Configuration:
Have we created the right repository assets?

Behavior:
Are developers and agents using those assets productively?

Outcomes:
Is the organization delivering better results?

This also creates a shared language across different teams.

Finance can understand allocation and cost.

Engineering can understand runtime behavior and repository practices.

Developer experience teams can understand adoption and friction.

Product leadership can understand delivery outcomes.

Security teams can understand control effectiveness.

Everyone gets a different view of the same underlying economic model.

Final thoughts

AI development economics cannot be reduced to:

Those metrics are useful inputs, but they are not the destination.

A mature tokenomics system should connect:

  1. Organizational economics, which measures investment and spend
  2. Repository economics, which measures static configuration and reusable assets
  3. Developer and agent economics, which measures runtime consumption and behavior
  4. Outcome economics, which measures engineering and business impact

The most important design principle is traceability.

Every major conclusion should be traceable through a chain like this:

Business outcome
  -> Engineering metric
    -> Developer or agent behavior
      -> Repository configuration
        -> Organizational investment

The finished product should not be a dashboard that merely reports activity.

It should be an evidence system that helps organizations decide:

The strongest tokenomics model is not the one that counts the most tokens.

It is the one that explains which tokens, repository assets, developer behaviors, and agent actions contribute to meaningful outcomes.

That is the path from AI consumption analytics to AI value realization.