FrostyTools AI text generation: a measured workload and its operational electricity cost

1   Findings

The gap is structural rather than incidental, and it is worth understanding rather than taking on trust. Streaming video pushes millions of pixels per second to hundreds of screens for hours on end, and roughly seven tenths of that electricity is spent on viewers’ own screens, with most of the remainder on the networks reaching them. Generating a few hundred words of text happens once, in a data centre, and then it is over. These are activities of a genuinely different order, and no accounting method brings them close together.

Across everything FrostyTools delivered in the window, the volume-weighted mean was 0.16 watt-hours per generation. Our two most-used features, chat recaps and channel summaries, are together more than half of everything we run by volume (yet only 17% of the electricity we use), and they cost about 0.05 watt-hours each: comparable to one conventional web search, and roughly one thirtieth of an AI-assisted one.

2   What a three-hour stream to 200 viewers costs

We start with the comparator, because it is the figure almost nobody has seen calculated. One broadcaster, three hours, 200 concurrent viewers. The accounting covers the streamer’s computer and GPU, capture hardware and displays, their router, live ingest and transcoding, origin and CDN servers, the core and access networks carrying the stream, every viewer’s home router, and every viewer’s screen.

3   What FrostyTools costs, feature by feature

We publish per feature rather than as a single number, because a single number would be wrong. Our shortest routine job and our longest differ by roughly a factor of thirty, and one feature sits far outside even that (§8 names it), so a single average would overstate the common case and understate the rare one. Each row also shows what share of our total AI electricity that feature accounts for, so the figures can be read in proportion to where the energy actually goes.

Each percentage is that feature’s share of our total AI electricity. We have not tabulated the underlying volumes, but we are not treating them as hidden either: combined with the platform total and the per-feature figures, they can be derived to within a few percent from what is printed here. These are generation counts, not user counts, and they do not convert into either: most of what we run is for people who pay nothing, and we do not publish the mix. A feature’s share of our electricity and its share of our usage are different quantities, and they diverge sharply: our two most-used features are among the smallest here. Shares are rounded and do not sum exactly to 100. These figures are also a point-in-time measurement of a system under active change, not a permanent state: the efficiency work named at the end of this paper is in progress, feature behaviour shifts as we tune it, and our total moves with usage in both directions. Energy figures include a measured rate of 1.035 attempts per delivered generation, so about 3.5% of the electricity above is spent on attempts that did not deliver, whether they were retried or the request was dropped. We count that against ourselves rather than reporting only successful work.

Total AI inference energy, all features

A per-generation figure with no total behind it is the disclosure pattern that has drawn the sharpest criticism directed at far larger companies: a small per-prompt number means little if the volume is withheld [19]. So here is ours. Across more than a million delivered generations in the window, all ten features combined:

Roughly two megawatt-hours a year at the measured rate. We also drop about 1% of requests without delivering anything, usually because no backend was available; that electricity is spent for no output and it is included in the totals above rather than netted out.

4   How we measured this

Most published AI energy figures are estimates applied from the outside. Ours are built on direct instrumentation of our own serving path, and it is worth being precise about which half of the calculation is measured and which is not.

Instead we apply a published watt-hours-per-token rate from peer-reviewed research to our measured token counts.

The rate comes from work by researchers at Microsoft, published in Joule, that models inference energy from token throughput and node power [7], corroborated by an independent academic measurement leaderboard that meters real hardware [14]. We deliberately calibrate against measurements of models larger than the compact tier that handles 98% of our work, which makes our figures an upper bound rather than a favourable estimate. And we carry two bounds rather than one, because the research offers two defensible treatments of how input context should be charged. Each of those coefficients also carries its own published uncertainty band. The ranges in §3 run from the decode-only bound at the bottom of its band to the effective-token bound at the top of its, so they cover both the treatment of context and the precision of the measurement behind it.

The two coefficients are these, and we publish them so anyone can reproduce every number in §3 from the token counts beside them:

Each feature’s central figure in §3 is the midpoint of the first two, multiplied by its own measured retry rate. Those retry rates differ sharply by feature, and publishing them is part of the accounting: our least reliable feature needs 1.70 attempts for every quiz it delivers, while our two highest-volume features need 1.01.

