Every meaningful action performed by an AI model today, whether understanding text, analyzing an image, interpreting audio, or generating a response, ultimately manifests as computation over tokens.

Tokens are the atomic units through which large language and multimodal models perceive, process, and produce information. They form the only universal unit that spans evaluation, inference, cost, hardware usage, and environmental impact.

During evaluation, models are tested with structured prompts to measure accuracy, coherence, and task performance. These tests also reveal how many tokens a model must process to achieve a given level of quality. When translated into energy, or cost per token, evaluation benchmarks become multidimensional, allowing organizations to compare not just accuracy but energy and cost efficiency across model versions or configurations.

However, the real impact emerges in inference. Google reported processing 1.3 quadrillion tokens monthly in 2025, a scale so large that raw token counts become abstract. The way to resolve this ambiguity is by translating token volume into quantifiable cost, usage, and energy consumption, turning statistically overwhelming numbers into operationally relevant metrics.

Provider	Reported Token volume (Monthly, 2025)	Notes/Source
Google (Gemini / DeepMind)	1.3 Quadrillion (1.3 x 10¹⁵)	Across all surfaces; doubled from 480 trillion in May to 980 trillion in July, reaching 1.3 quadrillion by summer.
Open AI (API + ChatGPT)	>259 Trillion (API only)	API at >6 billion tokens/min; total including ChatGPT estimated higher but not publicly detailed; 800 million weekly active users.
Microsoft (Azure OpenAI / Copilot)	1.7 Trillion (Foundry product)	Specific to Foundry; broader Copilot usage likely higher but no aggregate reported; quotas up to 32 billion for GPT-5 models.
Anthropic (Claude)	~25 Trillion (estimated)	25 billion API calls in Q2; assuming ~1,000 tokens per call; 30 million monthly active users.

Tokens in the Context of Providers

Model providers, across closed, and open-source releases, price their APIs (OpenAI, Gemini, Anthropic, Deepseek and others) exclusively in terms of tokens, distinguishing between input tokens (what the user sends into the model) and output tokens (what the model generates) and often adding separate rates for cached/context tokens.​. This differentiation of input, output, and context-extension tokens is because each carries a different computational footprint, from attention cost to KV-cache pressure, driving more granular cost models, including surcharges for long contexts or discounted rates for efficient batching and (in the future) low-carbon regions.

Real-time token telemetry is now standard. API users receive real-time token counts, burn-rate signals, and “token waste” diagnostics, enabling prompt optimization, throttling, and model switching. Token behaviour also shapes modern inference scheduling. Modern serving systems: multi-model routing, mixtures of experts, and chip-aware orchestrators use token-arrival rates and tokens-per-joule measurements to size batches, route workloads, andmaintain SLAs across large fleets. Providers additionally, under pressure from the community have begun to disclose energy-per-token and carbon-per-token metrics (see Google’s per token emissions analysis).

In the open-source ecosystem, token-normalised benchmarks (tokens per task, latency per token, and energy per token), are now common across multilingual and multimodal evaluations. (see Hugging Face’s AI Energy Score)

Together, these practices make tokens the provider’s operational reference point for pricing, routing, efficiency, and sustainability.

2025 Token Economics at a Glance

Model	Input Price (per 1M tokens)	Output Price (per 1M tokens)
ChatGPT 5.1	$1.25	$10.00
Claude Sonnet 4.5	$3	$15 / MTok
Gemini 3 Pro preview	$1.2, prompts <= 200k tokens $4, prompts > 200k tokens	$10.00, prompts <= 200k tokens $15.00, prompts > 200k tokens
Llama 4 Maverick (Meta)	$0.19-$0.49 (3:1 blended)	$0.19-$0.49 (3:1 blended)
Grok 4.1 Fast	$0.20	$0.50
DeepSeek	$0.028-0.28	$0.42
Mistral Medium 3	$0.4	$2.0

See this in action with the One-Token Model API

