Energy Usage

Pentos estimates the energy consumed by each AI response, giving you visibility into the environmental impact of your conversations. We believe you should know the cost of the compute behind your AI usage, and we are committed to being transparent about how those estimates are calculated, where our data comes from, and what the limitations are.

Where to View

• Per message: Open the Message Info panel for any AI response to see its estimated energy, CO₂, and water.
• Per chat: Open the Chat Info panel to see the total estimated energy, CO₂, and water for the whole conversation.
• Across all your chats: Open the Usage page in Settings to see your total estimated energy, CO₂, and water, then select any of them to open the Environmental Impact view, which adds relatable comparisons. The same page’s model breakdown can also be viewed by estimated energy, CO₂, or water, showing which models drive most of your footprint.

Units

Energy figures scale automatically to stay readable: a single message appears in watt-hours (Wh), while larger totals (a long chat, or your whole account) appear in kilowatt-hours (kWh). In the Environmental Impact view you can also switch the unit manually:

Our Approach

Energy transparency in AI is still a new field. Most AI providers do not publish the energy consumed by individual requests, which makes it hard to know the real footprint of your usage. To help address this, Pentos estimates the energy used to generate every AI response by implementing the EcoLogits open-source methodology and its per-token energy formula, plus our own published model for context cost, because the upstream standard doesn’t cover it yet.

Our guiding principles:

• Built on an open standard, not hand-waved: Our per-token energy values are produced using EcoLogits, an open-source (MPL-2.0) methodology maintained by the CodeCarbon non-profit. We implement a published standard so our numbers can be checked against it.
• Honest about uncertainty: No estimate for a closed model is a direct measurement. We label how each value was derived, and each value sits inside a likely range; we show its midpoint.
• Versioned and improvable: Our estimation formula is versioned (currently v2.2.0). When the underlying methodology improves, we update future estimates while preserving historical ones for consistency.

How Estimates Are Calculated

Every time an AI model generates a response, Pentos estimates the energy it consumed based on how much text the model read (input tokens), how much it generated (output tokens), the model’s size profile, how fast the model is served, and the data center’s facility overhead (cooling, networking, and so on).

The formula we use:

Energy (J) = PUE × (J_in × (m × fresh input + κ_read × cached input) + J_out × output tokens)

What each component means:

• Output tokens are the text the AI generates. Generating text is the most energy-intensive part of a request, so this is the dominant term. For models that “think” before answering, those internal reasoning tokens are counted here too.
• J_out (energy per output token) is calculated for every response with the EcoLogits methodology. It has two parts: the GPUs’ energy for each token, which grows with the model’s active parameter count at a representative serving batch size and with the number of GPUs needed to hold the whole model, and the rest of the server’s energy for the time it spends on that token. Larger models have a higher J_out. Speed matters too: a model served faster spends less server time on each token, so it uses less energy. We take that speed from the model’s measured output speed (tokens per second), the same figure behind its speed rating in the model picker, so when a model’s measured speed changes, its energy estimate moves with it. If a model’s speed has not been measured yet, EcoLogits’ own speed estimate for a model of its size stands in.
• Input tokens are the text you send, including the conversation history the model needs for context. Fresh input is the part the model has to process this turn; cached input is the part it can reuse from a previous turn.
• J_in (energy per input token) is set to 20% of J_out. Reading existing context is cheaper per token than generating new text, and the reason is architectural: processing your prompt happens in parallel and is limited by raw compute, while generating a reply happens one token at a time and is limited by memory bandwidth. Benchmarks that separate the two phases put their per-token energy ratio at roughly 1:5 on short prompts, narrowing to about 1:2 on long ones as attention cost grows. Combined with the input multiplier below, 20% reproduces that range. A defensible value sits somewhere between 20% and 40%, and we deliberately use the low end. This term is ours rather than EcoLogits’: the upstream methodology models output tokens only, so we add the input side and publish it here rather than leave it unstated.
• κ_read (cached input) is 10% of J_in, and cached tokens do not pay the input multiplier. On a cache hit the model skips the processing work entirely and only reloads the attention state it already computed, so those tokens cost far less than fresh ones.
• Input multiplier (m) accounts for the fact that very long conversations cost proportionally more per input token, because attention cost grows faster than linearly with context length. It starts at 1.0× for short messages (under 500 tokens) and scales up through 1.2×, 1.4×, 1.7×, and 2.1×, reaching 2.5× for prompts over 8,000 tokens. The 2.5× ceiling is a deliberate cap rather than a measured endpoint: real attention cost keeps climbing past 8,000 tokens, so for very long prompts this figure is more likely to understate the true energy than overstate it.
• PUE (Power Usage Effectiveness) is a standard industry measure of data-center efficiency. A PUE of 1.12 means the facility uses about 12% more energy than the computing hardware alone (cooling, networking, and overhead). Across the providers Pentos supports, PUE ranges from 1.09 (Google) to 1.20 (OpenAI and xAI), with Anthropic at 1.12 and Mistral at 1.16. The open-weight models (GPT OSS, Gemma 4, Kimi, GLM, DeepSeek, Llama, Nemotron, and Granite) are served on Cloudflare Workers AI at 1.15, so their estimates use that figure rather than their model maker’s.