Showstarter records no token counts, one of two open gaps in our instrumentation, and §10 commits to closing it. Its share of our electricity is estimated from its peers, but we claim no per-generation figure for it, on the same basis that we claim none for the quiz: where we cannot measure, we do not publish a central value. Note that we use means, not medians, throughout: the published anchors report medians of right-skewed distributions, and multiplying a median by twelve would understate a twelve-generation session. Our own means and medians sit within a percent of each other on the short features and diverge by 19% on the quiz, which is exactly where a skewed distribution would show up.

Two features carry a second, higher token count from our own per-feature tables, differing from the provider’s accounting by about twofold. We use the provider’s figures throughout. Had we used ours, the platform mean would be about 0.22 Wh rather than 0.16. We name it because it is the largest unresolved discrepancy in our instrumentation, and §10 commits to closing it.

How energy is allocated, and why the two sides differ. The published inference research measures data-centre energy and excludes the network and end-user devices [5][7], whereas the streaming figures in §2 are dominated by exactly those things. That is not an oversight. It follows from a choice we make deliberately, and it is worth stating outright.

The boundary has two halves, and they use different conventions on purpose. At the edge we are incidental: a chat recap adds essentially nothing at a device that is already on, so we charge no endpoint or network term. Billing it a share of hardware that would be drawing power regardless would double-count energy the broadcast already owns. In the data centre we are allocated, not marginal. The published coefficient we apply is an allocated figure by construction: it carries a scaling factor for idle machine capacity and a data-centre overhead multiplier for cooling and power distribution, both of which would be drawing power whether or not any single generation happened. We are marginal at the edge and allocated in the data centre, and we say so because the two conventions do different work. The same reasoning applies to our own servers in the other direction: they carry much more than the AI, which is why §5 reports them whole and separately rather than carving out an invented AI slice.

The stream is charged on a full basis: every viewer’s screen, every router, the entire delivery path. For a primary activity, that is the correct treatment, because watching is the reason those devices are switched on at all. The same asymmetry applies to the search comparison, and in our favour: the AI-assisted search figure in this paper includes a network and device allowance while our own figures include none. The incidental-endpoint logic above applies to the reader’s own screen during a search too, so the gap is smaller than it looks, but it is there, and stripping that allowance out would move the search figure from 1.2–2.1 Wh to roughly 1.1–1.9 Wh.

Using two conventions on two sides of one comparison is a judgement, so the objection is stated here plainly: a critic can argue those televisions would have been on anyway, showing something else, in which case the stream’s truly marginal cost is below 49 kWh and every ratio here narrows. We think primary-versus-incidental is the right distinction and we have applied it consistently in both directions. A reader who rejects it now knows exactly which number moves.

5   The servers behind the AI

Every FrostyTools figure so far covers AI inference only, the model work itself. That is the right scope for the question people ask, but the inference does not run on nothing: it is requested, queued and delivered by our own servers. So here is that layer too.

FrostyTools runs more infrastructure than this section counts. What follows is the server layer behind the text generation measured in this paper: two instances, a 16-vCPU shared-tenancy application server and a dedicated-CPU database server with eight physical cores. Both carry far more than AI: overlays, dashboards, scheduling and the chat integrations run on them too. Treat this as that layer, not as a total for the company.

Adding these two servers to the inference gives a combined total of about 265 kWh a month, or roughly 3.2 MWh a year, on a plausible band of 235–310 kWh monthly. That is about five and a half three-hour broadcasts to 200 viewers, or nine days of one average household’s electricity, for the AI work and the two servers that carry it, serving every user on the platform. Other FrostyTools infrastructure is not in this figure.

We do not fold this into the per-generation figures, and the reason matters. Those two servers carry much more than the AI, and we have no defensible key for splitting them between AI and everything else they do. Rather than invent one, we report the infrastructure whole and separately. On the most unfavourable reading, charging every watt of these two instances to the AI features alone, a generation costs about 0.25 Wh rather than 0.16 Wh. That is the honest ceiling, and it changes none of the comparisons in this paper.

6   Everything on one scale

7   What a day of searching costs

Watt-hours are unfamiliar units, and 0.05 Wh means nothing without something ordinary beside it. Searching the web is the most ordinary digital thing there is, and it is worth knowing what it costs front to back, including the work an AI answer does before it ever appears.