Our API brings token-level observability into a unified, real-time dashboard, enabling model comparison, prompt optimization, and precise allocation of AI costs across teams, products, and workflows. Organizations can benchmark performance, optimise AI workflows, and operationalise sustainable AI practices at scale.

Explore API

See this in action with the One-Token Model API

Our API brings token-level observability into a unified, real-time dashboard, enabling model comparison, prompt optimization, and precise allocation of AI costs across teams, products, and workflows. Organizations can benchmark performance, optimise AI workflows, and operationalise sustainable AI practices at scale.

Explore API

Across modalities, whether the AI model is reading text, analyzing an image, or listening to audio, it always breaks the input into small, understandable pieces called tokens.

Text Tokenization

Text is decomposed into small units: characters, sub-words, or words, through tokenizers such as OpenAI’s tiktoken, which approximates one token as ¾ of an English word. The model processes these tokens sequentially and produces new tokens one by one.

Audio Tokenization

Digitally, an audio signal is described as a continuous waveform of sound pressure over time. Audio tokenization transforms continuous sound waves into discrete representations, or tokens, that sequence models can interpret.

Some techniques include:

1. Phoneme/Character Tokens  (Automatic Speech Recognition) which converts spoken language into text by transforming audio signals into discrete tokens such as phonemes, characters, or words.

2. Codec Tokens (Neural Audio Codecs) like EnCodec (Meta’s) and SoundStream (Google’s)  turn audio into sequences of tokens without compromising quality, using vector quantization.

These representations align audio with the same discrete token-based processing, as text.

Image Generation

In digital context, an image is described as a collection of pixels. However, the image generation models don’t see an image as pixels, but as structured information that’s broken into smaller, meaningful representations. These compact representations are called tokens. They help the model understand patterns, textures, and semantics. Popular approaches:

• Patch Embeddings: They split an image into uniform, non-overlapping patches, each represented as a token. These tokens act like words in a sentence, allowing the model to process visual information as a structured sequence of discrete units.

  For a 224×224 image and 16×16 patch size, this gives (224/16)2=196 patches. Each becomes one token. These 196 tokens collectively describe the entire image, much like how words (tokens) describe meaning in a sentence.

2. Discrete Variational Auto Encoder (DVAE) and Vector Quantization: Think of vector quantization as turning image features into predefined buckets. Each bucket stores a representative vector, and the DVAE maps image parts to these buckets to learn consistent, discrete patterns.

3. CLIP-Style Contrastive Embeddings: Contrastive models like CLIP learn to align images and text in the same feature space. Each image or caption is converted into an embedding, and these embeddings can then be grouped or discretized into token-like units for other tasks.

Video Generation

The most common way to tokenize videos today is by breaking them into individual frames and pairing them with the corresponding audio. Each frame acts like an image token, while the audio provides temporal context. 

For example, models like Gemini process video as a sequence of image tokens interwoven with text and audio information.

To summarize, tokens are the currency of AI. Whenever a company embeds AI into an application: document analysis, summarization, search, chat, content generation, or media processing. Every user interaction becomes a sequence of tokens in and tokens out.

The One-Token Model (OTM) quantifies the energy consumed by an LLM during inference and expresses its environmental impact on a per-token basis. It tells you the energy consumption of your token usage, and its consequent emissions. 

The OTM works by observing the computation required to process each token, whether text, audio, image, or multimodal, and translating that computation into energy (kWh) and carbon emissions (gCO₂e). Because every interaction with an LLM ultimately reduces to tokens in and tokens out, the token becomes the most precise and universally comparable unit for evaluating the sustainability of AI usage. Frontier models such as those from OpenAI, Anthropic, Google, and Meta already operate internally using tokenization frameworks.

Although the word “token” appears at multiple layers of the AI stack, the One-Token Model unifies them into a coherent structure for measuring energy.

Accessing the Model Through the One-Token Model API

The One-Token Model API translates the conceptual framework described in this section into actionable, real-time measurements. Developers instrument their inference pipelines and receive per-token energy and carbon data without needing to implement the measurement engine themselves. The API handles all computation internally, returning structured responses with cost, performance, energy (kWh), emissions (gCO_e), and per-token breakdowns for every inference event.

