What happens when you send an AI message?

When you send an AI message, the service transmits it to a data centre, formats the conversation, converts the text into tokens and routes the request to a model. The model processes the input, predicts an output token and repeats that prediction until the answer is complete. The service streams those tokens back to your screen.

Electricity is used across that chain: network equipment, CPUs, memory and accelerators do work, while cooling and power systems support the facility. A short text answer may involve one model call. Search, uploaded files, reasoning modes, images or agents can trigger several systems. That is why “one message” is not a fixed unit of energy, carbon or water.

The app prepares and sends the request

Pressing send creates a network request containing your new message and whatever context the service decides to include. That may be the recent conversation, system instructions, model settings and references to files or tools. Good services encrypt the connection, authenticate the session and apply size or safety checks before model processing.

The text travels through local networking, internet infrastructure and the provider’s edge or application servers. For a normal chat, the data-centre computation usually dominates the operational estimate, but the network is not literally impact-free. Exact allocation is difficult because infrastructure is shared.

Privacy is separate from energy. An efficient assistant can still have unsuitable retention or training terms. Do not paste sensitive personal, school or company information unless the service and your policy allow it. A student’s guide to AI environmental impact covers that wider judgement for classroom use.

Security screening may add processing too, although providers rarely allocate it to individual answers.

Text becomes model-readable tokens

Language models do not receive sentences exactly as people see them. A tokenizer maps text into numbered pieces called tokens. A token may be a word, part of a word, punctuation or a special control marker. The service also applies a chat template that distinguishes system, user and assistant turns.

Hugging Face’s tokenizer documentation shows how formatted chat messages become input IDs and attention masks ready for a model. Different models can tokenise the same sentence differently, so word count is only a rough proxy for computational input.

Long chat history, pasted documents and retrieved web pages add tokens. Providers may truncate, summarise or cache some context, but their behaviour is not always public. Clear, relevant input reduces unnecessary processing and can improve the answer at the same time. It is more useful than obsessing over whether a polite word adds one token.

A router chooses what runs

Some services send every request to one model. Others route by complexity, subscription, latency, language, safety policy or requested feature. A simple question may go to a small model; difficult reasoning may go to a larger one. Search and file analysis can add retrieval systems before generation begins.

Tool-using assistants may run a loop: ask the model what to do, call search or code, return the tool result to the model and generate or check an answer. The interface can present this whole workflow as one message even though several backend jobs occurred.

This hidden variation makes brand-only comparisons weak. Choosing an AI assistant by energy use recommends checking whether providers disclose model routing, optional tools and the boundary around their figures. Without that information, a per-message average is a signpost rather than a measurement of your particular request.

The router’s decision can matter more than a few extra words in the prompt.

The model processes the prompt

Inference begins with a prefill phase. The model processes the input tokens, performing matrix operations across its layers and creating intermediate attention data that can be reused during generation. A longer prompt generally increases this initial work and the memory required for its context.

The Transformer architecture uses attention to relate tokens in a sequence, as introduced in the research paper Attention Is All You Need. Modern chat models add many engineering refinements, but large numerical operations and movement of model data through memory remain central.

Accelerators such as GPUs or TPUs perform these operations in parallel. Host CPUs, RAM and high-speed interconnects coordinate the workload. Providers may batch several users together to improve utilisation. That can lower energy per answer, although it may add waiting time and makes simple “chip power multiplied by seconds” calculations incomplete.

Software kernels and numerical precision also affect how much useful work the same hardware completes.

The answer is generated and streamed

After prefill, the model produces output autoregressively: it calculates probabilities for the next token, selects one according to its decoding rules, adds it to the context and repeats. Google researchers describe the basic constraint clearly: generating multiple output tokens normally requires serial model runs, even though techniques such as speculative decoding can accelerate the process.

This is why output length matters. “Give me three bullets” and “write a detailed report” request different amounts of generation. Reasoning systems may also create internal tokens that are not displayed, while image and video generation use different processes again.

The server can send each completed piece back as it appears, creating the typing effect. Streaming makes the interface feel fast but does not mean the full answer was computed in advance. Generation stops when the model emits an end marker, reaches a limit, a tool interrupts it or the user cancels.

The facility supports the computation

Servers turn electricity into computation and heat. Fans, pumps, chillers or cooling towers remove that heat. Power conversion, uninterruptible supplies, networking and lighting add facility overhead. Power usage effectiveness expresses total data-centre energy divided by IT energy, but it does not measure model quality, carbon or water.

Operational carbon depends on the electricity supplying the site. Water may be consumed directly by cooling and indirectly by power generation. Hardware manufacture and building construction add impacts outside most per-message estimates. A complete life-cycle allocation is much harder than estimating operational inference.

The response may also be logged, cached or stored in chat history according to the service’s settings. Those actions use infrastructure, but providers rarely expose enough information to assign them precisely to one answer. Honest accounting states what it excludes instead of hiding uncertainty behind decimals.

Retention settings can therefore matter for privacy even when their energy effect cannot be isolated.

What the message receipt can and cannot say

A useful receipt can record the model, input and output tokens and whether a larger system was used. It can then apply an energy estimate and a disclosed data-centre overhead. This creates a consistent comparison within the service, even when no power meter is attached to the individual response.

Treechat follows that approach. Its methodology describes a model-based operational estimate using model and token information, stated PUE and an average grid carbon factor. The water result is derived from estimated energy. It is not a facility reading and does not include every life-cycle impact.

For more common questions about those boundaries, see the AI environmental impact FAQ. The practical lesson is straightforward: one click can start a chain of work. Use the simplest tool and smallest capable model, keep context relevant, request the output you need and treat any per-message figure as an estimate with a named boundary.