Forem: Dario Castañé

The Honest Climate Case for AI

Dario Castañé — Fri, 10 Apr 2026 15:02:50 +0000

Most articles about AI and the climate answer a question that doesn't matter. Defenders spend thousands of words proving your personal ChatGPT use is negligible, which is true but beside the point. Critics warn that AI will cook the planet, which is not supported by any serious projection. Both camps avoid the actual question: how fast is aggregate AI demand growing, what will power it, and what will it enable?

Feeling guilty over a 0.3 Wh query is about as useful as holding your breath to fight climate change. Any industry that uses about 1.5% of the world's electricity, like air conditioning or industrial motors¹, shouldn't be a cause for concern. The real story is somewhere in the middle.

The 2026 snapshot

Global data centers consumed roughly 415 TWh in 2024, about 1.5% of global electricity.¹ AI-specific servers accounted for around 93 TWh in 2025, or about 0.3% of global electricity.² For comparison, residential air conditioning uses more than six times that amount, industrial motors use around forty times, and global video streaming sits in roughly the same ballpark as AI at 100–120 TWh.

A short query to a standard (non-reasoning) model like GPT-4o consumes about 0.3 Wh, roughly three seconds of microwave operation.³⁴ If you sent a thousand such queries a day, you'd rack up ~110 kWh per year, which is about 3% of what a typical Spanish household consumes annually.⁵

So on the narrow point, the "AI is fine" crowd is right. Someone who quits ChatGPT to "help the planet" while still eating beef and driving a combustion car is doing climate theater, not climate action. But this frame captures today's snapshot of a fast-moving target, and only for the simplest queries on the most efficient models. Three things make it misleading as a summary of where AI's climate profile actually sits.

The first thing: "average query" is a moving target

The 0.3 Wh figure applies to a short, single-turn query on a non-reasoning model. The industry has dedicated the past eighteen months to the transition of users to reasoning models, including o3, DeepSeek R1, Claude with extended thinking, and GPT-5, which require 10 to 100 times more energy per query. Measured benchmarks put o3 at around 33 Wh, GPT-4.5 at around 30 Wh, and Claude 3.7 Sonnet with extended thinking at around 17 Wh.⁶ These aren't edge cases. They're becoming the default.

Agentic workflows compound the shift. A single user request to an AI agent ("book me a flight", "refactor this module") can trigger dozens or hundreds of inference calls as the agent plans, searches, verifies, and iterates. The unit of energy cost is no longer a prompt. It's a task, and tasks can be arbitrarily compute-intensive.

The second thing: demand outruns efficiency

Every defender of AI's footprint eventually invokes efficiency, and the gains are real. NVIDIA's Blackwell is 25–50 times more efficient per token than Hopper.⁷ Algorithmic efficiency in pre-training triples roughly every year.⁸ Quantization, mixture-of-experts, and distillation all deliver genuine improvements.

The problem is that demand has been compounding faster. When per-query efficiency was supposedly improving quickly, ChatGPT processed roughly 1 billion prompts per day in December 2024 and 2.5 billion by July 2025, a 150% increase in just seven months ⁹. According to the IEA's central scenario, global data centers will be around 945 TWh by 2030 and 1,200 TWh by 2035. Their Lift-Off scenario reaches 1,700 TWh, about 4.4% of global electricity.¹

This is Jevons paradox in real time. Meta spent 50% more on AI after DeepSeek showed off its cutting-edge capabilities in January 2025 at a fraction of the cost of training. Microsoft, Google, and Amazon held or increased capex. Satya Nadella posted about Jevons paradox on the same day DeepSeek dropped: "As AI gets more efficient and accessible, we will see its use skyrocket."¹⁰ Token prices collapsed by over 90% across the industry in 2025, and total inference spending more than doubled.

The streaming video analogy that sometimes gets invoked doesn't rescue this picture. Streaming kept energy flat despite exponential traffic growth because video is cached at the edge, so the marginal cost of one more viewer is close to zero.¹¹ AI inference can't be cached that way: every query needs fresh GPU computation. And unlike streaming, where humans have finite viewing hours, AI demand has no obvious ceiling because agents can generate queries continuously.

The third thing: the grid mix matters more than the chips

Here's the fact that gets lost in per-query debates: AI's climate impact depends almost entirely on what kind of electricity is feeding the data center, not on how efficient the chips are. A 1,700 TWh AI sector powered by renewables and nuclear is a footnote in the energy transition. The same sector running on gas and coal is a real problem.