Start API Integration

Accessing the Model Through the One-Token Model API

The One-Token Model API translates the conceptual framework described in this section into actionable, real-time measurements. Developers instrument their inference pipelines and receive per-token energy and carbon data without needing to implement the measurement engine themselves. The API handles all computation internally, returning structured responses with cost, performance, energy (kWh), emissions (gCO_e), and per-token breakdowns for every inference event.

Start API Integration

Example 1: Model/Text Tokens

basic implementation

When a user chats with ChatGPT, their message is broken into tokens that form the prompt. The model then generates a response using N tokens, which remain invisible to the user. The performance, energy and environmental impact of this interaction is estimated by the One-Token Model API.

Example 2: API/Billing Tokens

Developers using APIs from popular LLMs as well as AI powered coding IDEs  can view token usage metrics, including the number of tokens exchanged (input, output, and total) per API call or interaction, through their respective dashboards or API responses. The cost, performance, energy, and environmental impact of this interaction is measured and estimated by the One-Token Model API.

Overview of the Methodology

Inference impact is measured by observing how a model exercises compute resources during token generation. The model starts at the hardware layer, where energy is actually consumed, and progressively incorporates model-level and system-level factors to calculate the energy per token and the corresponding carbon emissions.

The model builds on a shared body of empirical evidence rather than any single source. It aligns with the direction of prior work such as EcoLogits, methodologies developed by Salesforce and Hugging Face, and independent research, while extending these ideas into a unified, systematic framework designed for practical implementation. 

The One-Token Model separates the inference footprint into three interacting domains:

Domain 1: Hardware Utilization

The hardware domain captures the physical energy consumed during inference. This includes accelerator activity at the GPU level as well as non-accelerator infrastructure overhead (CPU, RAM, networking, cooling). The OTM measurement engine incorporates empirically derived baseline power factors for inference-optimized data centre deployments, calibrated against measurements from hyperscaler-class GPU nodes. Where deployment-specific telemetry is available, particularly in on-premise or tightly controlled environments, these baselines can be refined to reflect measured operating conditions. For closed models, the One-Token Model API relies on existing research, experimental data, and industry benchmarks for the hardware utilization metrics.

Domain 2: Model Architecture

The model architecture domain accounts for how a model’s internal structure determines its resource requirements during inference. Key architectural characteristics-including model architectures, and numerical precision settings-directly influence accelerator memory utilization and power draw. The One-Token Model API uses these architectural signals to estimate the computational footprint of a given model configuration during inference.

Domain 3: Inference Dynamics

The inference dynamics domain captures the temporal behavior of the generation process. These metrics define the time window over which energy consumption takes place. The number of generated output tokens provides the denominator for per-token normalization.

Energy and Carbon Estimation

The OTM’s measurement engine combines signals from all three domainsto estimate the total energy consumed during an inference event. Hardware utilization data, model architecture characteristics, and observed inference behaviour are integrated within the One-Token Model API to compute energy consumption in kilowatt-hours. Power Usage Effectiveness (PUE) and other research-backed overhead factors are applied to account for data centre cooling and infrastructure overhead.

Carbon emissions are then derived by combining estimated energy consumption with region-specific grid carbon intensity factors. The final per-token impact is obtained by normalizing total emissions by the number of output tokens generated, yielding a granular, comparable unit of environmental impact.

The OTM is aligned with ISO 14064, ISO/IEC 21031 and GHG Protocol guidance 

The specific mathematical relationships, weighting functions, calibration constants, and empirical correction factors that connect the three measurement domains are implemented within the One-Token Model API. This proprietary engine has been developed through extensive empirical testing, benchmarking against real-world deployments, and continuous calibration against hardware telemetry.

The One-Token Model API exposes the results of this engine without requiring users to implement or maintain the measurement logic themselves.

See this in action with the One-Token Model API

