Perspectives on Token Pricing

Core Thesis: There are only two certainties regarding the cost of tokens: we are currently experiencing a supply shortage, and the current state of affairs is fundamentally unstable.

The market is currently in a state of flux. Over the coming years, various variables will clash and resolve, eventually settling into a new equilibrium. While many analysts are obsessed with the "time to power," the real underlying question is whether foundation model providers will maintain strategic leverage and pricing power, or if they are destined to become high-margin software companies low-margin providers of commodity infrastructure.

Currently, the evidence suggests the latter.

The Supply and Demand Dynamic

The tension between availability and appetite is driving the current volatility.

1. The Supply Side

We are seeing a massive influx of hardware and efficiency gains:

• Capex: Over a trillion dollars is being poured into data centers, backed by even more semiconductor investment.
• Efficiency: The cost of inference is dropping rapidly.
• Tokenization: New models vary wildly in how efficiently they utilize tokens.

2. The Demand Side

While we've been capacity-constrained since 2022, the recent spike is narrow.

• The "Dev" Bubble: Most current growth is driven by software development—a relatively small niche.
• The Scaling Gap: If a consumer use case with hundreds of millions of Daily Active Users (DAUs) launched today, the existing infrastructure would collapse regardless of the price.

The Financial Architecture

The economics of LLMs are split between two different types of costs:

1. Inference (Marginal Cost): Currently operating at roughly 40-50% gross margins. However, this depends on the asset life of the servers (is it 5 years? 7 years?).
2. Training (Fixed Cost): The cost to build the next generation of models several times a year currently dwarfs total revenue.

We don't yet know if the ROI (Return on Investment) for these tools is quantifiable enough for a CFO to justify high prices, especially for future, unproven use cases.

The Forecasting Fallacy

One could attempt to model this using a bottom-up approach:

• Calculate current chip counts.
• Estimate TSMC's delivery schedule.
• Model data center onboarding speeds.
• Factor in power grid constraints.
• Guess at price discipline and use-case adoption.

Doing this is a reliable way to predict the future like trying to forecast the 1998 broadband market. You'll get a beautiful spreadsheet, and you might be right for the next twelve months, but the long-term structure is too volatile for a linear forecast.

Mathematically, we can express token price as: $\text{Price} = f(\text{Supply}, \text{Demand}) \text{ where } \text{Marginal Cost} < \text{Price} < \text{Buyer ROI}$

Since we don't know the actual values for supply, demand, cost, or ROI, the formula is currently an abstraction.

A Top-Down Framework

Instead of spreadsheets, we should look at historical patterns and the "Intelligence Curve."

The Intelligence vs. Cost Trade-off

We must ask: Who is willing to pay for the frontier?

• The Low End: Many tasks work fine with small, open-source models running locally for "free."
• The High End: A few tasks require the most expensive, cutting-edge models.
• The Middle: Most use cases fall somewhere in between.

Critical Questions for the Future

1. The Science Gap: Does the frontier continue to improve at a rate that outpaces the downward pressure of efficiency and capacity?
2. Competitive Landscape: Will we see a "winner-take-all" network effect, or will the market remain a handful of companies with equivalent capabilities? (Currently, they use similar data and science).
3. Value Capture: Does the model provider keep the profit, or is the value captured by the "wrapper"?

def value_capture(model_capability, tooling, proprietary_data, gtm_strategy):
    if tooling and proprietary_data and gtm_strategy:
        return "Value captured by Software Company"
    else:
        return "Value captured by Model Provider"

Ultimately, we must determine if the model can provide the entire solution, or if it remains a component that requires traditional software layers—support, networks, and process—to be actually useful.