In 2024, the carbon intensity of US data center electricity was approximately 48% higher than the national grid average, with a value of 548 gCO₂e/kWh compared to 369 gCO₂e/kWh. This is because data centers have clustered in gas-heavy regions such as Virginia.¹² The IEA's Lift-Off scenario predicts that fossil fuels will provide nearly half of the additional electricity for data centers between 2024 and 2030. Natural gas is expected to grow 1.5 times faster than the Base Case, with the United States experiencing the most significant absolute increase, and coal generation is expected to double, primarily in China.¹³ Google abandoned its net-zero goal in July 2025. Microsoft's emissions have risen roughly 23% since 2020 despite record renewable procurement.¹⁴

None of this is locked in. The same IEA report projects renewables meeting half of data center demand growth by 2030, with nuclear (including the first small modular reactors) contributing meaningfully after 2030.¹ Tech companies have committed over $10 billion to nuclear partnerships. Microsoft is restarting Three Mile Island. The money is real; the timelines are long. AI is forcing a binary choice: build clean firm generation fast enough to feed new demand, or lock in gas infrastructure that will be running in 2050. That choice is being made now in permit queues and interconnection agreements, and it has very little to do with whether you send another ChatGPT query today.

The positive case, stated without hype

The IEA predicts that the widespread adoption of current AI applications, including grid optimization, materials science, logistics, precision agriculture, and building efficiency, could reduce global emissions by approximately 5% of energy-related CO₂ by 2035. That's larger than the emissions from the data centers running those applications, even in the Lift-Off scenario.¹⁵

The qualifications are important. The IEA calls this figure an "exploratory analysis" rather than a projection and explicitly warns there is "currently no momentum" ensuring widespread adoption.¹⁵ It assumes aggressive deployment in sectors where deployment has been slow. It assumes rebound effects don't eat the savings, though rebound effects are well-documented: cheaper autonomous trips mean more trips, and cheaper AI-optimized shipping means more stuff shipped.

Genuine examples are emerging. DeepMind's cooling AI reduced Google data center cooling energy by roughly 40%.¹⁶ AlphaFold compressed decades of protein structure research into a few months.¹⁷ At a fraction of the compute cost, GraphCast performs better than traditional weather models. ¹⁸ These aren't experimental; they're being used in real-world settings.

The honest positive case is this: AI's potential climate benefits probably exceed its energy costs, but only if the benefits actually get deployed, the energy is clean, and rebound effects don't eat the gains. "AI will save the climate" is as lazy as "AI will destroy it."

What individuals should do

Stop feeling guilty about prompts. Your Wh per query is not the lever that matters. You'll do more climate good by eating one less steak, taking one fewer flight, or voting for better energy policy than by boycotting LLMs.

What matters at the individual level is where you direct your attention. Demand the acceleration of the deployment of clean generation to meet data center demand; grid interconnections, nuclear licensing, transmission lines, and permitting reform are the bottleneck, not GPUs. Advocate for transparency requirements on AI companies' operational emissions. Treat "AI for climate" claims with the same scrutiny you'd apply to any corporate sustainability marketing. Some of it is real; plenty is PR. And use AI where it genuinely makes you more effective at things that matter, including climate work. The question isn't "Is this query free?" (none are) but "Is this query worth it?" (many are).

What policymakers should do

The meaningful levers are systemic: carbon-aware siting rules that require new data center builds to demonstrate grid capacity, water availability, and carbon intensity below thresholds; mandatory energy reporting at the workload level, not just the facility level, because you can't manage what you can't measure; clean firm power built at the pace of demand through nuclear, geothermal, long-duration storage, and accelerated permitting; water accountability in stressed regions; and a firm refusal to let efficiency metrics substitute for absolute emissions reductions. The climate responds to absolute emissions, so that's what policy should target.

The bottom line

AI's current climate footprint is modest. It's comparable to streaming, smaller than air conditioning, and a rounding error next to steel, cement, transportation, or agriculture. Individual AI use is not a meaningful climate decision for most people.

The trajectory is a different story. AI is the fastest-growing source of new electricity demand in advanced economies, one of the few sectors where emissions are rising while most are flat or declining,¹ and it concentrates grid strain in specific regions in ways that will shape what generation gets built this decade. Efficiency gains so far are being reinvested into more capability rather than banked as energy savings.