Our API brings token-level observability into a unified, real-time dashboard, enabling model comparison, prompt optimization, and precise allocation of AI costs across teams, products, and workflows. Organizations can benchmark performance, optimise AI workflows, and operationalise sustainable AI practices at scale.

Explore API

See this in action with the One-Token Model API

Our API brings token-level observability into a unified, real-time dashboard, enabling model comparison, prompt optimization, and precise allocation of AI costs across teams, products, and workflows. Organizations can benchmark performance, optimise AI workflows, and operationalise sustainable AI practices at scale.

Explore API

Inference Phases and Why OTM Focuses only on Output Tokens

Every LLM inference request unfolds in two distinct computational phases:

1. Prefill (Input Processing): When you submit a prompt, the model first processes all input tokens together in a single forward pass. During this phase, the model builds an internal representation of your request by populating what's called the KV (Key-Value) cache. This phase determines how long you wait before seeing the first word of the response: the "Time to First Token" (TTFT).
2. Generation (Output Tokens): After prefill completes, the model begins generating output tokens one at a time. Unlike prefill, each output token requires a complete autoregressive pass through the entire model. The model must reference everything it has processed so far, apply its full reasoning capacity, and produce exactly one new token. Then it repeats this process for the next token, and the next, until the response is complete.

Empirical work, including EcoLogits, ML.ENERGY, AI Energy Score, and independent studies consistently show:

1. For many real-world workloads the decode phase (reasoning plus answer generation) often accounts for the clear majority of inference compute, with compute dominated by how long the model ‘thinks’ and how many output tokens it produces.
2. Prefill dominates only in very short outputs.
3. For many real-world LLM workloads with non-trivial answers, total compute tends to correlate more strongly with the length of the generated output than with the length of the input, although very long prompts or very short outputs can shift the balance toward input-side prefill

For this reason, V1.0 of the OTM attributes emissions primarily to output tokens, because they represent the section of inference where compute, and therefore energy, is concentrated. Focusing on output tokens provides an immediate, practical benefit: OTM can be applied to any single model without requiring cross-provider normalization.Within any individual model, output tokens provide a stable, consistent anchor for measurement because the tokenizer, architecture, and generation pathway all operate under unified internal logic.

Acknowledging the Limitation

We recognize that for practical measurements, many published methodologies sum these roles and report "energy per token" over the union of input and output tokens, which creates a more hardware, and architecture-agnostic metric.

Attribution to output tokens alone, as in our OTM v1.0 approach, is a pragmatic simplification but it may undercount scenarios where large prompts (many input tokens) significantly affect energy use, this often matters for instruction-following or RAG scenarios. Counting only output tokens does make metrics portable across providers and models, but can miss model design differences that affect prefill.

There is a requirement for a consistent measurement unit that faithfully represents computational work. Output tokens are the starting point for energy attribution because they dominate inference compute. But as models evolve, input tokens, modality-specific processing tokens, and internal reasoning tokens will also need to be incorporated into a more complete accounting. 

Modern AI usage rarely stays confined to one model or one provider. Organizations evaluate multiple options. Developers compare costs across OpenAI, Anthropic, and Google. Applications route requests dynamically based on workload characteristics.

Furthermore, even under proprietary models, the OTM estimates architectural characteristics based on performance heuristics and validated community research. OTM V1.0 focuses on text-to-text generation and does not yet account for the specific overhead of multimodal inputs.

On Hardware: The model isolates accelerator level power consumption and related metrics as the dominant energy contributor durina inference. Non-accelerator components are represented through empiricall derived baseline power factors based on measurements from inference-optimized data centre deployments. This creates a practical baseline that may not perfectly reflect custom on-premise hardware or alternative accelerators.

OTM Version 1.1: We are actively developing the next iteration, which expands the energy envelope to account granularly for all server components, improves power draw modelling at different utilisation rates, and fully integrates the Antarctica Token normalization layer for cross-provider benchmarking.

The Path Forward

