Global data-centre electricity consumption, including more than AI alone.
Keddeh Systems / Solving the AI Energy Crisis
More useful work.
Less wasted energy.
Solving the AI energy crisis is an ambition that calls for evidence. Our approach brings local context, reusable components and bounded intelligence closer to the work, then asks the question that matters: does the whole system use less?
An engineering direction, not a claim that the crisis is solved. No measured whole-system Keddeh saving is claimed.
People stay centralGuidance supports a person’s task and authority.
Roles stay boundedFile, guide and equipment agents remain distinct.
Results stay observableA promising design is followed by a measured test.
The challenge in context
Demand is growing.
The outcome is not fixed.
AI brings useful capabilities and a real infrastructure challenge. Electricity demand depends on efficiency, adoption and the kinds of tasks people run. Grid connections, equipment and chip supply constrain what can be built.
Projected global data-centre electricity demand. A forecast, not an inevitable outcome.
Less repeated work.
Reuse task context and defined components where it helps, then measure whether the complete deployment uses less energy.
Source: IEA (2026), Key Questions on Energy and AI, executive summary (source document in the references below). This evidence concerns demand growth and bottlenecks; it does not establish inevitable universal blackouts.
From the services actually observed
Compare the footprint.
Count the shared work once.
A small operating estate can share hosting, storage and browser execution. The starting point is the observed service inventory, followed by conventional alternatives with clear assumptions. Current Keddeh electricity and bills remain unknown; the figures below do not establish a saving.
Dated operating snapshot: 12 October 2026, approximately 03:43–03:48 UTC. This is a retained read-only snapshot, not a live dashboard. Browser qualification cited below occurred at 02:15 UTC that day.
Logical Sites deployments.
Page, application and API routes share Workers and storage. Five deployments do not establish five dedicated physical servers.
Logical hosts / ready idle workers.
Three ServerSpace host leases were fresh at observation; six worker threads were ready but idle. Physical placement and co-location are unknown.
Studios in one browser host.
Four Studios passed bounded install, launch and reload checks. They share browser execution; their client energy is not zero or included in a hosting price.
Read the resource samples and their limits
265.242 MiB gateway RSS
Sum of three Node gateway process reports. Target-side self-reported resident memory includes their worker threads; excludes Python supervisors, substrates, the operating system and other workloads. Shared memory pages may be counted more than once. This is not whole-host RAM or an electricity reading.
546 ms + 590 ms sampled CPU
Hosting-provider logs returned 100 frontage requests using 546 CPU ms and 100 runtime requests using 590 CPU ms. Both samples hit the 100-row cap and were mostly control-plane traffic. They are not complete hourly traffic, monthly usage, energy measurements or customer-load averages.
Source basis: Keddeh’s read-only deployment, host-lease and hosting-provider log inspection at the stated snapshot time, plus prior bounded browser qualification. No private host identifiers or raw logs are exposed here. No active mining, full Bitcoin Core node or neural inference workload is established by this snapshot.
Conventional alternatives
Shared cloud or
one consolidated host?
A like-for-like candidate must cover the hosted API and storage, resident Node/Python processes and the same client work. Capacity, isolation, backup, availability and response-time equivalence still need testing.
US$17/month, or US$19.40 with weekly VM backup.
One US$5 Workers/D1/R2 scenario plus one US$12 DigitalOcean 2 GiB VM for consolidated resident processes. The weekly percentage-based VM backup adds US$2.40. Before applicable tax; no currency conversion assumed.
This is a candidate architecture, not Keddeh’s observed invoice or a verified whole-estate replacement. Three isolated instances would change the price. A cloud bill does not reveal its allocated electricity.
Cloudflare Workers pricing · DigitalOcean VM and backup pricing
613.2 kWh / AU$274.99 per year before facility overhead.
One server at a named 70 W idle reference for 8,760 hours. With an illustrative PUE of 1.54: 944.328 kWh and AU$423.48 per year at the stated South Australian tariff reference.
This counts one consolidated server once. It is an idle benchmark scenario, not observed Keddeh power, a typical website requirement or proof of matched performance. Hardware and support costs are excluded.
SPEC R7715 result · AER tariff reference
Shared-cloud pricing assumptions and exclusions
The US$5 API/storage component assumes 2,000,000 Worker requests per month and 11,360,000 CPU ms. The request count is hypothetical. CPU is a scenario using 1,000,000 requests at each observed sample mean, 5.46 ms and 5.90 ms; those capped samples do not predict future load.
Additional assumed account-wide totals: D1 storage 0.1 GB, 1,000,000 rows read and 10,000 rows written per month; R2 Standard storage 5 GB-month, 10,000 Class A and 500,000 Class B operations per month. These are declared scenario inputs within the cited allowances, not measured full-estate totals. All usage must fit current limits and the account’s included allowances.
The resident-process VM candidate has 2 GiB RAM, 1 vCPU, 50 GiB SSD and 2,000 GiB monthly transfer. Its capacity and consolidation suitability are untested. If all compatible services can instead share this single VM, a VM-only alternative is US$12/month, or US$14.40 with weekly backup; equivalent durability and availability are not established.
Prices exclude applicable tax, domain fees, paid support, unlisted service usage, neural inference and extra replicas. Do not add the provider’s electricity to its bundled hosting bill. This is not a claim that the current stack fits a free tier.
Sources checked 12 October 2026: Workers plans and allowances, D1 pricing, R2 pricing and DigitalOcean Droplets and backups.
Editable conventional-host scenario
Change the assumptions. Keep the boundary visible.
One physical host, counted once. The visible defaults reproduce the dedicated-host example; none of these values is a Keddeh power measurement.
IT kWh = watts × hours ÷ 1,000. Facility kWh = IT kWh × PUE. Electricity cost = facility kWh × tariff.
Applies facility overhead once. Do not apply PUE again to a whole-facility meter or to browser devices. No fixed supply charge, hardware purchase, network, external storage or client energy is included. No input is sent or saved by this model.
Power, PUE and tariff source notes
SPECpower_ssj2008: Dell PowerEdge R7715, published 7 October 2025: 70.0 W active idle in the specified 160-core, 192 GB configuration. This is a large consolidation host, not a minimum web-host requirement. SPEC’s Java benchmark does not establish power or throughput for Keddeh workloads.
Uptime Institute 2025 Global Data Center Survey: weighted mean annual PUE 1.54 among 681 respondents. Used here as an illustrative factor. Site-specific PUE, including for the actual hosting providers, is unknown.
AER Default Market Offer 2026–27, final determination: South Australian small-business flat usage reference AU$0.448449/kWh including GST, applicable 1 July 2026–30 June 2027. It is a regulated reference cap, not Keddeh’s retail bill. The AU$1.855810 daily supply charge is excluded because it is not generally avoided by switching off a server.
The honest comparison today: observed logical services and bounded resource samples, alongside explicitly priced and powered conventional scenarios. Actual Keddeh watts, full traffic, physical allocation, provider bills and matched workload tests are missing. Energy and cost savings, including percentages, therefore remain unknown.
Have comparable measurements? Calculate their energy difference ↓Use your own readings
What would a power
difference mean?
Turn a measured or hypothetical average power difference into an energy estimate for your chosen period. The fields start empty: there is no assumed Keddeh saving. Positive results mean less electricity; negative results mean more.
Energy difference (kWh) = power difference (W) × hours × deployments ÷ 1,000.
An illustrative calculation, not a measurement or product guarantee. It excludes any power outside your chosen measurement boundary. No cost or carbon estimate is inferred. Inputs are calculated in this browser and are not sent or saved by this calculator.
A practical test
Measure the whole job.
- 01 · DefineSame task, same standard.
Choose a useful workload. Fix output quality, latency, completion criteria, run duration and comparable operating conditions.
- 02 · IncludeDraw the system boundary.
Account for active and idle local compute, reconstruction, network transfer, storage, remote services and allocated cooling. State any missing measurement.
- 03 · RepeatObserve rather than assume.
Use appropriate calibrated metering. Repeat baseline and proposed runs; report energy per completed task, total energy and uncertainty.
- 04 · DecideScale only what helps.
Check reliability, new demand and operational overhead. An efficient task can still increase total demand if usage grows. A negative saving is a valid result.
Choose your environment
One architecture.
Real working lives.
Follow a person through an illustrative day-to-day task. Each environment connects guidance, documents, equipment and services without treating them as one unrestricted agent.
Illustrative customer workflow
A better-prepared workshop.
A technician arrives with a job to finish. The guide brings the relevant instructions into view, while the equipment keeps its own bounded role.
- 01Ask with context
The person describes the repair. A local IL-LLM guide uses permitted job information, rather than starting from a blank conversation.
- 02Recover the right state
A file agent locates the authorised procedure and its identity. Reconstruction requires the referenced state and dependencies to be available.
- 03Choose the next action
The guide proposes a step; the person approves any handoff. An equipment agent can only use its permitted operations.
- 04Learn from readback
BRAINK augmented learning can relate an observed outcome to the task. Changed equipment or uncertain state calls for review.
Illustrative integration: neither this page nor the guide operates live machinery. Interlocks, isolation and safety-rated controls remain separate.
Illustrative customer workflow
Make the energy room legible.
In a factory energy room, a useful assistant helps an operator compare what was requested with what the equipment actually did.
- 01Read the situation
A local guide presents permitted equipment context and meter readings, when connected and validated.
- 02Keep roles separate
The file agent supplies the correct procedure. The equipment agent has a distinct identity and bounded command set.
- 03Authorise a handoff
The operator reviews the proposed action and its limits. No chat instruction bypasses electrical protection or site procedures.
- 04Check the result
Readback, exceptions and drift constraints keep a request distinct from a verified physical outcome. Measure energy across the same boundary.
Proposed integration, not an installed energy-management system. Switching, protection, metering accuracy and load ratings require target-specific engineering.
Illustrative customer workflow
Give every office task a smaller footprint.
A team needs the current document, the right service and a clear next step. Connected local context aims to reduce repeated setup across everyday work.
- 01Start close to the work
The local IL-LLM guide uses an authorised task context. Remote capabilities are brought in when the task requires them.
- 02Reuse a defined component
Double-wrapped HTML and VFS composition describe reusable, nested application components, with explicit dependencies and access boundaries.
- 03Transfer only what is needed
A file agent handles the permitted state; another service receives only the authorised handoff. Reconstruction still takes resources.
- 04Keep people in charge
BRAINK augmented learning supports task continuity. Changed sources, permissions or outcomes trigger a check rather than silent drift.
Illustrative workflow. Local deployment is not automatically more energy-efficient: idle power, model size, utilisation and remote work all matter.
Evidence before promises
Know what is built.
Know what comes next.
The energy case must connect working software to a representative physical deployment. A design relationship alone does not establish power consumption, safety or a whole-system saving.
What runs on this page.
These published guides, workflow choices and local calculator are software experiences. Their operation is testable; it does not verify a deployed equipment agent or energy benefit.
One context, distinct responsibilities.
Local-first IL-LLM guidance, BRAINK augmented learning, bounded agents, state reconstruction and modular power, compute and connectivity form the proposed integration.
Whole-system energy savings.
No measured whole-system Keddeh energy saving is presented here. Equivalent task quality, idle load, networking, cooling, reconstruction and remote compute must be included in a fair comparison.
Build a representative pilot.
Define one workload, engineer its interfaces, record a baseline, compare repeated runs and publish the boundary and uncertainty. Expansion depends on the result, not a promised date.
A connected architecture
How the proposed
integration works.
Local intelligence and bounded agent roles
IL-LLM is the local-first guidance layer; BRAINK provides augmented learning in the architecture. A guide agent, file agent and equipment agent retain separate responsibilities. Permissions, authorised handoffs, identity and drift constraints define where an action may go. Local-first is a deployment approach, not proof that every workload should run locally.
Vector relationships, KEX seed DNA and reconstruction
Vector relationships and KEX seed DNA describe identity and state reconstruction from defined seeds, rules and available dependencies. A finite seed cannot encode infinite arbitrary data. Recoverable content depends on the information actually present, available or generated by specified rules. Recovery, validation and transmission still consume time and energy.
Double-wrapped HTML, VFS and recursive composition
The design composes an inner application with an outer carrier, using a virtual file system (VFS) and nested components to preserve structured relationships. Reuse may reduce repeated copying, loading or recomputation where the workload supports it. Dependency management, isolation and the full cost of reconstruction still need testing.
Power, compute and connectivity as serviceable modules
The BRAINK hardware concept separates modular power, compute and connectivity so an integration can be engineered around its actual equipment. Replaceability may support a longer service life; manufacturing, maintenance and end-of-life impacts require separate lifecycle evidence. No certification or universal equipment compatibility is claimed.
Measurement sources and optional implementation guides
The workflow and its limits are explained above. Use a reference when you need the underlying source, equipment scope or implementation status.
Documents behind the comparison
- IEA 2026 · data-centre demand figures and projection
- SPECpower_ssj2008 · R7715 configuration and 70 W active-idle result
- Uptime 2025 survey · 1.54 weighted-mean PUE
- AER 2026–27 determination · South Australian tariff and supply-charge reference
- Cloudflare Workers · plan price, request and CPU allowances
- Cloudflare D1 · database storage and row pricing
- Cloudflare R2 · storage and operation pricing
- DigitalOcean · VM capacity, monthly price and backup options
Equipment and software scope
- Workshop integration brief · roles, interfaces and acceptance scope
- Factory-energy integration brief · roles, interfaces and acceptance scope
- Office-network integration brief · roles, interfaces and acceptance scope
- CENTRAL R1 · device interfaces and equipment applications
- Repair workflow · guide, file and equipment responsibilities
- KEX · state identity and reconstruction
- HTML App Studio · carrier, VFS and build boundaries
- Hardware engineering · discovery, sibling control and retained response
- Readiness roadmap · integration and qualification gates
- Green Futures · choosing a workload and resource-use priorities
A useful next step
Turn the comparison into a test.
Prepare a measurement brief with the task, output-quality requirement, baseline system, proposed system, metering boundary and test period. Include idle time, client work and remote services. The first deliverable is a repeatable comparison with missing measurements stated.
Opens an editable enquiry for review. Nothing is sent by following this link.