A search with an AI answer is not one search. The operator documents that its AI features fan a single prompt out into multiple background searches [6], and the published measurements put that at 9 to 12 on average, with a maximum of 28 observed [18]. With the answer generation on top, one AI-assisted search comes to roughly 1.2–2.1 Wh, against 0.04–0.30 Wh for a plain keyword search. The full build-up, its wide band and the two costs nobody counts are set out with the sources at the back of this paper; the AI-assisted search figure is the least certain number here, and we mark it that way wherever it appears.

A per-search figure is still abstract, because almost nobody runs one search. So here is an ordinary day. The number of searches is a stated scenario, not a measurement, and another count can be substituted.

Seven watt-hours is about four full FrostyTools sessions, or roughly 140 chat recaps, spent before anyone has watched anything, opened a game or made a coffee. Three searches out of the twenty carry about three quarters of that day’s total, because of the fan-out behind each AI answer. Set against watching, it stays small: a whole day of searching is roughly a thirty-fifth of one viewer’s three hours of a stream.

8   Where we would push back on ourselves

Five qualifications sit behind the figures above, and we would rather state them than leave them to be found. A comparison that only ever favours the party publishing it is not evidence.

1. 1   Chat Pop Quiz costs far more than anything else we run

   To write a quiz it reads the recent chat backlog, which means about 111,000 tokens of input per generation, more than two hundred times what the published research assumes. Its energy lands between 0.2 and 25 watt-hours, and we claim no central value, because the research we rely on is calibrated only to 20,000 input tokens and its authors warn that costs rise sharply beyond that [7]. Every total in this paper nonetheless needs some value for it, so here is the one we use: the midpoint of our two bounds, about 8 Wh. We do not present that as a central estimate, because the band spans two orders of magnitude and the published method is calibrated to a fifth of this feature’s input length. It is under 1% of our volume, so it moves the platform average by about ±6%, but it is comfortably the most expensive thing FrostyTools does and we would rather name it than let it hide inside an average. It is also our clearest efficiency target.

2. 2   Three features generate ten times what a recap does

   Smart Scheduled Chat, Custom Celebrations and Reactive Responses each produce roughly 1,700–1,900 output tokens against a recap’s 111, and cost about ten times as much. In Reactive Responses, most of that output is reasoning the viewer never sees, and it is generated and paid for regardless. Together these are about a quarter of our volume. The favourable comparison against AI-assisted search does not describe them.

3. 3   Volume is what scales, not unit cost

   A sixth of a watt-hour is trivial on its own. It is not trivial when multiplied by a growing user base at a rising rate, and a per-generation figure is precisely the framing that hides that. This is why we publish our total AI inference energy in §3 rather than the per-generation number alone.

4. 4   A small number is not an environmental claim

   This paper measures watt-hours during use. It does not convert those watt-hours into carbon, and here is why. Our servers run in Oregon, on a grid dominated by Columbia River hydroelectric power. Our provider reports fully renewable supply at its European sites rather than its US ones, so we do not claim that for ourselves. We chose a US region for two reasons: latency for the streamers who use these tools, and cost, which we pass on in what we charge. A European region would carry a documented renewable supply, higher prices and worse performance. That is the trade-off, and it is ours to own. As we add capacity and regions, documented renewable supply is one of the criteria we weigh, alongside latency and what it costs the people who use this, and we will not pretend it has been the deciding one so far. Where a provider or a region can carry the same performance on a cleaner supply, that is where we would rather be.

   The larger share of the energy in this paper is not on our hardware at all. AI inference runs on a serving provider’s infrastructure in a region we neither choose nor see, so its grid mix is unknown to us, which means the carbon intensity of the smaller half of our footprint can be stated and the bigger one cannot. Publishing a total would mean inventing the dominant term, so we have not. This paper also excludes water, the manufacture of every device involved, and the energy used to train the models. We also make no claim that using FrostyTools displaces energy anywhere else. If a generation is additive, meaning work that would not otherwise have happened, then the honest comparison is against zero, not against a stream, and every ratio in this paper stops being the relevant one.

5. 5   Energy is not a cost structure

   These figures are an energy accounting, not a cost structure, and the two do not track each other. The most expensive thing we run is free to use. The two features we run most are among the cheapest. Nothing here should be read as what any part of this product costs to provide or what it earns.

9   In everyday terms