For comprehensive cross-provider analysis, cost optimization, and fair performance benchmarking, the full spectrum of token types, and multi-modal differences across images, video, audio, and cross-provider, must be reconciled into a common measurement framework. For comprehensive cross-provider analysis, cost optimization, and fair performance benchmarking, the full spectrum of token types, and multi-modal differences across images, video, audio, and cross-provider, will be reconciled into a common token framework in the One-Token Model API.

The One Token Model API Principles

The OTM measurement engine is the core that connects the three signal domains described in the conceptual framework. It transforms raw infrastructure telemetry, model configuration data, and observed inference dynamics into calibrated energy and emissions measurements.

The API is built on several foundational principles:

A Structural Challenge in Enterprise Tokenomics

OTM is designed to be applied independently for each model, provider, and modality. This makes OTM immediately usable in practice. If a developer wants to understand the energy footprint of a prompt executed on GPT-5.1, OTM can measure it. If the same prompt is run on Anthropic Claude Opus, the model can be applied again, producing a separate, model-specific estimate. Each result stands on its own, in the same way that evaluation metrics such as latency, accuracy, or cost are typically compared today: model by model, test by test.

The OTM sometimes uses a simplifying assumption. For instance, for text prompts, approximately four words per token. This assumption is useful in contexts where exact token counts are not yet available, if for example, you are not using your own tokenizer, or because each model requires its own tokenizers, and different measurements for images, videos, and texts. 

The OTM in its current version allows teams to reason about orders of magnitude without needing access to provider-specific tokenization. However, this is explicitly an approximation. In any serious deployment, the OTM is intended to operate on the actual token counts reported by each model or inferred from its tokenizer, rather than relying on a fixed 4:1 rule. The approximation can therefore be viewed as a pedagogical bridge, not as a core constraint of the model.

But organizations don't operate in single-model environments. They evaluate options, compare providers, mix modalities, and make purchasing decisions that require apples-to-apples comparisons.Evaluating cross-provider behavior still requires normalized tokens, across input tokens, and behind-the scenes processing tokens, and “output tokens”. Teams can apply the OTM repeatedly across providers and modalities, building a comparable view over time, model by model, use case by use case.

A core challenge in measuring AI inference impact is that one token is not a universal unit of computation within providers. Each AI provider, OpenAI, Anthropic, Google, Meta, Mistral, and others, uses its own tokenizer, vocabulary, and segmentation logic. As a result,identical text, image, audio, or video inputs can yield significantly different token counts across models, even when the underlying computational workload is similar.

Tokenizers differ in vocabulary size, subword construction, merging rules, and handling of whitespace, punctuation, and code. As a direct consequence:

Four problems arise:

To summarize, real enterprise workloads increasingly chain providers("Use Claude for summarization, GPT-4 for structured extraction"), mix modalities ("Analyze this video and generate a written report"), and route through different execution strategies (small-to-large model cascades, MoE expert selection, reasoning mode toggles). Current cost, usage, and energy frameworks cannot reconcile these heterogeneous token types into a common unit. Comparisons become unreliable for tasks like "Analyze this earnings call video and produce a summary" because you cannot meaningfully compare 15,000 video tokens + 500 text tokens in one system against 12,000 unified tokens in another.

To summarize, the OTM is designed around a simple principle: inference compute is overwhelmingly driven by output-generation steps, and output tokens provide a stable anchor for attributing energy and emissions. Within any individual model, this anchor is consistent because the tokenizer, architecture, and decoding pathway operate under a unified internal logic.
But current cost, usage, and energy frameworks do not reconcile these heterogeneous token types into a common unit. This lack of a standardized token unit is a foundational gap in cross-provider sustainability, benchmarking, and cost analysis.

But, the lack of a standardized token unit is a foundational gap in cross-provider sustainability, benchmarking, and cost analysis.

See this in action with the One-Token Model API

Our API brings token-level observability into a unified, real-time dashboard, enabling model comparison, prompt optimization, and precise allocation of AI costs across teams, products, and workflows. Organizations can benchmark performance, optimise AI workflows, and operationalise sustainable AI practices at scale.

Explore API

See this in action with the One-Token Model API

