Berget AI Per-Request CO2: Open Method Shows 8.5x Gap Between Texas and Sweden

Berget AI, a Swedish inference provider, says the same AI request emits roughly 8.5 times more CO2 in Texas than in Sweden, and it has published the open-source method behind that claim. The release, dated October 21, 2026, is a per-request carbon calculator under the MIT licence, built with the Stockholm Environment Institute (SEI), the nonprofit WattTime and the Swedish climate platform Klimatkollen. It is the rare AI-emissions number you can rerun yourself, which is also why it deserves scrutiny rather than a headline.

This post walks through what Berget published, what the repository actually contains, what the method leaves out, and what developers on Hacker News argued about. For the wider power-and-siting picture, see our coverage of the Google and Voltus virtual power plant and the New York data center moratorium fight.

TL;DR: the questions people ask first #

What exactly did Berget publish? #

The press release describes three things at once. First, a methodology that computes emissions for each request separately instead of applying a fleet average, because the result changes with the model, the time of day and whether part of the prompt is cached. Second, a console feature: Berget says customers can now follow their own emissions request by request, and that it has reported per-request CO2 for every API call since 2025. Third, a public calculator at co2.berget.ai and the code on GitHub.

The company's stated goal is market pressure. In the words of CEO Andreas Lundmark, "most companies today have no way of knowing what their use of AI emits," and he wants more providers to publish per-request figures so buyers can "compare providers on data instead of marketing." That is a procurement argument as much as a climate one.

Berget also says that, as far as it knows, it is the first inference provider to calculate emissions for every request on its own infrastructure and publish the method. That is a self-description we could not verify, and the release itself acknowledges prior outside-in estimators such as EcoLogits and the Sustainable AI Group's CLEER dashboard. The difference is that those tools estimate from outside the provider, while Berget uses data from servers it operates.

The headline numbers, unpacked #

Berget's worked example is a typical request to the open-weight model Kimi K3 (about 5,000 input tokens and 387 output tokens), calculated with version 1.1.1 of its npm package on a shared B300 node, weighted by a typical day of traffic.

| Texas (ERCOT) | about 333 g/kWh (EPA eGRID 2023) | about 3.2 g | Two details matter more than the ratio. The energy per request is about 4 Wh in both Sweden and Texas, so the whole spread comes from where the electricity comes from and what the cooling costs. And the composition flips: in Sweden roughly 89 percent of the 0.38 g is hardware manufacturing, while in Texas about 90 percent of the 3.2 g is electricity. Berget adds about 6 mL of cooling water for the Texas case.

Notice that Germany and Texas have nearly the same grid intensity in Berget's table (337 versus 333 g/kWh) yet different per-request results. That comes from assumptions such as cooling efficiency: the release cites a power usage effectiveness (PUE) of about 1.15 with free-air cooling in the Nordics, moving toward 1.8 and up to 2 L of water per kWh in hot climates. In the repository, Texas is configured at PUE 1.80 with "extreme" cooling, Germany at 1.35.

The correction worth reading

The release carries a correction dated the same day. An earlier, embargoed version claimed 1.2 g for Ireland, 2.1 g for Germany and 3.9 g for Texas and a ten-fold Texas-to-Sweden gap. A source review of the grid intensities changed them to the figures above and the gap to 8.5x. We think publishing that correction is a good sign about the process, and a reminder that any single headline multiple here is sensitive to inputs. If you quote "8.5x", quote it as Berget's estimate under average-grid, location-based accounting.

How the method works #

Server blocks with airflow lines illustrating cooling overhead in a per-request AI CO2 calculation

The repository, which describes itself as "published so the numbers can be checked," follows the Green Software Foundation's SCI for AI specification. Per request it adds up:

• GPU operational energy during inference, including idle draw (the release notes an idle B300 still draws 236 W, measured over seven days in production)
• Server overhead such as CPU, memory and networking
• Cooling overhead through PUE and a water-per-kWh factor
• Embodied carbon from manufacturing, estimated at about 1,000 kg CO2 per data center GPU, amortised over a five-year life, with refurbished hardware counted as zero
• Optionally, amortised training, which the live calculator turns off

A utilization parameter scales the fixed costs: the README's anchors are about 0.10 for your own server, 0.70 for a shared deployment and 0.90 for a hyperscaler. That single knob is where a lot of the real-world variation hides, and it is a reminder that a provider running its GPUs busy looks cleaner per request than the same hardware sitting idle.

The package ships 14 model profiles (Llama, Mistral, Gemma, GLM, Kimi K3, Whisper and others), 15 grid regions and 7 hardware configurations including B300, H100, H200 and MI300X. Its own comparison for Gemma 4 31B shows why the operational/embodied split matters: operational emissions are about 56.7 times lower in Sweden than on the US average grid, but because embodied carbon does not change with location, the total only falls about 7.2 times.

