Make Every Useful Watt Go Further

Two services offer to help Mara with her letter. One produces a quick, clear answer that she can check. The other creates pages of confident language, misses the deadline in the original and requires several attempts to repair the result.

Counting each request as the same unit of useful work would hide the difference. So would measuring only the speed of the first response. The task is finished when Mara has a dependable result she can use, not when a machine has emitted enough words to look busy.

This is where efficiency should begin: with the work worth doing and the standard it must meet.

Better chips, software, cooling and operation matter. So does the decision about what to ask a system to do, which tool fits the task and how to avoid unnecessary repetition. A technically efficient process can still produce something nobody needs. A demanding computation can be worthwhile if it accomplishes a valuable task that simpler methods cannot perform adequately.

The aim is to get more human value from the resources we use. That requires more thought than making either consumption or novelty the only score.

We can be ambitious about capability and demanding about waste at the same time.

The unit has to match the question

A per-request measurement can help compare defined operations. It becomes misleading when the request is treated as a universal unit.

A short text answer, a long analysis, an image and a complex sequence of tool calls are different tasks. Even within one category, the amount of work can differ. A useful comparison should hold enough conditions steady to tell us something meaningful.

Google’s 2025 company-authored study reported a median Gemini Apps text prompt using 0.24 watt-hours in its measured period, including assigned idle and facility overhead. Its 0.26 milliliter water estimate concerned site cooling, using an annual fleet factor. These figures are provider-specific medians, not means, lifecycle totals or a universal footprint for AI requests. They should not be multiplied by all requests to estimate total use.¹

The lesson is to inspect the boundary before reacting to the number. A careful measurement can be valuable without applying everywhere. A company study can offer useful evidence while still needing independent scrutiny. An older estimate can become less informative as the system and workload change.

We should welcome better measurement and resist turning each new number into a slogan.

The public deserves comparisons that survive the footnote.

Compare a completed task

Suppose a local service office wants help sorting routine correspondence. It considers two tools and its existing process. The evaluation should begin with a sample of actual work, handled with appropriate privacy and security protections.

What counts as correct sorting? Which mistakes matter most? When must a person review a result? How much staff time is required to repair errors? What happens when a letter falls outside the ordinary categories? Can people still use the service if they cannot or do not want to use the automated channel?

Only after defining acceptable performance can the office sensibly compare resource use and cost. A cheaper process that creates an expensive pile of mistakes may be a poor bargain. A more capable tool may justify its resources on difficult cases while being unnecessary for routine ones.

This is an original procurement proposal rather than a claim that one method wins every test. The value comes from measuring the whole task rather than selecting the easiest flattering metric.

For a computing buyer, useful questions might include energy per completed acceptable task, total resource use over the trial, the amount of human correction and the level of service achieved. The exact measures depend on the work. They should be chosen before the result is known.

A clear test can reveal that AI is useful, that a simpler tool is better or that the process itself needs redesign. All three findings can save resources and improve service.

The winner should be the work, not the label on the software.

Fit the tool to the job

Imagine using a large workshop machine to sharpen a single pencil. It might work. The mismatch would still deserve a question.

Computing has its own versions of that mismatch. A routine operation may not need the most demanding available model. A repeated answer may not need to be recreated from scratch every time. A process may be able to separate simple cases from difficult ones, provided the sorting itself is reliable and privacy requirements are met.

These are design possibilities to test, not guaranteed savings from a recipe. A smaller tool that fails often can create more work. Reusing an answer can be inappropriate when the facts have changed or the task is personal. Routing hard cases to a stronger system requires a way to recognize them.

The principle is proportionality. Use enough capability to do the job well, and check whether the additional complexity earns its keep.

This principle can protect access. If every task is sold as requiring the most expensive service, people with fewer resources may be priced out of useful help. A range of well-tested options can serve different needs without assuming that low cost must mean poor quality.

Providers should make the choice understandable. Buyers should ask for evidence tied to their tasks. Public purchasers, in particular, should resist the pressure to display the newest tool before they have established whether it improves the service.