Our API brings token-level observability into a unified, real-time dashboard, enabling model comparison, prompt optimization, and precise allocation of AI costs across teams, products, and workflows. Organizations can benchmark performance, optimise AI workflows, and operationalise sustainable AI practices at scale.

Explore API

The Antarctica Token (AT) serves as this additional normalization layer.

It is defined as a normalized unit of LLM computational work, independent of provider tokenizer differences.

An Antarctica Token represents the standardized computational effort required to process or generate one unit of semantic content, normalized across tokenization methods, model architectures, languages, and modalities.

The Antarctica Token provides a:

1. Provider-Agnostic Equivalence

Effective normalization requires conversion mappings for every major model provider and architecture pattern. The Antarctica Token framework maintains the most extensive database of provider-to-normalized token conversions currently available. This database includes:

• All major closed-source providers: OpenAI, Google, Anthropic, Meta, xAI, and others.

• Leading open-source model families: Mistral, DeepSeek, and others.

2. Computational Grounding

The AT Framework works on a database built through systematic empirical testing rather than only theoretical assumptions. For each provider and model, the framework measures:

1. Full-Cycle Token Accounting tracks total throughput from ingestion to generation, ensuring complete visibility into cost and usage across the entire lifecycle.
2. Architectural Resource Profiling analyzes underlying model characteristics and computational weight to optimize performance allocation without manual tuning.
3. Adaptive Compute Pathways differentiates between standard processing and complex logic flows, routing requests efficiently based on required cognitive load.
4. Unified Multimodal Abstraction standardizes the consumption and generation of diverse media types into a single, cohesive accounting layer, regardless of format.
5. Semantic Density Evaluation assesses the information richness of the payload to adjust processing expectations based on the complexity of the content.
6. Comparative Infrastructure Benchmarking provides contextual performance data against market standards to validate efficiency and cost-effectiveness.

3. Continuous Database Expansion

AI providers release new models and tokenizer updates continuously. Maintaining accurate normalization requires ongoing measurement and database updates. The Antarctica framework incorporates:

1. Automated monitoring of new model releases
2. Rapid characterization of new tokenizers and architectures
3. Backward compatibility maintenance as older models are deprecated
4. Quality assurance through cross-validation against known workloads, and multiple data quality checks.

This operational infrastructure, the continuous process of measuring, validating, and updating conversion mappings, ensures the Antarctica Token remains a stable currency in a volatile ecosystem.

A normalized standard is only as valuable as its accessibility to the systems that need it. The theoretical rigor of the One-Token Model must be translated into actionable telemetry within real-world IT environments. These pathways allow organizations to ingest normalized metrics directly into their existing stacks, and apply the OTM seamlessly, regardless of whether they control the hardware or rely on third-party vendors. This brings us to the three architectural models for deployment.

The One Token Model is designed to meet organizations wherever they are in their AI deployment. Whether your team calls OpenAI’s API from a product backend, runs open-source models on your own GPUs, or operates a mix of both, the OTM plugs into your existing workflow without requiring changes to your model serving infrastructure, your application code or your choice of provider.

This section describes 3 integration paths. The One-Token Model API adapts its data sources, and estimation approach based on the level of telemetry available, ensuring that every organisation, from a 2 person startup calling an OpenAI or Claude API to a large enterprise running fine-tuned models on a private GPU cluster, receives actionable financial, performance, energy and carbon data.  

1. When you call a provider’s API

For teams using OpenAI, Anthropic, Gemini, or any hosted model API

This is the most common setup in production today. Your application sends prompts to a provider’s API and receives completions. You have no visibility into the GPUs or the model’s internal architecture. The provider’s API is a black box.

The One-Token Model API works alongside your existing API calls and applies the methodology. There is no need to change providers, or access hardware you don’t control. 

2. When you host your own models

For teams running open-source LLMs on their own GPUs or cloud instances