The most honest thing that can be said is that whether AI turns out to be good, bad, or neutral for the climate depends almost entirely on the electricity mix feeding the data centers. Clean firm power, and the benefits will outweigh the costs. Gas and coal, and we'll have built out fossil infrastructure for a generation to run chatbots and image generators. At this very moment, that choice is being made in lines for grid interconnection, permit offices, and public utility commissions, not in your ChatGPT tab.

If you care about this, pay attention to the infrastructure decisions. That's where the outcome actually gets determined.

IEA, "Energy and AI", April 2025. https://www.iea.org/reports/energy-and-ai ↩
Gartner, "Electricity Demand for Data Centers to Grow 16% in 2025 and Double by 2030", November 2025. https://www.gartner.com/en/newsroom/press-releases/2025-11-17-gartner-says-electricity-demand-for-data-centers-to-grow-16-percent-in-2025-and-double-by-2030 ↩
Epoch AI, "How much energy does ChatGPT use?", February 2025. https://epoch.ai/gradient-updates/how-much-energy-does-chatgpt-use ↩
Andy Masley, "What's the full "hidden" climate cost of a ChatGPT prompt?", August 2025. https://www.andymasley.com/writing/whats-the-full-hidden-climate-cost/ ↩
Endesa, "Household energy consumption in Spain (INE) and how to save", (~3,264 kWh/year). https://www.endesa.com/en/blogs/endesa-s-blog/light/energy-consumption-in-spanish-households ↩
Jegham et al., "How Hungry is AI?", arXiv:2505.09598, May 2025. https://arxiv.org/abs/2505.09598 ↩
NVIDIA Developer Blog, "Introducing NVFP4 for Efficient and Accurate Low-Precision Inference", June 2025. https://developer.nvidia.com/blog/introducing-nvfp4-for-efficient-and-accurate-low-precision-inference/ ↩
Epoch AI, "Trends in Artificial Intelligence", February 2026. https://epoch.ai/trends/#training-runs ↩
TechCrunch, "ChatGPT users send 2.5 billion prompts a day", July 2025. https://techcrunch.com/2025/07/21/chatgpt-users-send-2-5-billion-prompts-a-day/ ↩
NPR Planet Money, "Why the AI world is suddenly obsessed with a 160-year-old economics paradox", February 2025. https://www.npr.org/sections/planet-money/2025/02/04/g-s1-46018/ai-deepseek-economics-jevons-paradox ↩
IEA, "The carbon footprint of streaming video: fact-checking the headlines", December 2020. https://www.iea.org/commentaries/the-carbon-footprint-of-streaming-video-fact-checking-the-headlines ↩
Gupta et al., "Environmental Burden of United States Data Centers in the Artificial Intelligence Era", arXiv:2411.09786. https://arxiv.org/abs/2411.09786 ↩
IEA, Energy and AI, "Energy supply for AI", April 2025. https://www.iea.org/reports/energy-and-ai/energy-supply-for-ai ↩
MIT Technology Review, "We did the math on AI's energy footprint", May 2025. https://www.technologyreview.com/2025/05/20/1116327/ai-energy-usage-climate-footprint-big-tech/ ↩
IEA, Energy and AI, "AI and climate change", April 2025. https://www.iea.org/reports/energy-and-ai/ai-and-climate-change ↩
DeepMind, "DeepMind AI Reduces Google Data Centre Cooling Bill by 40%", July 2016. https://deepmind.google/blog/deepmind-ai-reduces-google-data-centre-cooling-bill-by-40/ ↩
Demis Hassabis, John Jumper, Pushmeet Kohli and Anna Koivuniemi, "AlphaFold: Five years of impact", https://deepmind.google/blog/alphafold-five-years-of-impact/ ↩
Remi Lam, "GraphCast: AI model for faster and more accurate global weather forecasting", November 2023. https://deepmind.google/blog/graphcast-ai-model-for-faster-and-more-accurate-global-weather-forecasting/ ↩

Hello world from a WASM module in a static binary

Dario Castañé — Sat, 22 Feb 2025 12:27:38 +0000

These are some quick notes documenting a Saturday morning's experiment. All the steps were executed on Linux.

TL;DR: What?

Compiling a static binary that runs a compiled Ahead-of-Time (AOT) WASM module.

