amadan

eleven / messenger Public

Clone 
git clone https://amadan.net/eleven/messenger

Plain git — no account needed to clone.

Download

Download this file

🤖 How the carbon compares

The third leg of the comparison series — the siblings are comparison.md (the product) and comparison-infrastructure.md (the architecture's prior art). This one estimates what the #550 architecture — one hibernating single-binary instance per space, state parked in S3 as ciphertext — costs the planet at scale, against the conventional alternative: a multi-tenant Rails monolith on a Kubernetes fleet with a big always-on database tier.

The short version: at a million spaces (~10M members), the Eleven model works out to roughly 10–50× more carbon-efficient, central estimate ~30× — on the order of 2 g CO₂e per member per year against ~75 g for the conventional stack. The headline mechanism isn't any one trick: it's that a compiled binary, in-process SQLite, scale-to-zero hibernation, no control plane, and E2EE-foreclosed server work multiply.

Everything here is a Fermi estimate with ±2–3× error bars, and the absolute numbers are softer than the ratio — most of the uncertainties (grid intensity, PUE, utilization assumptions) hit both sides and cancel. The inputs are real, though: the Eleven side starts from live measurements of the production fleet.

The measured starting point (production box, 2026-07-11)

The entire Eleven production — 15 running instances (every real space plus canaries), the router, all four sibling services (home, push relay, connect broker, cloud provisioner), and five AI bot sidecars — measured live:

| what | measured | |---|---| | A warm instance (whole app: server, DB engine, frontend) | 20–28 MB RSS, avg ~23 MB | | Router + all four sibling services | ~110 MB combined | | A Go bot sidecar | ~18 MB | | The whole fleet | ~550 MB RAM, load average 0.21 on 2 ARM vCPUs | | Hibernated instances (7 of 22 on disk at measurement time) | 0 MB, 0 CPU | | A space's entire E2EE history (SQLite ciphertext) | 1–16 MB |

That last table row pair is the whole story in miniature: the marginal cost of a sleeping space is a few megabytes of object storage, and the marginal cost of an awake one is ~23 MB of RAM and almost no CPU. Today's entire production draws a single-digit-watt slice of one shared server — less than a nightlight.

The scenario: 1M spaces, ~10M members

The anchor scale is the #550 plan's own 1M-space column. Coefficients are from the Cloud Carbon Footprint methodology (~2 Wh per vCPU-hour at typical utilization, ~0.39 W per GB of RAM, ~1 Wh/TB-hour for replicated object storage), AWS's published fleet PUE of ~1.15, and a location-based grid intensity of 350 g CO₂e/kWh (between the IEA global average of ~480 and typical European cloud regions; sensitivity discussed below).

The Eleven fleet

| assumption | value | basis | |---|---|---| | Spaces awake at any moment | ~10% (range 5–20%) | group chats are bursty; hibernation on idle | | Warm set | 100k × ~25 MB ≈ 2.5 TB active RAM; provision ~6 TB | measured RSS | | Messages | 10M members × 100/day ≈ 12k msg/s average | generous | | CPU | a few hundred vCPUs busy; ~1,000 provisioned | ~1–5 ms CPU per message incl. WS fan-out; RAM, not CPU, is the binding constraint (the live box serves everything at load 0.2) | | Space state | ~15 TB of SQLite ciphertext in S3 | measured 1–16 MB per space | | Attachments | ~100 TB on zero-egress object storage | the plan's figure |

Power: CPU 1,000 vCPU × 2 Wh/h ≈ 2.0 kW; RAM 6,000 GB × 0.39 W ≈ 2.4 kW; object storage (both buckets, 3× replicated) ≈ 0.3 kW; NLB, activator, sibling services, network ≈ +15%. Times PUE 1.15:

≈ 6 kW continuous (range 3–12 kW) → ~53 MWh/yr → ~18 t CO₂e/yr operational. Embodied carbon: this is only ~8–10 physical servers' worth of hardware plus a slice of the storage fleet — ~4 t/yr amortized over a 5-year life. Total ≈ 22 t CO₂e/yr ≈ 2 g per member per year, or about 0.5 joules of server energy per message.

The conventional comparator

The best public calibration point for a Rails fleet is 37signals' cloud exit: ~4,000 vCPUs and ~7.7 TB of RAM of purchased hardware to run Basecamp + HEY — order 1–2M users — and that's a famously lean shop (Kamal, no Kubernetes, tight packing). Scaled to 10M users: ~20,000 vCPUs, ~40 TB RAM, roughly 75–100 kW.

A typical multi-tenant Kubernetes deployment is materially heavier than that baseline. Industry container surveys (Datadog's container reports) put actually-used CPU at ~20–30% of requested; on top sit the control plane, service-mesh sidecars, the observability fleet (metrics, logging, tracing — commonly 10–20% of nodes), staging environments, and an always-on HA Postgres + Redis + search tier provisioned for peak with no scale-to-zero anywhere in the stack. That lands at ~150–300 kW — call it 200 kW central:

≈ 200 kW → ~1,750 MWh/yr → ~615 t operational + ~150 t/yr embodied (order 500 servers) ≈ ~750 t CO₂e/yr ≈ 75 g per member per year, or roughly 20–30 joules per message.

The ratio

| comparator | ratio | |---|---| | A lean Rails shop (37signals-grade, no K8s) | ~10–15× | | A typical enterprise K8s deployment | ~30–60× | | Central estimate | ~30× |

Where the ~30× comes from

The advantage is multiplicative across mostly-independent factors — which is why it's large, and why no single optimization on the Rails side closes the gap:

| factor | ~multiplier | why | |---|---|---| | Runtime: compiled Go + in-process SQLite vs Ruby/Puma + network-hop DB | 4–8× | a Puma worker is 500 MB–1 GB vs ~23 MB for an entire instance; language-energy studies (Pereira et al., SLE 2017) put Ruby at ~20× Go on CPU-bound work | | Scale-to-zero vs provision-for-peak | 2–4× | ~90% of spaces cost nothing at any moment; the multi-tenant fleet idles 24/7 at 20–30% utilization | | No control plane / sidecars / observability tax | 1.3–1.7× | the "orchestrator" is an activator + an S3 lease — a rounding error, not a node pool | | No hot database + cache + search tier | 1.5–2× | the database tier is often a third of a Rails fleet; here it's a file inside each process, and cold ones are parked ciphertext | | E2EE forecloses server-side work | 1.2–2× | no indexing, analytics, ML pipelines, image proxying, or transcoding — structurally impossible, not just declined; even image downscaling happens on the client |

The last row is the quiet one: E2EE is usually costed as a constraint. In carbon terms it's a subsidy — every feature the server can't see is a feature the server can't burn watts computing.

What this estimate is not

Honesty section, in the spirit of the siblings:

  • Hibernation is the entire trick. The marginal cost of an idle tenant actually favors multi-tenant — kilobytes of Postgres rows versus ~23 MB warm. Process-per-tenant without scale-to-zero would be worse than Rails, not better. If duty cycle approached 100%, the advantage shrinks toward just the runtime factor (~5–10×).
  • Grid intensity can dominate everything. A Rails app on a market-based-zero renewable contract versus this stack on a coal grid inverts the operational numbers. Embodied carbon — ~10 servers versus ~500 — favors the small fleet regardless of who signs which PPA.
  • Runtime AI inference isn't counted in the ratio. Heavy LLM use by the bot sidecars would dwarf either infrastructure's footprint — and applies to both models equally, so it cancels out of this comparison's ratio and dominates the absolutes. (It is at least measurable exactly: the sidecars run on an API key, so the provider console has precise token counts.) The live status-page run estimate does carry a small, bounded inference term (see The status page), and the AI cost of building the app is estimated in full — see the next section.
  • Client-side work moves joules, it doesn't create many. Crypto and image downscaling run on members' devices; the marginal energy per message on a phone is micro-joules against a battery already being spent on the screen.
  • The comparator is a plain chat app. A real product messenger with search, analytics, growth infrastructure, and data pipelines would widen the gap further; this comparison deliberately gives Rails the benefit of doing only what Eleven does.

What the AI that built it cost

The estimates above stop at the servers. But this codebase is AI-written, and the honest ledger has to include the tokens it took to write it — which turn out to dwarf, by orders of magnitude, the infrastructure they produced (at today's scale; at the 1M-space scale above, the fleet takes over).

The tokens are measurable. Claude Code keeps per-session transcripts with exact token counts. Summed over every session against this repo on the primary dev machine (the first measurement, 2026-07-03 → 2026-07-11, 162 sessions — transcripts from the repo's first week, 2026-06-27 → 07-02, had already been auto-pruned, so that week is extrapolated from the measured window's per-commit rate):

| | tokens | |---|---| | Output (generated text + code) | ~25M measured + ~9M extrapolated ≈ 34M | | Fresh input (prompt prefill) | ~145M measured | | Cache reads | ~7.9B measured |

The conversion is the soft part. No frontier lab publishes per-token energy or carbon. The best public calibration points disagree by ~30×: Google's production study of Gemini serving works out to roughly 0.1 mg CO₂e per output token, while Mistral's lifecycle study for Large 2 implies ~2.9 mg. We band with 0.1–3 mg CO₂e per output token, central 0.55 mg (the geometric mean), priced on output tokens only — decode dominates serving energy, and nobody publishes a price for cached prefill, which is ~97% of tokens processed here. That un-priced cache-read pile, plus cloud-side agent runs and any contributor machine that hasn't accrued its entries yet, make this a floor.

Result so far: ~6–180 kg CO₂e, central ~34 kg. To make that legible, the status page renders the central estimate as a set of everyday anchors (each factor documented under What the anchors mean below): about half a Dublin–London economy flight, ~15 hours of a petrol leaf blower, ~0.6 kg of beef, and ~1.6 tree-years to soak it back up — or ~200 km in a petrol car (~15 litres). E2EE keeps the servers from burning watts on members' content; the watts moved upstream, into the model that wrote the code.

This number accrues, so it's kept as a running tally: the ledger lives in web/status/carbon.json and publishes with the public dashboards at status.elevenmessenger.com/carbon.html (cumulative chart + per-period ledger; docs/status.md). It covers every contributor machine, each accruing entries under an anonymous stable source label, and keeping it up to date is automated: a SessionStart hook nudges any Claude session in this repo when its machine's entries go stale (the transcripts it measures from are pruned after about a week), and node tools/carbon-tally.mjs --write appends only what's newer than that machine's last entry — recipe in docs/status.md § Keeping the carbon tally accruing. A gap that slips past the pruning window gets an explicitly-flagged extrapolated entry, like the first week did.

The status page: two figures, built and run

The public page carries two ledgers, deliberately separate and neither editorialised against the other:

  • Built — the one-time AI cost of making the app (the tally above). It grows only when more AI development happens.
  • Run — the ongoing cost of operating the whole fleet, recomputed live at every publish. It rises with the fleet — one box today, fifty later.

They are two different things — one-time to make versus ongoing to operate, and rising with scale — so the page does not claim one is "bigger" than the other; the ratio between them is a moving target that says more about how young and how small the fleet is than about either number. The figure that stays meaningful at any size is the per-space run rate.

The run estimate, banded low/central/high. Computed at publish time in deploy/status-publish.sh (carbon_run_object), summing every service the stack needs:

  1. The router box + its instances. The Hetzner Cloud API gives each server's server_type (its vCPU count); the whole fleet is a lightly loaded, hibernating workload (load ~0.2 on the box), so its attributable draw is a low-single-digit-to-~15 W slice of the box, modelled as per-vCPU average watts — 1.5 / 3.5 / 7.5 W (marginal load-proportional → whole-box idle-inclusive). Times 24 h, times the box region's grid intensity, times PUE ≈ 1.15. The prod box is in Helsinki, so the Finnish grid ≈ 80–130 g CO₂e/kWh (a low-carbon, hydro/nuclear/wind mix); the low band takes the grid to ≈ 0 (Hetzner's EU sites run on a renewable-electricity contract), the high band to the location grid. vCPUs sum across every box in the account, so the term scales as boxes are added.
  2. Object storage (AWS). Our S3 use is a slice of ciphertext plus requests — near-zero, but stated as a small explicit banded term (~a gram a day), never folded to zero.
  3. Bot inference. The sidecars' ongoing Anthropic API use. Small today and bounded wide (the high band allows for busy days); precise token counts exist in the provider console, but the page publishes a bounded estimate rather than couple to a live spend feed.

The result publishes as a daily rate, a cumulative-to-date (the daily rate × days since the fleet's start — a first-order figure that assumes today's rate held), and per active space (denominator = the public instance count from the registry — never per-member, no member counts). At today's single box that lands at tens of grams of CO₂e per day for the whole fleet — less than a nightlight — and a per-space rate of a gram or so per space per day. All coefficients are honest bands, and the region grid is the one that can dominate everything (see below).

What the anchors mean

The everyday equivalents shown beside both figures (each scaled to its own magnitude — the build total, and the run's cumulative-to-date) convert the central kg through published, banded factors. Snapshot July 2026; these move, so re-check before quoting.

| anchor | factor (central) | band | source class | |---|---|---|---| | Petrol car | 170 g CO₂e/km; 1 L petrol ≈ 2.3 kg | ±~15% | DEFRA/EPA average passenger car | | Short-haul flight | 0.145 kg CO₂e per economy passenger-km, incl. the non-CO₂ altitude uplift (~1.9× radiative forcing) | 0.13–0.16 | DEFRA short-haul-with-RF economy class | | Leaf blower | 2-stroke ~1 L/h → ~2.3 kg CO₂/h | ±~25% | EPA small-engine fuel burn × petrol EF | | Beef | ~60 kg CO₂e/kg (land-use-inclusive) | 40–100 | Poore & Nemecek (Science 2018) / Our World in Data | | Tree-years | a mature tree absorbs ~21 kg CO₂/yr | 10–40 | EPA / arboricultural estimates |

The flight is expressed against one real short leg — Dublin–London (DUB–LHR) ≈ 460 km great-circle → ≈ 67 kg CO₂e per economy leg — so "half a Dublin–London flight" is ~34 kg. The uplift matters: without the radiative-forcing multiplier the same leg is ~40% lower, so the page names it explicitly. Distances and volumes convert with the metric/imperial toggle; the mass anchors (beef) convert too; counts and durations (flights, leaf-blower time, tree-years) are unit-agnostic.

The one-sentence version

~2 g versus ~75 g 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.

Sources

Snapshot as of July 2026 — coefficients and grids move; re-measure before quoting.