Many organizations host open-source models such as Llama, Mistral, DeepSeek, Falcon, and others on their own infrastructure, whether on cloud GPU instances (AWS, GCP, Azure, RunPod) or on-premise servers. In these deployments, the organizationmanages both the model, and underlying compute which means the One-Token Model API can access complete hardware telemetry and derive the highest-resolution measurements.

Because the hardware is monitored directly, with the One-Token Model API’s real-time observability, the output contains actual measurements rather than estimates, for every API call.

3. When you run both

For organizations using a mix of provider APIs and self-hostel models

Most mature AI deployments don’t fit neatly into a single category: a team might route summarization tasks to Claude or OpenAI, structured extraction to a self-hostel Llama instance, and image analysis to Gemini, all within the same product. The sustainability, cost and performance data for these workloads needs to appear in a single view, measured consistently regardless of whether the model runs on your hardware or someone else’s.

The hybrid integration of the One-Token Model API combines both these approaches. This means an engineering lead can compare 100+ metrics related to a Claude API call against a self-hosted Llama call for the same task, normalized, consistent, side by side. It also means AI sustainability reporting covers the entire AI inference footprint.

The OTM applies to wherever Al inference creates cost, consumes energy, or produces emissions, which is to say, everywhere Al is used. This section describes the three primary contexts in which the OTM delivers value:

1. Understanding what your AI usage actually costs

For individual developers and power users, every prompt has a cost, metrics to understand its performance, an energy footprint, and an emissions profile, which until now, most users had no visibility into. The OTM helps the user of AI get the data and  insights needed to make better decisions with their AI usage.

When a developer using the One-Token Model API sees these numbers in real-time, they start making informed decisions: Does this prompt need to be this long? Is the model generating unnecessary tokens? Would a smaller model produce comparable results at a lower cost and lower environmental impact.

For individual users interacting with a chat-based LLM, OTM can measure the per-prompt impact of an inference event using output tokens as the primary unit. Tools built on top of the methodology (such as lightweight instrumentation layers or prompt-side extensions) can help users understand:

1

How their query structure affects token generation

2

Whether a prompt is producing unnecessary work

3

How efficiency varies across different types of tasks (short-form, long-form, reasoning, or multimodal)

For enterprises, individuals request compounds. Organizations processing thousands of requests per day can see, at a glance, which models, environments, and team members are driving the highest spend and emissions. This enables per-department cost allocation, identification of wasteful patterns (such as failed requests that consume compute without producing output), and data-driven budgets for Al usage. Sustainability teams can extract the data needed for ESG reporting. Engineering managers can identify which workflows are efficient and which need optimization.

For enterprises, individuals request compounds. Organizations processing thousands of requests per day can see, at a glance, which models, environments, and team members are driving the highest spend and emissions. This enables per-department cost allocation, identification of wasteful patterns (such as failed requests that consume compute without producing output), and data-driven budgets for Al usage. Sustainability teams can extract the data needed for ESG reporting. Engineering managers can identify which workflows are efficient and which need optimization.

2. Hardware-Level Monitoring

For organizations running self-hosted models, the OTM connects usage directly to physical activity at the hardware layer. Using accelerator and server-level metrics captured through direct monitoring, the methodology produces a real-time mapping between each token generated and its energy and carbon footprint. This enables infrastructure teams to identify underutilised GPUs, detect power spikes associated with specific workloads, and make informed decisions about hardware procurement and fleet sizing. The data is measured from the actual hardware, providing ground-truth accountability for infrastructure costs and environmental impact.

3. Cross-Provider Benchmarking

Today, organizations choose between Al providers based primarily on output quality and price per token. But price per token tells an incomplete story, it says nothing about energy efficiency, carbon intensity, or how computational effort varies by region and architecture. The OTM enables consistent comparisons across providers.

See this in action with the One-Token Model API

Our API brings token-level observability into a unified, real-time dashboard, enabling model comparison, prompt optimization, and precise allocation of AI costs across teams, products, and workflows. Organizations can benchmark performance, optimise AI workflows, and operationalise sustainable AI practices at scale.

Explore API

See this in action with the One-Token Model API