This section gives the same quantities as household uses, on the arithmetic that watt-hours equal watts times hours. Every row shows the wattage it assumes, because appliance draw varies by model and setting. The ladder runs from the smallest thing we do to the largest thing a streaming year costs.

The table below gives the same quantities with every assumption exposed.

These conversions are for scale, not appliance audits, and should not be quoted without the assumption attached. Colour coding follows Figure 4: unshaded rows are FrostyTools; shaded rows are everyday household uses and the streaming side. The final row is a summary and carries both sides at annual scale.

10   What we are doing next

Five commitments follow from what this measurement exercise exposed, and we would rather list them here than be asked for them. None of them is finished. Measuring this is now part of how the product gets built, which is what makes the list a working one rather than a statement of intent.

Close the missing token counts. One feature, about 2% of our volume, does not yet record token counts. Its share in §3 is estimated from its peers and we claim no per-generation figure for it at all. That is a one-line fix and it should not have been outstanding when this paper was written.

Reconcile the two token sources. Two features carry counts from our own tables that differ from the provider’s by about twofold, and we cannot yet say which is right. Until they agree, the platform mean carries an unresolved band of 0.16 to 0.22 Wh. It is the largest open question in our instrumentation and it is the next one we close.

Log every attempt on every feature. Our 3.5% failover overhead is measured on the features that record every attempt and inferred for the rest, which makes it a floor rather than an exact figure. We would rather report a number we can stand behind completely.

Replace the modelled server figures. The infrastructure wattages in §5 rest on a full-node power estimate we cannot verify from inside shared-tenancy hosting. They are the weakest part of this account, and the first thing we would replace with a measurement if per-instance draw became available.

Reduce the quiz. It is comfortably the most energy-intensive feature we run, and the largest single efficiency opportunity in the product. Work on it is in progress.

About FrostyTools

Most Twitch chatbots moderate chat, run timers and answer commands. FrostyTools writes the chat itself. It exists to fight the uncertainty, disconnect and creative block that every streamer runs into, and every feature below is named for the problem a streamer described. The brief on all of them is the same: notice people, do not stand in for the streamer. At a TwitchCon 2024 panel on the ethical use of AI in streaming, FrostyTools was cited as an example of doing it well.

§3 measures these under their internal names: Warm Welcomes as Warm Welcome, Full-Scope Shout-Outs as Channel Summaries, Tailored Raid Messages as Tailored Raid, Chat Recaps and Trivia as Chat Recap, Chat Quiz as Chat Pop Quiz, and Smart Scheduled Messages as Smart Scheduled Chat. Vibe Raider is a retrieval feature rather than text generation and is not among the ten measured here.

Over 20 personality presets ship with the bot, among them Viking, Pirate and Film Noir Detective. A streamer can also write their own voice, in their own language, with their own channel emotes. Setup is Twitch OAuth and takes under a minute. No tech skills, nothing to download, nothing running on the streaming PC.

The core Twitch chatbot is free. A paid tier unlocks further features and is what pays for the AI measured in this paper. Chat Quiz is free to add.

What this paper does not cover. FrostyTools also makes Highlight Hunter, which turns VODs into memorable clips in minutes rather than hours of scrubbing; Shortify, which cuts them into short-form video; and plug-and-play browser-source overlays for BRB and Starting Soon screens. None of them is measured here. Analysing video is a different and substantially larger kind of work than generating text, and folding it into these figures would misstate both.

What we will and will not claim. The social and ecological weight of this work matters to us, and we build under real trade-offs. We choose server regions for latency and for cost, which we pass on to the streamers who pay for this, and the grid that comes with those regions is not the cleanest one we could pick. The larger share of the energy in this paper runs on infrastructure whose grid mix we cannot see at all. So we will not claim a carbon benefit we cannot show. What we will claim is this: we measured our own AI energy instead of estimating it, published the total rather than only the per-generation figure, and named the feature that costs far more than the rest. Work to reduce it is under way. Documented renewable supply is one of the criteria we weigh as we add regions, alongside latency and cost, and it has not been the deciding one so far. That is what responsibility looks like to us: measuring honestly, fixing what the measurement exposes, and naming the trade-offs we made.

The product, the pricing and the full feature list are at frostytools.com.

Sources and method notes