A good procurement is allowed to look less exciting than a demonstration.

Efficiency and growth can move together

Suppose an imagined service cuts the energy required for a given task in half. If the number and type of tasks remain the same, total energy for that work falls by half. If use doubles under the same conditions, the total returns to its starting level. If the work changes, we need a new account.

The arithmetic is simple. The actual future is not. Lower costs may encourage more use. New capabilities may create different tasks. Some activity may replace an older process, while other activity is entirely new. We should investigate those changes rather than declare in advance that efficiency will either solve everything or achieve nothing.

An improvement remains an improvement relative to the same work done less efficiently. Whether total demand rises is a separate question. Both questions matter for planning.

This distinction helps avoid a strange defeatism in which any increase in total use is treated as proof that efficiency was pointless. It also avoids the opposite mistake of assuming that a better per-task figure guarantees a smaller infrastructure need.

A growing service can become more efficient and still need additional supply. That is a reason to plan for growth and improve efficiency together.

The public bargain should reward genuine reductions in required resources without allowing them to substitute for evidence about the scale of the whole operation.

The resource you did not have to use

There is a quiet form of progress in work that no longer needs doing.

An imagined organization might discover that staff are using AI to rewrite a confusing internal form thousands of times. The tool helps each person. Fixing the form could remove much of the repeated task. The better outcome would combine a clearer process with assistance for the cases that still need it.

Another organization might generate long reports because nobody has defined the decision those reports support. A capable system can produce them faster, but speed does not settle whether they are useful. A shorter, well-designed record may save attention and computation at once.

These examples concern the design of work rather than a moral limit on curiosity. People should have room to explore, learn and make things for pleasure. Not every valuable use comes with a productivity metric. The point is to notice waste created by bad systems and remove it instead of celebrating how efficiently a new tool serves it.

We should ask what the technology helps us avoid as well as what it helps us produce.

Sometimes the most intelligent improvement is an answer. Sometimes it is a process that no longer forces everyone to ask the same question.

The machine has a life before and after the task

An operating-energy measurement does not describe the whole life of the equipment. Manufacture, transport, maintenance and end-of-use treatment raise additional questions. A responsible buyer should know when a claim stops at the electricity used during service and when it attempts a wider account.

This matters when comparing replacement with continued use. Imagine a new machine can perform the same work using less electricity, but replacing the old one requires new equipment and leaves the buyer with a disposal decision. The best choice depends on how much work will be done, the operating improvement, useful remaining life, repair options and the wider impacts being counted.

We should not assume either that replacement is always progress or that keeping older equipment is always responsible. A useful comparison names the time period and the service required. It considers whether equipment can be repaired, repurposed or transferred safely rather than treating every removal as the same outcome.

For a public procurement, the contract can ask for appropriate information about maintenance, support and responsible end-of-use arrangements. It can also clarify who owns the equipment and who carries the obligation when a service contract ends. Renting capability does not make the physical equipment disappear; it changes which party manages it.

The detail requested should be proportionate to the decision. The aim is to avoid a narrow saving that merely pushes an unexamined cost outside the chosen boundary. A complete enough account can recognize genuine improvements without demanding an impossible inventory of every distant effect.

The life of the machine belongs beside the life of the task. We need both to judge whether the next purchase is actually the better one.

Public buyers can ask better questions

A school district, local authority or public agency buying computing services can make its needs clearer than an ordinary consumer can. It can ask for consistent reporting and compare suppliers over a defined contract.

The request should be proportionate and feasible. A small procurement cannot reasonably demand that a vendor reconstruct every global supply chain. It can ask what is measured, what is estimated, which operations are included and how claims will be updated. It can request task-relevant performance evidence alongside resource information.

Contract terms can define reporting intervals, correction procedures and consequences for material misrepresentation. They can protect confidential information while requiring enough detail for independent assessment. They can also require a practical exit path so that a public service is not trapped if the product changes or stops meeting its needs.

These are proposed buying practices, not a statement that every public body already has the authority or expertise to use them. Building that expertise is part of the opportunity.