Our API brings token-level observability into a unified, real-time dashboard, enabling model comparison, prompt optimization, and precise allocation of AI costs across teams, products, and workflows. Organizations can benchmark performance, optimise AI workflows, and operationalise sustainable AI practices at scale.

Explore API

The application of the One-Token Model across usage, hardware, and provider layers enables organisations not only to measure impact but to translate those measurements into operational, economic, and environmental improvements. By exposing how efficiently tokens are produced, and used, whether in API-driven applications or self-hosted deployments, OTM provides the observability needed to guide optimization strategies. These strategies typically centre on three outcomes: cost reduction, performance efficiency, and emissions minimization.

Case Study: Improving Inference Efficiency in an Enterprise Deployment

A mid-sized organisation integrates an LLM-based assistant into its internal analytics platform. After an initial period of adoption, the engineering team observes that inference-related cloud costs and GPU activity are increasing at a rate disproportionate to the growth in user queries. To understand the source of the discrepancy, the organisation deploys the One-Token Model with the AT API, to monitor how much computational work is being performed per token and how efficiently that work is converted into user-visible responses.

Establishing a Baseline

Using OTM instrumentation, and the AT API, the team captures real-time metrics such as:

These measurements reveal the energy cost per token and highlight variations in efficiency across workloads and times of day. This baseline becomes the reference point for targeted interventions.

Targeted Optimization

Targeted Optimization with a clear view of the computation associated with each token, the organisation implements improvements along three dimensions:

For a production ready
implementation of the One-Token
Model API,
reach out to: contact@antarcticaglobal.com

See this in action with the One-Token Model API

Our API brings token-level observability into a unified, real-time dashboard, enabling model comparison, prompt optimization, and precise allocation of AI costs across teams, products, and workflows. Organizations can benchmark performance, optimise AI workflows, and operationalise sustainable AI practices at scale.

Explore API

See this in action with the One-Token Model API

Our API brings token-level observability into a unified, real-time dashboard, enabling model comparison, prompt optimization, and precise allocation of AI costs across teams, products, and workflows. Organizations can benchmark performance, optimise AI workflows, and operationalise sustainable AI practices at scale.

Explore API

As AI becomes more deeply embedded in products, workflows, and infrastructure, organisations need transparent and consistent ways to understand the computational, economic, and environmental consequences of their AI usage. The One-Token Model responds to this need by grounding measurement in the most consequential unit of inference, tokens, and linking that unit directly to the hardware activity, and provider architectures that drive energy consumption and emissions.

This whitepaper represents an effort in consolidation. We have synthesized insights from fragmented research, benchmarks, and disparate methodologies into a unified, systematic framework. By combining hardware-aware estimation with a normalized representation of token-level compute, the OTM establishes a common analytical layer for evaluating AI workloads across open-source, hybrid, and proprietary environments. This gives organisations a clearer basis for decisions related to model procurement, budgeting, capacity planning, and sustainability reporting.

At Antarctica, our core value is bringing radical transparency and measurable value to every company deploying AI. We believe that sustainability, FinOps, and operational efficiency are not opposing goals but shared outcomes. Our mission with the OTM is to make Sustainable AI actionable inside organizations, ensuring that the growing body of research is not merely theoretical, but is implemented to drive tangible impact.

When deployed in production systems, the OTM supports operational optimisation: reducing cost, improving performance efficiency, and lowering emissions without constraining capability. The OTM is a living standard. We are already actively developing Version 1.1, which addresses the limitations identified in this paper to provide an even more granular view of inference. V1.1 will expand the energy envelope to strictly account for CPU, RAM, and networking overhead, and will fully integrate the Antarctica Token, our normalization layer designed to make cross-provider benchmarking consistent.

The need for reliable, cross-provider measurement standards will only grow as AI becomes more ubiquitous and heterogeneous. We are now moving from consolidation to application. The One-Token Model represents a step toward that standardisation by aligning operational clarity with environmental responsibility, offering a practical and scientifically grounded path to understanding how modern AI systems consume resources and deliver value.