Only AI responses consume energy in our estimates. Your messages are not counted because they do not trigger model inference on their own.

Where Our Data Comes From

Energy-per-token values come from EcoLogits, an open-source methodology for estimating the environmental impact of AI model usage, maintained by the CodeCarbon non-profit. Rather than guessing energy from a model’s price, EcoLogits estimates it from physical factors: a model’s active parameter count, the number of GPUs needed to hold its total parameters, the serving batch size, the server overhead for the time spent generating each token, and the data center’s PUE. The per-token energy figures are based on a regression fit to published, hardware-measured benchmarks. We run the EcoLogits formula ourselves for every response, using each model’s measured output speed, and we test our implementation against EcoLogits’ own reference code.

For models whose architecture is publicly known (such as open-weight models), we use their real parameter counts. For closed models, EcoLogits publishes an estimated parameter range for each model it covers (for the few it doesn’t cover, we use the entry of the closest comparable model), which is why each estimate has a likely low-to-high range. We use the midpoint of that range as the headline number.

One nuance: a few very large open models (such as Kimi K2.6 and Kimi K2.7 Code) are sparse Mixture-of-Experts models that only use a fraction of their parameters for any given token and are served in a compressed (quantized) form. For these, scaling energy by their full parameter count would overstate the real per-token cost, so we map them to the size category that matches the parameters they actually activate. This keeps their estimates comparable to other models of similar working size.

For one provider (xAI), no EcoLogits coverage exists yet, so those models are estimated by analogy to the closest comparable size category and carry the widest uncertainty.

Data-center efficiency values (PUE) come from EcoLogits’ provider table, which draws on provider sustainability disclosures (Google, Microsoft, AWS) and regional infrastructure data. Where no figure is published, a conservative default is used: 1.20 in general, and 1.15 for Cloudflare Workers AI (which serves the open-weight models, and sits between Google’s 1.09 and xAI’s 1.20).

Energy by Model

The table below shows the approximate energy per typical message for each model Pentos supports, as of 2026-10-13. “Typical message” assumes a short conversation (400 input tokens, 300 output tokens). These figures are a snapshot: because each estimate uses the model’s measured speed, a model’s energy moves when its speed changes. Actual energy also varies with conversation length and response size, and each value has a likely range around it.

Anthropic

OpenAI

Google

xAI

Mistral

Moonshot

Z.ai

DeepSeek

Meta

NVIDIA

IBM

What “How it’s derived” means:

Every figure is an estimate; the column says where the model’s parameter counts come from.

• EcoLogits: EcoLogits publishes parameter counts for this exact model, and we use them: the real counts for open-weight models, a likely range for closed ones.
• Estimated: EcoLogits doesn’t list this model yet, so we estimate its parameters: from the real published counts for most open-weight models (the very large Kimi models use a size category, as explained above), or from the closest comparable model or size category for closed ones. xAI has no EcoLogits coverage at all, so Grok carries the widest uncertainty.

What Affects Energy

• Model choice: Smaller, faster models (like Claude Haiku 5.5 or Gemini 3.5 Flash Lite) use far less energy per message than large flagship models.
• Conversation length: As a conversation grows, the model processes more context with each response, increasing energy per message.
• Response length: Longer AI responses generate more output tokens and consume more energy.
• Reasoning: Models that “think” before responding generate additional internal tokens that add to energy usage, sometimes significantly. (This is captured by counting those tokens, not by treating the model as inherently higher-energy.)

Reducing Your Energy Usage

The two biggest levers are the first two above: which model runs your message, and how much context you send it. Pentos gives you a feature for each, and both are on by default.

Smart Router

