What Eleven costs the planet

Both halves of the bill, published: what it cost to build, and what it costs to run.

The bill for building it

Eleven is built with AI, and AI burns real electricity — so we keep a public, running tally of the estimated carbon behind every AI token spent building this product. As of today it stands at roughly 19 kg of CO₂e (honest error bars: somewhere between 3 kg and 100 kg) for the entire build so far — about what a family car emits driving 110 km. The live number, the methodology, and everything it deliberately doesn’t capture yet are at status.elevenmessenger.com/carbon, part of the openness charter.

Inefficient builds efficient

Why spend that at all? Factor IX of the Eleven Factors says it plainly: use inefficient systems to create efficient systems. A large language model is a spectacularly inefficient way to compute anything — and the finest tool ever made for creating things that compute efficiently. The kiln burns hot so the brick doesn’t have to.

So the question that matters isn’t whether the kiln was hot. It’s whether the brick came out efficient. Here’s the brick:

• ~2 g CO₂e per member per year on Eleven’s architecture, at scale
• ~75 g the same figure for a conventional multi-tenant cloud stack
• ~30× the difference (estimates range 10–50×)
• 0.5 J of server energy per message, versus 20–30 joules conventionally

Put the two halves together: the entire AI bill for building Eleven so far equals the yearly running footprint of about 9,000 members on this architecture — or of just 250 members on the conventional one. The kiln pays for itself quickly when the bricks are this light. And right now, the whole production fleet — every space, every service, the AI helpers — draws less electricity than a nightlight: about 550 MB of RAM at a load average of 0.21 on two small CPUs, measured live.

Why the brick is ~30× lighter

The conventional way to run a service like this is one giant multi-tenant system on a big always-on cloud fleet: everyone’s rows in one database, thousands of servers provisioned for the busiest moment ever expected, an orchestration layer, a monitoring fleet, and analytics pipelines idling around the clock. Eleven’s advantage over that isn’t one trick — it’s four ordinary decisions that multiply:

• It sleeps when you do. Each space is its own tiny system that simply switches off when nobody’s chatting — costing nothing — and wakes in about a second. Group chats are quiet most of the day; a provisioned-for-peak fleet idles through all of it. Worth roughly 2–4×.
• Small, compiled programs. A whole running space — app, database, everything — fits in ~23 MB of memory; the industry-standard process for the same job wants hundreds of times more, plus a separate database tier that never sleeps. Worth 4–8×.
• No cloud tax. No orchestrator node pools, no service mesh, no observability fleet — the "control plane" here is a couple of programs the size of an instance. Worth 1.3–1.7×, and another 1.5–2× for having no always-hot database + cache + search tier.
• Privacy saves power. Because everything is encrypted before it reaches any server, there is nothing to index, analyse, mine, or "enrich" — every feature a server can’t see is a feature it can’t burn watts computing. Surveillance is expensive. Worth 1.2–2×, structurally guaranteed.

Multiply those and you get the ~30×. The full architecture story — one small space at a time, to billions — is on the planet-scale page.

The honest bits

• All of these are careful estimates with error bars — the build tally especially (per-token carbon figures are contested; we publish low, central, and high). The ratio between the architectures is sturdier than any absolute number, because most uncertainties hit both sides and cancel.
• Sleeping-when-idle is most of the running-cost trick. If every space chatted around the clock, the advantage would shrink to “only” 5–10×.
• The build tally doesn’t yet count everything (cache reads, cloud-side agent runs) — the page says exactly what’s missing rather than pretending completeness.
• The comparison gives the conventional stack the benefit of the doubt: a plain chat service, no analytics or data pipelines. Against a real surveillance-funded messenger, the gap widens.

The method, briefly

The running-cost side starts from live measurements of our production fleet, projected to a million spaces using the Cloud Carbon Footprint coefficients; the conventional side is calibrated against the best public data on well-run and typical fleets. The build tally counts our AI tokens against published per-token energy estimates, low/central/high. Working shown, both halves, at the carbon page.

Publish your numbers

This page exists to be checked — and copied. If you run a service, publish your numbers: what it draws, what it emits, what it cost to build. We’d be glad to be beaten. The point is that everyone who ships software should know, and say, what it costs the planet.

~2 g versus ~75 g of CO₂e per member per year: the difference between an infrastructure that sleeps when its members do, and one that idles at peak provisioning forever.

The whole philosophy: The Eleven Factors — especially IX, Inefficient builds efficient.