What the method does not count #

Berget is upfront about several limits, and they matter for how you use the numbers.

1. Training is excluded. The release says self-reported training figures vary by about plus or minus 50 percent. The README adds that amortised training would dominate totals for many models and is not comparable between open and closed models.
2. Chip manufacturing water and energy are not in the current version. The partners say they plan to extend it.
3. It is location-based, average-grid accounting. An alternative, marginal emissions, estimates the impact of additional load on existing plants and on new generation built to serve it. Berget says marginal estimates will be added to the calculator next month and "may significantly change" the measured intensity of Swedish data centres. Expect the Sweden figure to move.
4. Embodied carbon is uncertain. The README states a plus or minus 30 to 50 percent range because NVIDIA and AMD do not publish per-GPU lifecycle assessments, anchoring H100 values to NVIDIA's published HGX H100 baseboard footprint.
5. It is a provider's model of its own stack. The inputs are Berget's measured infrastructure. A different batch size, quantization or cache hit rate gives a different answer.

What developers are saying #

The Hacker News thread had roughly 80 points and a few dozen comments at the time of writing. Treat these as individual opinions, not findings.

• User jlundberg, who submitted the story, described it as based on a newly released, open-sourced model for calculating this.
• User armcat, who said they had worked on CodeCarbon in the past, suggested contributing the findings to that widely used ML emissions tool so the methods converge rather than fragment.
• User reedf1 argued that location arbitrage is partly an illusion: energy markets are linked through trade and prices, so a watt in Sweden still raises marginal cost elsewhere. That is close to the marginal-versus-average distinction Berget itself flags.
• User IshKebab asked why data centers are mostly built near populated areas when AI inference is not especially latency sensitive, a question that connects to the siting fights we track in ourThane, India data center protest coverage .
• User bob1029 pointed out that the reasoning-effort setting can change token use by up to two orders of magnitude between medium and maximum, so per-token figures understate how much a workflow choice matters.
• User alpineman compared a single burger to thousands of requests, a framing others disputed, which shows how contested the "does it matter" question remains.

Other comments argued over climate politics and some were jokes; we left those out.

What this means for what you build or pay #

A leaf-shaped bead moving to the clear side of a track, picturing a lower-carbon region choice for AI requests

If you call open-weight models through an API, region is now a visible variable. Open-weight models can run in any data center, and Berget cites Vercel's AI Gateway data showing open models at 29 percent of tokens in June 2026, up from 11 percent in April. For those models the buyer often chooses where the request runs, which makes per-request emissions actionable in a way it never was for a single closed API. Practical steps:

1. Ask your provider for per-request or per-token emissions data , including the method, whether embodied carbon is included, and whether the figure is average or marginal.
2. Compare regions, not just prices. When two regions have similar latency and cost, the grid difference in Berget's table is large enough to be a tiebreaker.
3. Cut tokens first. Caching prompts, trimming context and choosing a lower reasoning effort reduce energy in every region. Our guide toKimi K3 serving numbers claimed versus verified shows how much serving setup moves throughput.
4. Run the calculator on your own stack with your real utilization, and treat the result as an estimate to reconcile with metered power.

If you automate workloads with AI agents that can fan out into thousands of tool calls, the amplification effect is also a cost and safety question: runaway loops burn energy and money. AgentBeam, the agent security platform from the explainx.ai team, is built to stop agents before they take dangerous actions.

Context: why per-request accounting is becoming a policy topic #

Berget quotes the International Energy Agency's projection that data center electricity use will more than double to about 945 TWh by 2030, with AI the principal driver. SEI's research director Somya Joshi says efficiency gains "are likely to be outweighed by higher demand." The policy pressure is already visible in our reporting: a recent Ipsos poll found majorities opposing data centers, Finland halted site work on a Google data center, and hyperscalers are buying nuclear uprates to secure power.

Per-request disclosure is a way to turn a vague public debate into a number buyers can compare, which is the strategy Berget states. Whether other providers follow is the open question. A vendor-neutral standard such as SCI for AI helps, but the headline caveats above, especially excluded training and average-versus-marginal accounting, mean two providers can publish very different numbers for the same request and both be defensible. The most useful thing a buyer can do today is insist on the method, not just the figure.

Bottom line #

Berget's release is useful less for its 8.5x multiple than for the artifact: code, assumptions, grid sources and a correction note that a skeptic can inspect. It is a vendor's own estimate, it leaves out training, and its Sweden figure is about to be re-examined under marginal accounting. Use it as a template for asking better questions of any AI provider.

Figures are accurate as of October 23, 2026 and come from Berget AI's press release and repository; the company plans to update its method, so check the repository for changes.