The Pentos Smart Router is built to choose the best model for each task. With recent advances in AI, lightweight models now handle increasingly complex work, so the router can send more requests to lighter models, reducing latency, cost, and energy without compromising quality on the tasks they suit. Heavier models demand far more energy per message than lighter ones, so steering simple work away from them is where most of the savings come from. The heaviest models use far more energy per message than the light ones, and the router never reaches for the most expensive tier automatically: Claude Fable 5.1, GPT 6 Astra, and Claude Opus 5.5 are manual selection only, and Fable 5.1 and GPT 6 Astra also require your own API key. GPT 6 Astra and Claude Fable 5.1 are also the two highest-energy models in the table. Gemini 4 Argon and Gemini 3.1 Pro come next; the router can select them, but only when a message genuinely calls for that tier.

Here’s an example using two models from the same provider, both with published EcoLogits estimates. A typical message on GPT 6 Luna, OpenAI’s most efficient GPT 6 model, costs about 162 J (0.05 Wh). The same message on GPT 6 Astra, OpenAI’s flagship, costs about 24,991 J (6.94 Wh), roughly 150 times as much. When a lighter model can do the job, choosing it over the flagship saves about 99% of the estimated energy for that message.

The savings apply only when a lighter model is genuinely up to the task. When your message needs more power, the router escalates to a heavier tier on purpose, because a worse answer isn’t a saving.

Lean Mode

Lean Mode caps a chat’s context at your last 10 messages instead of resending the whole conversation with every response. On a long thread, most of that older history is not shaping the current answer anyway, so trimming it saves energy with little effect on quality.

The savings grow with the length of the conversation:

These percentages reflect the reduction in the context (input) energy of each reply, since Lean Mode changes only how much history is sent, not how the reply is generated. With about 200 tokens per message, a reply in an N-message chat normally processes roughly N times that context, while Lean Mode caps it at the last 10 messages, so the reduction works out to about 1 − 10/N. Because this depends only on token counts and not on the model, it holds no matter which model runs your message. It also leaves out the extra attention cost that long, untrimmed contexts incur: counting that, the context energy saved on a 100-message chat is closer to ~94%, and the reduction in the reply’s total energy (context plus generation) is about 92%.

Three assumptions sit behind those figures, and they move it in both directions. The table assumes messages are roughly uniform in length: a large paste or attachment sitting in the trimmed part of the history saves more than the table shows, while the same paste sitting in the retained last 10 saves less. It assumes no untrimmed floor: your system prompt, saved memories, personalization context, and any persistent attachments are sent either way, and they dilute the percentage at every conversation length. And it compares against an untrimmed reply that reprocesses its full history each turn. When prompt caching is active, an untrimmed chat can reuse much of that history at a small fraction of the cost, which narrows the gap; because Lean Mode’s rolling window changes where the context starts on every turn, it benefits less from caching than a stable untrimmed one does.

The ~200 tokens per message is a demonstration figure, and your own chats will vary. Since Lean Mode only sends the most recent messages, the AI may not recall something from earlier unless it was saved as a Memory and Personalization is enabled. We recommend Lean Mode for focused, task-by-task work, not for demanding research where you might need the full context of the chat.

Smart Router and Lean Mode work independently, but the savings stack when you use them together.

Carbon Impact

Beyond energy, Pentos estimates an approximate carbon footprint for each response. It appears next to the energy figure in Message Info, Chat Info, and the Usage page, and in more detail in the Environmental Impact view. This turns an abstract number of Joules into something more tangible.

The conversion uses the standard location-based method:

CO₂ (grams) = Energy (kWh) × Grid carbon intensity (gCO₂e/kWh)

We use the average carbon intensity of the electricity grid where each response is generated. That location is set by who runs the model, not who made it:

• United States (384 gCO₂e/kWh): models served directly by OpenAI, Anthropic, Google (Gemini API), and xAI.
• France (41 gCO₂e/kWh): Mistral models, served by Mistral’s API in its default EU region.
• Global average (458 gCO₂e/kWh): the open-weight models served on Cloudflare Workers AI (GPT OSS, Gemma 4, Kimi, GLM, DeepSeek, Llama, Nemotron, and Granite), since Cloudflare serves them across its global network rather than from one region, plus any provider without a known location.

These grid figures are Ember’s 2025 data, as published by Our World in Data, the same data EcoLogits uses. They are location-based: they reflect the physical electricity mix rather than renewable-matching certificates. The location is a fixed assumption for each provider, not something we observe for each request.

