How to reduce your AI carbon footprint

To reduce your AI carbon footprint, first avoid AI where a simpler tool will do, then choose the smallest model that can complete the task reliably. Keep prompts and context focused, request only the output you need, and avoid repeated generations. For regular or organisational use, favour services that disclose energy methods, use efficient hardware and obtain lower-carbon electricity in a credible way.

That order matters. Buying an offset or funding a tree can support climate work, but it does not remove the electricity, water or hardware used by the original computation. Direct reduction comes first. There is no reliable universal carbon figure per prompt, so concentrate on choices that reduce the underlying work and ask providers to show their boundaries.

Start with the task, not the model

The lowest-compute option is often a search, calculator, database query, template or ordinary piece of software. Generative AI is useful when the task genuinely needs interpretation, drafting or synthesis; it is wasteful when it merely recreates a result you already have.

Before opening a chat, define the outcome. Do you need a two-sentence summary, a checked calculation or a polished report? A clear endpoint prevents exploratory prompts from turning into dozens of disposable versions. Reuse a good answer instead of regenerating it for minor wording changes.

If exploration is the purpose, set a boundary in advance: a time limit, a number of alternatives or a decision the session must produce.

This is not an argument for avoiding valuable AI work. It is a proportionality test. UNESCO’s Recommendation on the Ethics of Artificial Intelligence asks AI actors to favour data-, energy- and resource-efficient methods and to assess environmental effects across the life cycle. Use enough computation to solve the real problem, not the maximum available by default.

Choose the smallest model that succeeds

Smaller models generally perform fewer operations and move less data for each generated token. For routine rewriting, classification, extraction and straightforward questions, that can reduce energy substantially. Our explanation of small language models covers where that advantage comes from.

“Smallest” is not the same as “small at any cost”. If a weak model produces errors and you rerun the task five times, it may be less efficient than one successful answer from a stronger model. Start small, check the result, and move up only when the task demonstrates that it needs more capability.

Specialised models can be better than general-purpose chat systems too. In a published comparison, researchers found that task-specific systems used less energy than general-purpose generative models for the tasks they evaluated. Those benchmark results are not a universal product ranking, but they support a practical principle: match capability to work.

When a service offers several model choices, make the lighter option your routine default rather than requiring a fresh environmental decision for every prompt.

Reduce tokens and hidden extra work

Long inputs and outputs require more computation. Remove irrelevant conversation history, attach only the pages that matter and ask for the length you will actually read. “Give me five options” is usually cheaper than asking for fifty and discarding forty-five.

A concise prompt is useful when it prevents ambiguity, but brevity alone is not the goal. An under-specified request can cause corrections and retries. Include the necessary facts once, set a clear format and stop when the answer is good enough.

Pay attention to modes that expand one visible request into several backend jobs. Web research, agents, image generation, video and repeated self-checking may call multiple models or tools. Use them when their additional value justifies the work. Turning every ordinary question into deep research is the computational equivalent of taking a lorry to collect one envelope.

Uploads deserve the same discipline. Cropping an image or selecting relevant document pages can avoid processing material that has no bearing on the answer.

Improve the system, not just individual prompts

Organisations have stronger levers than individual users. Measure requests by model, task, token volume and success rate. Cache repeated results, batch suitable jobs, remove duplicate calls and set sensible output limits. Route simple work to smaller models and reserve more capable systems for exceptions.

Utilisation matters because provisioned hardware can draw power while waiting. Efficient batching and autoscaling can spread supporting energy across more useful work. Hardware choice, numerical precision, quantisation and model architecture also affect the electricity required per result. Mixture-of-experts models, for example, activate only part of their parameters for a token, although memory and networking costs remain.

Track quality beside energy. A lower-energy model that fails a safety check or produces unusable output is not a sustainable improvement. Use a stable evaluation set and compare complete tasks, including retries, tool calls and human correction.

Set budgets as well as averages. A maximum token allowance, tool-call limit and monthly volume alert can catch waste that a good per-request efficiency figure conceals.

Prefer cleaner electricity without confusing the claim

Once computation is reduced, where and when it runs affects operational carbon. The same kilowatt-hour can be associated with very different emissions on different grids. Flexible training and batch inference may be shifted towards regions or hours with more low-carbon electricity.

Provider claims require care. The International Energy Agency notes that matching annual consumption with renewable purchases does not mean a data centre used renewable power in every hour. Its data-centres overview distinguishes annual contractual matching from the physical supply.

Look for location-aware or hourly information, new clean generation and a clear description of residual grid power. Our guide to renewable-energy data centres for AI explains these differences. Clean procurement can lower emissions; it does not erase chip manufacture, construction or water use.

For flexible organisational workloads, scheduling can matter too. Training, indexing and batch analysis may be moved away from high-carbon periods, while interactive requests usually have less freedom to wait. Carbon-aware timing should never compromise safety, service obligations or data-residency rules.

Measure a defined unit and publish the limits

A useful footprint has a boundary and a denominator: per completed task, per thousand requests or per customer, for example. Include operational electricity, the carbon intensity used and the hardware allocation where possible. State whether figures are measured, modelled or estimated.

The Green Software Foundation’s Software Carbon Intensity specification combines operational energy, location-specific carbon intensity and embodied hardware emissions per functional unit. It also keeps offsets outside the score. That is a sound discipline even when complete supplier data is unavailable: measure consistently, disclose gaps and improve the physical system.

Treechat applies the same hierarchy in a narrower consumer setting. It routes everyday questions towards smaller models and estimates energy from model and token use. The receipt includes stated data-centre and grid assumptions; it is not a meter reading or full life-cycle footprint. The current method is published at /methodology.

Reducing your AI carbon footprint is therefore less about perfect personal arithmetic than repeated, defensible choices: use AI deliberately, right-size the model, constrain the work, prefer credible lower-carbon infrastructure and treat any climate contribution as separate from the emissions you still create. That is the practical core of green AI.