1. [1] G. Kamiya, International Energy Agency, “The carbon footprint of streaming video: fact-checking the headlines,” 2020. Source of the 0.077 kWh per viewer-hour intensity and the 72 / 23 / 5 split. Drawn from 2019 on-demand viewing; the IEA notes efficiency has improved since. iea.org
2. [2] ITU-R Report BT.2521-0, “Practical examples of actions to realize energy-aware broadcasting,” 2023. About 18 W for end-to-end delivery; under 1 W for data centres and CDN at 5 Mbit/s HD; under 3 W for a smartphone to about 100 W for a television. itu.int
3. [3] Google Cloud, “Overview of the Live Stream API” — cited for how live adaptive-bitrate transcoding works. docs.cloud.google.com
4. [4] U. Hölzle, Google Official Blog, “Powering a Google search,” January 2009. 0.3 Wh per search, stated as including prior work such as building the index. The only first-party per-search figure ever published. googleblog.blogspot.com
5. [5] Google Cloud, “Measuring the environmental impact of AI inference,” August 2025, and its technical paper. 0.24 Wh for a median assistant text prompt; excludes external and data-centre networking, end-user devices, training and storage. cloud.google.com  ·  arXiv:2508.15734
6. [6] Google Search Central, “AI Features and Your Website.” Confirms AI answers may issue multiple background searches; publishes no count. developers.google.com
7. [7] F. Oviedo, F. Kazhamiaka, E. Choukse, A. Kim, A. Luers, M. Nakagawa, R. Bianchini and J. M. Lavista Ferres (Microsoft), “Energy use of AI inference, efficiency pathways, and test-time scaling,” Joule, April 2026. The energy model this paper applies, its per-model measurements, and its stated calibration limits. doi.org/10.1016/j.joule.2026.102430  ·  preprint arXiv:2509.20241
8. [8] NVIDIA, “GeForce RTX 4070 Ti” product specification, 2023 — the rated-power anchor for the streaming-setup allowance. nvidia.com
9. [9] US Department of Energy, Federal Energy Management Program, “Purchasing Energy-Efficient Light Bulbs.” Frames the traditional 60 W incandescent bulb by its 800-lumen output, for which it lists 5.9–10.5 W LED replacements. energy.gov
10. [10] Virginia Cooperative Extension, “Estimating Appliance and Home Electronic Energy Use,” 2020. pubs.ext.vt.edu
11. [11] ENERGY STAR, Certified Refrigerators product finder. energystar.gov
12. [12] ENERGY STAR, “Clothes Dryers Key Product Criteria.” energystar.gov
13. [13] The Shift Project, “Did The Shift Project really overestimate the carbon footprint of online video?” 2020 — disputes the IEA revision in [1], from the opposite direction. Included because the streaming anchor is contested. theshiftproject.org
14. [14] ML.ENERGY Leaderboard v3.0 — 46 models over 7 tasks, metered on real accelerator hardware. Independent corroboration of the small-model energy band. ml.energy
15. [15] “Estimating the Increase in Emissions caused by AI-augmented Search,” arXiv:2407.16894. The efficiency-scaled 0.042 Wh conventional-search figure. arXiv:2407.16894
16. [16] Google 2026 Environmental Report — data-centre electricity above 42 TWh in 2025, used with [17] as a top-down cross-check on per-search energy. blog.google
17. [17] Google internal data reported January 2025 — more than 5 trillion searches a year. searchengineland.com
18. [18] Query fan-out measurements. Seer Interactive (501 prompts, Gemini 3 API): 10.7 average, minimum 3, maximum 28. Nectiv (60,000+ captured fan-outs): 9.06 average, maximum 28. Google I/O 2025 material: 12 to 15 average, complex queries past 20. Independent studies converge on 8 to 12. Adopted here: 9 to 12, with an outer band of 5 to 20. Chiefly third-party measurement. The operator has published no per-answer count, and the I/O material is descriptive rather than a disclosure. searchenginejournal.com
19. [19] C. Crownhart, MIT Technology Review, “Google’s still not giving us the full picture on AI energy use,” 28 August 2025 — the criticism that a per-prompt figure without total volume is not a disclosure. technologyreview.com
20. [20] Open Compute Project, “Sustainability Metrics Considerations — PUE.” Reports a global average data-centre PUE of 1.55 for 2022, the figure our provider’s published 1.13 is measured against. opencompute.org