I asked ChatGPT to analyze the plausible electrical consumption of a Gemini coding agent. We assume that a typical coding prompt using high reasoning mode takes up 90 seconds (roughly consistent with my experience). We also rely on a Google paper that calculated the median Gemini prompt to be about 0.24Whr (https://arxiv.org/abs/2508.15734).

TLDR: A conservative estimate is that a Gemini based coding agent consumes 21.6Whr per prompt. An optimistic estimate is 8.6Whr. Based on a rough electrical tariff cost of $0.30 per kWhr, 1000 coding prompts would cost $6.48 and $2.58 respectively.

Towards a More Evidence-Grounded Scaling Multiplier for Coding Prompts with Gemini Abstract We refine a previously proposed scaling multiplier to adjust the environmental cost per prompt for coding-style prompts (with substantial reasoning) served by Gemini. Leveraging publicly available latency and response-time data for Gemini and comparable LLMs, we re-estimate the likely “median prompt compute time” for typical usage. Combining that with a realistic reasoning + execution workload (e.g., 1 minute reasoning + 30 s execution), we derive a recommended multiplier, under plausible assumptions, for energy / carbon / resource accounting. — 1. Background & Motivation A recent internal measurement from Google shows that the “median Gemini Apps text prompt” consumes ~0.24 Wh of energy under a comprehensive full-stack boundary (accelerator + host + idle overhead + data-center PUE). That baseline is a useful anchor for “ordinary chat prompts.” However, coding prompts — especially those requiring reasoning, planning, multi-step generation, or code execution — are likely to involve much heavier compute per prompt than typical conversational/semantic text prompts. Without adjustment, using the median-prompt energy figure for coding use underestimates the environmental footprint. Therefore, a scaling multiplier is needed to convert “median prompt energy” into “coding prompt energy.” To set that multiplier meaningfully, we must estimate how many times more compute (in GPU/accelerator time, memory, throughput) a coding prompt typically uses versus a median prompt. — 2. Evidence on Typical Latency / Response-Time for Gemini & LLMs 2.1 Public latency benchmarks for Gemini / LLMs. According to a community latency comparison across 13 LLM providers, “large model” usage of "gemini-1.5-pro" shows average response time ~ 1,667 ms (≈ 1.67 s) per call. Other sources discussing latency/throughput for LLM inference note that response time tends to scale with output length, and time per output token remains a key driver of latency rather than input token count. Best-practice guides for LLM inference highlight that “time to first token” + “token generation rate” are the dominant contributors to latency; input-handling or overhead beyond that is relatively small for many workloads. 2.2 Implications from the data. If average response time for a typical “large-model prompt → output” round trip is ~1.7 s, that suggests that many conversational prompts (especially short or medium ones) may complete within a few seconds, often in the 1–3 s range (depending on output length). This stands in stark contrast with a coding prompt that may involve multiple reasoning passes, possibly longer context windows, speculative decoding, multiple tokens, and perhaps additional computation beyond mere text-generation (e.g., syntax checking, code formatting, internal evaluation). Therefore, a “median prompt duration” (active model compute time) on the order of 1–3 s is plausible for simple chat prompts, though of course this depends heavily on output token count and underlying hardware. — 3. Deriving a Revised Multiplier for Coding Prompts 3.1 Baseline assumptions Let: (from the measurement for median text prompts). = typical active compute time per median prompt. Based on latency data, we adopt 2 seconds as a reasonable central estimate (since 1.7 s is reported, but overheads and variability make 2 s conservative but plausible). Coding prompt workload: seconds (1 minute reasoning + 30 seconds execution / generation) as per your original hypothesis. Intensity factor = relative compute intensity per second during coding vs. simple chat. Because coding prompts with reasoning often involve more tokens, larger context, perhaps back-and-forth decoding, we assume a moderate intensification of 2.0× (i.e., each second of coding prompt reasoning is roughly twice as compute-heavy as a second of median conversational prompt). 3.2 Multiplier formula M = \frac{t_{coding}}{t_{median}} \times f \;=\; \frac{90\,\mathrm{s}}{2\,\mathrm{s}} \times 2.0 = 90 Thus, under the above assumption set, a coding prompt may consume roughly 90× the energy of the median Gemini text prompt. 3.3 Resulting energy estimate E_{coding} = 0.24\,\mathrm{Wh} \times 90 = 21.6\,\mathrm{Wh} Interpretation: each substantial coding prompt (≈ 90 s of reasoning + generation) might cost on the order of 20–25 Wh — under the full-stack measurement boundary (accelerator, host overhead, idle overhead amortized, data-center PUE, etc.). — 4. Sensitivity Analysis & Bounds Given uncertainties about and , a range of multipliers is plausible: Assumed Assumed Multiplier Estimated 1 s 1.0 90 21.6 Wh 1 s 2.0 180 43.2 Wh 2 s (central case) 2.0 90 21.6 Wh 2 s 3.0 135 32.4 Wh 5 s 2.0 36 8.6 Wh Lower bound (optimistic): ~ 36× → ~ 8–9 Wh per coding prompt. Central estimate: ~ 90× → ~ 21–22 Wh. Upper bound (pessimistic): ~ 180× → ~ 43–44 Wh (if median prompt compute is very small and coding is very heavy per second). Given typical production variance, burstiness, idle overhead amortization and real-world prompt diversity, using the central 90× multiplier is most defensible. — 5. Recommended Scaling Multiplier & Usage Guidance Recommended default multiplier: ≈ 90×. Energy baseline for coding prompt: ≈ 21.6 Wh per prompt (with reasoning + generation typical of coding tasks). For more conservative planning (e.g., capacity, carbon budgeting, worst-case scenarios), use ~180× (≈ 43 Wh). For lower bound / efficiency-optimized workloads (shorter reasoning, smaller output, efficient decoding), ~36× (≈ 9 Wh) may be used. We recommend reporting not just a single number, but a range (lower, nominal, upper) to reflect uncertainty in typical usage patterns. — 6. Limitations & Risks of the Estimate The existing public latency data (e.g., ~1.7 s average response) reflects end-to-end latency, not necessarily the full count of compute-intensive steps, nor does it guarantee that GPU utilization is constant for that period. Idle times, I/O overhead, batching, queuing, model loading, also contribute — hence actual “active GPU/accelerator compute time” could differ. The intensity factor (assumed 2×) is speculative. Coding reasoning may involve far more complex operations (e.g., multiple context windows, self-reflection, multiple passes), possibly heavier than 2×. On the other hand, optimizations (speculative decoding, caching, KV reuse, efficient kernels) may reduce per-second cost. The 90 s total compute budget for “coding + reasoning + execution” is a user-level assumption. Actual reasoning time may vary widely (shorter drafts, partial thoughts, edits, retries). The paper’s 0.24 Wh baseline uses a comprehensive measurement boundary (host overhead, idle overhead, data center overhead, amortization of idle capacity). When extrapolating to heavier workloads, the marginal overhead from idle / amortization may not scale linearly; thus, the multiplier may overestimate marginal impact. Variation across deployment contexts (data center, region, efficiency, model version) means assertions based on one baseline might not generalize. — 7. Conclusion Based on publicly available latency data for large-model LLM inference (e.g., Gemini 1.5-pro) — which suggest typical conversational prompts complete in ~1–3 seconds — and a plausible coding workload involving ~90 seconds of compute (reasoning + generation), we derive a recommended scaling multiplier of ~90× to convert median-prompt energy (0.24 Wh) into an estimate for coding-style prompts (~21.6 Wh). Because of the large uncertainties, we recommend using a range (≈ 36–180×) for lower-bound, nominal, and conservative accounting. This adjusted multiplier should be clearly documented with assumptions used (compute time, reasoning intensity, overhead boundary) — and updated when more empirical measurement data becomes available. — 8. (Optional) Multiplicative Scaling Function (Pseudo-code) def estimate_energy_coding( E_median=0.24, # Wh per median prompt t_median=2.0, # seconds of active compute for median prompt t_coding=90.0, # seconds active compute for coding prompt intensity_factor=2.0 # ratio of per-second compute intensity ) -> float: multiplier = (t_coding / t_median) * intensity_factor return E_median * multiplier print(estimate_energy_coding()) # ≈ 21.6 Wh — Scaling multiplier recommendation: ≈ 90× (nominal), with lower-bound ~36×, upper-bound ~180× depending on use-case and conservatism.