A shared evaluation method could help smaller institutions avoid repeating the same expensive work. Carefully designed cooperation can spread the cost of testing while preserving local judgment about the service people need.

The public should be a competent customer of progress, not a captive audience for it.

Give useful flexibility a useful payment

Efficiency reduces resources needed for a task. Flexibility changes when or where a task is done, or how its demand responds. The two can support each other, but they should not be confused.

An imagined service might use the same energy at a time when the network has more room. That could have value even without reducing its total energy. Another improvement might reduce energy across every hour without making the load interruptible. That could also have value.

A payment or incentive should match the service actually provided. If the benefit concerns relief during a constrained period, measure that response. If the benefit concerns lower annual energy, use a suitable baseline and account for changes in output. If both occur, avoid counting the same contribution twice.

Baselines need care because they describe what would otherwise have happened. An inflated baseline can make ordinary behavior look like a large saving. A rigid baseline can fail to recognize a genuine change. Independent review and transparent methods can improve the comparison.

Again, the purpose is to reward useful work. A company that reliably helps the system should be able to demonstrate that help and receive fair treatment for it. A company that only promises flexibility should not receive the same recognition as one that performs.

The meter and the agreement need to meet.

Access is part of the efficiency question

A society can become technically more capable while leaving ordinary people unable to use its gains. That is an inefficient social outcome even when the machines are well designed.

Imagine a small nonprofit that could save staff time with a reliable tool but cannot afford the service or the training needed to use it safely. Imagine a public office paying repeatedly for basic capability because its purchasing process cannot compare options. Imagine a household receiving an automated service with no accessible way to correct an error.

These problems require more than energy accounting. They belong here because the public is being asked to support the infrastructure that makes the service possible. The bargain should include a serious account of how useful benefits reach the people sharing the obligations.

Possible approaches include shared public procurement, accessible training, carefully governed public-interest computing capacity and affordable service options. Each needs a clear purpose, funding and safeguards. None is automatically justified by the words public interest.

A program should show whom it serves, what useful work becomes possible and how performance is checked. It should protect people from being forced into an unreliable system simply because they cannot pay for a human alternative.

Better tools should widen practical choice. They should not turn the cheapest citizens to serve into the only citizens worth serving well.

The household is not the system operator

An individual can make sensible choices: use tools when they help, check important outputs, avoid unnecessary repetition and prefer services that explain their practices. Those choices are worthwhile. They are not a substitute for the obligations of companies and public institutions.

Mara cannot negotiate a data center’s connection agreement each time she asks about a letter. She cannot see the exact cooling mode behind the response. She should not be made responsible for solving a supply chain that the provider itself describes only in broad terms.

The larger responsibilities belong with the actors who can act on them. Providers can improve operation and disclosure. Buyers can set standards. Regulators can govern shared costs. Public authorities can evaluate sites and protect resources. Users can participate in the public choices and use the resulting services with judgment.

This division of responsibility avoids both helplessness and misplaced guilt. It gives each participant a job that fits their power.

The person with the least control should not receive the most theatrical lecture.

More value from what we build

At the end of a good efficiency review, some tasks may use less computing. Others may use more because the results justify it. Some work may be shifted. Some may be removed. A few ambitious uses may require infrastructure that is worth building on responsible terms.

There is no shame in that variety. A serious economy does not aim to minimize every input regardless of what it produces. It aims to use resources well, meet human needs and respect constraints that cannot be wished away.

The public question is whether a growing system becomes more useful as well as larger. Does it help people finish work, improve access, make better decisions and develop capabilities they value? Are those gains reaching enough people to justify the shared commitments? Are the resources being used in ways we can explain and improve?

These questions resist an easy moral score. They lead toward practical choices.

Mara sends her letter after checking the dates. The tool has helped. Somewhere behind that small success, engineers can make the service more efficient, operators can honor a better agreement and public institutions can protect the systems it relies on.

The useful answer and the responsible infrastructure belong in the same ambition.

We should build for both.