Ideally it'd have been WASM bytecode compiled to native code, but I couldn't find a way that didn't rely on the WASM runtime, invoking it from the command line or embedded in a C program.

Why?

I've been thinking and learning this week about WebAssembly and its potential since I read "WASM will replace containers".

I decided initially to use Wasmer and ended filing a question on their repository because their own native binary build command doesn't work as expected.

Finally, I landed on Bytecode Alliance's WebAssembly Micro Runtime (WAMR) wamrc compiler.

How?

The code

(module
  ;; Import the required WASI functions
  (import "wasi_snapshot_preview1" "fd_write" (func $fd_write (param i32 i32 i32 i32) (result i32)))

  ;; Define a buffer to store the message
  (memory (export "memory") 1)
  (data (i32.const 8) "Hello, World!\n")

  ;; Define the _start function
  (func $main (export "_start")
    ;; Setup the iovec array
    (i32.store (i32.const 0) (i32.const 8))    ;; pointer to the message
    (i32.store (i32.const 4) (i32.const 14))   ;; length of the message

    ;; Call fd_write
    (call $fd_write
      (i32.const 1)  ;; file_descriptor - 1 for stdout
      (i32.const 0)  ;; *iovs - pointer to the iovec array
      (i32.const 1)  ;; iovs_len - number of iovec entries
      (i32.const 20) ;; nwritten - where to store the number of bytes written
    )
    drop ;; Discard the result
  )
)

This is WebAssembly Text. Learn more here.

The tools

Everything had to be compiled from scratch.

wasm-opt isn't really required, so I'll skip it. I learnt about it while looking at these benchmarks, and I want these notes to keep track of the interesting tidbits I discovered.

The process

First, let's generate WASM bytecode from our WebAssembly Text code:

wat2wasm ./hello_world.wat -o ./hello_world.wasm

Next, compile it:

wamrc --format=aot -o ./hello_world.aot ./hello_world.wasm

For the last step, we need some C glue to embed the WAMR runtime:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "wasm_export.h"  // Now points to WAMR's core/iwasm/include/
#include "hello_world.h"

// Define a static pool buffer with proper alignment
#define POOL_SIZE (256 * 1024)  // 256 KB pool
static uint8_t global_pool_buf[POOL_SIZE] __attribute__((aligned(8)));  // 8-byte alignment

int main() {
    RuntimeInitArgs init_args;
    memset(&init_args, 0, sizeof(RuntimeInitArgs));

    // Configure memory pool
    init_args.mem_alloc_type = Alloc_With_Pool;  // Use pool allocator
    init_args.mem_alloc_option.pool.heap_buf = global_pool_buf;
    init_args.mem_alloc_option.pool.heap_size = sizeof(global_pool_buf);

    // Initialize the WAMR runtime
    if (!wasm_runtime_full_init(&init_args)) {
        printf("Runtime initialization failed.\n");
        return -1;
    }

    // Load the AOT module from the embedded blob
    char error_buf[128];
    wasm_module_t module = wasm_runtime_load(hello_world_aot, hello_world_aot_len, error_buf, sizeof(error_buf));
    if (!module) {
        printf("Load failed: %s\n", error_buf);
        return -1;
    }

    // Instantiate the module
    wasm_module_inst_t inst = wasm_runtime_instantiate(module, 65536, 65536, error_buf, sizeof(error_buf));
    if (!inst) {
        printf("Failed to instantiate: %s\n", error_buf);
        return -1;
    }

    // Call a function named "main" exported from the WASM module
    wasm_function_inst_t func = wasm_runtime_lookup_function(inst, "_start");
    if (!func) {
        printf("Function '_start' not found.\n");
        return -1;
    }

    wasm_exec_env_t env = wasm_runtime_create_exec_env(inst, 65536);
    if (!env) {
        printf("Failed to create environment.\n");
        return -1;
    }

    // Execute the function
    wasm_runtime_call_wasm(env, func, 0, NULL);

    // Cleanup
    wasm_runtime_deinstantiate(inst);
    wasm_runtime_unload(module);
    wasm_runtime_destroy();
    return 0;
}

The sharp reader may be asking "Where are the wasm_export.h and hello_world.h includes? The former is in wasm-micro-runtime/core/iwasm/include, and the later needs to be generated:

xxd -i hello_world.aot > hello_world.h

And we can compile and run it:

gcc -static $HOME/Code/hello-wasm/main.c $HOME/Code/wasm-micro-runtime/product-mini/platforms/linux/build/libiwasm.a -lm -I $HOME/Code/wasm-micro-runtime/core/iwasm/include -I $HOME/Code/hello-wasm -o $HOME/Code/hello-wasm/hello_world

$HOME/Code/hello-wasm/hello_world
Hello, World!

Note: it's not a perfect statically-linked binary. It depends on getaddrinfo, but this is better left out of scope right now.

Image by Duncan Cumming.

A portal between Ruby and Go (using FFI)

Dario Castañé — Tue, 06 Sep 2022 09:48:50 +0000

Thinking about migrating some huge REST APIs from Ruby to Go, I researched how to replace the Ruby code progressively with Go code.

I ended up with a possible FFI-based prototype. The solution is to have the Ruby code load a Go library and wrap the Go functions in Ruby classes and methods.

The Ruby side

The Ruby side is pretty straightforward. We must load the Go library and import the Go functions in Ruby classes and methods.

require 'ffi'

module Portal
  extend FFI::Library

  ffi_lib './libexample.so'

  class Example < FFI::Struct
    # This must be completely in sync with the C struct defined in Go code.
    layout :id, :int, :prefix, :pointer

    def initialize(prefix, id)
      self[:prefix] = FFI::MemoryPointer.from_string(prefix)
      self[:id] = id
    end

    # This feels convoluted, but it hides the fact that our function is loaded
    # outside of the "struct mirror" class.
    def greet
      Portal.greet(self)
    end
  end

  attach_function 'greet', [Example.by_value], :void
end

ex = Portal::Example.new('C', 137)
ex.greet

The Go side

The Go side is a bit more complex. We need to define a C-compatible struct and export the functions we want to use from Ruby.

The cool thing is that we can define the functions with the struct as the receiver.

package main

/*
struct example {
    int ID;
    char *Prefix;
};
*/
import "C"
import "fmt"

// This declaration is just an alias to the C struct.
type Example C.struct_example

//export greet
func (e Example) greet() {
    fmt.Printf("Hello from %s-%d\n", C.GoString(e.Prefix), e.ID)
}

func main() {}

The build

The build is also straightforward. We need to:

Compile the Go code to a shared library. This command will generate the CGO bindings.
Run the Ruby code.

go build -buildmode=c-shared -o libexample.so example.go
ruby portal.rb

The result

If we run the code, we get the following output:

Hello from C-137

The benefits

The main benefit of this approach is that we can progressively migrate the Ruby code to Go. We can start by replacing part by part, until we are ready to switch to a pure Go service.

It's not only possible to replace existing Ruby code. Now we can reuse RSpec/Minitest specs to test the new Go code. Instead of going for a full rewrite with no tests, we can start by testing the new code with the existing ones.

The (possible) drawbacks

Performance-wise this approach is not ideal. We are adding a layer of indirection. This probably adds some overhead to the calls. This is something we need to measure if applied to high-traffic services.

Simple Deno HTTP server running in Nanos unikernel

Dario Castañé — Wed, 25 Aug 2021 21:11:15 +0000

This short post shows how to get a self-executable Deno HTTP server to run in Nanos using Ops.

The server

const port = Number(Deno.env.get('PORT'));
const listener = Deno.listen({ port: port });

console.log(`http://localhost:${port}`);

for await (const conn of listener) {
  (async () => {
    const requests = Deno.serveHttp(conn);
    for await (const { respondWith } of requests) {
      respondWith(new Response("Hello world"));
    }
  })();
}

Compilation and local deployment

deno compile --allow-env --allow-net hello.ts
ops run -e HOME=/ -e PORT=8000 -p 8000 hello

The trick is to set the HOME variable. It can have any value, but / feels right.

Summary

In this post, we have seen a minimal Deno HTTP server working in a Nanos unikernel.

Hi, I'm Dario Castañé

Dario Castañé — Thu, 22 Jun 2017 07:25:50 +0000

I have been coding for too much years. I don't even remember. No, seriously, I was born in 1985 and I started to code in 1997.

You can find me on GitHub as imdario.

I live in Barcelona (Catalonia).

I work for Loyal Guru as tech lead.

I mostly program in these languages: Ruby, Go, etc. I consider myself a polyglot programmer.

I am currently learning more about blockchain, webcomponents, IoT, etc.

Nice to meet you and happy hacking <3