Methodology
Token Price Index measures the user price of AI inference tokens in USD per million tokens. TPX complements it by showing token purchasing power in mTPD.
Index Framework
Core definitions that establish what ATPI measures, what it excludes, and how users should read TPI and TPX.
Index Design Principles
Transparent, auditable, simple, and explicit about uncertainty.
Definition
ATPI indices are designed to measure the commercial cost and purchasing power of AI inference tokens using observable market prices.
Rule
- Transparent: users can understand what the index measures and what it excludes.
- Auditable: every model price should have a source trail.
- Simple: the core unit is USD per one million text tokens.
- Explicit about uncertainty: estimated, manually reviewed, or parser-failed data must be labeled.
Example
If a provider publishes official API pricing, that price has higher confidence than an aggregator quote or an inferred enterprise estimate.
Review / Disclosure
Major methodology changes should be documented on the methodology page or in a public changelog.
Token Price Definition
Provider prices normalized to USD per 1M input and output tokens.
Definition
A token price is the normalized cost of AI text inference, expressed in USD per 1 million tokens.
Rule
- All provider prices should be converted into USD per 1M input tokens.
- All provider prices should be converted into USD per 1M output tokens.
- A combined normalized price may be stored if the index requires one blended value.
- For Chinese providers quoted in RMB, the price should be converted into USD using the latest available exchange rate or a clearly stated exchange-rate source.
Example
If a model charges $0.50 per 1M input tokens and $2.00 per 1M output tokens, the raw input and output prices should both be stored. If a blended index value is used, the blending assumption must be explicit.
Review / Disclosure
The UI should show input price, output price, currency, source type, and last reviewed time where possible.
Token Price Index / TPI
Weighted average user-facing price of AI inference tokens.
Definition
TPI measures the weighted average user-facing price of AI inference tokens.
Rule
TPI should be calculated as a weighted basket of representative model prices. A higher TPI means AI tokens are more expensive for users. A lower TPI means AI tokens are cheaper.
Example
If frontier model prices decline broadly across the market, TPI should generally fall. If high-demand models become more expensive or scarce, TPI may rise.
Review / Disclosure
The page should explain that TPI is a price index, not a performance benchmark and not a revenue index.
Token Purchasing Index / TPX
Inverse purchasing-power view of token price, measured in mTPD.
Definition
TPX measures how much AI token capacity one dollar can buy. It is the inverse purchasing-power view of token price.
Rule
TPX should be expressed as mTPD, meaning million tokens per dollar. Higher TPX means stronger purchasing power.
Example
If token prices fall from $10 per 1M tokens to $5 per 1M tokens, the same $1 buys twice as many tokens, so TPX rises.
Review / Disclosure
The UI should clearly show that TPX moves in the opposite direction from TPI.
Modality Boundary
Main TPI and TPX baskets are text-token indices.
Definition
ATPI's main TPI and TPX indices are text-token indices.
Rule
Text-token pricing should not be mixed directly with image, video, audio, or other media-generation pricing unless those services expose comparable input/output token prices.
Example
A text model priced at USD per 1M tokens should not be averaged with a video model priced at USD per second or USD per generation.
Review / Disclosure
Non-text modalities should be either excluded or placed into future separate indices.
Video Models
Media-generation products belong outside the main text-token basket.
Definition
Video models are media-generation products and usually have different pricing units from text models.
Rule
Video model pricing should not enter the main text-token TPI basket unless it is explicitly priced in comparable text-token units.
Example
JiMeng, SeedDance, Veo, Sora, or similar video products may belong in a future media-generation index using units such as USD per second, USD per video, or normalized generation unit.
Review / Disclosure
The methodology page should label video model treatment clearly to avoid confusion between text-token indices and media-generation indices.
Why Not One Company
A basket reduces dependence on one provider's pricing strategy.
Definition
A single provider's price does not represent the whole AI token market.
Rule
ATPI should use a basket of providers and models to reduce dependence on one company's pricing strategy.
Example
If one company temporarily cuts prices for promotion, a basket index prevents the entire index from being distorted by that single event.
Review / Disclosure
The methodology should state that the index is designed to represent market-level affordability, not one vendor's pricing.
Basket Construction
Eligibility, regional scope, watchlist handling, and frontier classification rules for live index constituents.
Regions
Regional baskets cover Global, United States, and China, with room to expand.
Definition
Regional indices measure token prices in different commercial AI markets.
Rule
- The public site should support at least Global, United States, and China.
- The data model should allow future expansion to Europe or other regional baskets.
Example
A China basket may include models from providers such as DeepSeek, Alibaba, Baidu, ByteDance, Tencent, or Moonshot if they satisfy inclusion rules.
Review / Disclosure
Regional basket definitions should be documented and reviewed periodically.
Model Inclusion
Eligible models need observable pricing, access, relevance, and a reliable source trail.
Definition
Model inclusion defines which models are eligible to enter an index basket.
Rule
- A model may enter an index only if it has observable pricing.
- It should have stable API or enterprise access.
- It should have real commercial relevance.
- It should have current flagship or mainline status for its provider.
- It should have a reliable source trail.
- Its price can be normalized into USD per 1M tokens.
Example
A public API model with official pricing is eligible. A demo-only model with no stable pricing is not eligible.
Review / Disclosure
Each included model should have a source URL, source type, last checked date, and confidence label where possible.
Model Exclusions
Non-comparable, temporary, private, or unreliable prices are excluded.
Definition
Model exclusions prevent unreliable or non-comparable prices from entering the index.
Rule
- The index should exclude private discounts.
- The index should exclude temporary promotions.
- The index should exclude chat-only products without API pricing.
- The index should exclude one-off benchmark releases.
- The index should exclude discontinued models.
- The index should exclude prices that cannot be normalized into USD per 1M tokens.
- The index should exclude non-general access prices and purely experimental models.
Example
A limited enterprise discount available to one customer should not affect the public index.
Review / Disclosure
Excluded model types should be documented so users understand why some famous products are not in the basket.
Watchlist
Newly detected models are staged before joining a live basket.
Definition
The watchlist is a staging area for new or newly detected models.
Rule
- A new model should enter the watchlist before joining a live index.
- During the watchlist period, ATPI reviews pricing clarity, API stability, availability, capability level, provider relevance, and source reliability.
Example
A newly released model with public pricing may be watched for 30 days before joining the next monthly rebalance.
Review / Disclosure
Watchlist models can be displayed separately from live index constituents.
New Models
Recent releases stay under review before receiving live basket weight.
Definition
New models are recently released products that may affect the market but have not yet been fully reviewed.
Rule
New models should stay on the watchlist for at least 30 days before they can join a live basket. At first inclusion, a new model should enter with a capped initial weight, such as up to 5%, unless the methodology is updated.
Example
If a new frontier model launches today, it should not immediately dominate the index before pricing stability and availability are confirmed.
Review / Disclosure
The site should show whether a model is live, watchlisted, or under review.
Frontier Standard
Frontier status requires leading capability, access, pricing, and service stability.
Definition
A frontier model is a high-end AI model with leading capability, commercial availability, and observable pricing.
Rule
- A frontier model should satisfy most of the following: stable public or enterprise API access.
- It should show leading real-task performance.
- It should have strong capability in at least three areas: reasoning, code, long context, agents, multimodal work.
- It should have observable pricing and stable service capacity.
- It should not be merely a benchmark-optimized release.
Example
A model that performs well only on one benchmark but has no reliable API access should not automatically be classified as frontier.
Review / Disclosure
Frontier classification should be reviewed regularly because model capability changes quickly.
Frontier Handling
High-end models receive extra review for capability, adoption, reliability, and availability.
Definition
Frontier handling defines how ATPI treats high-end models that strongly affect public perception of AI capability and cost.
Rule
- Frontier models should be reviewed using capability.
- Frontier models should be reviewed using availability.
- Frontier models should be reviewed using pricing observability.
- Frontier models should be reviewed using service stability.
- Frontier models should be reviewed using market adoption and reliability.
Example
A frontier model with public pricing but unstable service capacity may remain under review before entering a frontier basket.
Review / Disclosure
Future methodology versions may add benchmark, reliability, and adoption data to frontier classification.
Weighting & Rebalancing
How ATPI turns reviewed market signals into representative provider and model weights.
Weighting Logic
Weights come from market-share signals and auditable proxies, not from price level alone.
Definition
Weights determine how much each provider or model contributes to the index.
Rule
- Weights should be based on market-share signals first.
- If direct API market-share data is unavailable, ATPI may use auditable proxies such as AI revenue, cloud AI revenue, API adoption, developer ecosystem activity, public usage indicators, and enterprise adoption signals.
- Exact live constituent weights do not need to be exposed as a free real-time feed, but the weighting logic should be public.
Example
If Provider A has much larger commercial AI API usage than Provider B, Provider A should generally receive a higher basket weight, unless the source confidence is lower.
Review / Disclosure
The site should label whether a weight is based on direct share data or proxy data.
Daily Weight Update
Reviewed signals are normalized to 100% and recalculated separately from price changes.
Definition
Daily weight updates normalize the latest reviewed signals into index baskets.
Rule
- The scheduled weight job should load the latest reviewed market-share or proxy signals.
- It should normalize basket weights to 100%.
- It should recalculate TPI and TPX.
- It should avoid using token price changes themselves as weight changes.
Example
If a provider cuts price by 50%, its weight should not automatically increase just because its price is lower.
Review / Disclosure
The methodology should explain that price movement and weight movement are separate mechanisms.
Monthly Rebalancing
Membership and weights are formally reviewed each month.
Definition
Monthly rebalancing is the formal review cycle for basket membership and weights.
Rule
Basket membership and weights should be reviewed monthly. Source-page updates may trigger review, but they should not automatically rewrite constituents or weights without validation.
Example
If a provider releases a new flagship model mid-month, it can enter the watchlist immediately but usually joins the live basket at the next rebalance.
Review / Disclosure
The UI should show last rebalance date and next scheduled rebalance date if possible.
Market Share
Private API volume is not always observable, so direct data and proxies are separated.
Definition
Market share estimates help determine provider-level and model-level weights.
Rule
- ATPI should separate direct API volume data.
- ATPI should separate company-level market proxies.
- ATPI should separate revenue proxies, adoption proxies, and estimated values.
- Provider-level weights may be mapped to representative models.
Example
If exact API call volume is not available, public cloud AI revenue or developer adoption may be used as a proxy, but it should be labeled as a proxy.
Review / Disclosure
The methodology should clearly state that private API volume is not directly observable for every provider.
Regional Sleeves
Global baskets may be composed from regional sleeves before model normalization.
Definition
Regional sleeves divide the global index into region-level components before model-level normalization.
Rule
The Global basket may use regional sleeves such as US and China before allocating weights to individual models.
Example
If the Global basket assigns a certain sleeve to China, Chinese provider weights are normalized inside that sleeve before being combined into the Global index.
Review / Disclosure
Regional sleeve assumptions should be summarized in public methodology releases.
Weight Constraints
Constraints prevent distortion by one provider, one model, or low-confidence data.
Definition
Weight constraints prevent the index from being distorted by one provider, one model, or low-confidence data.
Rule
Every index must total 100%. No provider should receive weight purely because its price is high or low. Lower-confidence signals should remain visible as proxies until replaced by stronger sources.
Example
A low-priced model does not automatically receive a high weight unless market-share or adoption signals justify it.
Review / Disclosure
The methodology should disclose whether caps, floors, or confidence adjustments are used.
Data, Sources & Review
Rules for source reliability, parser failures, source-page changes, live pricing, and historical data labels.
Source Reliability
Each price row should carry a confidence label and source trail.
Definition
Source reliability ranks the confidence level of pricing and market data.
Rule
- Supported source types should include official.
- Supported source types should include cloud_marketplace.
- Supported source types should include aggregator.
- Supported source types should include manual.
- Supported source types should include estimated.
- Official pricing URLs should have the highest priority.
Example
An OpenAI, Anthropic, Google, DeepSeek, Alibaba Cloud, or Baidu official pricing page should be preferred over a third-party pricing table.
Review / Disclosure
Each price row should store source type and last checked time.
Source Page Changes
Changed provider pages are marked needs_review before values are rewritten.
Definition
Source page changes occur when a provider updates its pricing page, structure, model list, or terms.
Rule
- When a pricing page changes, the fetcher should mark the row as needs_review.
- The review should check new models, retired models, price changes, cached or batch price changes, regional price differences, and source reliability.
Example
If a provider changes the HTML layout of its pricing page, the parser should not silently overwrite prices without review.
Review / Disclosure
Rows marked needs_review should be visible internally and optionally surfaced in the public UI as uncertainty.
Live Pricing
Official pages are parsed where stable; reviewed values are retained when parsing is uncertain.
Definition
Live pricing means the system attempts to parse current provider pricing from official or reliable sources.
Rule
The fetcher should parse official pricing pages where page structure is stable. If a source cannot be parsed confidently, the system should store page metadata, keep the last reviewed price, and mark the row for review.
Example
If a dynamic pricing page blocks parsing, the last reviewed manual price should remain active but be labeled as manually reviewed or stale.
Review / Disclosure
The UI should distinguish live parsed prices from reviewed manual prices.
Missing Data
Parser failures retain last reviewed values and expose uncertainty.
Definition
Missing data occurs when a parser fails, a provider removes a price, or a source becomes temporarily inaccessible.
Rule
- If a parser fails, keep the last reviewed value.
- Record parser_failed.
- Show uncertainty in the UI.
- Avoid replacing the value with zero.
- Avoid deleting the model automatically.
Example
If a provider's page is down for several hours, the index should not collapse because the price cannot be fetched.
Review / Disclosure
The UI should show stale or uncertain status when data is not freshly confirmed.
Historical Movement
Charts distinguish confirmed snapshots from modeled launch history.
Definition
Historical movement shows how TPI and TPX changed over time.
Rule
Confirmed history should come from daily price and weight snapshots. Before enough real snapshots exist, the launch history may use a clearly labeled factor model.
Example
If the site launches before it has 90 days of snapshots, early charts can show model-based history, but they must not pretend to be audited historical data.
Review / Disclosure
The chart should label whether a time series is actual snapshot history or modeled launch history.
Price Events & Governance
Controls for interpreting price shocks, excluding manipulation, and disclosing project limitations.
Price Impact Factors
Major drivers explain price movement without becoming a deterministic forecast.
Definition
Price impact factors explain why token prices move.
Rule
- The methodology should identify compute affordability.
- The methodology should identify GPU supply.
- The methodology should identify serving efficiency, caching, and model distillation.
- The methodology should identify competition, frontier demand, regional cloud pricing, and enterprise adoption.
Example
Better inference efficiency and stronger competition tend to push TPI down and TPX up. Compute scarcity or frontier-model bottlenecks may push TPI up and TPX down.
Review / Disclosure
This section is explanatory and should not be treated as a deterministic forecast model.
Large Price Drops
One-time public cuts above 20% receive confirmation before full index impact.
Definition
Large price drops are sudden public reductions in model pricing that can materially move the index.
Rule
A one-time public price cut greater than 20% should trigger at least 5 trading days of confirmation. During confirmation, up to 40% of the price change may be reflected. The remaining impact can be phased in over 10 trading days if the price is stable and broadly available.
Example
If a provider cuts a model price by 50%, the index should avoid instantly accepting the full change until availability and pricing stability are confirmed.
Review / Disclosure
Large price events should be recorded in a public changelog or methodology note.
Anti-Manipulation
Temporary, private, or non-general prices do not enter the main index basket.
Definition
Anti-manipulation rules prevent temporary or non-general pricing from distorting the index.
Rule
- The main index should exclude limited promotions.
- The main index should exclude private discounts.
- The main index should exclude short-term credits.
- The main index should exclude non-general pricing.
- The main index should exclude one-customer enterprise deals.
- The main index should exclude prices unavailable to normal commercial users.
Example
A one-week free-token campaign should not reduce the official TPI.
Review / Disclosure
Promotional prices can be mentioned separately but should not enter the main index basket.
Limitations
ATPI discloses uncertainty around dynamic pages, private prices, share proxies, and non-text modalities.
Definition
Limitations explain what ATPI cannot measure perfectly.
Rule
- Some providers publish pricing in dynamic pages.
- Some enterprise prices are private.
- API usage share is not fully observable.
- Currency conversion can introduce noise.
- Model quality changes faster than pricing pages.
- Text-token indices do not measure image, video, or audio generation cost.
Example
A model may be important commercially but excluded temporarily if its price cannot be verified or normalized.
Review / Disclosure
Limitations should be visible on the methodology page to make the project more credible, not less credible.
Capability Extensions
SCU concepts are preserved as a separate capability methodology layer and do not replace the core text-token TPI and TPX baskets.
Standard Capability Unit
A capability-adjusted token unit that remains separate from core TPI and TPX price indices.
Definition
SCU, or Standard Capability Unit, is a normalized unit for measuring the practical AI capability delivered by model tokens.
Rule
SCU compares usable reasoning, coding, math, multimodal understanding, agentic execution, reliability, and inference efficiency across models. It is not a hardware compute metric and does not measure GPU FLOPs, training cost, or raw inference compute.
Example
A model with stronger verified task performance may deliver more SCU per 1M weighted tokens than a cheaper model with weaker reliability or capability.
Review / Disclosure
First-version SCU data is marked estimated until the Capability Oracle and real-task validation are live.
Live SCU Spot
A high-frequency capability quote layer that is labeled as simulation until telemetry is connected.
Definition
Live SCU Spot adjusts base SCU rates for delivery conditions such as latency, reliability, availability, routing, and queue pressure.
Rule
The public spot price is the weighted average of the top three lowest live USD per SCU quotes. Prototype live telemetry must be deterministic, model-seeded, smooth over time, and labeled as simulation.
Example
A model with low base cost can still show a worse live USD per SCU quote if latency, retries, or queue pressure rise.
Review / Disclosure
Live SCU simulation is designed to be replaced by real provider latency, error rate, routing, availability, capacity, and task queue telemetry.
SCU Fair, Market, and Forward Values
SCU separates fundamentals, tradable market quotes, and 30-day expectations.
Definition
Fair Value SCU is the slower fundamental value. Market Price SCU is the faster quote layer. Forward SCU is the expected 30-day value implied by current expectation factors.
Rule
- Fair Value uses capability, cost efficiency, trust, availability, and long-term demand.
- Market Price starts from Fair Value and adds bounded news momentum, demand heat, scarcity premium, sentiment, liquidity, and volatility effects.
- Forward 30D starts from Market Price and adds expected capability, cost, demand, and scarcity changes.
- Real-time volatility must be bounded, deterministic in prototype mode, explainable, and mean-reverting unless a verified data update or reviewed major event occurs.
Example
CHNUS Fair Ratio may show China SCU at 0.72 of US SCU while CHNUS Market Ratio trades at 0.75 because China news momentum and demand heat are stronger.
Review / Disclosure
The market and forward layers are experimental research signals, not investment advice, and simulated signals must be labeled separately from verified price or benchmark data.
China-US SCU Spread
CHNUS compares China and US capability supply through fair, market, and forward ratios.
Definition
CHNUS is the China SCU value divided by the United States SCU value. USCN spread is the United States SCU value minus the China SCU value.
Rule
- CHNUS Fair Ratio equals China Fair SCU divided by US Fair SCU.
- CHNUS Market Ratio equals China Market SCU divided by US Market SCU.
- CHNUS Forward 30D equals China Forward 30D divided by US Forward 30D.
- Each major move should show timestamped factor attribution including capability, cost efficiency, demand heat, availability, news momentum, sentiment, and volatility.
Example
If China demand heat and cost efficiency rise while US availability weakens, CHNUS Market Ratio can rise even if the slower fair value ratio is nearly unchanged.
Review / Disclosure
The page must distinguish verified data such as official API prices and published benchmark results from estimated or simulated inputs such as demand heat, news momentum, and sentiment.