To make the number relatable, the view also shows everyday equivalents, each drawn from an authoritative source:

• Miles driven in an average gas car (about 400 gCO₂ per mile, EPA).
• iPhone charges (about 15 Wh of energy per full charge).
• Minutes of video streaming (about 0.6 gCO₂ per minute, IEA).

These are estimates, not precise measurements. Real emissions depend on where and when the compute runs, and some providers match their usage with renewable energy on a market basis, which a location-based figure does not credit. We show the location-based number for honesty and label its source directly in the view.

Water Impact

Pentos also estimates the water behind each response, shown next to its energy and CO₂. The estimate has two parts:

• Cooling (on-site): the water a data center consumes to cool its servers.
• Electricity generation (off-site): the water power plants consume to generate the electricity the data center uses.

In words: the servers’ share of the energy (total energy divided by PUE) times the cooling water factor, plus the total energy times the electricity-generation water factor. This is the formula EcoLogits uses, from research by Li et al. (2025):

Water (liters) = (Energy (kWh) ÷ PUE) × On-site WUE + Energy (kWh) × Off-site WUE

WUE (Water Usage Effectiveness) is measured in liters per kWh. The factors depend on where inference runs, using the same locations as the CO₂ estimate:

Where these come from:

• United States cooling: the average site WUE of US data centers through 2023, from Lawrence Berkeley National Laboratory’s 2024 United States Data Center Energy Usage Report.
• France cooling: the average reported WUE of EU data centers in 2024, from the European Commission’s 2026 report on the energy efficiency of data centres in the EU. It counts total water input, so it likely reads high.
• Global average cooling: a stand-in. No measured global average exists, because few operators publish their WUE, so we use the higher of the two measured regional averages.
• Electricity generation: EcoLogits’ electricity-mix data, based on World Resources Institute data.

Electricity generation makes up about 90% of every water figure. Cooling is the part most people picture, but electricity generation is the largest contributor to a data center’s water footprint (Mytton, 2021), so leaving it out would understate yours.

The Environmental Impact view also shows your water estimate as glasses of water (250 mL each). Like the CO₂ figure, these are averages for where inference runs, not measurements of a specific data center.

Accuracy and Limitations

These are estimates, not exact measurements. Real-world energy consumption varies with data-center load, hardware utilization, request batching, and infrastructure changes that Pentos cannot observe directly. In particular, every value assumes a representative serving batch size; the true figure can be higher or lower depending on how a provider actually serves a model. Our estimates are designed to give you a well-reasoned, openly-derived approximation, not a precise meter reading. When the underlying methodology improves, we update the estimation formula for future messages.

Sources

• EcoLogits: open-source methodology for estimating the environmental impact of generative AI (MPL-2.0; CodeCarbon non-profit). ecologits.ai · github.com/mlco2/ecologits
• Boavizta: the open hardware-impact data the methodology builds on. boavizta.org
• PUE values from EcoLogits’ provider table, drawing on provider sustainability disclosures (Google, Microsoft, AWS), with a conservative 1.20 default where none is published.
• TokenPowerBench: hardware-measured power consumption of LLM inference, attributed separately to the prefill and decode phases. This is the basis for our input-to-output per-token energy ratio. arxiv.org/abs/2512.03024
• Sarathi: characterizes prefill as saturating GPU compute while decode generates one token at a time at low compute utilization, which is why input tokens cost less per token than output tokens. arxiv.org/abs/2308.16369
• Ember: global and national electricity carbon-intensity data (2025) used for the CO₂ estimates, as published by Our World in Data. ember-energy.org · ourworldindata.org
• Lawrence Berkeley National Laboratory (LBNL), 2024: Shehabi et al., 2024 United States Data Center Energy Usage Report, the source of the US cooling water factor.
• European Commission, COM(2026) 500: Report on the energy efficiency of data centres in the EU (2026), the source of the EU cooling water factor. eur-lex.europa.eu
• Li et al., 2025: “Making AI Less ‘Thirsty’”, Communications of the ACM, the basis of the water formula (cooling plus electricity generation). doi.org/10.1145/3724499
• Mytton, 2021: “Data centre water consumption”, npj Clean Water, on why electricity generation belongs in a data center’s water footprint. doi.org/10.1038/s41545-021-00101-w
• World Resources Institute (via EcoLogits): the water consumed to generate each kWh of electricity, used for the electricity-generation water factors.
• EPA and IEA: reference factors for the everyday carbon comparisons (miles driven, video streaming). epa.gov · iea.org